Jim Owens, PMP: JIMBOK 4th ed – Integration Management

Number of View: 2341

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 was added to PMBOK in the mid 90’s, and it’s main reason for existing is to manage the interactions and interdependencies between the other eight knowledge areas, and it involves making decisions and balancing competing demands for resources, etc.

Suppose for example, a risk occurs in a project (i.e. it becomes an “issue”), and it is discovered that a deliverable requires repair work. The repair may then involve extra time, leading to changes to the schedule (Time management), extra cost (Cost management) employing more staff (HR management), notifying stakeholders (Communications management), updating the risk register (Risk management), possibly improving quality procedures (Quality management) and so on and so on. And it is Integration management that ensures that all these changes ripple through the appropriate areas, and then ensures that necessary documentation is completed too.

Integration means bringing parts together to form a whole, and so it is in project management that Integration management pulls everything together to form a completed project.

Integration management is intermeshed with all the other knowledge areas, 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, 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 – in organizations where I have worked they called the project plan the project charter – but in the exam the document 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,
• A lot of detail at this early stage will imply a greater level of certainly, which may lead to other making decisions that later prove to be incorrect
• 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 includes:

• The business needs, and current understanding of the customer’s needs
• The new product, service, or result that is intended to satisfy these needs
• Project purpose or justification,
• Measurable project objectives and related success criteria (Note the “and”)
• High-level requirements,
• High-level project description,
• High-level risks,
• Summary milestone schedule,
• Summary budget,

What the Charter does:

• Formally authorizes a project or a phase.
• Identifies and assigns the Project Manager
• Authorizes the PM to apply resources to project activities
• Documents initial requirements that satisfy the stakeholders’ needs and expectations.
• Establishes a partnership between the performing organization and the requesting organization or customer
• The approved project charter formally initiates the project.

Who does what:

• The project initiator or sponsor either creates the charter, or delegates that duty to the project manager.
• It is signed off by a manager, senior to the PM (e.g. project initiator, sponsor, senior manager, committee, or even another organisation), external to the team.

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,
• Organizational need,
• Customer request,
• Technological advance,
• Legal requirement,
• Ecological impacts, or
• Social need

This information is normally included in the Business Case or similar document that argues why the project is worthwhile, from a business perspective. This document usually includes a cost-benefit analysis.

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), which is a narrative description of the goods or services to be delivered by the project, 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). 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 process 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 this will be in the exam – know all about it. Each change has to be evaluated then approved or rejected. Change requests may be formal (a printed, signed document) 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 (the activities are in the Activities list, which you will fin in my notes on Time Management).

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