Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with - or even disagree with - leave a comment.

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.

"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

Posted: Jan 21, 2010 1:55 PM

Dan Swanson

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?

Posted: Feb 3, 2010 9:33 AM

Nina Kelley-Rumpff (@Nina_K_Rumpff)

Susan, I agree with almost everything you say. However, I'm somewhere in between your point of view and Michael's with regard to changes in scope.

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.

Posted: Jan 30, 2012 2:23 PM

TL

First, I think accommodating customer requests at any stage in a project is acceptable and should be considered as long as changes to both budget and schedule are discussed and accepted. If the customer says no to an increase in one or the other or both, then the change should not be made. Customers are not boogeymen.

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.