Integration Management - Knowledge Area

National Project Management System
Business Projects-IT-Enabled

TITLE:

Integration Management Knowledge Area

1. EFFECTIVE DATE:

December 2010

2. AUTHORITY:

This policy-related document is issued under the authority of the Deputy Minister, Public Services and Procurement Canada (PSPC).

3. CONTEXT:

This knowledge area is to be implemented in conjunction with the PWGSC/PSPC National Project Management System (NPMS) policy.

4. PURPOSE:

To describe the components and requirements of the National Project Management System (NPMS) as applied to Project Integration Management.

5. DETAILS:

The Project Management Body of Knowledge (PMBOK®), Project Integration Management knowledge area is focused on processes and the coordination of project management activities within the Project Management Process Groups.

The objective of the NPMS Integration Management Knowledge Area is to align the PMBOK® knowledge areas into the NPMS framework through the core NPMS control point deliverables.

For the Business Projects-IT-Enabled Stream, Integration Management is the main process by which the Project Director and the Project Manager ensure that all components of the project are adequately developed, coordinated and managed during the entire project lifecycle from inception to close out.

The main project management products of the Integration Management Knowledge Area are:

  • the approved preliminary project plan (PPP), which describes how the project will be managed during the Identification Stage;
  • the approved project charter, which is the document that formally authorizes a project, and documents the expected deliverables, risks, constraints, timelines, governance and roles and responsibilities; and
  • the approved project management plan (PMP), which describes how the project will be managed and how the product or solution will be delivered and implemented during the Delivery Stage.

Note: Abbreviated versions of the project charter and PPP templates are available for projects following the « Lite » NPMS Procedure.

Objectives

The purpose of project Integration Management is to ensure that:

  • the project meets the need or opportunity for which it was created;
  • the project is delivered on time, on budget and within the approved scope; and
  • the project is monitored, controlled and delivered in accordance with the NPMS Knowledge Area best practices for the Business Projects-IT-Enabled.

Integration Management Process by NPMS
Stage and Phase

Inception Stage

Definition phase:

The project conducts a preliminary assessment and documents a business need or opportunity in the form of a statement of requirements (SoR) document. The document does not outline high-level project scope or refer to a solution at this point; it simply requests that management provide seed funding for further analysis of the problem.

Identification Stage

The objectives of Integration Management during the Identification Stage are to:

  • develop a comprehensive PPP, Business Case, and project charter with associated documents adapted to the size, complexity, and risk of the project that are consistent with industry standards and Government of Canada (GC) policies;
  • align the project to strategic goals, investment plans, and business needs as well as to project stakeholder objectives;
  • address project constraints and risks;
  • ensure that the project deliverables are consistent with the SoR and the business requirements;
  • begin project communications with and among stakeholders;
  • establish and implement the Change Management process; and
  • establish and implement project governance structures.

During the Identification Stage, the PPP is the principal mechanism utilized by the Project Director or Manager to formally define the goals and objectives of the project and to document the project's key parameters.

Initiation phase

Projects provide a scope statement in the PPP along with a set of milestones and deliverables relevant to the Identification Stage (e.g. creation of a feasibility report and Business Case). During the initiation phase, business requirements are documented. This document constitutes the foundation upon which the project scope is primarily built; however, constraints such as those related to cost and time may limit the scope.

Feasibility Phase

The project may conduct an environmental scan to review available technical solutions to the business problem and to assist in the feasibility assessment process. The feasibility report identifies several options and the high-level activities related to each option. The preliminary analysis performed during the Feasibility Phase allows the project to narrow down the potential solutions to a manageable set of viable options. These viable options will be subject to further analysis, when developing the Business Case.

For « Lite » projects, the preliminary screening of options is part of the Business Case and a feasibility report is not required. A Conceptual Architecture Solution document is produced during the Feasibility Phase. A Concept of Operations document is either produced, or an existing document is refined to reflect how a solution may operate once implemented. These documents provide support to the scope definition process.

Analysis Phase

The objective of the Analysis Phase is to recommend a solution in order to achieve the desired outcome that was initially defined in previous phases. The Business Case presents the analysis and the recommended solution while the project charter summarizes the project parameters for the Delivery Stage, such as the initial scope, high-level deliverables and milestones, the roles and responsibilities, and the governance structure.

Identification close out phase

The objective of the Identification Close-Out Phase is to facilitate the transition from the Identification Stage that is focused on business analysis, to the Delivery Stage, which is focused on the development/acquisition and implementation of the solution selected. The Identification Close-Out Phase is the opportunity to review how the Identification Stage performed against its planned time, cost, quality, scope, and risks. It is also during this phase that the issue and risk logs are closed, while issues and risks still active are transferred to the next stage documentation. The Identification Stage Close-Out Document (ICOD) is the control point deliverable used to record the completion of core deliverables and the status of the key close out activities for this Stage.

In light of the preliminary project approval (PPA) decision obtained in the Analysis Phase, project teams ensure that the final records prepared in this Phase are updated including the Scope Statement, the high-level Work Breakdown Structure (WBS), payment records, actual schedule and the list of the deliverables produced.

NOTE: If the project is not approved at PPA, the PPP is finalized and a Project close out document is produced.

Delivery Stage

Planning Phase

The objectives of Integration Management during the Delivery Stage are:

  • to develop a PMP during the Planning Phase and manage how the project will be delivered;
  • to ensure that the project deliverables are consistent with the business requirements and aligned to the department's strategic goals and investment plan;
  • to refine and update the project governance structure as required for the Delivery Stage; and
  • to obtain required approvals for key deliverables such as the project charter and PMP.

During the Planning Phase the project produces the PMP. For Business Projects-IT-Enabled, the project management plan defines how the project will be managed in accordance with core PSPC project management knowledge areas throughout the Delivery Stage.

For a detailed description of the contents of the PMP, please see Annex B - project management plan.

Change Management is part of the Integration Management Knowledge Area Change Management is one of the most important processes covered in the PMP. This subject is covered in Annex A - Change Management Process.

Design Phase

During the Design Phase, the product design is refined, finalized and approved. The approved project charter and the approved PMP are updated to reflect the approved design.

Implementation Phase

During the Implementation Phase, the approved design is turned into products, processes and results. The product is tested, approved for release and then implemented in accordance with the PMP.

Delivery Close-Out Phase

Once the project is complete, the project team prepares the close out document (COD), including lessons learned and conducts the administrative and contract close out activities, documenting the project close out process thoroughly. The WBS and any other subsidiary scope management documents, such as the change log attached to the Scope Management Plan, must be updated to summarize all scope changes that were proposed. If the change was approved, the log details the implementation activities and the consequences of the change activities.

Integration Processes that Cross All Phases

Direct and Manage Project Execution

The direct and manage process requires the Project Manager and project team to perform multiple actions to execute the PMP and to accomplish the scope of work defined in the scope statement and the fully elaborated WBS. Among other things, these actions include:

  • performing activities, expending effort and spending funds to accomplish project objectives;
  • conducting cost, time, scope, HR, procurement, communications, risk, quality requirements and change management activities;
  • reporting on project key performance indicators; and
  • adapting approved changes into the project scope, schedule and budget.

Monitoring and Control

During all phases of the project lifecycle, the Project Manager, the project management team and the project governance structure are responsible for monitoring and controlling the project.

The monitoring and controlling process is performed to monitor project processes associated with initiating, planning, executing and closing the project. Corrective actions are taken to control performance and to adapt the project to approved changes. Monitoring activities include, collecting, measuring and disseminating performance information. The performance management system and the reporting processes are key to effective monitoring and control. Monitoring gives the project management team insight into the project's health. Independent validation and verification assists the delivery organization by ensuring objectivity and consistent application of standards and practices both within the project and across the project portfolio.

The project monitoring and control function is concerned with:

  • comparing actual performance to the PMP and to the project charter;
  • assessing performance to determine whether corrective actions are required;
  • analyzing, tracking and monitoring project risks and issues;
  • implementing risk and issue response plans;
  • maintaining an accurate information base including action and decision logs;
  • providing information via the status reporting and communications processes;
  • providing forecasts to update current schedules and budgets; and
  • monitoring the implementation of the current plan as well as approved changes.

6. SCOPE:

This Integration Management Knowledge Area applies to all PSPC projects.

7. DEFINITIONS:

Project Scope Statement
PMBOK® defines the narrative description of the project scope, including major deliverables, project objectives, project assumptions, project constraints, and a statement of work, and provides a documented basis for making future project decisions and for confirming or developing a common understanding of project scope among stakeholders.
Project Integration Management
According to PMBOK®, Project Integration Management includes the processes and activities needed to identify, define, combine, unify and coordinate the various processes and project management activities within the Project Management Process Groups.
Project charter
A project charter is defined as a document issued by the project initiator or sponsor that formally authorizes the existence of a project, and provides the Project Manager with the authority to apply organizational resources to the project activities. This document addresses the project's key risks, governance, scope, WBS, time estimates, resource requirements, and cost at a level sufficient to gain budget approval.
Project management plan
The PMP is a formal, approved document that defines how the project is executed, monitored and controlled.

8. RESPONSIBILITIES:

All parties responsible for conducting Integration Management activities and developing components of the project charter and the project management plan are strongly encouraged to:

  • consult with other Project Leaders/Managers, Senior Project Managers, technical experts and other subject matter experts (SMEs); and
  • consider historical information and lessons learned from similar projects within PSPC when producing/updating these core project management deliverables and subordinate project management documents.

Project Lead (Business Side)

The Project Director/Project Lead defines the business need or opportunity, leads the identification stage activities and represents the client during delivery. The specific responsibilities include:

  • planning, controlling and providing overall management oversight of the entire project in accordance with the NPMS Framework for Business Projects-IT-Enabled;
  • setting general direction and priorities;
  • authorizing all planning documents;
  • reviewing and endorsing the project charter;
  • approving the PMP and other project deliverables;
  • being accountable for budgets;
  • recommending major changes that impact scope, time and cost;
  • approving changes that do not impact hard milestones and costs;
  • monitoring progress;
  • assigning/authorizing resources;
  • liaising with the project steering committee;
  • acting as primary project interface between the business and the project teams; and
  • being accountable for any project procurement activity (or delegates this to a Procurement Manager).

Project Manager

The Project Manager is responsible for overall project Integration Management. The specific responsibilities include:

  • developing the key Integration Management document deliverables:
    1. the PPP
    2. the project charter, and
    3. the PMP
  • ensuring that the project team is aware of and follows project integration processes in performing their associated responsibilities;
  • developing the project scope statement;
  • eliciting project and product scope input from stakeholders;
  • documenting the project scope;
  • creating the WBS;
  • verifying project scope;
  • directing and managing project execution;
  • chairing project meetings;
  • monitoring the project;
  • controlling changes to all aspects of the project (e.g. time, cost and schedule); and
  • reporting on the key project indicators: scope, time and cost.

Client/Business Line Owner

The Client/Business Line Owner is responsible for the following activities:

  • providing input to the scope analysis and definition process;
  • providing input to the project integration process;
  • supporting the Project Manager in the development of the scope statement;
  • approving the project scope baseline and all significant changes to the project scope, time and cost; and
  • participating in project direction, monitoring and controlling functions.

Project Team

The Project Team is responsible for the following activities:

  • developing and maintaining the associated project deliverables that contains the fully elaborated project and its products;
  • performing their assigned tasks without deviating from the approved scope, time and cost plans;
  • reporting their actual and forecast work effort; and
  • submitting change requests that may impact project scope, time and cost as and when required.

Stakeholders and Subject Matter Experts (SMEs)

The stakeholders and SMEs are responsible for the following activities:

  • providing input into the project scope analysis and definition process; and
  • supporting the Project Manager in the development of the Integration Management deliverables:
    • the PPP
    • the project charter and
    • the PMP

9. REFERENCES:

10. ATTACHMENTS:

11. ENQUIRIES:

Please direct enquiries about this knowledge area to the Director, Centre of Excellence, ITSB Project Delivery Office.

Annex A - Change Management Process

Background

Change Management is a process used to ensure that change requests are assessed for their impact to all aspects of a project as well as the outcome that the project aims to achieve. The Change Management Process is performed from project initiation to close out.

The Change Management Process used in a project must be described in the PMP.

Objectives

The key objectives of the Change Management Process are:

  • to manage each request for change, in order to keep the scope of the project under control with full traceability;
  • to allow the impact of all changes to be understood, documented and managed;
  • to make sure each request for change is assessed by key project stakeholders;
  • to make sure each assessed change request is accepted, rejected, or deferred by the appropriate authority; and
  • to enable the orderly implementation of each accepted change.

Roles and Responsibilities

Change Manager

Either as a dedicated role or additional responsibilities to another role, the Change Manager is responsible for the overall management of changes on the project. Specific responsibilities include:

  • reviewing and understanding the change requests;
  • requesting impact assessments from stakeholders;
  • compiling and summarizing the impact assessments;
  • monitoring the progress of the change;
  • updating the change log and the project status report; and
  • closing the change requests.

Project Manager

The Project Manager is responsible for the following change management activities:

  • providing resources to undertake the change management activities (personnel and tools);
  • defining the Change Management Process in the PMP; and
  • ensuring that all personnel are following the established Change Management Process.

Change Management Board

The Change Management Board, consisting of the project management team and additional stakeholders as required, is responsible for the following activities:

  • reviewing the change request;
  • approving the change request if within the authorization level; and
  • reviewing the progress of the change request.

Stakeholders

Stakeholders may include clients, members of the project team, and external contributors. Their responsibilities include:

  • reviewing the change request;
  • determining the anticipated impact;
  • implementing approved changes;
  • providing the status of the change request; and
  • attending all relevant change management meetings as needed.

Project Steering Committee (PSC)

The Project Steering Committee is responsible for:

  • reviewing and endorsing all recommended changes to project scope, time, or cost.

Standard Change Management Process

The process described in this document is composed of activities and procedures grouped and sequenced under the following headings:

  • create a change request;
  • submit the change request;
  • assess impact;
  • approve the change request;
  • track the change request; and
  • close the change request.

These activities are described in the sections that follow.

See link below for the long description.

Figure 1 - Change Management Process

A larger image of this diagram - Change Management Process, is available on a separate page.

  1. Create a Change Request

    The first step in the Change Management Process is the identification and definition of the need for a change to one of the project deliverables. Any project stakeholder (e.g. client, user, member of the project team, or external contributor) may identify a need for a change. The stakeholder then becomes the Office of Primary Interest (OPI) of the change request. The OPI must clearly describe the change and provide reasons for the change, using the Change Request (CR) template. The output of this step is a clearly documented CR.

  2. Submit the Change Request

    Every CR is to be sent to the Change Manager who reviews it to ensure that all needed information is present. The Change Manager may wish to perform a preliminary analysis in order to more fully understand what is involved in the change and may conduct meetings with the originator of the request to verify the request. A number is assigned to the CR, and it is recorded in the Change Request log.

  3. Assess Impact

    The Change Manager sends the CR to all affected stakeholders who must assess the impact of the CR on their work. The completed CR must be returned to the Change Manager within a timeframe to be specified by the Project Manager. The Change Manager then compiles the impact assessments, conducts a thorough analysis of the impact, updates the CR form and provides it to the Project Management team. Potential impacts are:

    • Budget Impacts: Any change or circumstance (whether in or out of scope) which requires an increase to the allotted budget will require approval by the Project Steering Committee (PSC).
    • Schedule Impacts: Any changes that impact the scheduled delivery of approved key milestones of the project will require PSC approval.
    • Scope Impacts: Any changes that involve either a decrease or an increase in scope that cannot be contained within the allotted budget and schedule will require PSC approval.
  4. Approve the Change Request

    The Change Management Board can approve the CR if the impact on the project is within the impact parameters identified above. If not, the Change Manager will convene the PSC and provide them with the CR in order for them to review the change.

    If a CR is approved, it is assigned to a stakeholder; normally the Technical Manager, for implementation and all relevant project documentation must be updated. If the CR is not approved, the Change Manager must inform the OPI and close the CR.

    NOTE: Approved changes that affect scope, time or budget will require that the core deliverables be updated.

  5. Track the Change Request

    Progress on approved change requests will be reviewed on a weekly basis as part of the Project Management team's weekly meeting.

    The Change Manager ensures that all of the activities related to the requested change are tracked accordingly. The Change Manager updates the Issue Register accordingly and also updates the Project Status Report to reflect any outstanding changes.

  6. Close the Change Request

    Once the change has been implemented, the Change Manager closes the Change Request and updates the Change Log and the project status report. The OPI, the Project Management team and, if necessary, the PSC will receive confirmation from the Change Manager that the change has been completed. An important part of Change Request Close Out is the documentation of lessons learned during the course of the change activities.

    A change request may not be implemented because it fails to resolve the problem it was designed to address. If so, the Change Log will need to be updated to reflect that fact. The original Change Request will be closed and a new change request will be created. In these cases, the entire change management process begins again.

    All change requests, whether approved or not, shall be retained as project records. The output of this step is the closure of the Change Request.

Annex B - project management plan

The project management plan covers the following knowledge areas:

Scope Management: This includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. Project Scope Management is primarily concerned with defining and managing what is and is not included in the project. The project scope should be managed so that any proposed changes that could result in additional cost and/or time are identified early enough to either obtain additional funding and/or time extensions to ensure completion. Without approval such changes to scope are rejected and the original scope is maintained. Featured within the processes composing scope management, is requirements management which describes how requirements will be managed throughout the project. The subject is covered in an annex of the Scope Management Knowledge Area.

Time Management: This involves identification of project duration, milestones and activities and description of the strategy to manage the project timelines within the parameters of the project.

Cost Management: This knowledge area begins with the identification of the investment options and source of project funding. Cost Management describes the strategy to manage the project finances within the approved funding parameters, including lifecycle costing issues, cash flow constraints and approval requirements. Cost Management activities include the processes involved in planning, estimating, budgeting, and managing the costs so that the project can be completed within the approved or amended approved budget.

Risk Management: This includes the processes concerned with conducting risk management planning, identification, analysis, responses, monitoring, reporting and assigning risk management responsibilities on a project. Consideration of the cost implications of risks is important in order to accurately develop the project contingency funding, a key tool to completing the project within the approved or amended approved budget.

Procurement Management: This involves the identification of the different types of contracted services, such as professional and technical services, and product components required to produce the end product of the project. Procurement Management includes a description of the strategy to solicit, acquire and coordinate those services and product components to meet the project objectives.

Quality Management: This process identifies the quality assurance and control processes required to ensure that the end product of the project will satisfy the needs for which it was intended.

HR Management/Staffing Management: This knowledge area identifies the roles, responsibilities, accountabilities, skill sets, stakeholders' authorities and provides a description of the strategy relative to team development, succession planning, matrix management initiatives and partnering.

Communications Management: This knowledge area identifies and defines the project communications needs and constraints. It also describes the strategy and tools required to establish the appropriate communications network and manage information collection, distribution, progress reporting and record keeping.