This video quickly runs through Integration Management, one of the 9 Knowledge Areas of the PMBoK. Integration has seven processes and the first three processes: Management Plan, Scope Statement, Charter are all planning processes and the others are Executing. So today I’m just going to be concentrating above the line on the planning aspects.
Our Winning Project Management Training shows you how to succinctly establish an integrated project management framework – CLICK HERE
Project Integration Management (Transcribed from Video)
Hi, James Clements here. Today I’m going to quickly go through Integration Management, one of the 9 Knowledge Areas of the PMBoK. Integration has seven processes that are listed here, and the first three processes: Management Plan, Scope Statement, Charter are all planning processes and the others are Executing. So today I’m just going to be concentrating above the line on the planning aspects.
There’s two aspects to integration. One is the integration with the external environment of the project and the other is the internal integration of all the parts of the project. So, to address the external aspects your project is not an island. You don’t sit out there doing everything differently to the rest of the organization. You don’t have your own currency – you don’t have your own people, race, rules, religion and so forth. Your project is more like this one. It is connected to the mainland it’s still it’s own project; it’s still it’s own entity, but it must take all its rules, regulations, currencies and so forth from the mainland. So, it needs to be complimentary. So, you should not try and set up your project to be totally stand-alone.
Doing this will just cause all of your project teams members a whole bunch of grief cause they have extra work to do – Work that already exists within the organization, and when they start to exchange documents backwards and forwards between the project and the information – if they’re different then that’s going to cause you issues. So, you need to think long and hard about doing things differently. There are times where this is required, but think about it first. You know, be smart use everything that exists because your project team has got enough to do anyway.
The other aspects are all of the internals of the project. Once all of the bits and pieces of the project are thought about, sized correctly, complimentary to each other – then you’re going to start to create some Synergy within your project. More of the bits and pieces tied together.
So, you’ve got nine knowledge areas within the PMBoK. All of these can be set up as stand-alone processes and tools and monitoring and so forth. But when you get them all working together when you draw some framework through the middle of them that ties them all together – that’s when you’re really going to start to get your effectiveness in your project management.
I’ll give you some examples:
When you develop a Scope Statement you’re going to have a Broad Strategy, and within that Broad Strategy you’re going to already start to define what the main deliverables are to that project. So, you need to be thinking about – in the early days – how you’re going to set up your project, what are going to be the main deliverables, how are you going to do it, and this can then flow directly into your work breakdown structure. So, when you’re developing your deliverable base work Breakdown Structure it should take its lead from the Scope Statement.
This will then lead you into a WBS Dictionary based on the WBS and then a schedule again based on the WBS – down a couple of levels of WBS – not all the way – you don’t have to keep that consistency but in the top levels 1, 2 and 3 you should have that consistency between your WBS and your schedule and similarly the consistency between your WBS your Schedule and your budget which will then allow you to start to report on an in-value basis, set up a time-phase budget you can start to get good reporting going.
And then once you’ve got that, you’ve all of your WBS elements are fully defined from a Scope point of view, they’ve got a Schedule, they’ve got a Budget and you can allocate them to your project team members as part of your responsibility assignment metric. So you see you’ve drawn a link between the early days of setting up the Scope right down scoping, scheduling, budgeting, reporting, and allocation of tasks to your project team members. So, you’ve got that traceability right back through the project.
So another similar example, again, when you do a Scope Statement you’re going to define some objectives and most of those objective are fairly intangible while statements of intent for a project. So what you need to is you need to take those objectives and put them in you quality plan and start to put some measures around those and set them as quality objectives for your project. You can link personal performance within the project of your team through achievement of those quality objectives. You can then also use those objects as part of your risk criteria.
So when your ranking risk and when you’re setting up risk mitigation strategies you can look up what your objectives are and then you can make decisions based on those objectives and similarly when you’re selection vendors for your project you can look at “What are our objectives?” “How are we measuring achievement of those objectives?” “Does this vendor suit?” “What’s the risk acceptability for doing certain things within the project?” and then you can make your vendor selections based on this.
So you see I’ve got a nice traceability right back through the project joining up all the parts of the project. Run some consistency in the project yet people can see what the performance is being judged against. You can make decisions based on where you’re heading in the project.
So I hope that’s given you a bit of insight into Project Integration. In a later blog I’ll address the executing processes of Integration. Goodbye for now.