Implementing and Improving Systems Engineering Processes for the Acquisition Organization


Definition: A process is a set of steps to accomplish a defined purpose or produce a defined product or service. The state-of-the-art technical aspects of systems development and management have evolved over the past few decades from basic concepts, practices, techniques, and tools borrowed from other domains into a sophisticated, structured engineering discipline called "systems engineering." Experience shows that supporting disciplined program and project management with rigorously applied systems engineering is a steadfast approach to successfully defining and managing the development and fielding of complex technology-based products and services. The most effective way to implement this strategy is by integrating project management and systems engineering into a seamless set of processes, plans, work products, reviews, and control events that are documented and continuously improved in an orderly, controlled manner, based on experience and lessons-learned.

Keywords: Capability Maturity Model Integration (CMMI), continuous process improvement, process, process improvement, process model, Standard CMMI Appraisal Method for Process Improvement (SCAMPI) appraisal, systems engineering processes

MITRE SE Roles & Expectations: MITRE systems engineers (SEs) are expected to support the implementation and continuous improvement of core and shared systems engineering processes. They develop process implementation plans, including process improvement goals, schedules, and estimated resources, and they identify the need for, and often assist in, conducting process maturity assessments [1].

The MITRE systems engineer's role can vary from that of a trusted advisor providing guidance to the government on critical government and contractor work products, processes, methods, and tools to direct involvement in the development of strategies, plans, technical specifications, statements of work, methods, tools, and commercial off-the-shelf product evaluations and recommendations, coaching, training, and decision support. The MITRE systems engineer should assume a degree of ownership for the effectiveness of the systems development process. The MITRE systems engineer should assist the government in achieving organizational performance goals, provide constructive feedback to development contractors in collaboration with the government, and help assure the quality, integrity, and appropriateness of MITRE's products and services.

Background

Government agencies typically obtain software-intensive systems, hardware, facilities, and operational support by issuing contracts for services from commercial contractors. The government calls this approach "systems acquisition." The government's role is to define what it wants to acquire, how it will acquire it, and how to plan and manage the effort on behalf of its end-user organizations and operators. If commercial bidders hope to be awarded a contract, they must demonstrate prior experience and success with the products and services sought by the government as well as exhibit the required management, technical, and support services skills.

The government also has realized that it must have the capability to perform its role effectively and work in partnership with the selected contractor; the government sets the tone for the partnership. What the acquisition organization does is just as important as what the system development contractor does. An immature, demanding, dysfunctional acquisition management organization can render ineffective the practices and potential of a mature, high-performing contractor. When one or both parties perform inadequately, the entire development process is impaired. Planning and documenting what each party will do, how each will do it, and when each will do it is essential to success. Each party needs to keep activities and work products up to date and synchronized. Plans and methods need to be refined as more is learned about the nature and challenges inherent in the system or capability being built and its intended operating environment.

Systems Engineering Process Improvement

Systems engineering processes are documented in a variety of sources, including the International Council on Systems Engineering TP-2003-002-03.1 Systems Engineering Handbook, Institute of Electrical and Electronics Engineers (IEEE) Std. 15288-2008 Systems and Software Engineering—System Life Cycle Processes, and American National Standards Institute (ANSI)/Energy Information Administration (EIA)-632-1999 Processes for Engineering a System.

Most of these references cite and implement project management, technical control, and systems engineering guidelines collected in the Carnegie Mellon Software Engineering Institute's CMMI for Development, Version 1.2, 2007. The CMMI is organized by various categories: Process Areas, Maturity Levels, and formats. Refer to the Process Areas in the "Engineering" category, primarily in Maturity Level 3 of the "staged" version of the model.

Carnegie Mellon University's IDEAL model (Initiating, Diagnosing, Establishing, Acting, and Learning) is a widely used method for project management and systems engineering process improvement. This model serves as a roadmap for initiating, planning, and implementing improvement initiatives or projects. Process improvement professionals can apply it with the CMMI and the SCAMPI. Note that the IDEAL model is a variation on Deming's "Plan, Do, Check Act" cycle, which is discussed in the "Continuous Process Improvement" topic article [2].

Depending on the need, several other prominent process improvement methods are available. Examples include the International Standards Organization (ISO) 9000 Series, the Information Technology Infrastructure Library, and the ISO/International Electro-technical Commission 15504 standard, also known as the Software Process Improvement and Capability Determination method.

Some government agencies have adopted "best practice" process models (e.g., Carnegie Mellon Software Engineering Institute's CMMI or various ANSI and IEEE standards) as guidelines for assessing a contractor's system development capability and performance. Some agencies have gone further. They acknowledge that by adopting versions of these recognized frameworks and guidelines tailored to their respective roles and responsibilities, they can contribute more to reducing the risks that are inherent in complex systems development and deployment. In this type of operating environment, the MITRE systems engineer can assess system design and development plans, processes, and actual activities against the requirements of the process model being used. The MITRE systems engineer also can determine the level of compliance, identify gaps, and recommend remedial actions to the government and, indirectly, to development contractors.

Best Practices and Lessons Learned

  • Consider adopting a de facto measurement standard or benchmarking tool when your organization does not use a recognized process model. This best practice requires judgment. If you tailor a de facto model, recommend incremental changes or additions to current practice that are feasible without substantial impact on schedules and resources. Focus on recommendations that reduce specific acknowledged risks or contribute to resolving or preventing the recurrence of specific known issues. The process model should be used as a checklist and part of your knowledge base, rather than as a binding standard.
  • Base recommendations for process improvement on a recognized process improvement framework. A structured improvement is most effective when based on a recognized process framework and on proven organizational change management or organizational development methods guided by trained, experienced organizational change and process improvement professionals. See the Matching Systems Engineering Process Improvement Frameworks/Solutions with Customer Needs article for guidance on selecting an appropriate process model. Get help with the intricacies of organizational change management and process improvement if you or your team have not already demonstrated mastery of these methods and tools.

References & Resources

  1. The MITRE Institute, September 1, 2007, "MITRE Systems Engineering (SE) Competency Model, Version 1," pp. 48-49, accessed February 10, 2010.
  2. Deming, W. E., August 2000, Out of the Crisis, MIT Press, Cambridge, MA.

Additional References & Resources

Chrissis, M. B., M. Konrad, and S. Schrum, 2003, "CMMI: Guidelines for Process Integration and Product Improvement," Boston, MA: Pearson Education, Inc., Addison-Wesley.

Chrissis, M. B, M. Konrad, and S. Schrum, 2007, "CMMI, Second Edition, Guidelines for Process Integration and Product Improvement," The SEI Series in Software Engineering, Boston, MA: Pearson Education, Inc., Addison- Wesley.

McFeeley, R., February 1996, IDEAL: A Users Guide for Software Process Improvement Handbook, CMU/SEI-96-HB-001, Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University.

Shewhart, W. A., 1931, "Economic Control of Quality of Manufactured Product," New York: D. Van Nostrand Company.

Publications

Download the SEG

MITRE's Systems Engineering Guide

Download for EPUB
Download for Amazon Kindle
Download a PDF

Questions?
Contact the SEG Team