Systems Engineering and Project Management Intersects and Confusion

Eileen  P.  Arnold   Independent   Eileen.Arnold@incose.org  
Copyright  ©  2012  by  Eileen  P.  Arnold.    Published  and  used  by  INCOSE  with  permission.

Abstract. Commonalities, differences, and confusion between the top level Systems Engineering, Systems Engineering Manager, and the Project/Program Manager views are explored based on the International Council on Systems Engineering (INCOSE) and Project Management Institute (PMI) process basis for Systems Engineering and Project Management certifications with an undercurrent of four initial factors that are observed to cause conflicts and confusion between the disciplines in the real world. The certification sources, the INCOSE Systems Engineering Handbook (SEHBK) which is aligned with ISO/IEC 15288, and the PMI Body of Knowledge (PMBoK), are the certification sources that guide Systems Engineers and Project Managers in their quest for credentials and on-the-job influence. These intersects are expected to work in concert, yet in real life, the interaction often results in mismatched expectations and confusion as to who has the responsibility for each process/knowledge area, in part due to mismatched certification bases. Recommendations are provided for initial alignment of the disciplines.

Introduction
Orientation. This paper, “Systems Engineering and Project Management Intersects and Confusion” proposes four observed factors that contribute to confusion with respect to the role/responsibility/accountability relationships among the systems engineering and project management functions. These factors are inter-woven into the main body of the paper; a comparison of the processes used for the certification bases. As more research is conducted and observations expressed, it is anticipated these factors will morph into a more worldly view with output resulting in a refined set of factors with broader application. Key word definitions are included, along with a list of project management artifacts used to illustrate ownership viewpoints. Lastly, a summary provides initial recommendations for alignment as a starting place for further elaboration and refinement. Introduction. Similarities between systems engineers (SEs), systems engineering managers (SEMs), and project managers (PMs) are not by accident. The desire for integrated project performance and effective organizational dynamics encourages the aggregation of multi-discipline efforts, initially carried out in parallel, with subsequent team interaction producing a theoretically integrated and agreed-to result. In reality, there is often discourse    

and confusion between SEs SEMs, and PMs with mismatched expectations. Many systems engineering handbooks and systems engineering books recognize management as a cornerstone of systems engineering, including the International Council on Systems Engineering (INCOSE) Systems Engineering Handbook (SEHBK) (Haskins 2010), the NASA Systems Engineering Handbook (NASA 1992) and Systems Engineering, Coping with Complexity (Arnold et al 1998, 152-168). Arnold et al has a chapter dedicated to SE and PM. With the acknowledgement of PM and SE interaction, it would seem the SE certification basis for INCOSE, the SEHBK, and the PM certification basis, the Project Management Institute (PMI) Project Management Body of Knowledge (PMBoK), would have integrated guidance for both in an ideal world. Although synergistic terminology is improving between the two certification bodies, the intersects have room for improvement and are currently being worked through a joint PMI/INCOSE PM-SE Alliance Working Group. A comparison of the two sources and their processes form the basis of this paper. The actual manifestation of the various role/responsibility/accountability relationships on a specific project varies, dependent on the context of the organization, its people, and its established practices. Efforts are expected to continue for future comparative studies to refine the terminologies, cross pollinating the knowledge areas and processes. Meanwhile, PMs, SEM’s, and SEs often struggle with their projects, due in part to: Factor #1: Cultural Differences – On-the-job reactions to the established or entrenched methodologies from differing project viewpoints derived from knowing different “truths” from differing past experiences. Differing project cultures may also include elements of generational differences or experience derived from other companies and their cultures. Sadly for some organizations, project management (and a few unaware “systems engineers” and “systems engineering managers”) believe the systems engineer’s role is simply to follow the systems engineering process with an emphasis on stakeholder elicitation and requirements development. Systems engineers may expect more of a role in the overall technical management than the organization’s SE process specifically defines due to previous knowledge that embraces SE cognitive skills such as big picture thinking. “Cognitive and Personality Characteristics of Successful Systems Engineers” (Frank 2000) is an excellent source of systems engineering characteristics beyond process knowledge. These differing project viewpoints, e.g. who has final authority over shared documents such as a Work Breakdown Structure, may cause conflicts, unless an understanding is reached and collaborated between the project leadership. Factor #2: Education Overlaps – Ownership confusion of perceived similar and differing process activities due to formal education overlaps and incongruities of SE and PM knowledge, including personnel certification-based knowledge, cause conflicting expectations and confusion. Those with formal training and certifications may have differing viewpoints from those that have only had on-the-job experience in addition to the discipline differences. The integration activity overlaps trigger conflicting expectations, in part due to definition confusion, and differing goals. Differing tool sets between the systems engineering world and the project management world add to the confusion (Sharon, Dori, and deWeck 2010). Factor #3: Objectives Expectations - Cost and schedule conflicts stimulate confusion. SEs are often expected to push the envelope of technological maturity beyond acceptable risk to cost and schedule. Engineers love to design, and redesign to perfection. PMs just want it done! PMs are expected to bring the project in on budget, on schedule, at an acceptable level of quality, delighting the customer. “Skirting the Pitfalls of Project Management/Project    

“Whilst there are obvious project management and contractual issues. deployment or maintenance phases or stages.“A collection of generally sequential project phases whose name and number are determined by the control needs of the organization or organizations involved in the project” (ANSI and PMI 2008. maintain. Without an understanding of overarching level of accountability. integrated master schedule (IMS) and the project management plan (PMP)? This author has observed the PMP commonly duplicates and conflicts with the systems engineering management plan (SEMP). e. 15). Before we compare the SEHBK and PMBoK process and knowledge areas. integrated master plan (IMP). elicitation of stakeholder needs. own. “The system life cycle is composed of a set of interacting system elements. Lewotsky states. Which role has final authority in your organization for the work breakdown structure (WBS). e. The cycle might include beginning.g. a project lifecycle is contained within one or more product life cycles” (ANSI and PMI 2008. The SEHBK does not have the definitions that are equivalent to the PMBoK in all cases. especially in those areas where the discipline activities intersect adds to the mix of discourse if role/responsibility/accountability expectations are not clear. Dawson (Dawson.” Factor #4: Ultimate Authority – Power struggles as to which discipline has the ultimate decision making authority. and end. System Life Cycle – “The evolution with time of a system-­‐of-­‐interest from conception through to retirement” (Haskins 2010). non-overlapping product phases whose name and number are determined by the manufacturing and control needs of the organization. 9). using processes for execution of these actions” (ISO/IEC 15288 2008). without undue risk to health or the environment” (IEEE Std 1220 2005).g. A. Generally. design or integration of components. A system progresses through its life cycle as the result of actions. there are also impacts on the engineering process”.Management Success” (Lewotsky 2006) provides insight into the project management view of the conflict. Project Life Cycle . developed in isolation from each other.g. The last product life cycle phase for a product is generally the product’s retirement. building a schedule that assumes everything will go without a hitch. Program – “A group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually” (ANSI and PMI 2008. middle. Supporting sources were also consulted. 18). each of which can be implemented to fulfill its respective specified requirements. “Novice program managers often make the error of being overly optimistic. 1999) recognizes that how projects are managed influence how the engineering processes are implemented. The system of interest is composed of multiple products. An integrated approach helps! Definitions. a few definitions are included for the context of this paper. conflicts with activity ownership exist in projects that haven’t come to an understanding of the role/responsibility/authority/accountability clarifications. “Engineering activities necessary to guide product development while ensuring that the product is properly designed to make it affordable to produce.     . Life Cycle Product Life Cycle – “A collection of generally sequential. performed and managed by people in organizations. e. and eventually to dispose of. operate.

systems engineering managers (SEM). Systems Engineering Handbook (SEHBK) – The INCOSE Systems Engineering basis for certification. mentioned above. This term will apply to those project managers. Both of these sources have been steadily improving their cross-discipline intersects and definitions. 5). Most of the tables in this paper follow these color-codes and layout. 6). with responsibility for delivering the system of interest. The role applies to any project or program personnel applying the knowledge. service or result” (ANSI and PMI 2008.     . which includes product and system oversight as a subset of the overarching responsibility. skills. This paper captures where we are today. skills. Project Management Body of Knowledge (PMBoK) – The PMI Project Management basis for certification. and engineering managers. and techniques to project activities to meet the project requirements. systems engineers that perform the role-specified activities regardless of their associated discipline. Comparisons of the top level processes/knowledge areas of the two illustrate a starting place for the confusion and overlaps resulting in the four Factors. Project Management – “The application of knowledge. although there are still opportunities for further refinement. supply chain. A project manager is the person accountable for accomplishing the stated project objectives. It applies to all disciplines such as finance. the SEHBK and the project management basis for certification. the PMBoK serve as the primary education sources for SE and PM credentials. SE and PM Process/Knowledge Area Intersects The systems engineering source for certification. and techniques to project activities to meet the project (not product) requirements” (ANSI and PMI 2008. based on a top level comparison of the two certification sources in anticipation of an improved understanding of where the certifying organizations and academic/industry organizations should head for the future. and accountability demanded of a project manager.The technical managers of systems engineering. Project Manager (PM) . dependent on the construct of the organizational structure (matrix/projectized/composite). authority. program managers. Systems Engineering Manager (SEM) . quality. tools. Table 1 illustrates an orientation view of the layout of the six SEHBK process areas and processes (left side) with the PMBoK knowledge areas and process activities across the top for comparison and colored coded in columns for the bolded nine areas. contracts. They may or may not be people managers. tools. The SEHBK process color-codes are inserted under the PMBoK process activities in rows where top level PM intersects are the most likely.Project – “A temporary endeavor undertaken to create a unique product. The term will also be inclusive of the term program manager for this paper.a person named to manage the complete project.

SE and PM activities and processes are not one-for-one. and end-item software/hardware/systems. The SEHBK identifies Life Cycle Model Management. the SE processes dove tail with the PM processes. nor should they be. augmenting activities.     . SE and PM Processes: Organizational Project Enabling Processes. In some cases. although necessary.Table 1: Orientation SEHBK Process Areas and PMBoK Activity Intersects Tables Attachment A illustrates a more complete comparison between the SEHBK and PMBoK process activities/knowledge areas. the disciplines are executing different. Table 2. all with intersects to the PMBoK project integration/quality/human resource management activities. In other cases. An understanding of when they should be collaborative and integrative could be clearer than they are today. These deliverables are expected to mature until an agreed to delivery date. documentation. as a key enabling process. A full system life cycle begins with a concept of what is needed in terms of deliverables which may include services.

the product or suite of products crafted into a system. and then monitors/controls the execution of the technical maturation. For example. 2. Mooz and Wilson further emphasize how unusual it is to find fully integrated project cycles that address both the business (PM) and technical aspects (SE) as an integrated process. There is generally recognition that at least two life cycles exist. a modified waterfall model for software or the systems engineering VEE model for systems. “Life cycles vary according to the nature.Table 2: SEHBK Organizational Project Enabling and PMBoK Integration/Quality/Resource Management Process Activity Intersects Project management initiates.     . use and prevailing circumstances of the system. This is usually done by defining life cycle stages and using decision gates to determine readiness to move from one stage to the next” (Haskins 2010. controlled process usually transition first to a project cycle and then to a gated project cycle to manage accomplishments (Mooz and Wilson 2003). one for project management and one for technical management. 21). project management may close the project. The system lifecycle is seen as an intersection of project management (the business case and funding) and the technical aspects. They are terminated by the customer. As products are being developed. Projects are closed out when 1. The project management knowledge areas and processes are progressively elaborated in concert (desirably) with the product processes. A decision is made based on the perception that the derived costs outweigh the expected benefits. 21)”. plans. Organizations may also require phase closures to define a more prominent gated progression. There are of course numerous other lifecycle models that could be imbedded. “The purpose in defining the system life cycle is to establish a framework for meeting the stakeholders’ needs in an orderly and efficient manner. purpose. systems engineering processes are iterated. “Organizations that successfully transition from ad-hoc work practices to a repeatable. At any point in the lifecycle. Life cycle phases provide organizations with a framework from which management has high-­‐level visibility and control of both the project and system. or 3. Each stage has a distinct purpose and contribution to the whole life cycle and is conserved when planning and executing the system life cycle (Blanchard 1998. They are completed.

Systems engineers focus on the integration of the system of products and contribute to the project charter. the best managers and systems engineers possess personal skills to impact and influence others as leaders. All team members are responsible for performing Integrated Change Control for technical changes that are driven by a contractual change. The project manager aspires to project success through satisfaction of measurable business criteria. (Factor #3: Objectives Expectations) but are typically held more accountable for technical aspects than the other two. possessing knowledge. and project management plan sections applicable to the technical management view with SEM oversight. perform the role of project management. experience in their disciplines and domains. and integrating within their technical sphere of influence. This causes conflict between the SE and the PM as the PM is typically more accountable (Factor #4: Ultimate Authority)  for cost and schedule. SEMs and PMs would be expected to be competent in project management. when planning and managing (monitoring and controlling) their system of interest. Quality management and human resource management are obvious intersects in Table 2. with project managers focused on the project management plan and contractual changes. engineering management plans. abilities. These contributions undergo further integration with other functions such as finance. The author has observed that the role of project management and the title of project manager have subtle differences that befuddle communication between SEMs and PMs and which are often indistinguishable in an organization’s processes. supply chain. In this case. skills. the SEM is planning. PMP (Baldwin 2010) PM competence includes: • • • Knowledge of Project Management Application of Project management Personal Competencies o Achievement and Action o Helping and Human Service o Impact and Influence o Managerial o Cognitive o Personal Effectiveness SE competency includes: • • • Understanding the processes Gaining input from specialized experts Defined as basically. and of course. the result aimed at managing the products or systems. to produce an integrated set of projects resulting in a project managed by a project manager. monitor and control project work and are responsible for closing out the project or phase’s technical aspects. with project managers performing the project integration and SEM performing the systems management throughout the life cycle. with PM oversight. Additionally. quality. a specialized “technical” project manager     . The SE is accountable for budget and schedule of their “project”. Technical managers perform project management roles in support of the over-arching project manager. For example. According to Clifton Baldwin. Both are actively engaged in change control. SEMs. managing. development (sometimes through deployment). The SEMs direct and manage project execution of the product definition.The SEMs are focused on technical changes.

risk management. I’m not sure why he thinks SE’s have no technical expertise. Understand how your project will operate and the ownership and collaboration responsibilities for all artifacts before the project begins. The details. technical coordination. Each artifact includes notations as to ownership. and customer interaction. although Systems Engineers are commonly asked to author them for the project whether for an internal     . and systems engineering as shown in Figure 1. or systems integration.Baldwin recognizes that SEs have overlapping skills with project managers. Factor #1  Cultural Differences! According to Peter Pao (Pao 2005) SEs: • • • • • See the big picture. SE and Project Planning and Control Intersects (Haskins 2010) To further illustrate the interaction. SEs must see the big picture from a technical perspective. Artifact infighting for ownership (Factor #4: Ultimate Authority). the focus of systems engineers and SEMs. As you read through the list. with a focus on delivering the right system on time at an acceptable cost without unintended consequences. Project management. Project Management requires more “managerial” skills but not management” (Baldwin 2010). PMs must see the big picture from an integrated project performance perspective. think about which roles have the responsibility and accountability in your organization. are shown as the intersects. “Systems engineering requires more “technical” skills but not technical expertise. For instance. drives inefficient and ineffective behavior resulting in duplication of effort and differing and often incompatible formats. Project managers (not project management) should not be focused on performing the technical work of system architecture. and SEMs must see the big picture from both perspectives. including SEMs are all focused on the project planning and control. Task definitions. strategically Have broad knowledge and experience Understand the tools and methods Are equipped with good communication and leadership skills Have strong domain knowledge The author maintains that these attributes are applicable to both disciplines. and focus are what set them apart. context. His experience must be from a different culture than this author knows. a composite list of recognized project management artifacts is listed below. which may or may not be the same in your environment. The SEHBK recognizes intersects between project planning and control. with SEMs focusing on the system technical management. and think system. Figure 1. • Project Charter – This is typically a PM-developed and owned document.

it is systems’ engineering that performs the vast majority of change administration in accordance with the plan. Requirements management plans are often included in the developed documentation.The WBS is progressed from the product breakdown into activities. Business case /Feasibility Study – The business case is a PM-owned artifact. Others identify separate registers for technical and business risks. These plans should be identified in the PMP. from an accountability standpoint. with oversight for feasibility studies early in the business winning/early phases of the lifecycle. Work Breakdown Structure (WBS) – The WBS. a best practice. If separate program and product projects exist. all are contributors. only using different terminology and slightly different methodologies. six-sigma. contracts for those items of contractual interest. or Systems Engineering. and WBS Dictionary can be owned. more than one may be in existence. etc) for an integrated project view. • • Project Management Plan (PMP) – An overarching (project and technical) project planning document that is typically owned by the PM. Risk and Opportunity Management Plan . although the Plan should encompass project and technical requirement management. especially if the WBS is product-based. Responsibility Assignment Matrix (RAM) . • Scope Statement / Statement of work – Overall scope is the responsibility of the PM. driving the methodology to be used on the project. Systems engineering is a major contributor. bid by individuals assigned to the responsibilities. with the PM owning the WBS and Systems Engineering providing the vast majority of input. trade-off analysis. for documentation and end item products and systems. and when. The WBS is tightly coupled with the RAM. the technical risks     . • • • Change Control Plan – Although the PM owns the Change Control Plan.The Risk and Opportunity Management Plan provides risk and opportunity oversight for the project manager. which work they will be performing. but is commonly managed by systems engineering for system-based development. In some cases. In reality. but should involve active participation by Systems Engineering for those items of technical interest. often part of the Charter. Feasibility of technical solutions are often included in the SE-associated artifact. • • Risk Register – Some organizations limit the Risk Register to technical risks. by the Finance Manager. The equivalent plan for the technical aspects is the Systems Engineering Management Plan/Systems Engineering Plan/Engineering Management Plan. primarily to manage the technical requirements. This is an area that should be agreed upon up front across all disciplines employing a common language if the organization’s processes are not clear. Both disciplines are trained in risk (and in some cases opportunity) management. and all of the support functions (lean. finance for those items of financial interest. supply chain for those items of procurement interest. requiring the PM to own who is assigned to the team. quality. although there is both project scope AND system scope.working group or for an external system. manufacturing for those items of production interest. PMs. The Statement of Work commonly calls out project-based requirements and references a separate system requirements set which together define the customer expectations of the scope. although not the only function involved.

systems engineering owns them. dependent on the functions or projects capturing the issues and actions. It will aid in smooth-flowing communication. not only for the project of interest. simplifying communication channels. It is critical that SE’s also communicate from a technical perspective.Learning from experience is a critical effort. just as the SE needs to be aware of both. is under the purview of the PM. especially across domains (software. but other critical path elements as well. at a lower level. • • Document Management – Configuration and Data Management if the documentation is a function of the PM because documentation transcends technical documentation. For systems engineering meetings. All actions in one place seems to make sense when a project is driven to ensure timely action item closure. although SEMs are often the negotiators for technical resources. Management of these items is most efficient and effective at the program level. PMs are expected to spend 90% of their time communicating (PMI). especially in a matrix organization. “Systems Engineers' Perceptions on the Adequacy of Project Management Methods for Systems Engineering Management” (Sharon. PMs also know this. Meeting Minutes – for project meetings. Future projects can benefit if the lessons are truly learned and integrated. • Resource Management Plan – The PM is indeed responsible for obtaining the best resources available for the project. Ideally. whether or not it is for the project or program. with contributions gathered from all functions applicable to the project. Stakeholder Analysis – Systems Engineers know this is one of the first steps in the process. the most difficult of any of the expectations to facilitate and execute. the actual hands-on creation and analysis of the schedule is performed by schedulers often a separate planning and control group. Mechanical. feed the master project schedule including the Integrated Master Schedule (IMS). although a subset of the total set of project documentation. • Communications Management Plan – The PM owns this management plan. It includes contracts documentation. not always assimilated into a common stakeholder list. although for large projects/programs. and deWeck 2010) explores the     • . • • Lessons learned . • Project Status Report – Project status is provided either via a project portfolio management tool with instant access by senior leadership or through briefings given by Systems Engineering to Project Management or by the Finance Organization to indicate business status or from the Project Managers to the Program Management team. financial documentation and other items. The PM needs to be aware of both. This is one of the most important plans if understood and followed. yet it is often a plan that is overlooked after capturing. the PM maintains the project/program list with input from Systems Engineering and other relevant functions. in one format. Dori. Electrical) and Financial (Design to Cost). Systems Engineers perform configuration management and data management of their documentation. with metrics in place to observe consistent issues across projects. which commonly results in two different lists. Technical schedules. An integrated plan seems to make sense. The intersect is not only the milestones. Project Schedule – The Master Schedule.bubble up to business risks. the PM owns them. • Issue Log/Action Item List – These documents are often created in multiple instances and even formats.

Environmental. the system and its influences determine the behavior of the system and its acceptance based on the timing of deployment. understanding the coordination of the multitudes of activities going on simultaneously. Economic. Table 3. (Gillespie 2003) cannot be determined or explained by its constituent parts. Subsets of the SEHBK Technical processes are applicable to project management activities. Over time. Social. Taking an interdisciplinary approach to engineering systems is inherently complicated (Sheard and Motishari 2010) since the behavior of and interaction among system components is not always immediately well-defined or understood. Contractual requirements and subsequent flow down and tracking are of course critical to the project. organizational structure. This may include architecting communication channels. Instead. yet another view into the two disciplines and potential sources of confusion. process usage. This is again true of project management. System-of-Systems (SoS). Table 3: SEHBK Technical Processes and PMBoK Project Integration/Scope Activity Intersects Architectural design not only applies to the system. Systems’ thinking is needed by PM’s and SE’s alike. Legal). SE and PM Processes: Technical. but would also apply to the organization and project set up if one stretched the definition. Projects can be seen as an organizing mechanism for getting work done. Systems. This author maintains this is also true of project management. Technical. All of the properties of a system (Public.differences and commonalities in systems engineering and project management tools. Finance tools may also complicate the ownership and operating confusion.g. the term “requirement” has enhanced the concept of “scope”. The ability to handle complexity is one of the reasons PMs are systems engineers prior to becoming PMs at some companies. and their constituent makeup are often too complex to manage in their     . The development of systems requires contributions from diverse technical disciplines in addition to the non-technical disciplines and functions. Systems are holistic by nature. or other such architectures. Requirements should be more than technical requirements. the PMBoK has aligned to more common definitions systems engineers would recognize e. Systems thinkers think in parallel.

Table 4 and Factor #3: Objectives Expectations. although not mentioned directly in the PMBoK. the intersects to the PMBoK Project Cost Management knowledge area. Although budget is not mentioned in the Specialty Engineering section of the SEHBK. or a combination of the above. and Cotterman 2005)”. SE and PM Process: Project Processes. SE trade-off studies help identify value sources. since almost every engineering endeavor has unknown land mines in the good-day-scenarios. Project Planning. service-based. The PMBoK’s Estimate and Control Costs sub-processes align with systems engineering team activities as input to the project. The SEHBK Training Needs Analysis intersects and aligns with the PMBoK expectations of Develop Human Resource Plan. SE and PM Processes: Specialty Engineering. Conversely. the processes identified in the SEHBK and PMBoK have obvious similarities for a few of the processes.     . comparing possibilities. Upon further inspection at depth. one realizes the meanings may not be quite the same. since there is varying degrees of process decomposition with differing words and life cycle timing used at more detailed levels between the two disciplines. Architecting systems into their constituent parts. The technical community identifies what is needed to improve individual’s skills with the PM and human resources identifying additional training. The integration management of the PMBoK is intended to be project coordination. another confusing source of terms. the requirements must be achievable within the budget and schedule (Forsberg. Mooz. whether product/subsystem-based. or other sources of knowledge. Table 4: SEHBK Specialty Engineering and PMBoK Project Cost/Human Resource Management Activity Intersects Another common source of PM/SEM/SE conflict is the adherence to established cost targets. Additionally. function-based. naturally result in a structure that can be organized into a multitude of projects. The SEHBK Disposal Process could be part of the PMBoK Close Project process. The Integration Process of the SEHBK is intended to be technical (product and system) integration. mentoring.entirety. organization-based. At first look. “Budget and schedule must enable achievement of the technical requirements. The words belie the connection. Included in the Specialty Engineering activities of the SEHBK are Life Cycle Cost and Cost Effectiveness Analysis. and System Life Cycle. Lean. it is included in sections on System of Systems.

one notices the words Qualitative Risk Management and Quantitative Risk Management. unless responsibility and accountability is defined (Factor #4: Ultimate Authority). (Factor #3: Objectives Expectations) exist due to schedule slippage as a result of objective misalignment. the down time can be quantized for inclusion in the schedule as a risk with allocated contingency or eliminated using other schedule crashing or fast tracking techniques (PMBoK 2008. Risk and Opportunity Management (R&OM) are highly visible intersects between SE and PM with differing processes indicated by the SEHBK and PMBoK. Table 5: SEHBK Project Process and PMBoK Project Integration/Time/Quality/Communication/Risk Management Intersects Project Time Management conflicts. 157).     . If tracked by an organization. Table 5 indicates the SEHBK Project Process and PMBoK Project Integration/Time/Quality/Communication Management Process intersects. 156. password issues. including. Quality Metrics (measurement) in the PMBoK is recognized as a critical output of the planning process under Project Quality Management. yet there is no mention of the word ”measurement” at the process level in the PMBoK. Both SEs and PMs would most likely recognize all of the SEHBK Project Processes as ones they perform. The commonalities set the stage for confusion.For example. Loss of computer service for individuals contributing to the project are known to cause down time on any given project due to a wide variety of factors. which partially satisfies the measurement intent. server failure. an alignment opportunity. although they are not necessarily mapped directly to the PMBoK processes. Identification of the SEHBK and PMBoK R&OM processes are illustrated in Table 6. Upon further investigation. R&OM is a project function and therefore should be shared and practiced across all disciplines. accompanied with the expectation that quality metrics are provided in the form of control charts and other helpful measurement tracking tools. but not limited to. such as Decision Making which is spread across the life cycle. predictable across most organizations and those that are organizationally unique due to domain and company culture. etc. at the process level the SEHBK identifies the Measurement Process. There are known indicators of schedule slippage. Table 5. Measurement is a definite undercurrent of the PMBoK processes throughout numerous activities across the life cycle. Knowing and tracking the amount of float in a schedule may also help ease the conflicts inherent in schedule adherence.

The SEHBK adds an iteration activity. although in an overseer capacity. Risk and opportunity management extends beyond engineering technical risks and project management oversight of the technical risks. which is indeed the intended case.Table 6: Risk and Opportunity Management Intersects and Confusion INCOSE Handbook (and ISO-IEC 15288) Plan Risk Management PMI PMBoK Plan Risk Management Identify Risks Manage the Risk Profile: Analyze Risks Perform Qualitative Risk Analysis Perform Quantitative Risk Analysis Manage the Risk Profile: Treat Risks Manage the Risk Profile: Monitor Risks Manage the Risk Profile: Evaluate the Risk Management Process “Plan Risk Management” is identical in naming for both disciplines. such as the risk register. but this author and workforce colleagues with both certifications want to see an alignment regardless of organizational tailoring. and ESEP levels assesses against fourteen functional areas recognized in the context of the required SE experience. which should be true of all processes and activities. although the above serves to illustrate several points of confusion.”and would be included in the SEHBK Analyze Risks activities. The project manager manages the overarching planning. both define the risk strategy for determining how to conduct the risk activities.. as all disciplines are critical to the participation in R&OM. which would equate to the PMBoK Identify Risks. How similar are they when a lower level of interpretation is analyzed? For example. The products produced (the outputs) have commonalities between the certifications bases (Factor #2 Education Overlaps). The Risk and Opportunity activities are summarized as. could also be explored further. often as a flow down from their acquisition customer or inserted as a personal contribution of their process author. CSEP. “develop and implement Risk and Opportunity     Plan Risk Responses Monitor and Control Risks . Further analysis of the two risk methods could be included here. the SEHBK suggests Analyze Risks includes “identification and definition of risk situations”. “Should Risk and Opportunity Management processes between INCOSE and PMI have better alignment?” There are of course advantages to differences. The SEHBK Analyze Risks and the PMBoK Perform Qualitative and Quantitative Risk Analysis are also similar as is Monitor Risks and Monitor and Control Risks. The PMBoK’s Identify Risks and Plan Risk Responses equate to the SEHBK. Evaluate the Risk Management Process. “Define a treatment scheme and resources for each risk. organizations create their own “brand” of risk management. This raises the question.. To exacerbate the confusion. INCOSE’s certification program for the ASEP.

The SEHBK references ambient risk. ISO/IEC 15288 defines the Acquisition Process as. secondary risks. An attribute critical to SEMs. and residual risks (ANSI and PMI 2008). assess risk issues and opportunities. project risk. Table 7. Table 7: SEHBK SE Process and PMBoK Project Procurement Management Intersects       .Management Plans. The Agreement Processes include the Acquisition and the Supply Processes. knowing there are many sources of guidance. identify risk issues and opportunities. due in part to artifact changes over time. from the supplier (seller) perspective. develop and implement risk mitigation and opportunity achievement plans. The SEHBK supply process becomes the PMBoK procurement management process. and track risk reduction/opportunity achievement activities (INCOSE CAG 2011). Confusion often results from certifying organizations adopting words not common to vernacular across disciplines or sources.” The PMBoK mentions fallback plans. only within the same organization. and Cotterman 2005). or of elements of a system being developed by a project (ISO AND IEC 2008). is the ability to adjust to company language. or results needed from outside the project team. of services in support of operational activities. prioritize risks and opportunities. This opportunity does not stop at R&O. An opportunity exists to evolve R&O into synergistic language by the two major certifying bodies for the SE and PM credentials.e. Business risk. companies make up their own terms. Tailoring language to adapt to the company is recognized as a best practice IF the adaptation is more than just a change of words to be “different”. how many different words are used to describe risk? To add to the communication challenge. The SEHBK Agreement Processes and Project Procurement Management processes from the PMBoK are similar.” This is yet another source of misalignment. SE and PMs. programmatic risk.. “Ambient risk is often neglected in project management.” The PMBoK definition “includes the processes necessary to purchase or acquire products. “provid(ing) the means for conducting business with a supplier of products that are supplied for use as an operational system. Contract management and change controlled processes are required to develop and administer contracts or purchase orders issued by authorized project team members. services. Mooz. technical risk. The ambient risk is defined as the risk caused by and created by the surrounding environment (i. ambience) of the project (Forsberg. SE and PM Processes: Agreement Processes.

Confusion between SE. if understood. PMI and INCOSE recognize the need for collaboration. Provide guidance in addition to elaborated processes providing context of expectations across the lifecycles. Improved alignment of the SEHBK and PMBoK as the SE and PM certification bases. and SEs. instructor led or web/computer-based). with the development of the PM-SE Alliance Working Group. Again. would guide the cross-discipline understanding of the two. That inclusiveness extends to the finance. verifying the system against the technical requirements and validating with the customer that the system is what the customer needs. repeatedly. working with finance. the customer. establishment of role definition will help mitigate these conflicts (Factor #4: Ultimate Authority)  if authority and expectations are communicated. who is empowered to make commitments for the organization) may result in conflict. quality. The following list is a basic start in suggested organizational alignment in anticipation of certification alignment. This may be in the form of presentations and joint collaboration experiences. concentrating on the interfaces between the products/systems at the lowest integration level. Provide cross-training for PMs. coordinating cost. Recommendations based on the four factors of confusion identified throughout this paper: 1. Recognize the need for integrated project management by the project management organization (PMO) that includes systems engineering and other key disciplines early in the lifecycle. The SEs would be focused on integrating the products and systems together. The recently signed     . repeating as the products produce the next higher level product/system/SoS. a. working cross-project with the SEMs ensuring the technical expectations are being met on time and on budget in accordance with the Project Management Plan. 2. c. PMs and SE’s/SEMs must unite in alignment with the organization’s vision. just-in-time human and physical resources. in concert with other disciplines as applicable. The SEMs would be managing the technical integration. PMI and INCOSE should work together to align common language where it makes sense. working business risks. Factor #2: Education Overlaps . using good project management based on an integrated (with the PM) plan. SEMs.   a. effectiveness. business wining. timing/schedule. human resources. SEs.e. and Supply Chain over who controls the actual purchase of goods (i. risk.SE and PM incongruities due to certification and stove-piped discipline education. b. Factor #1: Cultural Differences -  Struggles for contrasting cultural knowledge. SEMs. The PMBoK is written from an acquisition (buyer) organization perspective. The commonalities and differences of PMs. supply chain. can be leveraged to form an effective and efficient functioning organization dissipating confusion that may currently exist. Summary During system integration the PM would ensure the combined efforts of all the relevant stakeholders are integrated across projects for each of the applicable knowledge areas. PM. and program success (profitability) are the goal. Thankfully. The goal of industry is to make money (Goldratt 1992) although ethical practices and environmental considerations are refining that goal. objectives. and program mission if efficiency. and other functions via either formal or informal training courses (on-the-job-training/mentoring. and other functions within and external to the organization.

organizations are recognizing the need for collaboration. project manager/project management. The INCOSE Risk and Opportunity Working Group has conducted a survey     . available from the WG . authority. have completed a mapping of Lean Enablers for Project Management to the SEHBK. f. although SE and PM discipline stovepipes and long standing accountability conflicts will most likely continue. Identify. in writing.   a.(2011) Memorandum of Understanding between the two organizations shows a strong commitment and start for both organizations as they continue the systems and project management integration! b. d. although wishfully at a less intense rate. The SEHBK recognizes the duality of the SE and PM roles. Define escalation mechanisms ahead of time if issues continue. Include float and contingency in the execution strategy for schedule and risk management of all schedules. Donald Kauffman asked. b. Factor #3: Objectives Expectations . Align management plans and other documentation products to reduce duplication and gain a common understanding of how the project will be run. SEMs and SEs! c. A few companies have recognized the similarities of the PM and SE roles and have required their PMs to be chief systems engineers prior to becoming project managers. and PMI through the Lean SE Working Group (WG) initiative. INCOSE. Agree and communicate the Tricks of the Trade (Mulcahy 2009) for schedule and cost management among the disciplines. A decade ago. reinforcing the definitions during conversations: e. and project deliverables/product deliverables. Roles will never be completely defined. since changing tools requires funds for purchase. a. Align tools if it makes sense to do so. maintenance.g. at least obtain and communicate an understanding of how the tool outputs between the disciplines would work. INCOSE should align the language of their certification 14 function areas with the language of the SEHBK or other basis for certification. This may be an opportunity to further cross-align the INCOSE and PMI bodies of knowledge. verification/validation. the role responsibility. not domination. d. and accountability of project personnel. “Which profession should dominate the intersection (Kauffman 1998)?” Although domination struggles persist today. e. MIT LAI. b. A more detailed analysis of the intersects is under consideration for a follow-on paper. project/program. Follow the written word.Typically due to cost and schedule conflicts. c. Additional research will be conducted by INCOSE/PMI/Massachusetts Institute of Technology (MIT) Lean Advancement Initiative (LAI) as a result of the PM-SE Alliance. role/title. Factor #4: Ultimate Authority  -­‐  Align expectations. and retraining. If tool alignment is not an option. The Systems Engineering Body of Knowledge (SEBoK) (Pyster et al 2011). 3. although captured expectations move the project towards a more collaborative result. 4. c. recently released. Work with the customer to ensure duplication of required documentation is eliminated for a more efficient and affordable project. One could certainly understand the need for big-picture thinking (for integration) and leadership for PMs. Agree to common word definitions typically used to communicate on the project. Develop realistic schedules and cost targets agreed to by both disciplines. may eventually replace the SEHBK as a systems engineering certification source and may provide additional cross-discipline guidance. The SEBoK should continue to expand the understanding between the roles.

  Geneva:  International  Organization  for  Standardization.  Visualizing  Project  Management.  Engineering  in  Integrated  Project  Teams. help identify further SE and PM intersects and confusion.    American  National  Standard/Project  Management  Institute.  Revised  by  K.  The  Goal:  A  Process  of  Ongoing  Improvement.  and  R.  pp.  H.  Cognitive  and  Personality  Characteristics  of  Successful  Systems  Engineers.org/educationcareers/certification/details..  2007  Foundations  of  Economics  -­‐  PESTEL  Analysis  of  the  Macro-­‐Environment.  San  Diego.  Jackson.  Version  3.  D.that may.   ANSI/PMI  99-­‐001-­‐2008.     http://www.oup..  P.  Logistics  Engineering  and  Management.  1998.  PMP.  Systems  and  software  engineering  –  System  life  cycle  processes.  2nd  Rev   Haskins.  ISBN-­‐13  0-­‐978-­‐0-­‐471-­‐64848-­‐2.  A.  S.   Geneva:  International  Organization  for  Standardization.  2003.  J.  1999. In any case.  ISBN:0-­‐13-­‐095085-­‐8.  and  Cotterman.  5th  Ed.  Forsberg  and  M.  Coping  with   Complexity.  ISBN  0-­‐88427-­‐061-­‐0.  Stevens..  K.  Krueger.  D.  Project  Management  and  its  relation  to  Systems  Engineering.  Institute  of  Electrical  and  Electronic  Engineers  (IEEE).   Goldratt  E..com/uk/orc/bin/9780199296378/01student/additional/page_12.    Standard  for  Application  and  Management  of  the  Systems  Engineering   Process.incose.ht m edition.  Systems  Engineering  Handbook:  A  Guide  for  System  Life  Cycle   Processes  and  Activities.  2011..  1992.   Blanchard. upon interpretation.  Proceedings  of  the  ninth  annual   International  Symposium  of  the  International  Council  on  Systems  Engineering.  K.     ———TR  19760.   Arnold.  Minneapolis..     INCOSE  Certification  Advisory  Group  (CAG).  21-­‐23.  pp.  3rd  Ed.  North  River  Press.  2005.   Frank.  H..  Brook.  Federal  Aviation  Administration  (FAA).  1998.  2010.  CA  (US):  INCOSE.  C.  ACB-­‐2010.   Gillespie.       .  2000.aspx?id=level   ISO  and  IEC  15288.    2010.  Prentice  Hall  Europe.  A  Guide  to  the  Project  Management  Body  of  Knowledge  (PMBoK).  C.2. stay tuned for more research and alignment progress in the near future! References ANSI  and  PMI.   Baldwin.  R.M.  Hamelin.  Systems  Engineering  –  A  guide  for  the  application  of  ISO/IEC  15288.  ed.  M.  Which  Level  is  Right  for  Me?  -­‐  function   areas  recognized  in  the  context  of  the  required  Systems  Engineering  experience:   http://www.   Forsberg.   Dawson.   The  Proceedings  of  the  International  Council  on  Systems  Engineering.152-­‐168.       Systems  Engineering  Division..  B..   Wiley  &  Sons.  A.  Mooz.  2008.   Fourth  Edition.   Walden.   MN.  2005.  Systems  Engineering.  2008.  Prentice  Hall.   IEEE  Std  1220.

  Lewotsky  K.E.    Olwell.  A  Complexity  Typology  for  Systems  Engineering.  D.ucla.  ISBN:10932735-­‐07-­‐0.  A  Revolutionary  Guide  to  What  REALLY  Matters  When   Managing  Projects.   http://www.    Skirting  the  Pitfalls  of  Project  Management/Project  Management   Success.  Systems  Engineering  Body  of  Knowledge  (SEBoK)  v.   Proceedings   of   the   eight   annual   International  Symposium  of  the  International  Council  on  Systems  Engineering.  National  Aeronautics  and  Space  Administration  Systems  Engineering  Handbook.  2003. The Proceedings of the International Council on Systems Engineering.    Dori. ESEP-Acq..       Biography Eileen Arnold. She has been an active INCOSE volunteer since 1996 holding leadership positions as Chair of the Competency Working Group.  2010. and Systems across the project and product life cycles. and Technical Societies (MFESTS) Charles W. including development.  2011.     Mooz.  Dave. and INCOSE Technical Board/Technical Leadership Team/Technical Operations. INCOSE Certification Advisory Group (CAG).   Stephanie.  Project  Management  Tricks  of  the  Trade.  SP-­‐6105.jsp?pubId=1&id=2349 &pageNum=3. Science.    and  deWeck.     ———2006.   Mulcahy.  O.  and  Enck.pdf   Pyster.  Hutchison.  RMC  Project  Management  Inc. IL.   http://www.  2009.  H. She has a B.  Nicole. has over 30 years of experience in the managing of multi-site projects/programs.   NASA.  S. Britzius life time achievement award.  Jim.  “Project  Management  and  Systems  Engineering:  Where  the  Professions   Intersect   -­‐   Generate   Synergy   Not   Conflict”.  M.  Art.     Sheard..  Squires.   NASA-­‐SP6105.25.  2010.  The  Heritage  and  Power  of  the  Integrated  PM/SE  Project   Cycle.  PM  Crash  Course. and measurement/analysis. She was a primary instigator in the formation of the Heartland Chapter and has been the INCOSE North Star Chapter Director of Government and   Academia in addition to its editor for the North Star     .  A.seas.  D.   Pao  P.org/   Sharon. SW. She gained insight into the project/program management world with her capability lead assignments at BAE Systems in Fridley.  A.A and most recently received the Minnesota Federation of Engineering.  2006.com/publication/article.  and  Motishari. modeling and simulation.bkcase.advancedimagingpro.  S.edu/mae/The%20Myth%20of%20System%20Engineering%20-­‐ %20presentation. and the engineering and management of HW. for both the commercial and defense sectors. SE and PM competency frameworks. PMP. Minnesota.  D.  R.  A.   http://www.  Anthony.   Washington. Chicago.  2005.E and an M.  Attributes  of  System  Engineers:  The  Myth  of  System  Engineering.  1998.  and  Wilson.Kauffman.C.  The  Proceedings  of  the  International  Council  on  Systems  Engineering.S.  Alice.  Systems  Engineers'  Perceptions  on  the  Adequacy   of  Project  Management  Methods  for  Systems  Engineering  Management.  1992.

She has held the office of President for both chapters. She is also a member of Project Management Institute (PMI) and the local PMI-MN chapter.     .Chapter newsletter The Integrator as well as acting web master for the chapter web site.

2  Define  Scope   5.  Project   Integration  Mgmt   5.Attachment A: Process/Activity/Knowledge Area Comparison   SEHBK  (ISO/IEC   15288)   Technical   Processes     SEHBK   Processes/Activities   Stakeholder   Requirements   Definition     PMBoK   Knowledge   Areas   5.1  Collect   Requirements   5.1  Develop   Project  Charter   5.  Project   Integration  Mgmt     Spread  across  all       4.6  Close  Project   or  Phase   5.  Project  Scope   Mgmt       4.  Project  Scope   Mgmt     Spread  across  all   5.  Project   Integration  Mgmt       .  Project  Scope   Mgmt                           Requirements   Analysis   Architectural  Design       Process   Implementation   4.4  Verify  Scope   PMBoK   Processes   4.3  Direct  and   Manage  Project   Execution     4.4  Monitor  and   Control  Project   Work               Verification   Transition    Validation     Operation   Maintenance   Disposal       4.3  Create  WBS   5.5  Control  Scope     Integration   4.2  Develop   Project   Management   Plan   4.

4  Estimate   Activity   Durations   6.4  Monitor  and   Control  Project   Work   4.5  Develop   Schedule   6.2  Plan   Communication   4.3  Direct  and   Manage  Project   Execution     Project  Assessment   and  Control   4.  Project   Communications   Mgmt   10.)   6.  Project   Integration  Mgmt   4.  Project  Risk   Spread  across  all   11.2  Sequence   Activities   6.)     Project  Planning   (cont.1  Define   Activities   6.1  Plan  Risk       .1  Identify   Stakeholders   10.SEHBK  (ISO/IEC   15288)     SEHBK   Processes/Activities   Cross-­‐Cutting   Technical  Methods   Operation       PMBoK   Knowledge   Areas     PMBoK   Processes   Project  Processes   Project  Planning   4.3  Estimate   Activity   Resources   6.2  Develop   Project   Management   Plan   6.6  Control   Schedule   Project  Processes   (cont.  Project   Integration  Mgmt       Decision  Mgmt   Risk  Mgmt   Spread  across  all   11.  Project  Time   Mgmt         10.

4  Manage   Stakeholder   Expectations   10.3  Distribute   Information     10.5  Plan  Risk   Responses     Configuration  Mgmt     4.4  Perform   Quantitative  Risk   Analysis     11.3  Perform   Qualitative  Risk   Analysis     11.  Project  Risk   Mgmt   11.3  Perform   Quality  Control         11.4  Perform   Quantitative  Risk   Analysis         .3  Perform   Qualitative  Risk   Analysis     11.SEHBK  (ISO/IEC   15288)   SEHBK   Processes/Activities   PMBoK   Knowledge   Areas   Mgmt   PMBoK   Processes   Management   11.2  Identify   Risks   11.)     Measurement   8.5  Perform   Integrated   Change  Control   10.2  Perform   Quality   Assurance   8.  Project   Integration  Mgmt   10.  Project   Communications   Mgmt   4.  Project  Quality   Mgmt     8.5  Report   Performance     Information  Mgmt     Project  Processes   (cont.

6  Close  Project   or  Phase     Infrastructure   Management   4.3  Direct  and   Manage  Project   Execution     4.4  Monitor  and   Control  Project   Work   4.   Closing     PMBoK   Processes   4.   Executing.SEHBK  (ISO/IEC   15288)   Organizational   Project-­‐Enabling   Processes   SEHBK   Processes/Activities   Life  Cycle  Model   Mgmt     PMBoK   Knowledge   Areas   Initiating.  Project   Integration  Mgmt   4.   Planning.2  Develop   Project   Management   Plan     4.  Project  Human   Resource  Mgmt     Spread  across  all   9.4  Manage       .2  Acquire   Project  Team     9.)   SoS  Project  Portfolio   Mgmt   Human  Resource   Mgmt     Spread  across  all   9.   Monitoring  and   Controlling.1  Develop   Project  Charter     4.1  Develop   Human  Resource   Plan   9.3  Develop   Project  Team     9.5  Integrated   Change  Control     Organizational   Project-­‐Enabling   Processes  (cont.4  Monitor  and   Control  Project   Work   4.3  Direct  and   Manage  Project   Execution   4.

1  Plan  Quality   8.2  Perform   Quality   Assurance   8.2  Determine   Budget   7.  Project  Cost   Mgmt         7.  Project  Cost   Mgmt   7.  Project  Quality   Mgmt     8.1  Estimate   Costs   7.SEHBK  (ISO/IEC   15288)   SEHBK   Processes/Activities   PMBoK   Knowledge   Areas   PMBoK   Processes   Project  Team     Quality  Mgmt   8.3  Control  Costs     Electromagnetic   Compatibility   Analysis   Environmental   Impact  Analysis   Interoperability   Analysis   Life-­‐Cycle  Cost   Analysis   Manufacturing  and   Producibility   Analysis                   7.3  Perform   Quality  Control     Tailoring   Processes   Specialty   Engineering   Activities         Tailoring     Design  for   Acquisition  Logistics   –  Integrated   Logistics  Support     Spread  across  all     Spread  across  all   Cost-­‐Effectiveness   Analysis   7.3  Control  Costs         .

3  Control  Costs   12.4  Close   Procurements           .1  Develop   Human  Resource   Plan         7.SEHBK  (ISO/IEC   15288)     Specialty   Engineering   Activities  (cont.  Project   Procurement   Mgmt   9.3  Administer   Procurements   12.)       SEHBK   Processes/Activities     Mass  Properties   Engineering  Analysis   Safety  &  Health   Hazard  Analysis     PMBoK   Knowledge   Areas       PMBoK   Processes     Sustainment   Engineering  Analysis   Training  Needs   Analysis     Usability   Analysis/Human   Systems  Integration   Value  Engineering   Agreement   Processes     Acquisition  Supply   7.  Project  Human   Resource  Mgmt       9.  Project  Cost   Mgmt   12.2    Conduct   Procurements   12.1  Plan   Procurements   12.

Sign up to vote on this title
UsefulNot useful