Systems engineering the project
Before exploring the idea of using systems engineering in project management, let's first examine the key differentiators of the two functions as well as where they intersect. First, it is essential to understand that a program or project is based on requirements. There must be a business, market, or regulatory requirement for the product of the project or program, as well as performance requirements against which successful completion is measured (verified). A product must be developed to meet all the customer requirements for the product, while simultaneously meeting the project requirements and end-user needs. It is important to note that the customer and end user may be different parties when one organization procures a product or system for another organization.
Please keep in mind, that systems engineering is a discipline based on requirements and all considerations pertaining to analyzing and managing them. When it comes to product requirements, project managers have a different focus than systems engineers because of the nature of their job. The systems engineer is primarily focused on ensuring that the identified product requirements are documented and written in such a manner that they can be verified (built the product right) and validated (built the right product). Verification ensures the product requirements are met as documented, whereas validation is the equally important aspect of meeting the end user's original intent.
Contractually speaking, a customer may be required to procure a product that, in the end, is of little or no use to them even if it meets all product requirements specified in the contract. For example, a medical product such as a catheter may meet all customer requirements specified in the contract, as measured on the test bench in the vendor's laboratory, but not work properly in its intended environment — attached to a patient in a hospital or clinic. This is the systems engineer's domain of expertise. The project manager is responsible for project outcomes as well as the time, cost, and resources required to meet the requirements of both the product development and entire project (or program). Working together, the project manager and the systems engineer ensure the customer is satisfied with the project product by focusing on the business case, the funding, and the technical product aspects of the project, ensuring that the business case and product architecture solutions are adequate, achievable, and verifiable.
The Systems Approach to Requirements
As presented above, project management and systems engineering are complementary functions, with great benefit from leveraging each other's strengths in a team environment. Figure 1 provides a detailed visual illustrating how the two disciplines complement each other and their roles and responsibilities on different aspects of the project. While the project manager manages the project life cycle, the systems engineer manages the technical baseline of the product under development. The project manager and systems engineer share requirements management responsibility, and by working closely together they keep the project on track.
The systems engineering team is focused on product requirements and should be empowered to handle them autonomously, involving the project manager when a technical requirement has project requirement impacts. An empowered systems engineering team allows the project manager to remain focused on the over-arching programmatic issues. Needless to say, there are interfaces between the project and product requirements that must be managed. For example, technical problems will most likely have an impact on the project cost and schedule.
The systems engineer must keep the project manager informed regarding technical requirements risks that have the potential to affect the project risk profile. If a key supplier is having difficulty maturing technical aspects of the design, it may pose a risk to the project and should be recorded in the risk register as a cost, schedule, and supplier risk to the project — three project risks created by one technical observation by engineering. It is also important to keep in mind that the systems engineer does not formally report every requirement evolution to the project manager, but must be ready to answer any questions the project manager has, and keep him or her informed of significant issues. A relationship of trust is critical to executing this process. A project manager must trust that the systems engineering team will be forthcoming with important information that the project manager will require in the decision-making process, as well as general trends and requirements risk status. The project manager depends on the systems engineering team to provide key information in a timely manner, but the systems engineer does not over-burden the project manager with unnecessary information that might distract him or her from key responsibilities in managing the project. It is a symbiotic relationship.
Figure 1: Project management and systems engineering inter-relationship.
While it is not required to involve the systems engineer in the Initiating Phase of the project to create the Project Charter and Identify Stakeholders, it is wise to do so. However, during the Planning Phase, a seasoned systems engineer provides great value in collecting customer product needs, defining the product scope, and generating the work breakdown structure (WBS), as well as deriving product requirements that are verifiable. Systems engineers possess a wide breadth of technical discipline knowledge, which allows technical concerns to be addressed as well as serving as a point of contact between the project manager and the technical community. The systems engineer ensures the right expertise is brought in as needed to ensure thorough planning of project activities. For example, while the project manager is collecting the sponsors’ technical, cost, and schedule requirements, the systems engineer is evaluating the technical feasibility by determining the technology readiness level (TRL) of the available technology and assisting the project manager in development of the business case.
A systems engineer adept at programmatics is often a great resource for a non-technical project manager needing deep technical concerns translated into a cost-to-benefit business case for proper consideration in decision making. For example, a project manager having inadequate resources to address all product risks (threats to minimize and opportunities to maximize) may call systems engineering to consult with the technical subject matter experts, evaluate the technical data, and provide a business case for each risk as well as a complete Pareto analysis chart summarizing the top project risks.
The systems engineer may perform these functions at the program and portfolio levels as well, as part of the total life cycle cost analysis and life cycle model management. This is often referred to as Systems Thinking or the Systems Approach as it pertains to an interdisciplinary approach examining the system as a whole. And, because systems engineers are experienced technical risk analysts, they often play a key role in developing the risk management plan and supporting documentation — contributing greatly to make–buy decisions. They also free up the project manager to focus on programmatic risks, such as supplier, schedule, and cost risks. They may also assist in Monte Carlo schedule risk analysis, which is critical to successful project execution due to the hidden pitfalls of the critical path method as pointed out by David T. Hulett in his paper, Schedule Risk Analysis Simplified.
The project manager and systems engineer can generate a comprehensive systems approach to project and product planning by thinking in terms of interdependencies and interconnectedness of project and product attributes, as well as defining pre-planned product improvement objectives and goals. The International Council on Systems Engineering (INCOSE) Systems Engineering Handbook (version 3.2.2, pages 17–18) provides the results of a research study conducted by the INCOSE Systems Engineering Center of Excellence (SECOE) on the value of Systems Engineering. It cites increased cost and schedule predictability at 12% SE effort, resulting in 0.80 – 1.41 x planned cost and 0.78 – 1.22 x planned schedule.
“Systems engineers orchestrate the development of a solution from requirements determination through operations and system retirement by assuring that domain experts are properly involved, that all advantageous opportunities are pursued, and that all significant risks are identified and mitigated. The systems engineer works closely with the project manager in tailoring the generic life cycle, including key decision gates, to meet the needs of their specific project.” — INCOSE SE Handbook, p. 21
Steven R. Meier (Project Management Journal, 39(1), 59–71) noted the following cost drivers in his study of large scale acquisition programs in his paper entitled, “Best Project Management and Systems Engineering Practices in the Preacquisition Phase for Federal Intelligence and Defense Agencies:”
- Overzealous Advocacy
- Immature Technology
- Lack of Corporate Technology Roadmaps
- Requirements Instability
- Ineffective Acquisition Strategy
- Unrealistic Program Baselines
- Inadequate Systems Engineering
- Inexperienced Workforce and High Turnover
While this study was conducted among U.S. government agencies, its applicability is easily translated to the commercial project management sector. Technology readiness levels (TRLs) and corporate technology roadmaps are the domains of the systems engineer, as are requirements analysis and technical baseline management. Inadequate systems engineering during the Planning Phase of the project is a common root cause of inadequate cost and schedule projections and vendor-supplier integration. The systems engineer is critical to the project make-buy decisions, because he or she is critical to performing the technical analysis required to assure that the project manager is making an informed decision based on the best available data, noting that the project manager must often make decisions based on incomplete data due to schedule and budget constraints imposed by the project stakeholders; hence, the common phraseology, “The 80% solution.”
Lessons learned experience has shown that requirements instability is a major, if not primary, root cause of scope creep on both small projects and large, programs that are complex because each time a product requirement is altered, it affects the technical baseline and likely the project baseline as well. A product requirement change will often have cost, schedule, and risk exposure concerns that must be addressed. It is always beneficial to perform a cost, schedule, and technical impact analysis on any proposed change and brief the project sponsor on the study outcome, before committing to an engineering and/or contract change proposal. Any captured risks that are affected, or new or secondary risks that are created, must be noted in the risk registry. For example, if the technical complexity is increased, this will pose a direct risk to the cost and schedule baselines. Also, requirement changes made late in the project life cycle (e.g., late in the Execution Phase or during Closeout) will negatively impact the cost and schedule risk. The systems engineer is a great resource in aiding the project manager in tying the project baseline to the product (technical) baseline by helping to determine the links in the technical baseline that drive the project baseline. Controlling the product (technical) baseline is often the key to minimizing scope creep.
Requirements are often interdependent, some by design and some by other factors. Say, for example, marketing wants to change the graphical user interface (GUI). Changing the color scheme to make it flashier and eye catching might be great for marketing, but what if the new color scheme does not meet government requirements for accessibility to the disabled and visually impaired. The GUI development team has just updated the user interface by request of the marketing department and all appears to be well with the world until that moment, many months later, when the product fails to complete verification or government certification. Now, the team must go back and redesign again, late in the development cycle, causing great adverse effects on the project schedule and cost.
Requirements often arise in conflict, and usually in greater complexity than noted above. The requirement that a car door be easy to open, for example, is in direct conflict with the requirement for isolating road noise and preventing rain penetration into the cabin. In order to determine the amount of door force required to open the door, a systems engineer must perform a trade study between the competing requirements to determine the best design solution. The same is true for the GUI example given earlier, because changing a single requirement often has implications reaching well beyond the obvious. This is especially true as systems become more complex. The better the communication between disciplines, and system level perspective applied, the less likely you will be to develop a wireless device that can't communicate over the network when the antenna is covered by the user's finger.
The systems engineer may also help ground the project manager in the technical maturity of the various technical elements of the project work packages, thus minimizing the propensity to oversell the project to senior management and the sponsor. Creating a realistic project baseline and identifying obstacles early, with accompanying recommendations for dispositioning, leads to greater confidence from executives and sponsors. The systems engineer may also help the project manager to prioritize the triple constraint, as shown in Figure 2, to preserve the required trade space for successful project execution.
The triple constraint is a powerful tool for managing project resources. It may take several forms, with a generic non-tailored view as depicted in Figure 2. Generally, cost and schedule are closely linked, as are scope and performance, with quality being an independent variable. The key to successful management of a project is the prioritization of the three constraints during project initiation as part of creating the project charter. Having the triple constraint defined during project initiation provides the project manager and systems engineer with a clear trade space upon which to perform trade studies, decision analysis, and actively manage project priorities.
Several high-profile programs have far exceeded their initial cost and schedule constraints, while simultaneously falling short on capability (technical performance). The root cause is often the strict adherence to the initial cost, schedule, and capability requirements on products that were initiated with immature technology readiness levels. Incorporating systems engineering during the request for proposal (RFP) and proposal bid processes is a systematic approach to reduce this negative risk (threat) and potentially leverage some positive risk (opportunity). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (Project Management Institute) defines risk as an uncertain event or condition that, if it occurs, has a positive or negative effect on a project's objectives with an opportunity being a condition or situation favorable to the project and a threat being a condition or situation that is unfavorable to the project.
Figure 2: Trade space triple constraint.
If one knows that cost is inflexible and schedule is tight but there is some flexibility in capability, trade space is preserved for the systems engineer to perform trade studies on potential product system architectures. In this case, the priority ranking is: (1) cost; (2) schedule; and (3) capability. Knowing this, the systems engineer will hold cost as fixed and perform trade studies on the various technology architectures that allow the program or project to best meet its requirements. The systems engineer can use trade study methodology tools such as Cost As an Independent Variable (CAIV, pronounced ‘cave’) or Schedule As an Independent Variable (SAIV, pronounced ‘save’) to develop solutions to product requirements without violating project requirements.
On the other hand, if there is no prioritization of the trade space and cost, schedule, and capability/performance are all held as fixed, one may overrun the cost and schedule baselines chasing system requirements that may not be achievable. The project manager is the final decision authority, because he or she is ultimately accountable for project execution; however, the systems engineer provides critical input to the project manager and is frequently called upon to advise the project manager on technical matters and their impact on project parameters. A systems engineer, or if resources permit, a systems engineering and integration team (SEIT) serve as the custodian of the technical requirements with a focus on overseeing the product (technical) aspect of the project, thus freeing the project manager to focus on project requirements such as funding, business case, schedule, supplier, market environment, and organizational environmental factors. While the project manager leads the initial stakeholder meetings, the systems engineer must be present to understand the systematic issues of the project, especially when technical matters are to be discussed.
Once a working relationship with the stakeholders is established, it is often productive to create a technical requirements working group as a means of requirements communication between the stakeholders and the project team. This group is led by the SEIT lead, with status reporting requirements to the project manager. It is the duty of the SEIT lead to ensure the project manager is made aware of any issues affecting project execution. An effective systems engineer does not allow the project manager to be blindsided by technical issues or risks that have the potential to affect the project.
Wrapping It Up
When the time comes to engineer the front end of the project, during the Planning Phase, a seasoned systems engineer is a critical member of the project leadership team. System engineers are essential in identifying technical risks, managing and deriving requirements, aligning the technical baseline with the project baseline, deriving the system architecture framework, and translating technical issues into actionable business cases that the project manager can use to make critical business decisions. Experienced systems engineers often serve as the project manager's technical advisor.
On technically complex programs, it is advantageous to appoint a project manager who has a strong technical background; however, partnering with a systems engineer regardless of the technical background of the project manager often adds value to the technical project.
Many technical issues can be solved with the addition of time and money. It is in the context of highly constrained resources that problem solving takes on the programmatic complexity and challenge requiring the systems management approach to product development. For the project manager to put forth a case for additional resources (time, people, money, or materials) to executive management and the customer, an accurate, complete, and concise definition of the issues and recommendations for rectifying them must be very compelling, which necessitates an in-depth understanding of the technical issues and how their interdependencies on the programmatics are characterized. This requires leveraging the benefits of both project management and systems engineering into a cohesive systems approach to planning and execution.
Systems engineers may be vetted similarly to project managers via professional certification. Many job requisition postings for project managers set a baseline requirement of Project Management Professional (PMP)® certification by PMI. Systems engineers may also be baselined by the professional certification entitled CSEP (Certified Systems Engineering Professional), awarded by INCOSE (International Council on Systems Engineering). The certification process is similar to that of the (PMP)® credential, requiring minimum experience verification to be authorized to sit for the professional exam, with the added requirement of professional endorsement submissions from established systems engineering professionals attesting to one's systems engineering domain performance and ability. Once a CSEP reaches 20 years of systems engineering domain experience, he or she is eligible to apply for a panel review to become an ESEP (Expert Systems Engineering Professional). The CSEP also requires continuous learning as part of the continuing certification requirements, similar to those required for PMP certification. Keep in mind that certification alone does not provide an adequate enough picture in itself for hiring purposes. Experience and past performance must still be considered when hiring, as one would do for hiring a PMP credentialed project manager.
Hulett, D. T. (1996). Schedule risk analysis simplified. PM Network, 10(7), 25–32.
International Council on Systems Engineering (INCOSE) (2011). Systems engineering handbook, Version 3.2.2.
Meier, S.R. (2008). Best project management and systems engineering practices in the preacquisition phase for federal intelligence and defense agencies. Project Management Journal, 39(1), 59–71.
Project Management Institute (2012). A guide to the project management body of knowledge (PMBOK® guide) – Fifth edition. Newtown Square, PA: Author. ANSI/PMI 08-001-2012.
About the Author
Dennis Van Gemert, PMP, CSEP has 18 years of experience in project management, systems engineering, design engineering and analysis, and procurement. He holds master's degrees in project management and aerospace engineering, and is an Associate Fellow of the American Institute of Aeronautics and Astronautics (AIAA). He is a project management instructor at The University of California at Irvine University Extension and a senior systems engineer with Stellar Solutions, Inc.
Special thanks to editorial reviewers Betsy Pimentel, VP Defense Programs, and David Frostman (Maj Gen USAF Ret), VP Strategic Initiatives, at Stellar Solutions, Inc.
PMI Virtual Library | www.PMI.org | © 2013 Dennis Van Gemert