Processes and process groups of integration management | The Definitive Guide to Project Management: The fast track to getting the job done on time and on budget (2nd Edition)

This section describes the key processes that fall within project integration management. The aim is to describe each process and enable you to understand its role in integration, so that you can do it. The context of this is project integration management. The individual processes (and in brackets the process groups to which they belong) within project integration management are:

Develop project charter (Initiating)
Develop preliminary project scope statement (Initiating)
Develop project management plan (Planning)
Direct and manage project execution (Executing)
Monitor and control project work (Monitoring and Controlling)
Integrated change control (Monitoring and Controlling)
Close project (Closing).

Note that this list can also be read as a sequence of things to do to run a project. The charter is a 'plan for a plan' or a high-level, first-cut plan for the project. Often it need be no more than a one-page 'What? Why? Who? How? Where? When?' outline of the project as it is first conceived, but for larger projects it may be a longer document. The purpose of the scope statement is to say what does and does not fall within the project, and, following from that, what the key interfaces of the project are. The key elements of the charter and the scope statement are also key ingredients of the project plan. Why are they separated out in project management methodology as separate activities before the main planning^[2]? For all but the smallest, simplest projects, planning is a complex activity and it can be hard to know how to begin planning the work. If you are having difficulty in deciding or even thinking about how to start planning your project, don't worry that is entirely normal, even for very highly qualified and experienced executives.

If you are finding it hard to start planning, here are two ideas that may help. First, start by writing just a one-page plan, with a few lines under the headings 'What are we trying to do in this project: Why? How? When?'. And secondly, develop in your mind, and later on paper, a high-level, very rough view of the aim and rationale for the project, which is provided by the charter, and an initial or 'strawman' view of the rough scope of the project and the key interfaces. In both of these, use the strawman approach (see key idea box). Things can always be revised as more is learnt.

Key Idea

The strawman

A dictionary definition of 'strawman' is an argument set up to be defeated^[3]. In project management, we use the term to mean something, typically a plan or report, that is set up to be modified or changed completely. The key idea is that it is a starting point only, and criticism, comment and total change not only do not matter, they are positively welcomed. We use a strawman to get the ball rolling, that is to get things started. People who receive strawman ideas should understand that they ought not to get angry with the strawman idea or use it to attack the project, but instead if they think it is misguided, they should come up themselves with a better idea and feed it back to the project. Getting traditional cultures to use the strawman can require a little cultural change.

The sequence of integration processes

Project management starts with project initiation. In project initiation the various project stakeholders are brought together to develop the project charter and the preliminary scope statement. Once those things are done the project then moves into the planning phase. Planning uses the outputs from initiation to start integrating all the detail needed to prepare, develop and coordinate the subsidiary plans produced in the project management plan.

The next stage of integration management is to direct and manage the execution process group by completing the work specified in the project management plan, together with the implementation of the approved changes. During execution a major output presented to the project manager is information about work performance. This information is assessed and reviewed to determine whether the project is running as planned or whether it is running at variance to the performance baselines. This information gathering and assessment is what is called monitoring and controlling.

PMI says

Control

'Control (Technique). Comparing actual performance with planned performance. Analyzing variances. Assessing trends to effect process improvements. Evaluating possible alternatives, and recommending appropriate corrective actions as needed.' PMBOK Guide (p.355)

Control will generate a set of preventive actions. They require an approval process and change control process, or otherwise the project will change in an uncontrolled way, which increases cost and risk. Like so much in project management, this is no more than common sense, but experience shows that it is useful to make the point explicitly.

We will next look at some of the processes within project integration management in more detail.

How do projects get started?

How do projects come to be? There are many root causes leading to business needs for projects, including the commercial needs of the organization ('market driven'), new legal or regulatory requirements, changing fashions, or responses characterized by varying degrees of gambling in the face of advances in technology or the opening of new markets. The vanity and ego of chief executives and elected and non-elected government officials has also been proposed by some, although it is beyond the scope of this book to opine on the likely validity of such claims. Once the business need has been established, the next stage is to decide how to respond to this need. A typical approach here is to generate a number of possible approaches and run a selection process to pick the one that will be used in the project. As an aside, it is common for such selection processes to be a source of concern and problems in large organizations, but that is also beyond the scope of this book.

The project manager should understand the constraints and assumptions included in the project charter. 'Should', because that is the ideal but may not be possible; for instance, if the project is large and complex, say to modernize working practices across a varied, multi-business organization, working out the constraints and assumptions is a mini-project in itself. In such cases the key thing is for the project manager and sponsor to be aware of their state of ignorance, and the size of the task necessary to work out the constraints and assumptions to a degree that allows proper planning. This lack of knowledge can be documented in the charter.

Top of Page