I have hanging outside my office the overview poster that came with my PMBOK4. The poster shows a rough flow chart of all the PMBOK’s project management processes. It also shows the macro-flow between Planning, Monitoring & Controlling, and Executing. A decent flow chart. Wish I could find a soft copy of it.
One of our young developers walked by today. He helps me out when I have more technical linux questions. He saw the chart and asked some questions. The crux of the questions really came down to this:
“Out of that whole project flow, where do I fit?”
The answer, for a developer who spends all his time developing on projects, was at first discouraging. All his stuff, all his work, fit only in that box at the very center of the chart: Executing. And not just within the set of Executing processes, mind you. Pretty much just in the single process of Executing.
We chatted about it. It was a good chance for me both to reassure him about his place on the chart, and expand his understanding of what it takes, of everything else that has to happen so that he can be successful developing on the projects.
Here were the key points we discussed.
Project Planning
On the chart, planning is the biggest process group. It can be an “ah-ha” for a developer to begin to glimpse all that has to happen before he starts work, just so that he knows what the heck he’s supposed to do.
I also tied in his experiences having to redo work as requirements shifted, or as we discovered misunderstood requirements. He, like many, has had the unfortunate experience of demoing the first half of your work only to hear, “But, I thought it was supposed to do [insert new, surprise requirement].”
Planning helps to avoid that.
But that leads to the next principle: “Plan to replan.” It’s gonna happen. Expect it. Plan for it.But if you didn’t have a good plan in place, you can’t judge impact, downstream changes, etc., nearly as effectively.
And that leads to the next topic.
Project Control
In projects, “control” refers primarily to knowing where you are on your plan, spotting variance, and handling that variance.
Principle: “If you don’t have a plan, you can’t know where you are on the plan. If you don’t know where you’re supposed to be, you can’t judge variance.”
Well, you can guess. And if you’re really good at what you do, you’ll even guess right a lot of the time. That might even be more true for us in talented Cottage PM organizations — smaller project teams, smaller projects, even though they have huge impact. But it’s not necessarily true for us, either.
It goes further, too.
If you don’t know where you’re supposed to be, you can’t report your progress — at least not with any reliability — to stakeholders and sponsers.
Wrap Up
Finally, was able to point out the key planning process outputs that he uses: WBS & Schedule. The PM we have working on his team is pretty darn good, so he knows these tools well. I reassured him that from the project manager’s view, all the developer’s work might be in that one box, but in that box are those really long WBS charts and detailed Schedules — all those things the developer is working to. It represents all the “getting it done.”
I’m not sure he left feeling the “ah-ha” that I’d hoped he would feel after my explanations. Perhaps I wasn’t as clear or as insightful as I’d hoped. But perhaps it sets a stage so that the next time the PM is pulling her hair out, he can understand that a little better.
Related posts:
