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

   

Management Success” (Lewotsky 2006) provides insight into the project management view of the conflict. Lewotsky states, “Novice program managers often make the error of being overly optimistic, building a schedule that assumes everything will go without a hitch.” Factor #4: Ultimate Authority – Power struggles as to which discipline has the ultimate decision making authority, 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, A. 1999) recognizes that how projects are managed influence how the engineering processes are implemented, “Whilst there are obvious project management and contractual issues, there are also impacts on the engineering process”. Without an understanding of overarching level of accountability, conflicts with activity ownership exist in projects that haven’t come to an understanding of the role/responsibility/authority/accountability clarifications. Which role has final authority in your organization for the work breakdown structure (WBS), integrated master plan (IMP), 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), developed in isolation from each other. An integrated approach helps! Definitions. Before we compare the SEHBK and PMBoK process and knowledge areas, a few definitions are included for the context of this paper. The SEHBK does not have the definitions that are equivalent to the PMBoK in all cases. Supporting sources were also consulted. Life Cycle -

Product Life Cycle – “A collection of generally sequential, non-overlapping product phases whose name and number are determined by the manufacturing and control needs of the organization. The last product life cycle phase for a product is generally the product’s retirement. Generally, a project lifecycle is contained within one or more product life cycles” (ANSI and PMI 2008, 18). “Engineering activities necessary to guide product development while ensuring that the product is properly designed to make it affordable to produce, own, operate, maintain, and eventually to dispose of, without undue risk to health or the environment” (IEEE Std 1220 2005). The cycle might include beginning, e.g. elicitation of stakeholder needs; middle, e.g. design or integration of components, and end, e.g. deployment or maintenance phases or stages. Project Life Cycle - “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, 15).

System Life Cycle – “The evolution with time of a system-­‐of-­‐interest from conception through to retirement” (Haskins 2010).

“The system life cycle is composed of a set of interacting system elements, each of which can be implemented to fulfill its respective specified requirements. A system progresses through its life cycle as the result of actions, performed and managed by people in organizations, using processes for execution of these actions” (ISO/IEC 15288 2008). The system of interest is composed of multiple products.

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, 9).

   

Project – “A temporary endeavor undertaken to create a unique product, service or result” (ANSI and PMI 2008, 5).

Project Management – “The application of knowledge, skills, tools, and techniques to project activities to meet the project requirements. The role applies to any project or program personnel applying the knowledge, skills, tools, and techniques to project activities to meet the project (not product) requirements” (ANSI and PMI 2008, 6). This term will apply to those project managers, program managers, systems engineering managers (SEM), systems engineers that perform the role-specified activities regardless of their associated discipline. It applies to all disciplines such as finance, contracts, supply chain, quality, and engineering managers.

Project Management Body of Knowledge (PMBoK) – The PMI Project Management basis for certification.

Project Manager (PM) - a person named to manage the complete project, which includes product and system oversight as a subset of the overarching responsibility, authority, and accountability demanded of a project manager. A project manager is the person accountable for accomplishing the stated project objectives. The term will also be inclusive of the term program manager for this paper. Systems Engineering Handbook (SEHBK) – The INCOSE Systems Engineering basis for certification. Systems Engineering Manager (SEM) - The technical managers of systems engineering, with responsibility for delivering the system of interest. They may or may not be people managers, dependent on the construct of the organizational structure (matrix/projectized/composite).

SE and PM Process/Knowledge Area Intersects The systems engineering source for certification, the SEHBK and the project management basis for certification, the PMBoK serve as the primary education sources for SE and PM credentials. 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, mentioned above. This paper captures where we are today, 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. Both of these sources have been steadily improving their cross-discipline intersects and definitions, although there are still opportunities for further refinement. 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. The SEHBK process color-codes are inserted under the PMBoK process activities in rows where top level PM intersects are the most likely. Most of the tables in this paper follow these color-codes and layout.

   

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.

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

   

Table 2: SEHBK Organizational Project Enabling and PMBoK Integration/Quality/Resource Management Process Activity Intersects

Project management initiates, plans, and then monitors/controls the execution of the technical maturation. At any point in the lifecycle, project management may close the project. Projects are closed out when

1. They are completed, 2. A decision is made based on the perception that the derived costs outweigh the

expected benefits, or 3. They are terminated by the customer.

Organizations may also require phase closures to define a more prominent gated progression. “Organizations that successfully transition from ad-hoc work practices to a repeatable, controlled process usually transition first to a project cycle and then to a gated project cycle to manage accomplishments (Mooz and Wilson 2003). 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. “The purpose in defining the system life cycle is to establish a framework for meeting the stakeholders’ needs in an orderly and efficient manner. 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, 21).

There are of course numerous other lifecycle models that could be imbedded. For example, a modified waterfall model for software or the systems engineering VEE model for systems. There is generally recognition that at least two life cycles exist; one for project management and one for technical management. “Life cycles vary according to the nature, purpose, use and prevailing circumstances of the system. 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, 21)”. Life cycle phases provide organizations with a framework from which management has high-­‐level visibility and control of both the project and system. The system lifecycle is seen as an intersection of project management (the business case and funding) and the technical aspects, the product or suite of products crafted into a system.

As products are being developed, systems engineering processes are iterated. The project management knowledge areas and processes are progressively elaborated in concert (desirably) with the product processes.

   

The SEMs are focused on technical changes, with PM oversight. Systems engineers focus on the integration of the system of products and contribute to the project charter, engineering management plans, and project management plan sections applicable to the technical management view with SEM oversight. The SEMs direct and manage project execution of the product definition, development (sometimes through deployment), monitor and control project work and are responsible for closing out the project or phase’s technical aspects. All team members are responsible for performing Integrated Change Control for technical changes that are driven by a contractual change.

Quality management and human resource management are obvious intersects in Table 2, with project managers performing the project integration and SEM performing the systems management throughout the life cycle. Both are actively engaged in change control, with project managers focused on the project management plan and contractual changes.

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. For example, SEMs, when planning and managing (monitoring and controlling) their system of interest, perform the role of project management. In this case, the SEM is planning, managing, and integrating within their technical sphere of influence, the result aimed at managing the products or systems. These contributions undergo further integration with other functions such as finance, supply chain, quality, to produce an integrated set of projects resulting in a project managed by a project manager. The project manager aspires to project success through satisfaction of measurable business criteria. Technical managers perform project management roles in support of the over-arching project manager. SEMs and PMs would be expected to be competent in project management; possessing knowledge, skills, abilities, and of course, experience in their disciplines and domains. Additionally, the best managers and systems engineers possess personal skills to impact and influence others as leaders. The SE is accountable for budget and schedule of their “project”, (Factor #3: Objectives Expectations) but are typically held more accountable for technical aspects than the other two. This causes conflict between the SE and the PM as the PM is typically more accountable (Factor #4: Ultimate Authority)  for cost and schedule.

According to Clifton Baldwin, 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, a specialized “technical” project manager

   

Baldwin recognizes that SEs have overlapping skills with project managers. “Systems engineering requires more “technical” skills but not technical expertise. Project Management requires more “managerial” skills but not management” (Baldwin 2010). I’m not sure why he thinks SE’s have no technical expertise. His experience must be from a different culture than this author knows, Factor #1  Cultural Differences!

According to Peter Pao (Pao 2005) SEs:

• See the big picture, and think system, 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. The details, context, and focus are what set them apart. For instance, PMs must see the big picture from an integrated project performance perspective. SEs must see the big picture from a technical perspective, and SEMs must see the big picture from both perspectives, with a focus on delivering the right system on time at an acceptable cost without unintended consequences. The SEHBK recognizes intersects between project planning and control, and systems engineering as shown in Figure 1. Task definitions, risk management, and customer interaction, are shown as the intersects. Project managers (not project management) should not be focused on performing the technical work of system architecture, technical coordination, or systems integration, the focus of systems engineers and SEMs. Project management, including SEMs are all focused on the project planning and control, with SEMs focusing on the system technical management.

Figure 1. SE and Project Planning and Control Intersects (Haskins 2010) To further illustrate the interaction, a composite list of recognized project management artifacts is listed below. As you read through the list, think about which roles have the responsibility and accountability in your organization. Each artifact includes notations as to ownership, which may or may not be the same in your environment. Understand how your project will operate and the ownership and collaboration responsibilities for all artifacts before the project begins. Artifact infighting for ownership (Factor #4: Ultimate Authority), drives inefficient and ineffective behavior resulting in duplication of effort and differing and often incompatible formats.

• Project Charter – This is typically a PM-developed and owned document, although Systems Engineers are commonly asked to author them for the project whether for an internal

   

working group or for an external system. If separate program and product projects exist, more than one may be in existence.

• Scope Statement / Statement of work – Overall scope is the responsibility of the PM, although there is both project scope AND system scope. 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. Requirements management plans are often included in the developed documentation, primarily to manage the technical requirements, although the Plan should encompass project and technical requirement management.

• Business case /Feasibility Study – The business case is a PM-owned artifact, often part of the Charter, with oversight for feasibility studies early in the business winning/early phases of the lifecycle. Feasibility of technical solutions are often included in the SE-associated artifact; trade-off analysis.

• Project Management Plan (PMP) – An overarching (project and technical) project planning document that is typically owned by the PM, but should involve active participation by Systems Engineering for those items of technical interest, finance for those items of financial interest, contracts for those items of contractual interest, supply chain for those items of procurement interest, manufacturing for those items of production interest, and all of the support functions (lean, quality, six-sigma, etc) for an integrated project view. The equivalent plan for the technical aspects is the Systems Engineering Management Plan/Systems Engineering Plan/Engineering Management Plan. These plans should be identified in the PMP.

• Work Breakdown Structure (WBS) – The WBS, and WBS Dictionary can be owned, from an accountability standpoint, by the Finance Manager, PMs, or Systems Engineering. In reality, all are contributors, with the PM owning the WBS and Systems Engineering providing the vast majority of input, especially if the WBS is product-based; a best practice.

• Responsibility Assignment Matrix (RAM) - The WBS is progressed from the product breakdown into activities, bid by individuals assigned to the responsibilities. The WBS is tightly coupled with the RAM, requiring the PM to own who is assigned to the team, which work they will be performing, and when. Systems engineering is a major contributor, although not the only function involved.

• Change Control Plan – Although the PM owns the Change Control Plan, driving the methodology to be used on the project, it is systems’ engineering that performs the vast majority of change administration in accordance with the plan, for documentation and end item products and systems.

• Risk and Opportunity Management Plan - The Risk and Opportunity Management Plan provides risk and opportunity oversight for the project manager, but is commonly managed by systems engineering for system-based development. Both disciplines are trained in risk (and in some cases opportunity) management, only using different terminology and slightly different methodologies. 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.

• Risk Register – Some organizations limit the Risk Register to technical risks. Others identify separate registers for technical and business risks. In some cases, the technical risks

   

bubble up to business risks. The PM needs to be aware of both, just as the SE needs to be aware of both.

• Communications Management Plan – The PM owns this management plan, with contributions gathered from all functions applicable to the project. This is one of the most important plans if understood and followed, yet it is often a plan that is overlooked after capturing. It will aid in smooth-flowing communication, the most difficult of any of the expectations to facilitate and execute. PMs are expected to spend 90% of their time communicating (PMI). It is critical that SE’s also communicate from a technical perspective, especially across domains (software, Mechanical, Electrical) and Financial (Design to Cost). An integrated plan seems to make sense, simplifying communication channels.

• Issue Log/Action Item List – These documents are often created in multiple instances and even formats, dependent on the functions or projects capturing the issues and actions. Management of these items is most efficient and effective at the program level, in one format, with metrics in place to observe consistent issues across projects. All actions in one place seems to make sense when a project is driven to ensure timely action item closure.

• Resource Management Plan – The PM is indeed responsible for obtaining the best resources available for the project, although SEMs are often the negotiators for technical resources, especially in a matrix organization.

• Project Schedule – The Master Schedule, whether or not it is for the project or program, is under the purview of the PM, although for large projects/programs, the actual hands-on creation and analysis of the schedule is performed by schedulers often a separate planning and control group. Technical schedules, at a lower level, feed the master project schedule including the Integrated Master Schedule (IMS). The intersect is not only the milestones, but other critical path elements as well.

• 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.

• Lessons learned - Learning from experience is a critical effort, not only for the project of interest. Future projects can benefit if the lessons are truly learned and integrated.

• Stakeholder Analysis – Systems Engineers know this is one of the first steps in the process. PMs also know this, which commonly results in two different lists, not always assimilated into a common stakeholder list. Ideally, the PM maintains the project/program list with input from Systems Engineering and other relevant functions.

• Document Management – Configuration and Data Management if the documentation is a function of the PM because documentation transcends technical documentation. It includes contracts documentation, financial documentation and other items. Systems Engineers perform configuration management and data management of their documentation, although a subset of the total set of project documentation.

• Meeting Minutes – for project meetings, the PM owns them. For systems engineering meetings, systems engineering owns them.

“Systems Engineers' Perceptions on the Adequacy of Project Management Methods for Systems Engineering Management” (Sharon, Dori, and deWeck 2010) explores the

   

differences and commonalities in systems engineering and project management tools, yet another view into the two disciplines and potential sources of confusion. Finance tools may also complicate the ownership and operating confusion.

The development of systems requires contributions from diverse technical disciplines in addition to the non-technical disciplines and functions. Systems are holistic by nature. All of the properties of a system (Public, Economic, Social, Technical, Environmental, Legal). (Gillespie 2003) cannot be determined or explained by its constituent parts. Instead, the system and its influences determine the behavior of the system and its acceptance based on the timing of deployment. This author maintains this is also true of project management. 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. This is again true of project management. The ability to handle complexity is one of the reasons PMs are systems engineers prior to becoming PMs at some companies. Systems thinkers think in parallel, understanding the coordination of the multitudes of activities going on simultaneously. Systems’ thinking is needed by PM’s and SE’s alike.

SE and PM Processes: Technical. Subsets of the SEHBK Technical processes are applicable to project management activities, Table 3. Requirements should be more than technical requirements. Contractual requirements and subsequent flow down and tracking are of course critical to the project. Over time, the PMBoK has aligned to more common definitions systems engineers would recognize e.g. the term “requirement” has enhanced the concept of “scope”.

Table 3: SEHBK Technical Processes and PMBoK Project Integration/Scope Activity Intersects

Architectural design not only applies to the system, but would also apply to the organization and project set up if one stretched the definition. This may include architecting communication channels, organizational structure, process usage, or other such architectures. Projects can be seen as an organizing mechanism for getting work done. System-of-Systems (SoS), Systems, and their constituent makeup are often too complex to manage in their

   

entirety. Architecting systems into their constituent parts, whether product/subsystem-based, function-based, organization-based, service-based, or a combination of the above, naturally result in a structure that can be organized into a multitude of projects. The Integration Process of the SEHBK is intended to be technical (product and system) integration. The integration management of the PMBoK is intended to be project coordination, another confusing source of terms.

The SEHBK Disposal Process could be part of the PMBoK Close Project process, although not mentioned directly in the PMBoK.

SE and PM Processes: Specialty Engineering. Included in the Specialty Engineering activities of the SEHBK are Life Cycle Cost and Cost Effectiveness Analysis; the intersects to the PMBoK Project Cost Management knowledge area, Table 4 and Factor #3: Objectives Expectations. Although budget is not mentioned in the Specialty Engineering section of the SEHBK, it is included in sections on System of Systems, Lean, Project Planning, and System Life Cycle. Additionally, “Budget and schedule must enable achievement of the technical requirements. Conversely, the requirements must be achievable within the budget and schedule (Forsberg, Mooz, and Cotterman 2005)”. The PMBoK’s Estimate and Control Costs sub-processes align with systems engineering team activities as input to the project.

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, since almost every engineering endeavor has unknown land mines in the good-day-scenarios. SE trade-off studies help identify value sources, comparing possibilities.

The SEHBK Training Needs Analysis intersects and aligns with the PMBoK expectations of Develop Human Resource Plan. The technical community identifies what is needed to improve individual’s skills with the PM and human resources identifying additional training, mentoring, or other sources of knowledge.

SE and PM Process: Project Processes. At first look, the processes identified in the SEHBK and PMBoK have obvious similarities for a few of the processes. Upon further inspection at depth, one realizes the meanings may not be quite the same. The words belie the connection, since there is varying degrees of process decomposition with differing words and life cycle timing used at more detailed levels between the two disciplines.

   

For example, at the process level the SEHBK identifies the Measurement Process, yet there is no mention of the word ”measurement” at the process level in the PMBoK, Table 5. Upon further investigation, one notices the words Qualitative Risk Management and Quantitative Risk Management, which partially satisfies the measurement intent. Quality Metrics (measurement) in the PMBoK is recognized as a critical output of the planning process under Project Quality Management, accompanied with the expectation that quality metrics are provided in the form of control charts and other helpful measurement tracking tools. Measurement is a definite undercurrent of the PMBoK processes throughout numerous activities across the life cycle. Both SEs and PMs would most likely recognize all of the SEHBK Project Processes as ones they perform, although they are not necessarily mapped directly to the PMBoK processes, such as Decision Making which is spread across the life cycle. Table 5 indicates the SEHBK Project Process and PMBoK Project Integration/Time/Quality/Communication Management Process intersects. The commonalities set the stage for confusion, unless responsibility and accountability is defined (Factor #4: Ultimate Authority).

Table 5: SEHBK Project Process and PMBoK Project Integration/Time/Quality/Communication/Risk Management Intersects

Project Time Management conflicts, (Factor #3: Objectives Expectations) exist due to schedule slippage as a result of objective misalignment. There are known indicators of schedule slippage, predictable across most organizations and those that are organizationally unique due to domain and company culture. 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, including, but not limited to, password issues, server failure, etc. If tracked by an organization, 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, 156, 157). Knowing and tracking the amount of float in a schedule may also help ease the conflicts inherent in schedule adherence.

Risk and Opportunity Management (R&OM) are highly visible intersects between SE and PM with differing processes indicated by the SEHBK and PMBoK. R&OM is a project function and therefore should be shared and practiced across all disciplines; an alignment opportunity. Identification of the SEHBK and PMBoK R&OM processes are illustrated in Table 6.

   

Table 6: Risk and Opportunity Management Intersects and Confusion

INCOSE Handbook (and ISO-IEC 15288)

PMI PMBoK

Plan Risk Management Plan Risk Management

Identify Risks

Perform Qualitative Risk Analysis Manage the Risk Profile: Analyze Risks

Perform Quantitative Risk Analysis

Manage the Risk Profile: Treat Risks Plan Risk Responses

Manage the Risk Profile: Monitor Risks

Monitor and Control Risks

Manage the Risk Profile: Evaluate the Risk Management Process

“Plan Risk Management” is identical in naming for both disciplines; both define the risk strategy for determining how to conduct the risk activities. The project manager manages the overarching planning, which is indeed the intended case, although in an overseer capacity. Risk and opportunity management extends beyond engineering technical risks and project management oversight of the technical risks, as all disciplines are critical to the participation in R&OM.

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. How similar are they when a lower level of interpretation is analyzed? For example, the SEHBK suggests Analyze Risks includes “identification and definition of risk situations”, which would equate to the PMBoK Identify Risks. The PMBoK’s Identify Risks and Plan Risk Responses equate to the SEHBK, “Define a treatment scheme and resources for each risk...”and would be included in the SEHBK Analyze Risks activities.

The SEHBK adds an iteration activity, Evaluate the Risk Management Process; which should be true of all processes and activities.

Further analysis of the two risk methods could be included here, although the above serves to illustrate several points of confusion. The products produced (the outputs) have commonalities between the certifications bases (Factor #2 Education Overlaps), such as the risk register, could also be explored further.

To exacerbate the confusion, organizations create their own “brand” of risk management, often as a flow down from their acquisition customer or inserted as a personal contribution of their process author. This raises the question, “Should Risk and Opportunity Management processes between INCOSE and PMI have better alignment?” There are of course advantages to differences, but this author and workforce colleagues with both certifications want to see an alignment regardless of organizational tailoring.

INCOSE’s certification program for the ASEP, CSEP, and ESEP levels assesses against fourteen functional areas recognized in the context of the required SE experience. The Risk and Opportunity activities are summarized as, “develop and implement Risk and Opportunity

   

Management Plans, identify risk issues and opportunities, assess risk issues and opportunities, prioritize risks and opportunities, develop and implement risk mitigation and opportunity achievement plans, and track risk reduction/opportunity achievement activities (INCOSE CAG 2011).” This is yet another source of misalignment, only within the same organization, due in part to artifact changes over time.

Confusion often results from certifying organizations adopting words not common to vernacular across disciplines or sources. The SEHBK references ambient risk. “Ambient risk is often neglected in project management. The ambient risk is defined as the risk caused by and created by the surrounding environment (i.e., ambience) of the project (Forsberg, Mooz, and Cotterman 2005).” The PMBoK mentions fallback plans, secondary risks, and residual risks (ANSI and PMI 2008).

Business risk, project risk, technical risk, programmatic risk; how many different words are used to describe risk? To add to the communication challenge, companies make up their own terms. An attribute critical to SEMs. SE and PMs, is the ability to adjust to company language, knowing there are many sources of guidance. 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”. An opportunity exists to evolve R&O into synergistic language by the two major certifying bodies for the SE and PM credentials. This opportunity does not stop at R&O.

SE and PM Processes: Agreement Processes. The SEHBK Agreement Processes and Project Procurement Management processes from the PMBoK are similar. ISO/IEC 15288 defines the Acquisition Process as, “provid(ing) the means for conducting business with a supplier of products that are supplied for use as an operational system, of services in support of operational activities, or of elements of a system being developed by a project (ISO AND IEC 2008).” The PMBoK definition “includes the processes necessary to purchase or acquire products, services, or results needed from outside the project team. Contract management and change controlled processes are required to develop and administer contracts or purchase orders issued by authorized project team members. The Agreement Processes include the Acquisition and the Supply Processes, Table 7. The SEHBK supply process becomes the PMBoK procurement management process, from the supplier (seller) perspective.

Table 7: SEHBK SE Process and PMBoK Project Procurement Management Intersects

 

   

Confusion between SE, PM, and Supply Chain over who controls the actual purchase of goods (i.e. who is empowered to make commitments for the organization) may result in conflict. The PMBoK is written from an acquisition (buyer) organization perspective. Again, establishment of role definition will help mitigate these conflicts (Factor #4: Ultimate Authority)  if authority and expectations are communicated, repeatedly.

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, working with finance, supply chain, the customer, working business risks, 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. The SEs would be focused on integrating the products and systems together, concentrating on the interfaces between the products/systems at the lowest integration level, repeating as the products produce the next higher level product/system/SoS. The SEMs would be managing the technical integration, coordinating cost, timing/schedule, quality, risk, just-in-time human and physical resources, verifying the system against the technical requirements and validating with the customer that the system is what the customer needs, using good project management based on an integrated (with the PM) plan. PMs and SE’s/SEMs must unite in alignment with the organization’s vision, objectives, and program mission if efficiency, effectiveness, and program success (profitability) are the goal. The goal of industry is to make money (Goldratt 1992) although ethical practices and environmental considerations are refining that goal. That inclusiveness extends to the finance, human resources, business wining, and other functions within and external to the organization.

The commonalities and differences of PMs, SEMs, and SEs, if understood, can be leveraged to form an effective and efficient functioning organization dissipating confusion that may currently exist. Improved alignment of the SEHBK and PMBoK as the SE and PM certification bases, would guide the cross-discipline understanding of the two. Thankfully, PMI and INCOSE recognize the need for collaboration, with the development of the PM-SE Alliance Working Group. The following list is a basic start in suggested organizational alignment in anticipation of certification alignment. Recommendations based on the four factors of confusion identified throughout this paper:

1. Factor #1: Cultural Differences -  Struggles for contrasting cultural knowledge. a. Provide cross-training for PMs, SEMs, SEs, and other functions via either formal

or informal training courses (on-the-job-training/mentoring, instructor led or web/computer-based).

b. Provide guidance in addition to elaborated processes providing context of expectations across the lifecycles. This may be in the form of presentations and joint collaboration experiences.

c. 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.

2. Factor #2: Education Overlaps - SE and PM incongruities due to certification and stove-piped discipline education.  

a. PMI and INCOSE should work together to align common language where it makes sense, in concert with other disciplines as applicable. The recently signed

   

(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. Agree to common word definitions typically used to communicate on the project, reinforcing the definitions during conversations: e.g. role/title, project/program, project manager/project management, verification/validation, and project deliverables/product deliverables.

c. INCOSE should align the language of their certification 14 function areas with the language of the SEHBK or other basis for certification.

3. Factor #3: Objectives Expectations - Typically due to cost and schedule conflicts. a. Agree and communicate the Tricks of the Trade (Mulcahy 2009) for schedule and

cost management among the disciplines. b. Include float and contingency in the execution strategy for schedule and risk

management of all schedules. c. Develop realistic schedules and cost targets agreed to by both disciplines. d. Define escalation mechanisms ahead of time if issues continue.

4. Factor #4: Ultimate Authority  -­‐  Align expectations.  a. A decade ago, Donald Kauffman asked, “Which profession should dominate the

intersection (Kauffman 1998)?” Although domination struggles persist today, organizations are recognizing the need for collaboration, not domination.

b. 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. One could certainly understand the need for big-picture thinking (for integration) and leadership for PMs, SEMs and SEs!

c. Identify, in writing, the role responsibility, authority, and accountability of project personnel. Roles will never be completely defined, although captured expectations move the project towards a more collaborative result. Follow the written word.

d. Work with the customer to ensure duplication of required documentation is eliminated for a more efficient and affordable project.

e. Align tools if it makes sense to do so. If tool alignment is not an option, since changing tools requires funds for purchase, maintenance, and retraining, at least obtain and communicate an understanding of how the tool outputs between the disciplines would work.

f. Align management plans and other documentation products to reduce duplication and gain a common understanding of how the project will be run.

The SEHBK recognizes the duality of the SE and PM roles. The SEBoK should continue to expand the understanding between the roles, although SE and PM discipline stovepipes and long standing accountability conflicts will most likely continue, although wishfully at a less intense rate. The Systems Engineering Body of Knowledge (SEBoK) (Pyster et al 2011), recently released, may eventually replace the SEHBK as a systems engineering certification source and may provide additional cross-discipline guidance. This may be an opportunity to further cross-align the INCOSE and PMI bodies of knowledge.

A more detailed analysis of the intersects is under consideration for a follow-on paper. 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. INCOSE, MIT LAI, and PMI through the Lean SE Working Group (WG) initiative, have completed a mapping of Lean Enablers for Project Management to the SEHBK, available from the WG . The INCOSE Risk and Opportunity Working Group has conducted a survey

   

that may, upon interpretation, help identify further SE and PM intersects and confusion. In any case, stay tuned for more research and alignment progress in the near future!

References ANSI  and  PMI.  2008.  A  Guide  to  the  Project  Management  Body  of  Knowledge  (PMBoK),  

Fourth  Edition.    American  National  Standard/Project  Management  Institute.  ANSI/PMI  99-­‐001-­‐2008.  

Arnold,  S.,  Stevens,  R.,  Jackson,  K,  Brook,  P.  1998.  Systems  Engineering,  Coping  with  Complexity.  Prentice  Hall  Europe.  ISBN:0-­‐13-­‐095085-­‐8.  pp.152-­‐168.  

Blanchard,  B.  1998.  Logistics  Engineering  and  Management,  5th  Ed.,  Prentice  Hall.  

Baldwin,  C.,  PMP.    2010.  Project  Management  and  its  relation  to  Systems  Engineering.      Systems  Engineering  Division,  Federal  Aviation  Administration  (FAA).  ACB-­‐2010.  

Dawson,  A.  1999.  Engineering  in  Integrated  Project  Teams.  Proceedings  of  the  ninth  annual  International  Symposium  of  the  International  Council  on  Systems  Engineering.  

Frank,  M.  2000.  Cognitive  and  Personality  Characteristics  of  Successful  Systems  Engineers.  The  Proceedings  of  the  International  Council  on  Systems  Engineering.  Minneapolis,  MN.  

Forsberg,  K.,  Mooz,  H.,  and  Cotterman,  H.  2005.  Visualizing  Project  Management,  3rd  Ed.,  J.  Wiley  &  Sons.  ISBN-­‐13  0-­‐978-­‐0-­‐471-­‐64848-­‐2.  

Gillespie,  A.  2007  Foundations  of  Economics  -­‐  PESTEL  Analysis  of  the  Macro-­‐Environment.  http://www.oup.com/uk/orc/bin/9780199296378/01student/additional/page_12.htm

 Goldratt  E.M.  1992.  The  Goal:  A  Process  of  Ongoing  Improvement.  North  River  Press;  2nd  Rev  

edition.  ISBN  0-­‐88427-­‐061-­‐0.  

Haskins,  C.,  ed.  2010.  Systems  Engineering  Handbook:  A  Guide  for  System  Life  Cycle  Processes  and  Activities.  Version  3.2.  Revised  by  K.  Forsberg  and  M.  Krueger.,  D.  Walden,  and  R.  D.  Hamelin.  San  Diego,  CA  (US):  INCOSE.  pp.  21-­‐23.  

IEEE  Std  1220,  2005.    Standard  for  Application  and  Management  of  the  Systems  Engineering  Process.  Institute  of  Electrical  and  Electronic  Engineers  (IEEE).    

INCOSE  Certification  Advisory  Group  (CAG).  2011.  Which  Level  is  Right  for  Me?  -­‐  function  areas  recognized  in  the  context  of  the  required  Systems  Engineering  experience:  http://www.incose.org/educationcareers/certification/details.aspx?id=level  

ISO  and  IEC  15288.  2008.  Systems  and  software  engineering  –  System  life  cycle  processes.  Geneva:  International  Organization  for  Standardization.    

———TR  19760.  2003.  Systems  Engineering  –  A  guide  for  the  application  of  ISO/IEC  15288.  Geneva:  International  Organization  for  Standardization.  

   

Kauffman,  D.  1998.  “Project  Management  and  Systems  Engineering:  Where  the  Professions  Intersect   -­‐   Generate   Synergy   Not   Conflict”.   Proceedings   of   the   eight   annual  International  Symposium  of  the  International  Council  on  Systems  Engineering.  

Lewotsky  K.  2006.    Skirting  the  Pitfalls  of  Project  Management/Project  Management  Success.  

http://www.advancedimagingpro.com/publication/article.jsp?pubId=1&id=2349&pageNum=3.  

Mulcahy,  R.  2009.  Project  Management  Tricks  of  the  Trade.  RMC  Project  Management  Inc.    

———2006.  PM  Crash  Course,  A  Revolutionary  Guide  to  What  REALLY  Matters  When  Managing  Projects.  ISBN:10932735-­‐07-­‐0.    

Mooz,  H.  and  Wilson,  M.  2003.  The  Heritage  and  Power  of  the  Integrated  PM/SE  Project  Cycle.  The  Proceedings  of  the  International  Council  on  Systems  Engineering.  Washington,  D.C.  

NASA.  1992.  National  Aeronautics  and  Space  Administration  Systems  Engineering  Handbook.  NASA-­‐SP6105,  SP-­‐6105.  

Pao  P.  S.  2005.  Attributes  of  System  Engineers:  The  Myth  of  System  Engineering.  http://www.seas.ucla.edu/mae/The%20Myth%20of%20System%20Engineering%20-­‐%20presentation.pdf  

Pyster,  Art,    Olwell,  Dave,  Squires,  Alice,  Hutchison,  Nicole,  Anthony,  Jim,  and  Enck,  Stephanie.  2011.  Systems  Engineering  Body  of  Knowledge  (SEBoK)  v.25.  

http://www.bkcase.org/  Sharon,  A.,    Dori,  D.,    and  deWeck,  O.  2010.  Systems  Engineers'  Perceptions  on  the  Adequacy  

of  Project  Management  Methods  for  Systems  Engineering  Management.    Sheard,  S.  A.  and  Motishari,  A.  2010.  A  Complexity  Typology  for  Systems  Engineering. The

Proceedings of the International Council on Systems Engineering. Chicago, IL.      

Biography Eileen Arnold, PMP, ESEP-Acq, has over 30 years of experience in the managing of multi-site projects/programs, and the engineering and management of HW, SW, and Systems across the project and product life cycles, including development, modeling and simulation, SE and PM competency frameworks, and measurement/analysis, for both the commercial and defense sectors. She gained insight into the project/program management world with her capability lead assignments at BAE Systems in Fridley, Minnesota. She has a B.S.E.E and an M.A and most recently received the Minnesota Federation of Engineering, Science, and Technical Societies (MFESTS) Charles W. Britzius life time achievement award. She has been an active INCOSE volunteer since 1996 holding leadership positions as Chair of the Competency Working Group, INCOSE Certification Advisory Group (CAG), and INCOSE Technical Board/Technical Leadership Team/Technical Operations. 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

   

Chapter newsletter The Integrator as well as acting web master for the chapter web site. 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.

   

Attachment A: Process/Activity/Knowledge Area Comparison  

SEHBK  (ISO/IEC  15288)  

SEHBK  Processes/Activities  

PMBoK  Knowledge  Areas  

PMBoK  Processes  

Technical  Processes  

Stakeholder  Requirements  Definition    

 

5.  Project  Scope  Mgmt    

           

 

 

4.1  Develop  Project  Charter  

5.1  Collect  Requirements  

5.2  Define  Scope  

5.3  Create  WBS  

  Requirements  Analysis  

5.  Project  Scope  Mgmt    

5.5  Control  Scope  

  Architectural  Design        

  Process  Implementation  

4.  Project  Integration  Mgmt  

4.2  Develop  Project  Management  Plan  

  Integration   4.  Project  Integration  Mgmt  

4.3  Direct  and  Manage  Project  Execution    

4.4  Monitor  and  Control  Project  Work  

  Verification   5.  Project  Scope  Mgmt  

5.4  Verify  Scope  

  Transition      

   Validation     Spread  across  all   Spread  across  all  

  Operation      

  Maintenance      

  Disposal   4.  Project  Integration  Mgmt  

4.6  Close  Project  or  Phase  

   

SEHBK  (ISO/IEC  15288)  

SEHBK  Processes/Activities  

PMBoK  Knowledge  Areas  

PMBoK  Processes  

  Cross-­‐Cutting  Technical  Methods  Operation    

   

Project  Processes   Project  Planning   4.  Project  Integration  Mgmt  

4.2  Develop  Project  Management  Plan  

Project  Processes  (cont.)  

Project  Planning  (cont.)  

 

6.  Project  Time  Mgmt  

6.1  Define  Activities  

6.2  Sequence  Activities  

6.3  Estimate  Activity  Resources  

6.4  Estimate  Activity  Durations  

6.5  Develop  Schedule  

6.6  Control  Schedule  

   

 

10.  Project  Communications  Mgmt  

10.1  Identify  Stakeholders  

10.2  Plan  Communication  

  Project  Assessment  and  Control  

4.  Project  Integration  Mgmt  

4.4  Monitor  and  Control  Project  Work  

4.3  Direct  and  Manage  Project  Execution  

  Decision  Mgmt   Spread  across  all   Spread  across  all  

  Risk  Mgmt   11.  Project  Risk   11.1  Plan  Risk  

   

SEHBK  (ISO/IEC  15288)  

SEHBK  Processes/Activities  

PMBoK  Knowledge  Areas  

PMBoK  Processes  

Mgmt   Management  

11.2  Identify  Risks  

11.3  Perform  Qualitative  Risk  Analysis    

11.4  Perform  Quantitative  Risk  Analysis    

11.5  Plan  Risk  Responses  

  Configuration  Mgmt     4.  Project  Integration  Mgmt  

4.5  Perform  Integrated  Change  Control  

  Information  Mgmt     10.  Project  Communications  Mgmt  

10.3  Distribute  Information    

10.4  Manage  Stakeholder  Expectations  

10.5  Report  Performance  

Project  Processes  (cont.)  

 

Measurement   8.  Project  Quality  Mgmt    

8.2  Perform  Quality  Assurance  

8.3  Perform  Quality  Control    

    11.  Project  Risk  Mgmt  

11.3  Perform  Qualitative  Risk  Analysis    

11.4  Perform  Quantitative  Risk  Analysis    

   

SEHBK  (ISO/IEC  15288)  

SEHBK  Processes/Activities  

PMBoK  Knowledge  Areas  

PMBoK  Processes  

Organizational  Project-­‐Enabling  Processes  

Life  Cycle  Model  Mgmt  

 

Initiating,  Planning,  Executing,  Monitoring  and  Controlling,  Closing    

4.1  Develop  Project  Charter    

4.2  Develop  Project  Management  Plan    

4.3  Direct  and  Manage  Project  Execution  

4.4  Monitor  and  Control  Project  Work  

4.6  Close  Project  or  Phase  

  Infrastructure  Management  

4.  Project  Integration  Mgmt  

4.3  Direct  and  Manage  Project  Execution    

4.4  Monitor  and  Control  Project  Work  

4.5  Integrated  Change  Control  

  SoS  Project  Portfolio  Mgmt  

Spread  across  all   Spread  across  all  

Organizational  Project-­‐Enabling  Processes  (cont.)  

Human  Resource  Mgmt    

9.  Project  Human  Resource  Mgmt    

9.1  Develop  Human  Resource  Plan  

9.2  Acquire  Project  Team    

9.3  Develop  Project  Team    

9.4  Manage  

   

SEHBK  (ISO/IEC  15288)  

SEHBK  Processes/Activities  

PMBoK  Knowledge  Areas  

PMBoK  Processes  

Project  Team  

  Quality  Mgmt   8.  Project  Quality  Mgmt    

8.1  Plan  Quality  

8.2  Perform  Quality  Assurance  

8.3  Perform  Quality  Control    

Tailoring  Processes  

Tailoring   Spread  across  all   Spread  across  all  

Specialty  Engineering  Activities  

Design  for  Acquisition  Logistics  –  Integrated  Logistics  Support    

   

   

  Cost-­‐Effectiveness  Analysis  

7.  Project  Cost  Mgmt  

7.1  Estimate  Costs  

7.2  Determine  Budget  

7.3  Control  Costs  

  Electromagnetic  Compatibility  Analysis  

   

  Environmental  Impact  Analysis  

   

  Interoperability  Analysis  

   

  Life-­‐Cycle  Cost  Analysis  

7.  Project  Cost  Mgmt  

7.3  Control  Costs  

  Manufacturing  and  Producibility  Analysis  

   

   

SEHBK  (ISO/IEC  15288)  

SEHBK  Processes/Activities  

PMBoK  Knowledge  Areas  

PMBoK  Processes  

  Mass  Properties  Engineering  Analysis  

   

Specialty  Engineering  Activities  (cont.)  

Safety  &  Health  Hazard  Analysis  

   

  Sustainment  Engineering  Analysis  

   

  Training  Needs  Analysis  

9.  Project  Human  Resource  Mgmt    

9.1  Develop  Human  Resource  Plan  

  Usability  Analysis/Human  Systems  Integration  

   

  Value  Engineering   7.  Project  Cost  Mgmt  

7.3  Control  Costs  

Agreement  Processes    

 

Acquisition  Supply   12.  Project  Procurement  Mgmt  

12.1  Plan  Procurements  

12.2    Conduct  Procurements  

12.3  Administer  Procurements  

12.4  Close  Procurements