Classic PM: 04 Integration

Abstract

Integration is often referred to as a core area of project management knowledge because its tasks include compiling the Project Manager’s vision on project management, merging and coordinating the actions of other management processes and, more importantly, Integration is carried out throughout the life cycle of the project.

The word «integration» itself means cohesion, uniting something into a whole. In project management, the process group Integration plays the role of the core of the project - it brings together all areas of the project into a single entity and presents it as a main document of the project - Project Management Plan. The consolidating role of Integration can be illustrated as follows:

Integration is also responsible for balancing processes from different project areas, such as resolving conflicts between the process of Plan Quality Management and Determine Budget, Plan Risk Responses and Estimate Operations Duration, etc.
The main task of the manager is, of course, to carry out the project under constraints (starting from Time and Cost, and ending with Human Resources), compliance with all Requirements imposed by Stakeholders of the project. At the same time, it is impossible to plan everything in advance - sooner or later there will be additional requirements, restrictions and changes to the project content (Scope, practically). By the way, Change Management is one of the main problems in the Integration field. But let’s consider everything in order.

Integration includes the following processes:

• Abstract
  • 4.1 Develop Project Charter
    • Project Selection
    • Constraints
    • Project Management Information System
    • Assumptions
    • Statement of Work
    • Charters Versatility
    • Stakeholders Register
  • 4.2 Develop Project Management Plan
    • Project Documents
    • Project Management Plan Approval
  • 4.3 Direct and Manage Project Work
  • 4.4 Monitoring and Control Project Work
    • Work Authorization System
    • Change Request
  • 4.5 Perform Integrated Change Control
  • 4.6 Close Project or Phase

4.1 Develop Project Charter

Whatever a person wants to begin, first of all, it is necessary to answer the question - «Why?». Often this question is overlooked, following only the desire to receive a particular order. It is also not uncommon for the Charter to include everything starting from the technical details of the project and ending with the means of communication of the parties. This is fundamentally wrong! PMI believes that the Project Charter should contain only basic provisions, a superficial view of the future project. And this is a very justified approach - planning should take place in the Planning Process Group, i.e. after signing the Project Agreement, and spending company resources is not profitable when it is not yet known, whether the customer and the contractor agree to carry out the project under these conditions. This saves not only time, but money, as well.

So we figured out that the Charter should not contain project details, but should describe a superficial overview of the goals of the project. What else should be inherent in the Charter of the Project:

• Charter must contain a description of the company’s Business Case (what’s the purpose of the Project?). Business goals can be different - for instance, for external projects, such as profit generation or expansion of product markets; for internal - simplification and acceleration of internal paperwork. The described business objective should be in line with the company’s strategic goal;
• Charter should describe known limitations of the Project as identified in High-level Planning. For example, project time limits (“Project must be completed by August 2014”), project budget boundries (“Project budget is $150,000,000.”), resources («The outbuilding shall be built by 20 June 2013 by one team consisting of 10 people, one crane-manipulator and two delivery trucks») etc.;
• Charter should describe the Project that can be implemented. It would be more accurate to say that if the goals described in the Charter couldn’t be reached, then the executor should not sign it. Not surprisingly, signing an undeliverable project is quite common;
• Charter should contain a High-Level Risks overview. This may include, for example, management risks («Loss of interest in the project by the customer and termination of project financing»), market risks («Appearance of a cheaper and more modern product») etc. It is desirable that the list is not too large, because the detailed description of risks is carried out in the Planning Process Group;
• Charter should appoint a Project Manager and clearly describe his power. In practice, project managers do not always pass the entire Project Lifecycle. But, nevertheless, the Authorities of the Project Manager (apart from individuals) should be written in the Charter. Of course, each company has some table in which the positions are described within the organization, however, the Charter should contain such information;
  Since the Charter may refer to certain documents, reference to them should be clearly defined. If the Project Requirements point to some documents the Project must to satisfy, then these documents should be noticed in the Charter. what’s more, versions of noticed documents must be specified, as well. Let’s give an example: «The execution of the project should be carried out and documented in accordance with the requirements of PMBok v.5, as well as Requirements for documentation of project management, LLC «Barnyard», 2014». Imagine what happens if the version of the document is not specified, but a large number of changes were changed in newer versions?

Perhaps these are the main points that should be described in the Charter. Also I want to note that the Charter is a legal document and must be formed accordingly, I called this rule «To be acquitted in court». In other words, the Charter should describe the work not in this way: «The purpose of the project is to install a satellite antenna», but in manner like that: «The purpose of the project is to install on the roof of a house at the address of My Honest Street., 1, a satellite antenna capable of receiving video signal on frequency 12245.34 MHz».

More example of Project Charters could be found here.

Project Selection

To choose a project from a plenty, there are quite many ways. Justg a couple of them: personal preferences, the desire to implement something, the desire to change personal lifestyle, etc. All utterly given example aren’t suitable for choosing a project a company is ready to spend its resources. Ways to choose a project can be divided into the following groups:

• Benefit Measurement Methods;
  • Murder Board;
  • Peer View;
  • Scoring Model;
  • Economic Model;
• Constrained Optimization Methods;
  • Linear Programming;
  • Dynamic Programming;
  • Multi-Objective Programming;
  • Integer Programming.

Constraints

Constraints is an important element of the Charter and a significant argument when choosing a project from a batch. As noted above, every project is limited in some way - be it time, or resources, or budget. The Project Team (including, of course, the Project Manager) should balance and strive to execute the project with maximum respect for all project requirements.

At the time of drafting the Charter, not all limitations can be identified, but along with this, some general boundries must be identified. General constraints include, for example, project start and end dates, maximum budget for project implementation, human resource limitations, major content of the project, etc.

Project Management Information System

It is an information system that is used as a tool to facilitate project management. The most popular are MS Project and Primavera.

Assumptions

Assumptions, according to the term - is an event that can occur during the Execution of a project with some probability. Assumptions at the phase of the Initiation Processes Group, are very superficial in nature; at the phase of Planning Process Groups - more meaningful and assessed; at the time of Execution - is reactive in nature; during Monitoring and Control Process Group - the Project Team confirms or rejects the event of given assumptions. It can be said that this is a risk and, as noted in the relevant field of knowledge, the risk can be both positive and negative (i.e. can be beneficial to the Project but can also harm it).

Statement of Work

This is a description of the Project Product - the outcome of the Project. Usually used by the external customer to describe what the Project should implement (in Russia, this role can be Technical Task). That term will be unfolded in details in the Procurements area of knowledge. The Statement of Work may serve as an entry point for the Develop Project Charter process.

Charters Versatility

In addition to the official Project Charter, each party can create its own version of this document. In this case, each of these statutes can describe their business goals and requirements differently. For example, if a family needs to build a three-storey house designed for comfortable living, they are the clients of the project. In this case, the contractor (builder) in its own Charter may describe his private business goals such as performance of work according to requirements, profit and compliance with construction standards of the specified type of buildings; but, in the customer’s Charter - a construction cand be described as a comfortable house according to personal wishes, preferences and with the lowest costs.

Stakeholders Register

Practically, is an output for the Identify Stakeholders Process/management/classic/stakeholders#identify from the knowledge area of the Stakeholder Management/management/classic/stakeholders#mgm, but the list of Stakeholders is also part of the Project Charter, so here you have to give at least a brief description of what it is. In addition, the High-Level Requirements will be described with the involvement of Stakeholders. In drafting the Charter, its manager’s function to take into account all the most crucial requirements harvested of everyone who is on this register.

4.2 Develop Project Management Plan

Project Management Plan consolidates all the management plans of different project areas into one document:

• Scope Management Plan
• Schedule Management Plan
• Cost Management Plan
• Quality Management Plan
• Communications Management Plan
• HR Management Plan
• Risk Management Plan
• Procurement Management Plan
• Stakeholder Management Plan

In addition to the major project management plans listed above, it is also recommended that the following management plans be included:

• Configurations Management Plan is a plan for managing the results of the Project and the features of the Product or service that should be achieved at the end of the project;
• Change Management Plan - a plan of how the Project changes will be managed. May include a description of the rules for maintaining change histories, a description of the processes and procedures required for changes to become effective, etc. May include, for example, the following information: change control procedures (who performs them), ranking of changes and determination of those who are responsible for them, rules of meetings on the issue of changes, list of means used to control the execution of changes, etc.;
• Requirements Management Plan - the document includes information of how the requirements gathering process will be conduced, ensuring and compling with the requirements of stakeholders, monitoring new and modifying existing requirements, etc. Often it’s necessary (and sufficient) to create an extended Requirements Traceability Matrix;
• Processes Improvement Plan is a plan that describes the processes and procedures required to improve existing processes, which are mandatory for execution during Project Executionссылка на процессы#execution.

In the Project Management Plan, you can briefly describe each area of knowledge and give a reference to the detailed management plan of a given area of knowledge, as well as giving a detailed description in the main Project Management Plan. PMI says that there is no need to always give an extended review of the management plan of a particular area - it all depends on the style of management, project requirements, corporate requirements, objective circumstances, etc. The Project Manager should determine on the basis of his or her experience the format and detail both the Project Management Plan, and all extended plans.

The Project Management Plan must contain or refer to the Baseline for the three areas of knowledge - the Scope Baseline, the Schedule Baseline, and the Cost Baseline. Taken together, these baseline plans are referred to as the Performance Measurement Baseline. PMI categorically insists on the presence of these elements, because their presence makes it possible to assess the performance of the Project Team, the Project Manager, the efficiency of processes management, make some conclusions and adjuct not only in the Project but the entire company, as well. Unfortunately, in Russia, as a rule, only a basic timetable and a partial basic plan of implementation are created. Evaluation processes for the implementation of baseline plans are covered in corresponding articles.

So, the Project Management Plan ideally should include:

• Description of project management processes - the processes that will be applied on the Project. It is strongly recommended to write down all processes that must be followed by all project participants (on which the Project Manager has influence);
• Management plan for each area of knowledge or reference to them;
• Baselines;
• Configuration Management Plan, Change Management Plan, Requirements Management Plan, Processes Improvement;

Project Documents

This category includes all project-related documents, except those which are related with a particular knowledge area plans. The Project Documents also include references to procedures, rules, regulations, etc., applied in the organization.

Project Management Plan Approval

Before proceeding to the Execution of the Project, the Project Management Plan must be signed by the client and the contractor. This is a mandatory condition that helps to increase the customer’s involvement and enjoyment of the Project, improve their understanding of the Project, as well as giving the contractor confidence that the plan has been approved and the customer agrees with all its parts.

Another aspect that deserves special attention is that after any change to the Project Management Plan, it must be reviewed further and re-approved. Of course, this applies only to tremendous changes - it’s not desirable to address the customer about any «trifles».

It is also recommended to schedule a Kickoff Meeting, where the Project Management Plan should be presented and all key aspects unfolded. The meeting should involve all key Stakeholders - this helps to improve communications and understanding of the Project.

4.3 Direct and Manage Project Work

In essence, it is just the execution of project work according to the Project Management Plan, which is under the supervision of the Project Manager. Belongs to the process group Execution.

The project management methodology requires that the Project Manager in the process of Direct and Manage Project Work is directly involved in managing (not controlling) of Time, Cost, Risks, Quality and other areas of knowledge. In addition, it is necessary to pay attention not to the Project as a whole, but to each of its areas separately - the Project Manager must always remember and manage all areas of the Project!

The most notable thing here is that the Project Team and Project Manager should only perform those changes that have passed the Perform Integrated Change Control process and have been officially agreed (they are one of the inputs to the process). For instance, among them might be named either changes caused by any Defect Repair product or service (mistake of the performer), or Corrective or Preventive changes. These changes should be the subject of consideration at the Meetings, which must be held by the Project Manager, see in more details the corresponding section of Communications knowledge area.

4.4 Monitoring and Control Project Work

This process is very important for understanding - the main task is to collect, measure and document information about project execution. Monitoring and Control Project Work provides an understanding of the success of the project and allows Project Manager to request changes based on measurements. The analysis is exactly what is actually done and compared with what was planned (methodology categorically prohibits to indicate incorrect values when taking measurements). Monitoring and Control Project Work is part of the knowledge area of Integration, which means that this process should be considered as unifying.

Integration knowledge area itself covers all areas of the Project, thus the Monitoring and Control Project Work process should be considered as a blanket for all other knowledge areas.

This process receives Work Performance Information as a particular input, which is subsequently processed. Moreover, the output of the process will be decisive for determination if changes in the Project are necessary or not. Generally, any kind information on the progress of the Project that may play a role of an output, for instance:

• Forecasts (Time and Cost);
• Detected and predicted Risks;
• Current Achievements;
• Current status of the project.

For example, during the construction of the house, the Project Team had proceeded standard Control Quality procedure and found that the roof construction have a plenty of defects. Seeing that workers who are resposible for that type of works have an absence in the knowledge of confirmed standards (say, GOST 12.3.040-86), the Project Manager claims for a change - «It is necessary to have 2 employees familiar with the principles of roofing in accordance with GOST 12.3.040-86». Hiring or training will depend on the specific situation.

Work Authorization System

It is part of the Project Management Information System, which controls and manages Activities and Work Packages that must ti be started soon.

Change Request

Can occur for different reasons and any any phase of the Project. In addition to Integration, Change Request can occur within any knowledge area, particularly in the during the monitoring and managing of Time, Cost, Scope, etc. Wherever Change Request comes from, it should be processed in the process of Performing Integrated Change Control!

Every Change Request can be referred to one of three major group:

• Defect Repair - ther simplest, these are the defects that have been committed by the contractor. This kind of changes must be corrected by the contractor, which characterizes it as extremely undesirable. The presence of a large number of defects in the project is usually either a lack of planning or a sign of poorly executed Quality Assurance and Quality Control;
• Corrective Action – these are changes that adjust the work, bringing it in accordance with the Project Management Plan. For example, «delivering new equipment to increase the performance of…» or «cleaning ventilation equipment using…»;
• Preventive Action - changes that are intended to handle negative (or positive) effects on the Project in the future. It is desirable, of course, to be aware of this probability before the start of the project and mark it as Risk, but it is impossible to foresee everything. A classic example is the controlled removal of a nozzle from the roof of a house.

4.5 Perform Integrated Change Control

The main goal of the Project Manager is to protect the Project from any negative factors affecting it and enhance. One of the most negative factors that have terrible influence onf the Project is Change. Of course, it is better to plan everything in advance, because making changes is very expensive, takes longer, and the quality of the product or service suffers from them. However, change management is an integral part of project management. It is also logical that the earlier a potential change is identified, the more effectively it can be implemented, avoiding haste and problems. The PMI particularly highlights Change Management as an area where mistakes are often made, which causes a large number of projects to suffer. Consider what the standard thinks about this.
The mandatory requirement of PMI says that any Change should be transferred through this process, i.e. if you need to add something to the Scope, then you need to start the Perform Integrated Change Control process; if there is a need to shorten the lead Time or a new Risk has emerged and an additional human resource is required, all of theese changes should be passed through Integrated Change Control.

The second and equally important aspect is that before each Change, it is necessary to calculate the possible damage of this particular Change, even if the Change does not affect other aspects of the project. For example, during the construction of a house, there might be a situation when the customer wants to paint the house in beige color, although it is already orange (according to initial Project Management Plan). This will cause additional costs, both Financial and Time, and possibly problems with other areas.

The third aspect is that the result of Integrated Change Control process is either confirmation or rejection of a change. To do this, you will need Baselines that are part of the Project Management Plan, as well as a clear understanding of the Project framework and a full description of the project results. The responsibility of the Project Manager is to prevent the implementation of unapproved changes. The Project Team should also be aware that no unapproved changes can be performed, as described in detailref to HR in the relevant knowledge area.

The fourth aspect is that the Project Manager should try to predict» the subsequent development of events and try to make Preventive and Corrective changes before they will cause defects in a product or service.
And finally, the fifth important nuance of Change Management is that the Project Manager is obliged to keep records of changes in the Change Log - this will help prevent similar changes in future projects. For example, when installing a window frame by the company “X” the usage of mounting foam by “Y” was extraordinary and the foam by “Z” is prefferable. This record should be placed in the Change Log for subsequent warning of similar problems in other projects.

Next, let’s list the necessary conditions for a problem-free change management:

• Collect a complete list of Requirements from Stakeholders;
• Produce a high-quality analysis of Risks;
• Plan time and cost Reserves;
• Follow the Integrated Change Control process;
• Availability of Change Requests templates;
• Clearly identify person(s) responsible for implementing the change;
• Assess the impact of changes on other aspects of the project;
• Assess the impact of change on business processes;
• Apply only confirmed changes.

So, let’s say you’ve performed assessment of the impact on other areas of the Project, what happens next? The next step is to obtain confirmation that this change does not pose a critical risk to the project - it’s not beyond the Scope of the project and can be implemented. According to PMI, this should be decided by the Change Management Committee. The committee is not a group of people who do nothing besides that; this committee can be a group of people from both sides of the project (the project customer and the performer), external experts, team members, etc. Acceptance or rejection of the change should be documented, so in case of acceptance - this should be reflected in the Project Documents and carry out additional Project Planning iteration; in case of a rejection, the reason for refusal should be specified.

So, let’s take a step-by-step look at change management:

1. Constantly prevent root problems causing changes
2. Permanently identify change. Changes may come from different sources, different content and with different requirements;
3. Assess the possible damages caused by changes;
4. Create Change Requests. The rules for completing of change requests must be written in the Project Management Plan or in the documentation of the company’s standard processesссылка%20на%20enterprise%20env%20fact, at least;
5. Follow the procedure of Integrated Change Control:

           a) Evaluate the Change. Answer key questions that will help reject changes out of scope;
        b) Analyze the properties of the Change. The term “properties” is defined as what effect change will make to the Project. This can be either a shift of some milestone (milestone) or addition of Risks, or a request for new human resources etc.;
           c.Application or rejection of the Change;
           d. Update status in the Project Management Information System;

6. Update Project Management Plan and Baselines. This can include management plans for a particular knowledge areas (Scope, Time, Cost, Risks, etc.). If the change affects Scope, Time or Cost, the corresponding master plans should be updated and subsequently measured and managed in accordance with the changes made to the Project;
7. Enter a record to Change Log;
8. Manage the expectations of Stakeholders that could be affected by the Change;
9. Continue project Execution according to updated plans.

4.6 Close Project or Phase

This is a process that completes the Project or one of its phases. The project may end successfully or unsuccessfully, but regardless of the outcome, the Project Manager must complete the Project or phase. This process is characterized by the fact that the Project Manager must analyze whether the entire project has been completed, whether all the Requirements of the Stakeholders have been met, archive all the Project Documents, receive official confirmation of successful completion of the Project, describe the reasons of the Project failure, provide the results of the Project to the customer (even in case of not finished product).

Also during this process, it is desirable to summarize of Project Manager’s work, the results of the Project Team’s work, correctness of applied decisions and analyze communications. The methodology requires a review document to be compiled and included in the Accumulated Knowledge Database. It should include all the non-standard events of the Project, briefly describe their causes, ways to solve them and suggest ways to prevent them.

In addition to complete the Project in term of [Integration] phase, the Close Project or Phase is also presented in Procurements knowledge are (to be precise, in the Close Procurements procedure). Applicably for all processes related to [Integration], the Close Project or Phase process covers the whole spectrum of project completion, consolidating processes from other areas of knowledge to carry out the ultimate project completion.