Definition: Evolutionary acquisition is an acquisition strategy structured to deliver capability in increments, recognizing, up front, the need for future capability improvements. The objective is to balance needs and available capability with resources, and to put capability into the hands of the user quickly. The success of the strategy depends on phased definition of capability needs and system requirements, and the maturation of technologies that lead to disciplined development and production of systems that provide increasing capability over time .
Keywords: acquisition strategy, capability increments, evolutionary acquisition, operationally useful
MITRE SE Roles & Expectations: MITRE systems engineers (SEs) are expected to understand the principles of evolutionary acquisition as it applies to the programs they support. They are expected to evaluate the intended purpose of a proposed acquisition, advise the program manager on the use of an evolutionary acquisition strategy compared to other strategies, and implement that strategy for program planning and execution.
An acquisition strategy is a high-level business and technical management approach that is designed to achieve program objectives within specified resource constraints. It is the framework for planning, organizing, staffing, controlling, and leading a program. It provides a master schedule for research, development, test, production, fielding, and other activities essential for program success. It also provides a master schedule for formulating functional strategies and plans. A primary goal in developing an acquisition strategy is to minimize the time and cost of satisfying an identified, validated need. This goal is consistent with common sense, sound business practices, and the basic policies established by sponsors.
An evolutionary approach delivers capability in increments, recognizing, up front, the need for future capability improvements. The objective is to balance needs and available capability with resources, and to put capability into the hands of the user quickly. The success of the strategy depends on consistent and continuous definition of requirements, and the maturation of technologies that lead to disciplined development and production of systems that provide increasing capability toward a materiel concept .
Evolutionary acquisition is a method intended to reduce cycle time and speed the delivery of advanced capability to users. The approach is designed to develop and field mature technologies for hardware and software in manageable pieces. It is focused on providing the operational user with an initial capability that may be less than the full requirement as a trade-off for speed, agility, and affordability. Evolutionary acquisition also allows insertion of new technologies (when they become sufficiently matured) and capabilities over time. In principle, the approach provides the best means of quickly providing advanced technologies to the users while providing the flexibility to improve that capability over time.
There are two approaches to evolutionary acquisition. In the first, the ultimate functionality is defined at the beginning of the program, with the content of each deployable increment determined by the maturation of key technologies. In the second, the ultimate functionality cannot be defined at the beginning of the program, and each increment of capability is defined by the maturation of the technologies matched with the evolving user needs.
Best Practices and Lessons Learned
Architecture is key: This is the most important lesson of this article. To effectively implement evolutionary acquisition, the architecture of the system or capability must be developed first. Employ use-case and similar methodologies to define an "operational architecture" or business process model. Once the operations of the system are understood, a notional system architecture can be generated. The architecture will need to support an evolutionary methodology and should form the basis of the program plan. The first delivered increment should include the target system architecture from which subsequent increments can build. Modeling and simulation may be used to validate architecture assumptions and information flow.
Manage stakeholder expectations and yours, too: Managing expectations ranks high in importance. Whether you define the ultimate functionality up-front (not recommended for commercial off-the-self [COTS]-based Information Technology [IT] systems) or by increment, realistic expectations within the program office and community stakeholders are a must for success. Expect change and expect cost growth. Do not believe you can define the content of all the increments accurately in advance. Change will happen and you need to be prepared. Do not confuse this with “requirements creep;” recognize it as a normal part of the evolutionary process. For more information on managing stakeholder expectations, see the Stakeholder Assessment and Management article under the Transformation Planning and Organizational Change topic in this guide.
Understand the operational users' context: Along with managing stakeholder expectations, close coordination and communication with stakeholders is important. User requirements should drive the content and priority of increments, as long as the users understand the end state of the program. This should to be balanced with effective contract execution. Understand the intended mission and operations of the system being acquired; systems engineering in an operational vacuum is not effective. Get acquainted with the operations and the users. Recognize that they have different priorities and a different perspective from a program office. Program offices plan and execute a program; users conduct a mission. It is acceptable to have differing opinions at times. Make sure those differences are handled by open communication leading to positive resolutions.
No technology before its time: Manage technology, instead of technology managing you. The principle behind evolution is to take advantage of emerging technology when it is mature. Stay abreast of new products that can contribute to mission effectiveness, and incorporate routine methods for tracking new technology (e.g., via the annual cycles in the Department of Defense [DoD] for government research laboratories Advanced Technology Demonstrations and Small Business Innovative Research programs). Be aware that new technology sometimes can bring new operational capabilities not previously considered. For example, users see a new toy, and instead of asking for the functionality, they ask for the toy. They see a capability in this toy that you are not aware of and they cannot articulate. Establishing a good working relationship with the stakeholders and users can help you bring out the capability inherent in the toy. This can help mitigate the churn often seen in COTS-based IT systems. Use evolutionary acquisition to your advantage (refer to the articles on Assessing Technical Maturity and Technology Planning within this section of the guide). As long as a useful capability is delivered within a short period (approximately 12-18 months), the users will be respond in kind.
Think "parallel developments:" Often in an evolutionary model, development of increments must occur in parallel to deliver capability on time. Increments may vary in time to develop and integrate. If done serially, they can extend the program schedule and adversely impact the ability to deliver capability to the users in a timely manner, which was the purpose of evolutionary acquisition. Managing parallel development is challenging but not unachievable; it should not be avoided. Make use of configuration management to control the development baselines and track changes. Allow time in the increment development schedules for the reintegration of a “gold” baseline for final incorporation of parallel changes prior to test and fielding. For more information, refer to the Configuration Management topic within this guide.
The right contract type: Carefully consider the contract type for an evolutionary acquisition. As evidenced by these lessons learned, changes are frequent and should be part of the plan. Time-and-materials, cost-reimbursement, product-driven payments, or awards can allow for flexibility without severe cost implications. Focus should be on delivery of a useful product, not processes. Indefinite Delivery/Indefinite Quantity style contracts should be considered, but need to be structured so that each delivery order is not treated as an independent entity from the total program (this was seen on a DoD program and was quite painful, since delivery orders can be interdependent and cause critical path analysis and integrated master schedule obscuration if not managed and reported as a single program).
References & Resources
- Department of Defense, December 2, 2008, Defense Acquisition Guidebook, "" DoD Instruction Number 5000.02.
Additional References & Resources
Boehm, B., July 2000, , Spiral Development Workshop, February 9, 2000, CMU/SEI-2000-SR-008.
Dobbins, J., M. Kelley, and P. Sherlock, October 2009, "DoD Acquisition Assurance for IT Systems."
Hansen, W.J. et al., July 2000, , A Report on the CSE-SEI Workshop, February 2000, CMU/SEI-2000-SR-006.
Hansen, W.J. et al., May 2001, The SEI-CSE Workshop, September 2000, CMU/SEI-2001-SR-005.
Onomi Social Bookmarks tagged with "Evolutionary Acquisition, viewed January 8, 2010.