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.
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.
Scope must not only be looked at literally, but abstractly as well. In my experience, most customers do not necessarily have a complete itemized inventory of requirements to meet their goals. It is completely logical, if the customer is willing to fund and allot time, for requested activities just outside the scope, to achieve a desired product which was identified as per the project charter. I would argue that scope creep must be controlled and aligned with the project objectives. My job is to provide my customer a product with specific criteria and if a little scope creep here and there (within objective alignment) is what it takes to satisfy my client, so be it. What good is a project if the product doesn’t provide benefit to the customer and they are left dissatisfied?
I have two major issues with this post. Firstly you write:
"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.
Regards
Susan de Sousa
Site Editor http://www.my-project-management-expert.com