Integration management is sometimes referred to as “the glue that holds the project together”. So I’ve written these notes in case you get stuck.

Integration management is a bit more like a helicopter view of project management, as it pulls them altogether, and so many of the components of Integration are covered in more detail in my other exam tips.

Every project should begin with a Project Charter, according to PMI, or a contract document, if the project is performed under contract. Your organization may have other names for the charter (even some that I can say in print) such as Project Brief, Project Initiation Document, and so on – but in the exam it is called a Charter.

The charter is a high-level one or two-page document; it should be broadly based with just sufficient detail to initiate the project, because:

·         Extra detail wastes time prior to initiation and as you don’t know a great deal at this stage then it is just a pointless exercise,

·         Extra detail encourages people to argue and stall the project initiation,

·         Time spent at this stage is lost money to the organisation because, as the project doesn’t officially exist yet, there will be no cost-account in the General Ledger to charge it to,

·         If a project charter is broadly based, it will also reduce the need to change it during the project. The real detail will be progressively elaborated in Scope Management, and then throughout the rest of the project, and

·         Details that you write into the charter at this stage will act as constraints while managing the project. Constraints limit the options of the team.

The charter:

·         States the strategic reason for the project,

·         Describes the deliverable(s) of the project (product, service or result), at a high level,

·         Names the project manager,

·         Authorises the PM to utilise organisational resources to complete the project, and

·         Is signed off by a manager, senior to the PM (e.g. sponsor, senior manager, committee, or even another organisation), external to the team.

The charter should be written by the project manager (or at least a PM), is the PM is the person in the organisation with the necessary skills to create the charter.

After the charter is signed, the project manager starts creating the project team and then the real planning processes begin.

Prior to creating the charter:

A project normally comes about as the result of a:

·         Market demand,

·         Business need,

·         Customer request,

·         Technological advance,

·         Legal requirement, or

·         Social need

The project is normally selected as a result of a:

·         Feasibility study

·         Needs analysis, or

·         Preliminary plan

The sponsor usually creates a Project Statement of Work (SOW) as input to the charter, that lists the:

·         Business need

·         Product scope

·         Product requirements, which progressively elaborated during project execution

·         A link to the organisation’s strategic plan

Project Management Plan (or Project Plan)

The main goal of any planning in the project is to produce a Project Management Plan (called Project Plan, prior to PMBOK Third Edition – note, the exam may use either of these two terms) – this is the primary output of the planning processes. It is the roadmap of the project, it is not a project deliverable, but it enables the deliverables to be produced.

One of the most common mistakes that inexperienced project managers make is to confuse the Project Schedule with the Project (Management) Plan. The Project Schedule is a Gantt chart, but the Project Management Plan (or Project Plan) is a collection of all of the plans in a project, including the Project Schedule.

Study the Project Management Plan and know its importance as the key document that maps the way through the project.

·         All project-related decisions will be made by reference to this plan. It assists the Project Manager with the execution and control of the project.

·         The Project Management Plan is also of great value in communicating project progress to the various stakeholders, including the project team.

Get to know the subsidiary plans that make up the Project Management Plan – what they are used for and how they are updated.

There is a lot of time and energy involved in creating the project Plan, but it is time very well spent. The Project Management Plan provides the direction for the project execution and control processes, and the confidence that everyone is heading in the right direction.

Don’t miss the vital procedure of Formal Management Approval for the Project Plan; work must not commence until this is completed – irrespective of the urgency, or who insists that it must be started (forget what happens in your organization, PMBOK is right, PMBOK is right).  Remember that this plan may be your best (only?) defense when things go wrong.

In every project unexpected changes occur and so have to be managed by an Integrated Change Control system, and so will be in the exam – know all about it. Each change has to be evaluated then approved or rejected. Change requests may be formal or informal (maybe just a phone call on a small project), internal (e.g. management, project team or other internal stakeholders) or external (e.g. government, lobby/environment groups or changes in law).

You will be required to know all about the Work Breakdown Structure (WBS) – for more detail, please see my tips on Scope Management - as it is another critical tool that is created using input from the project manager and project team. The WBS is not a list of activities to complete the project – it is a list of deliverables (things) to complete the project – this point cannot be overstated. Some project managers have a different viewpoint – but PMI are marking your exam, so the PMBOK is always right.

The WBS is an input to five planning processes, that’s how important it is:

1. Cost Estimating

2. Cost Budgeting

3. Resource Planning

4. Risk Management Planning

5. Activity Definition

As you progress with the project, especially when the scope changes, update the historical database with lessons learned. Study the importance of lessons learned. They provide an invaluable reference pool for future projects.

If a project is abandoned, record that information too along with the reasons so that you don’t have to waste time in future rediscovering these lessons on similar projects.

Historical information is very valuable because people in your own organization have lived through these experiences and so are likely to be quite a reliable guide.

The Project Management Plan should be archived as well, along with the WBS. The archived WBS’s (and many other plans, forms and reports) can then serve as templates for future planning and save a lot of time.

Assumptions are beliefs held to be true for the purposes of the project – you don’t have to prove them, but they must be documented in the Project Plan. As they are assumptions then be aware that they have an element of risk attached to them. If assumptions later turn out to be false during the execution of the project then this may lead to changes in project scope.

Constraints (internal and external) must similarly be documented in the Project Management Plan – understand what they are. Constraints are restrictions upon the project. Additionally every project will be subjected to the triple constraint of time, cost, and scope so you need to know all about these for your exam.

Tip: constraints are considered to be outside the control of the team.

N.B. Some project managers may have different viewpoints or opinions to those expressed here – but PMI are marking your exam, so the PMBOK is *always* right and if I say anything that appears to contradict the PMBOK, then believe the PMBOK.

PS I’ve made every effort to get this right to help you in your exam – but if I’ve missed something please let me know.

Regards, Jim Owens PMP