Skip to content

Leveraging Systems Engineering in Project Management

To enhance the success of projects, it is vital to understand the importance of successfully identifying and managing product requirements.  This paper explores the use of Systems Engineers to improve your project success through better requirements handling; thus, reducing scope creep and unwanted surprises.  It also explores the complementary aspects of these two distinct functions and how Project Managers can achieve success through the use of professional Systems Engineers.


Background

Before delving into the subject matter of integrating the critical disciplines of Project Management and Systems Engineering, let’s first examine the key differentiators of the two fields, where they come together.  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 product requirements against which success completion is measured.   A product must be developed meeting all the customer requirements for the product, while simultaneously meeting the project requirements.   Please keep in mind that Systems Engineering is a discipline based on requirements and all considerations pertaining to them.  
When it comes to product requirements, Project Managers have a different focus than Systems Engineers.  The Systems Engineer is primarily focused on ensuring that the identified product requirements are written in such a manner that they can be verified and validated.  Verified meaning that the product requirements are met as documented, while validation is the equally important aspect of meeting the end users original intent.  Contractually speaking, a customer may be required to procure a product that is of little or no use to them, 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 lab, but not work properly in its intended environment – attached to a patient in a hospital or clinic.  This is the Systems Engineer’s area of expertise and interaction with the customer.  The Project Manager’s focus is on the time, cost, and resources required to meet the requirements of both the product and entire project (or, program).  Working together, the Project Manager and the Lead Systems Engineer ensure   the customer is satisfied with the project product, which often also requires input from a Quality Engineer, to maximize customer and sponsor satisfaction and repeat business.
Leveraging Complementary Disciplines
As discussed above, Project Management and Systems Engineering are complementary disciplines, with great benefit from leveraging each other’s strengths in a teamwork environment.   Figure 1, created by the author, provides a detailed visual illustration regarding how the two disciplines complement each other, and their unique roles and responsibilities. 
 
While it is not necessary to involve the Systems Engineer in the Initiating Phase of the project to create the Project Charter and Identify Stakeholders, it is often wise to involve an experienced Systems Engineer during the Planning Phase, as they provide great value in collecting customer product requirements, defining the product scope, and generating the Work Breakdown Structure (WBS).  Systems Engineers poses a wide breadth of technical discipline knowledge, allowing technical concerns to be addressed, as well as serving as a point of contact between the project manager and the technical community; bringing in the right expertise as needed to ensure thorough planning of project activities.  

A Systems Engineer, who is adapt at programmatics, is often a great resource for the 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 on a systems engineer 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 Lead Systems Engineer may perform these functions at the Program and Portfolio levels as well.  And, since systems engineers are astute technical risk analysts, they often play a key role in developing the Risk Management Plan and supporting documentation, and contribute greatly to make-buy decisions.  They also free-up the PM to focus on programmatic risks, such as supplier, schedule, and cost risks.  And, may assist in Monte Carlo schedule risk analysis, which is critical to successful project execution.  Working together, 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. 
Steven R. Meier (Project Management Journal, Vol. 39, No. 1, 59–71) noted the following cost drivers in his study of large scale acquisition programs:

 

       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

It must be noted that technology readiness levels (TRLs) and corporate technology roadmaps are the domain of the systems engineer, as are requirements analysis and technical baseline management.  Inadequate Systems Engineering speaks for itself.  Experience has shown that requirements instability to be a major, if not the primary, cause of scope creep on both small projects and large, complex programs.  Since 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 a good idea 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 lifecycle (e.g., late in the Execution Phase or during Closeout) will negatively affect 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 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.  The SE may also help ground the PM in the technical maturity of the various technical elements of the project work packages; thus minimizing the propensity to over-sell the project to senior management and the sponsor.  By creating a realistic project baseline and identifying obstacles early, with accompanying recommendations for dispositioning, leads to greater confidence from executives and sponsors.  The SE may also help the PM 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 an overarching view depicted in Figure 2.  Generally, Cost and Schedule are closely linked, as are Scope and Performance, with Quality being an independent attribute.  The key to successful management of a project is prioritization of the three constraints.  Several high profile government programs have far exceeded their initial cost and schedule constraints, while simultaneously falling short on capability (technical performance).  The reason for this was the strict adherence to the initial cost, schedule, and capability requirements on programs that were initiated with immature technology readiness levels.  Incorporating Systems Engineering during the Request for Proposal and Proposal Bid processes is a tactic to reduce this negative risk (threat), and potentially leverage some positive risk (opportunity).  For example, 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 architectures.   In this case, the priority ranking is:  1. Cost; 2. Schedule; and 3. Capability.  Knowing this, the SE 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.  One the other hand, if there is no prioritization of the trade space and cost, schedule, and capability are all held as fixed, one may overrun the cost and schedule baselines chasing system requirements that may not need to be absolute.  To fully take advantage of the Triple-Constraint tool, the PM and SE need to work closely together to define the parameter importance towards meeting the project goals.  While the PM makes the final decision, the SE provides critical input to the PM, and is utilized frequently as an advisor to the PM on technical matters and their impact on project parameters.
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.  They 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 PM, who has matured in the Systems Engineering function before transitioning into the role of PM.  Highly experienced systems engineers tend to be well versed in programmatics, and often migrate into project management as a way to maintain the challenge and grow professionally.  Many technical issues can be solved with the addition of additional time and money.  It is in the context of highly constrained resources that problem solving takes on true complexity and challenge.  For the PM to put forth a case for additional resources (time, people, money, or materials) to senior management and the customer, an accurate, complete, and concise definition of the issue and recommendations for rectifying it must be very compelling; requiring an in-depth understanding of the technical issues and how their interdependencies on the programmatics is characterized.  This requires leveraging the benefits of both Project Management and Systems Engineering into a cohesive systems approach to planning and execution.
“Leveraging Systems Engineering in Project Management” is an editorial bringing to light the importance of integrating Systems Engineering best practices in New Product Development Projects.  The paper was inspired by the story of one of my students in a course I teach entitle “Systems Engineering for Project Managers” for The University of California at Irvine.  He told a story about a breakdown in the requirements verification and validation process that nearly killed his young start-up company, pioneering a new catheter product.  Even though the product met all requirements, the medical community convinced the FDA to recall it due to not meeting doctors intended operating parameters.