A PMBOK® Guide for the Trenches
When you are introduced into a project environment, with a team who has never used project management and knows little of it, what is going to help most? Is A Guide to the Project Management Body of Knowledge (PMBOK® Guide) too airy and sophisticated?
Put another way, if you find yourself in a World War I-era trench, which would you rather have: the operator's manual on your howitzer or The Art of War by Sun Tzu?
Over my next few posts, I want to introduce my own version of the PMBOK® Guide, unencumbered by peer review (or even consistency). It will give me a chance to cut through some of the academic cobwebs that may have set into our practices, and illuminate recent issues and problems.
We'll start with scope.
Scope: (noun) the output or outcome for which your customer is willing to pay.
You've probably already recognized that, by this definition, the customer can't request anything out of scope, since what they desire is, by definition, in scope. And you would be correct.
So, if you don't want to find yourself in a situation where your (paying) customer is asking for more than you were originally willing to produce for a certain price, you had better have a very detailed agreement--otherwise, that most deadly of project ruination elements, scope creep, will devastate you, your team, your organization and your project.
Here's further proof that my definition for scope is correct: If your customer wants to add work to your project and will to pay for it, what project manager would refuse to do it on the grounds that it wasn't in the original statement of work?
No matter how absurdly the original work breakdown structure (WBS) was set up, if a person with sufficient organizational clout generated it, it can never be substantially changed.
In fact, the very act of pointing out that a proposed WBS element is inappropriate is a serious career-limiting move, since everyone knows that the ability to create a valid WBS is the litmus test for real project managers and pretenders. I've found that the pretenders will attack any challenge with a ferocity rooted in their insecurity.
Yes, it all begins with scope, but it obviously doesn't end there.
Next up: schedule.
"If your customer wants to add work to your project and will to pay for it, what project manager would refuse to do it on the grounds that it wasn't in the original statement of work?"
Project manager's who take this approach end up never delivering the project. You have to say No and No a lot to scope changes whether the client has the money or not. The simply reason being that the client will always want the project launched on the original launch date, and often no matter how much money is thrown at it, scope changes cannot be included. So my view is this is completely inaccurate advice and will lead to unstoppable causes of scope creep.
Secondly you write:
"In fact, the very act of pointing out that a proposed WBS element is inappropriate is a serious career-limiting move, since everyone knows that the ability to create a valid WBS is the litmus test for real project managers and pretenders. I've found that the pretenders will attack any challenge with a ferocity rooted in their insecurity."
I have been an interim program and senior project manager for 14 years. I specialize in projects which must launch on time, or turning around those which are failing. At no time have I ever been asked to do a WBS because WBS does not work with Agile and 95% of IT projects now use a derivative of agile scrum not waterfall software development.
Therefore to say that "creating a valid WBS is a litmus test for real project managers" is ridiculous where IT is concerned and again would I think unnecessarily panic new project managers unnecessarily. And this isn't just my view. I speak to a large number of program and project managers, and guess what? in industries such as manufacturing or defence WBS is used a great deal, but in the fast moving cutting edge industries which utilise IT (i.e. almost everything else), WBS is considered in much the same way as waterfall (i.e. old news).
Lastly when I get involved in troubleshooting a failing project the first thing I check on is the project scope. In 75% I find the project manager has either followed your approach of allowing changes because the sponsor provided budget and it snowballed, or scope was open to interpretation to begin with and this has been taken advantage of.
Susan de Sousa
Site Editor http://www.my-project-management-expert.com
|Nina Kelley-Rumpff (@Nina_K_Rumpff)|
I don't say "no" necessarily but present the sponsor with exactly what the result would be in accepting the changeâ€”both from a schedule and a cost perspective.
If the sponsor agrees to late delivery and more costs, then the change is implemented, and all changes are tracked throughout the life of the project, including their impacts. My experience is similar to yours, whereby the sponsor typically wants the product delivered in the same timeline. In which case, I'm not the one saying "no.â€ The sponsor is, by rejecting the increase in time to deliver.
Project managers should not be afraid to listen and consider new points of views at all stages of their project. Projects are not static entities, set off in one direction and unmovable till delivery.
There is potential for flexibility throughout the entire delivery process, and project managers should be open to that. Why the traditional project management methodology and use of the WBS is described as "old news" is beyond me.
There is just as much value to a traditional method and the WBS as there is to an agile method. They both do not work on every project, but they are both great for the projects they do work on.
I don't think the WBS is the end-all-be-all litmus test of the project managersâ€™ awesomeness. And I don't think that pointing out flaws in a WBS is career limiting. A good project manager should treat their entire project team (stakeholders, sponsors, delivery team, vendors) as adults, which means having conversations about things you see that may or may not work.
The conversation should be centered around what's best for the project. If something in the WBS isn't best for the project, then it should be highlighted and discussed.
Please Login/Register to leave a comment.