Let that roll off the tongue a few times. It sounds deadly dull, right.
It reminds me of the poor cousin amongst the PMBOK Knowledge Areas.
Always listed last.
Tacked on at the end after all the othe Knowledge Areas are covered.
This was in my mind recently, while completing a survey about my work experience in the “key project management disciplines”. Ten questions, one on each knowledge area and yes, Integration Management was last. Sigh.
So here’s my thing.
Integration Management deserves more love.
It’s not the dull, left-till-last knowledge area.
It’s not an afterthought, to be looked at after the “important” areas are covered.
On the contrary.
It sits at the heart of what we do. It’s the glue that binds our other knowledge areas together. Without integration management, our practices sit out on their own. Quite simply, things don’t get done.
A risk is something that might happen until you integrate it with your schedule, budget, quality and communication planning. Then you can understand where it really impacts you, and focus your mitigation effort where it matters most.
A schedule is just a list of dates until you integrate it with a budget and your stakeholder plan. Then you can understand the real value of delivering that work package a month early.
A budget is just a set of numbers until you integrate it with a scope statement, schedule, and stakeholder plan. Then you can show why you need additional budget to launch that new product this Quarter.
Most importantly, a project just builds things until it is integrated into the sponsoring business and drives strategic, high-value change outcomes.
PMBOK vs Prince2 – how do the two Big Books treat Integration Management?
PMI and Office of Government Commerce (OGC) take different approaches to integration management. Different focuses, different priorities. Both organisations talk about Integration Management, but they do so in very different ways.
Integration Management, the PMI Way
PMI takes a very descriptive approach. The PMBOK (and PMI Guide to Program Management) contain lots of dry discussion about building an integrated project management framework. Heavy reading. Plenty of detail. It’s PMBOK as we know and love it.
Integration Management, according to OGC
OGC (Prince 2) takes a more prescriptive approach. It focuses on the project structure and the specific processes that you should follow.
Why does this matter?
PMBOK talks in lovely, rich detail about why you should ensure your knowledge areas all hang together.
At the same time, Prince 2 talks about managing Change and Progress. Tracking issues and making sure that all the baselines are managed. Measuring progress against your baselines. But it doesn’t take the next step and describe how to make sure the baselines hang together.
PMBOK says very clearly “you need to take steps to build this sort of comprehensive framework to bring all your Knowledge Areas together.”
Prince 2 says “use these processes and controls to manage changes across your baselines, and you will know how you are tracking at any point in time.”
Both work, but I like the depth and stability of the PMBOK framework, so on this issue, I’m a PMBOK kind of guy.
Have a think about which approach works for you, and take that into account when building your project plan. Take your time and think it through carefully. The approach you take will help shape and guide your integration planning, so avoid shortcuts!
Integration and the Client Organisation
We often think about Integration Management in terms of the project team only, but this is only half the picture. Try extending your thinking to consider how the project integrates with the client organisation.
The idea here is to couple the project team and organisation as tightly as possible. This is key to giving your project the best opportunity to tap into the business drivers, strategies and priorities.
So how can we do this?
Here are 5 simple ways to look at project/client integration.
1. Acceptance Criteria
- Include your client’s Acceptance Criteria in your Quality Plan. This is the key to understanding exactly what you must deliver before the client deems the project a success.
- Add these as deliverables in your Project Schedule and tag them to the completion of your testing/deployment tasks.
- Include a project risk around the impacts of the client not accepting the end product. Quantify the cost and schedule impacts where rework is needed. Include the Acceptance Criteria as measurable activities/deliverables that you can use to mitigate this risk.
2. Stakeholder Engagement
- Ensure that you have client representatives on your Project Control Board. Make sure your client has a voice at the table.
- Include your client representatives in your Stakeholder Management Plan. Make sure to include their salience, special needs, and impact at different stages in the project.
- Include all client stakeholders in your Communication Plan – keep a clear, documented understanding of their communication needs and expectations.
3. Client Priorities
- Keep your client’s priorities in mind by blending the strategic delivery roadmap into your project/program plan. This is a really simple two-step process.
- Place a top-level line item in your project schedule for the client’s target monthly/quarterly outcomes
- Link the client outcomes to your project deliverables.
As your delivery dates move, you will be able to see them roll directly into the client’s roadmap.
- Include a periodic task in your action list, to review the client roadmap and adjust your high-level planning where needed. In a previous role, my team ran a 2/weekly planning session with the client’s leadership group. This was a super-useful session, where we reviewed progress and priorities, then updated the delivery roadmap on a Trello Board.
4. Risk Planning and Budgeting
As you work through your risk planning, you will build a picture of the cost and timing impacts. You will know how much a risk may cost and when that cost is likely to be incurred.
- Walk your client through this planning on a regular basis.
- Show the client the high impact risks. Make sure they understand how these will affect their business, how you are reducing the impacts, and where they need to get involved.
5. Change Impacts
Your project will deliver a change outcome into the client organisation. Regardless of the size and complexity of the change, your success depends on having an engaged, informed and an active client.
- Commence your change management planning as soon as your project kicks off – NOT once the solution has been built!
- Identify your change champions early and include them in your stakeholder planning. Understand who they are, how they will be impacted, what their needs and priorities are. Make sure you provide an engagement process that works for them.
- Include your change champions in early Scope, Communication and Quality planning. Use them to help you map out
- What needs to be done
- How the end result will look, and
- How to share the right messages with the right people
Integration Management – Egg Yolks, Glue and the Rusty Iron Triangle
We often think of the classic Iron Triangle as central to our project success. Scope, time, cost. How does a change in one impact the other two?
But what happens if we think about the Iron Triangle in a different way? How do the three sides connect?
What holds them together?
This is where Integration Management does its thing. Think of it as the glue that holds the sides of the Iron Triangle together. Which makes sense in a way.
If we change the scope, we need to see how that impacts our schedule and budget. But these don’t happen magically. The triangle works when the three sides are connected.
Scope decomposed into agreed work packages. Cost applied to each work package. Work lined up and scheduled.
Each package producing an estimated and scheduled deliverable that rolls up into a project schedule and budget.
Integration management. Tools and practices holding the three sides of the triangle together. Glue.
Bringing It All Back Home
So with this in mind, perhaps we should rethink the classical triangle.
Rather than a triangle, is it time to think of the project as an egg, with the scope/time/cost ‘yolk’ surrounded by the integration management ‘egg-white’?
OK, so maybe I’m talking tongue-in-cheek, but my point remains.
We need to make sure that our project planning connects our focus areas. It’s not enough to just say “the triangle shows us the change impacts”. We need to make sure that we have tools and processes in place to make sure the triangle sides are connected. Glue. Foundation.
And yeah, I still like the egg analogy 🙂