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, SEMs, 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 engineers 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 organizations 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 havent 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 products 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 phases 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 organizations 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). Im not sure why he thinks SEs 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 organizations 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 SEs 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 PMs and SEs 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 PMBoKs 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 individuals 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) 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; 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 PMBoKs 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. INCOSEs 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 Plan Risk Responses Monitor and Control Risks

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 SEs/SEMs must unite in alignment with the organizations 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.ht m edition. ISBN 0-88427-061-0.

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

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) Technical Processes SEHBK Processes/Activities Stakeholder Requirements Definition PMBoK Knowledge Areas 5. Project Scope Mgmt Requirements Analysis Architectural Design Process Implementation 4. Project Integration Mgmt 5. Project Scope Mgmt 4.2 Develop Project Management Plan 4.3 Direct and Manage Project Execution 4.4 Monitor and Control Project Work Verification Transition Validation Operation Maintenance Disposal 4. Project Integration Mgmt Spread across all 4.6 Close Project or Phase 5. Project Scope Mgmt Spread across all 5.4 Verify Scope PMBoK Processes 4.1 Develop Project Charter 5.1 Collect Requirements 5.2 Define Scope 5.3 Create WBS 5.5 Control Scope

Integration

4. Project Integration Mgmt

SEHBK (ISO/IEC 15288)

SEHBK Processes/Activities Cross-Cutting Technical Methods Operation

PMBoK Knowledge Areas

PMBoK Processes

Project Processes

Project Planning

4. Project Integration Mgmt

4.2 Develop Project Management Plan 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

Project Processes (cont.)

Project Planning (cont.)

6. Project Time Mgmt

10. Project Communications Mgmt

10.1 Identify Stakeholders 10.2 Plan Communication 4.4 Monitor and Control Project Work 4.3 Direct and Manage Project Execution

Project Assessment and Control

4. Project Integration Mgmt

Decision Mgmt Risk Mgmt

Spread across all 11. Project Risk

Spread across all 11.1 Plan Risk

SEHBK (ISO/IEC 15288)

SEHBK Processes/Activities

PMBoK Knowledge Areas Mgmt

PMBoK Processes 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 10. Project Communications Mgmt

4.5 Perform Integrated Change Control 10.3 Distribute Information 10.4 Manage Stakeholder Expectations 10.5 Report Performance

Information Mgmt

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) Organizational Project-Enabling Processes

SEHBK Processes/Activities Life Cycle Model Mgmt

PMBoK Knowledge Areas Initiating, Planning, Executing, Monitoring and Controlling, Closing

PMBoK Processes 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

Organizational Project-Enabling Processes (cont.)

SoS Project Portfolio Mgmt Human Resource Mgmt

Spread across all 9. Project Human Resource Mgmt

Spread across all 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 Specialty Engineering Activities

Tailoring Design for Acquisition Logistics Integrated Logistics Support

Spread across all

Spread across all

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 Manufacturing and Producibility Analysis

7. Project Cost Mgmt

7.3 Control Costs

SEHBK (ISO/IEC 15288) Specialty Engineering Activities (cont.)

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 Cost Mgmt 12. Project Procurement Mgmt 9. Project Human Resource Mgmt

9.1 Develop Human Resource Plan

7.3 Control Costs 12.1 Plan Procurements 12.2 Conduct Procurements 12.3 Administer Procurements 12.4 Close Procurements