Project Management at a Glance

Project Integration Management

by

In our first five segments of this series on project management, we outlined the five process groupsof project management: initiation, planning, execution, monitoring and controlling, and closing. If we were talking about the design of an automobile engine we might have discussed the ignition system, fuel system, air/oxygen control, exhaust, and temperature control. But designing autonomous components of a complex system, without concern for how to make them all work in concert, is only half the job.

Project Integration Management, briefly stated, is the process by which all other processes within the project methodology, whichever is used, are combined into a unified whole to enable a successful project.

Skillful integration management is what separates the merely good project manager from the great. A good mechanic might know all the tricks in the book, but a great one knows the tricks that aren’t in the book. That’s exactly why writing about Project Integration Management is a difficult task and why you’ll never find an exhaustive discussion of it written anywhere. The simple truth is, truly skillful integration management is the result of a combination of knowledge of all the project management basics combined with years of experience. Integration management is the process of making difficult choices and trade-offs. It’s the process of seeing, understanding, and controlling interdependencies among not only project processes, but among people and organizations both inside and outside of the organization for which the project is being undertaken. Therefore, the project manager needs to have a thorough understanding of the organization in which he or she is working, including formal and informal power structures. Getting back to our example of the automobile engine, we’re not dealing with a modern computer-controlled BMW. Instead, imagine a 1957 Chevy. It can be a tricky, cantankerous, fickle machine that works magnificently one day with specific settings, and on another, with a change of weather, or just for reasons of “animal spirits,” decides not to run at all. That “shade-tree mechanic” is the expert project manager who can still get all the parts to work together and purr like a cat.

In a project all processes interact to some degree. Some interactions are obvious—a decrease in the budget will affect project deliverables, schedule, and/or risks. Other details of the project—e.g., a change to the toolset the computer graphics designers are using—may go unnoticed and may even be transparent to the rest of the project. However, considering whether that seemingly slight change may affect any other part of the project is the nature of Integration Management.

The six process areas of project management that we want to ensure are integrated are:

• Project Charter
• Project Management Plan
• Project Execution
• Monitor and Control
• Change Control
• Project Closure

We’ll consider each in turn and discuss how the concept of Project Integration relates each to the others.

Project Charter

The Project Charteris the document that formally authorizes the project. It documents the initial requirements and spells out exactly what the need of the organization is that requires that time and money be spent on the project. The Charter defines the relationship between the requestor, or customer, and the project team; without the formal approval of the charter, there is no project.

So where does integration fit in? Bear in mind that the process areas listed above are all tied together during the project. Like it or not, they are all integrated. The process areas in the above list except Project Closure are happening at once, as if all the words from this article were combined into one blob and thrown on the page. The skillful project manager is the one who can look at that blob and make sense of it, can integrate the process areas intelligently and effectively.

The Project Charter integrates information from the statement of work (SOW), the project’s business case, any relevant contracts (e.g., if the project is managed by an outside vendor), enterprise environmental factors, and organizational process assets. With these inputs, the charter then becomes the sole enabling document for the project.Drawing from the SOW, it states what will be accomplished.From the embedded business case we know why the project is needed and why it is the best use of funds from all other choices. Finally, the Project Charter states the high level process for how the project will be accomplished using organizational and environmental factor information. The charter initiates and authorizes the work to be done. For this reason it is signed off by a person or persons with the authority to fund the project. Once the project is chartered it should be integrated into associated programs and the business of the enterprise.

Project Management Plan

The team will develop the Project Management Plan after final approval of the Charter. Then, outputs of the Project Charter are used as inputs to the Project Management Plan. In developing this plan, the team will integrate all information from all previous activities, including the Statement of Work and Charter, taking into consideration all environmental factors of the organization, such as available human resources, work hours, current established processes, on-going projects, and other constraints that might affect the operation of the project in any way. This document is the official reference for how the project will be executed, including change control, communications, how budget and schedule will be tracked and measured, how risk will be managed, and other information vital to the project. Details concerning risks, communication plan, budget tracking, and others will be detailed in lower level documents, but the Project Management Plan rolls up the summary information and tells where the details can be found.

Even after the Project Management Plan is written and signed off by the project sponsor, manager, and all relevant stakeholders, it is not a complete document. The plan itself must be integrated into the processes of the rest of the project which may require changes to the plan. During the “Direct and Manage Project Execution” phase, and while monitoring and controlling the project and performing integrated change control—all those other phases or processes discussed in earlier articles—new information that affects the project will come to light or methods the project team thought were fully understood will suddenly become less so, causing the project plan to be revisited and changed. Changes to one thing invariably affect another. Thus, everything needs to be integrated.

Project Execution/Monitor and Control

During the Direct and Manage Project Execution phase the project manager, with the team, drives the activities that have been planned and scheduled with the goal of achieving the stated deliverables which comprise the overall output, the purpose of the project. During this phase, current work depends on previous deliverables or other work having been accomplished.Information about the completed deliverables feeds the activity plan of subsequent periods. Information generated by the project activities becomes the subject of various reports which are then used by oversight or steering committees to make decisions regarding the subject project or others.

As we discussed in the fourth instalment of this series, this oversight, monitoring, and auditing of schedules, budgets, purchasing, and all other aspects of the project is an overarching process, performed alongside and in support of all the other processes, known as Project Monitoring and Controlling. This is the process group where the actual work of collecting data, measuring and evaluating it, and reporting to stakeholders is performed. The results of the analysis of project information may lead to the need for some kind of action: corrective, preventive, repair, or updates to other plans, processes, or documents.

Corrective action is called for when the project work being executed is not congruent with the desired output. This is a polite way of saying someone’s not quite doing their job. For example, part of a computer program should have been written and tested in a two-week time span, but our progress audit part way through the period shows that work is behind schedule and that meeting the estimated completion date will be impossible. Corrective action may involve changing the schedule, changing or adding personnel, or reworking successive actions or dependencies so that the project can move forward. All of these, of course, require changes to and integration with other plans and documents.

Preventive action is taken in response to project risks, with the intention of decreasing the possibility of the risk happening or the negative consequences to the project if it does happen.

Defect repair refers to changing a component of a project, or correcting it after a problem has been identified and documented. The defect that needs repair or replacement may be a computer hard drive or a person. It may be a process that, through the monitoring and controlling actions, has been found to be insufficient for the project. Any of these repairs or replacements will go through the integration process as documentation, schedules, budgets, or other affected sub-systems of the project are altered.

Finally, the project manager or other team members will make Updates to project documentation when deliverables or objectives of the project are modified or added.

Change Management

This brings us to Integrated Change Management.This process actually begins as soon as there is anything to change. Which is to say, as soon as a decision to change anything has been made, no matter how early or late in the project, that change requires not just change control, but Integrated Change Control. Nothingis altered without affecting other components of the project. For that reason, all change requests must be managed through a change control process where all ramifications of the requested change are evaluated for their effect on scope, quality, risk, budget, and schedule. If a change request is granted, then it has to be implemented through Integrated Change Management.

Approved changes may require revisions to cost estimates; budget baselines may have to be changed. Changes may affect the schedule, so schedule baselines will have to be revised. Revised schedules may affect personnel and budgets. Methods for reporting changes to budget and schedule baselines, current tracking to time and money budgets, and estimates at completion should have been considered and documented in the Project Management Plan.If not, these decisions will now have to be made as part of Integrated Change Management and documented in the management plan.

Project Closure

We finally arrive at Project Closure. We discussed this at length in our last installment of this series of articles. Here, we’ll concentrate on only those aspects of closure related to other phases of the project.

The most important thing the project manager needs to accomplish in Project Closure is, of course, to ensure that the entire scope of the project was delivered and more importantly, delivered to the satisfaction of the project customer. The closure process relies heavily on the Scope Statement with all approved changes integrated. Because the Scope Statement was created using the original Statement of Work and was agreed upon by all relevant stakeholders, by verifying that all items in the Scope Statement have been delivered to the satisfaction of the customer, the project manager can safely call that part of the project complete. (For a discussion of a project that did not complete for whatever reason, see our article in last month’s issue on Project Closure.)

Other inputs to Integrated Project Closure include the Project Management Plan and Organizational process assets. The Project Management Plan includes communication protocols, transition plans, and any other processes that were completed before closure. Organizational process assets are those people and the equipment that were utilized for the completion of the project. Depending on organizational environmental factors, the project manager may have verbal discussions with personnel management, or be required to complete paper or automated system processes to notify other entities that project assets are no longer needed.

The closure phase may also be integrated with knowledge-base systems for collection of lessons learned, or the project manager may be required to complete personnel evaluations.

Concluding Remarks

Project Integration Management also includes one very important aspect that is easily overlooked. Experienced project managers know that not every possible project management process is required for every project. Projects vary in size, budget, and complexity; going overboard in conforming every project plan to every process in a methodology can be as detrimental to its success as using too few. But that doesn’t mean that every process shouldn’t be considered. The project manager, with the team, should consider each process within the methodology being used to determine whether it is appropriate to the current project. If not, the decision should be documented and become part of the project plan.

Many of the tasks we’ve discussed have been covered under the subject headings of project initiation, planning, execution, monitoring and controlling, and closing. The salient point in Project Integration Management is that these process groups do not exist in a vacuum, and a project of any complexity whatsoever cannot be managed as a series of separate processes: Create the business case, then file it. Create the Statement of Work, then file it. Produce the Project Charter, then call it complete, etc. Every project process and artifact feeds and is dependent on others. This is one reason the “waterfall methodology,” where all processes flow in one direction and once you “go over one waterfall” you can’t go back, was seen as inappropriate for complex projects, and so other, more adaptive techniques were developed. As with most analogies and mental images, the waterfall has its limitations. Even if a project utilizes a standard step-by-step procedural process, the project manager and team still need to see that every process is interdependent.

As an exercise in mental imagery, picture parts of the world where salmon are common. There, oftentimes rivers are dammed for hydro-electric generating stations. The salmon have to go back up-stream to spawn, so along-side the dam the engineers have built fish ladders, a series of smaller waterfalls alongside the dam that allow the salmon to jump back up river so they can accomplish their mission.

Keep all parts of your project integrated. Build fish ladders into your project and use them because you will want to go back upstream.

by