Capabilities Based Planning
November 20, 2009 @ Herding Cats from Glen B. Alleman
One of the five process areas of our program management method is "Capabilities Planning." Here's a small picture of a moderately complex topic. In the same style of asking the Five Questions, these question need answers if you want to have any hope of being successful.
I get questions (outside the defense business) about "what do you mean when you say capabilities." Most everyone in commercial and defense gets the idea of requirements, the need for a master cost and schedule to fulfill those requirements, the actual running of that plan during execution, and of course the continuous risk management needed to keep everyone and everything moving in the right direction.
Well OK, not most everyone, otherwise we wouldn't have all those projects in the ditch upside down with their wheels spinning would we.
But capabilities is not always obvious. This week the Defense A&R Journal arrived while I was on the road.
Joint Acquisition Command Doctrine: A Success Story is a good example of Capabilities thinking. There was a comment from "Chart" (who never uses his - or her - real name and has a gmail address) about managing global integration projects. The concepts in this article can be applied to very large programs. Those project where the processes used for smaller project always seem to fail - those seemingly impossible ERP projects that every talks about.
- Treat global ERP projects like a military campaign - planning in depth is the watch word for military processes. Have a Plan B and a Plan C. Have a plan for everything that can go wrong. Have a plan for this you don;t even know about, that can go wrong. This is he definition of "planning in depth." This is called "managing in the presence of uncertainty." It is the opposite of "trying to manage uncertainty," which is the common red herring of the uninformed project manager who rails against having a plan and a schedule - oh yea and knowing the cost of things - just couldn't resist.
- Defined the needed capabilities first. Only then ask what requirements are needed at what time during the program to produce those capabilities. If you start with requirements you'll simply create a huge mess, follow every bunny down the rabbit hole, have no way to tie requirements with benefits and ask that dreaded question that's been floating around from the last couple of posts - "how can I connect the cost of this project with the value delivered by the outcomes. If anyone here still has any doubts about why you absolutely must have some understanding of a projects (program) cost no matter what you're doing this is the reason.
- Build full traceability between capabilities, requirements, and the work packages that deliver those requirements. Then establish a Performance Management Baseline and actually "manage" the project.
- Manage everything as a Risk Manager. Use Tim Lister's quote - Risk Management is How Adults Manage Projects. Along with the related quote - "what's the difference between this place and the boy scouts?" "The boy scouts have adult supervision."
Comments
Got something to say?