PMI Virtual Library © 2013 Dennis Van Gemert Systems Engineering the Project By Dennis Van Gemert, PMP, CSEP fore exploring the idea of ‘using systems ‘engineering in project management, lees first examine the key differentiators of the Please keep in rind, that systems engineering is a discipline based on requirements and alll considerations pertaining co 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 enginecr is primarily focused on ensuring that the identified product requirements are documented and. written in such a ‘manner that they 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 project success through better requirements handling, thus reducing scope creep and unwanted surprises. It ‘wo functions as well as where they intersect. First, itis essential to understand that a program or project is based on requirements. “There must be a business, market, oF 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 ect all the customer also explores the complementary aspects of systems engineering and project management functions and how project managers can achieve success through the use of professional systems engineers. requitements 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. 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 mecting 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 asa catheter ‘may meet all customer requirements specified in the contract, as measured on the test bench in the vendor’ laboratory, but rnot work properly in its intended environment — attached to patient in a hospital or clinic. ‘This is the systems enginecr's domain of expertise. "The project manager is responsible for project outcomes as well as the time, cost, and resources requited 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 | provides a detailed visual illustrating how the two disciplines complement each other and their roles and Project Management responsibilities on different aspects of the project. While the project manager manages the project life cycle, the systems engineer manages the technical baseline ofthe product under development. The project manager and systems engineer share requitements 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 con the project cost and schedule The systems engincer must keep the project manager informed regarding technical requirements risks that have the potential to affect the project risk profile. Ifa key supplier is having difficulty macuting technical aspects of the design, it ay pose a rsk to the project and should be recorded in the sisk register asa cost, schedule, and supplier risk to the projece — three project risks created by one technical observation by engineering. Icis also important co keep in mind thatthe systems engineer does not formally report every requirement Systems Engineering Dx\vanemest=2006 2013) Figure I: Project management and systems engineering inter-relationship. PMI Virtual Library | www.PMIorg | © 2013 Dennis Van Gemert 2evolution co 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 tust 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 docs not over-burden the project manager with unnecessary information that might distract him or her from key responsibilities in managing the project. It is symbiotic relationship, While ic is not required co involve the systems engineer in the Initiating Phase of the project to create the Project Charter and Identify Stakeholders, itis 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 produce 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 a8 a point of contact between the project manager and the technical community. The systems engineer ensues 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 ease for proper consideration in decision making, For example, a project manager having inadequate resources co 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 cota life cycle cost analysis and life eycle model management. This is often referred to as Systems Thinking or the Systems Approach as it pertains to an interdiseiplinary approach examining PMI Virtual Library | www.PMl.org 3 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 tisk analysis, ‘which is critical to successful project execution due to the hidden pitfalls of the eritical path method as pointed out by David T. Hulecc in his paper, Schedule Risk Analysis Simplified. “The project manager and systems engineer can generate a comprchensive 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, Te 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 thac 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 | © 2013 Dennis Van Gemert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 don of the systems engineer, as are requirements analysis and technical baseline management, Inadequate systems engineering during the Planning Phas o isa 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, i affects the technical baseline and likely the project baseline as well, A product requirement change will often have cost, schedule, and tisk exposure concerns that must be addressed. Itis 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 ‘enginecring and/or contract change proposal. Any captured risks that are affected, or new or secondary risks that are cexeated, 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 (eg. late in the Execution Phase or during Closeout) will negatively impact the cost and schedule risk. ‘The systems engineer isa great resource in aiding the project manager in tying the project baseline to the product (technical) baseline by helping to determine the links in che technical baseline that drive the project baseline Controlling the product (‘echnical) 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 lashier and eye catching might be ‘great for marketing, but what if the new color scheme does hot meet government requirements for accessibility to the disabled and visually impaired. ‘Ihe GUI development team. has just updated the user interface by request of the marketing department and all appears to be well with the world uncil the project 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, isin 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 she 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 witeless device that cant 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 ate closely inked, as ate seope and performance, with quality being an independent variable. ‘The key to successful management of a project isthe prioritization of che 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 shore on capability (technical performance). ‘Ihe root cause is often the strict adherence to the inital cost, schedule, and capability requirements on products that were initiated PMI Virtual Library | www.PMl.org | © 2013 Dennis Van Gemert 4DK Van Gemert - 2008 Scope / Performance Figure 2: Trade space triple constraint. with immature technology readiness levels. Incorporating systems engineering during the request for proposal (RFP) and proposal bid processes isa 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, ifit occurs, has a positive or negative effect on 4 project’ objectives with an opportunity being a condition or situation favorable to the project and a threat being a condition oF situation that is unfavorable to the project fone knows that cost is inflexible and schedule is tight but there is some flexibility in capability, erade space is preserved for the systems engineer to perform trade studies on potential product system architectures, In this «ase, 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 oF project co 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 (SAIY, pronounced ‘save) to develop solutions to product requi (On the other hand, if there is no prioritization of the ments without violating project requirements 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 isthe 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 enginect, 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 oon project requirements such as funding, business case, schedule, supplier, market environment, and organizational environmental factors. While the project manager leads the initial stakeholder mectings, 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, itis 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. Ic is che duty of the SEIT lead to ensure the project manager is made aware of any issues affecting project execution. An effective systems PMI Virtual Library | www.PMI.org | © 2013 Dennis Van Gemert 5engineer does not allow the project manager to be blindsided bby 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 ‘enginecr isa 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 asthe project managers technical advisor. On technically complex programs, itis 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| ‘ime 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, References Hulett, D. T: (1996). Schedule risk analysis simplified. PM Network, 10(7), 25-32. International Council on Systems Engineering (INCOSE) (2011). Systems engineering handbook, Nession 3.22. Meier, $.R. (2008). Best project management and systems engineering practices in the preaequisition phase for federal intelligence and defense agencies. Project Management Journal, 39(1), 59-71 Project Management Insticute (2012). A guide to the ‘Project management body of knowledge (PMBOR® guide) — Filth edition, Newtown Squae, PA: Author. ANSI/PMI 08- 001-2012. PMI Virtual Library |. www.PMIL RRNA Systems engineers may be vetted similarly to project, ‘managers via professional certification, Many job requisition postings for project managers set 1 baseline requirement of Project Management Professional (PMP)® certification by PMI. Systems engineers may also be basclined 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 o apply for a pane! review to become an ESEP (Expert Systems Engineering Professional). ‘The CSEP. also requites 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 hiting a PMP credentialed project manager. About the Author Dennis Van Gemert, PMP. CSEP has 18 yeas of experience in project management, systems engincering, design. engineering and analysis, and procurement, He holds master’s degrees in project management and acrospace engincering, and is an Associate Fellow of the American Institute of Acronautics and Astronautics (AIA). He is a project management instructor at The University of California at Irvine University Extension and a senior systems engineer with Stella Solutions, Inc Special thanks to edicorial reviewers Betsy Pimentel, VP Defense Programs, and David Frostman (Maj Gen USAF Ret), VP Strategic Initiatives, at Stellar Solutions, Inc. ‘org | © 2013 Dennis Van Gemert 6