dgrimm100We’ve been looking at the integration management and how it relates to initiating and planning. With planning out of the way, we can look at Directing and Managing Project Execution, which occurs simultaneously with Monitor and Control Project Work.
Directing and Managing Project Execution is not the same as the executing process group, exactly. The executing process group is getting the work done. Directing and Managing Project Execution is integrating all of the efforts into a finished project. So, Directing and Managing Project Execution is the overview of the entire project (Mulcahy 118).
Mulcahy makes two critical points here: 1) Directing and Managing Project Execution involves managing people, doing the work (and therefore managing people doing the work), and implementing approved changes. And 2) it’s about ‘being of service’ (118).
In my opinion, these really become the two critical pieces of running a project: ensuring a common understanding, and being of service. I think the picture I posted last week clearly sums up what happens when you don’t ensure a common understanding. As for being of service, look at that post I just linked to. Down there at the bottom, in the game plan: Everyone is your customer. Are we afraid to get our hands dirty to help keep a team member on track? Are we out in front of the risks, trying to remove roadblocks to keep things on track?
Tied with Directing and Managing Project Execution is Monitoring and Controlling Project Work. This is best seen as balancing the demands of the different knowledge areas to control the project (Mulcahy 122). The output is change requests, project plan and document updates .
As we’ve been saying repeatedly, in discussions about planning and discussions about process groups, all projects must be controlled. Controlling a project is about ensuring that the work is proceeding according to plan, and when it is not, creating change to push it back on track. Taking corrective action is, according to Mulcahy, the correct answer for what to do when a task takes longer than expected.
One method of keeping work on schedule is the work authorization system. As we get into more detail about work packages, we’ll be in a better position to discuss this, but essentially, this is signing off that someone should begin work, because the prior dependency is complete. Mulcahy gives the example of building contractors needing to work in the same place, but it also applies to formal sign-off from the developer that QA can proceed in reviewing the IT code (Mulcahy 122).
When you compare the work authorization system with the concept of being of service, it feels, on the surface, almost contradictory. On the one hand, you’re trying to remove roadblocks, and assist the team members. On the other, you’re standing the way of starting on a work package until formal approval is given. But, in the long run, when you have 100+ people working on a project, how much more helpful is it to make sure no one is tripping over each other?
Dan's Project Management Blog 