Scope Creep is always bad.

Standard

Tip o’ my hat to PMHut (@PMHUT) for a comment last week. In it, he/she describes how the technique described for developing a Work Breakdown Structure could led to Scope Creep. Agreed – enthusiastic team members can use that technique to introduce cool new features, functions, capabilities not intended in the Charter. Not good.

We all know that Scope Creep in all its flavors is the enemy of Project Managers, right? Don’t we?

No, we don’t. Some Project Managers continue to assert that giving the client a little extra, exceeding their expectations, is good PM.

Wrong. it might be good business, but it is bad PM, and it is bad practice. While you are busy being a business manager, you are not being a project manager. It is very difficult to wear both hats at once. You will do both poorly. Beware.

Our loyalty, as a PM, should lie with our Project Charter and the defined project scope, budget, schedule and quality objectives. ANY unplanned, uncontrolled change is a threat to the Charter and project.

We PM’s should not be the source of change. We should resist unplanned change, even as we assess, control and implement approved change.

Whether from outside pressures (Scope Creep) or from inside the team (Gold Plating), it is a bad PM practice. Don’t be bad. be good.

Start at the End

Standard

Your WBS (Work Breakdown Structure) is nothing more than the breakdown of your final project deliverable into smaller and smaller pieces. Keep breaking down until you can accurately estimate cost and time (duration) for each sub-deliverable.

Try this. Get some open wall space and a lot of post-it notes. Write out the project’s main top level deliverable, for example “12 story office tower”, on a single post-it, and place it at the top center of the wall.

Now have your team write out everything single thing they can think of that will be needed to create such a tower, one thing (one deliverable) per post-it. Have them randomly place them on the wall. Have them start to place the alike thing together, and label the groups. For example, anything to do with heating could be grouped under “HVAC”.

(Ask them to do this without talking to each other. This prevents the verbal team members from dominating the non-verbal team members.)

If you like, you can start with those high level groupings first. This is easier when you have knowledge and expertise onboard from the beginning. and it speeds things along.

You should see the organic creation of the initial high-level WBS, appearing quickly on the wall.  You will also see your team members interacting, learning from each other, possible building up some team spirit. You will witness cross-discipline thinking, and professional growth.

Plus – it’s fun to mess with post-its at work.

The Triple Constraint

Standard

Draw an equilateral triangle, the kind where all three sides are the same length.

On one side, write “Scope”
On the next, write “Cost”
On the last side, write “Time”
In the middle, write “Quality”

The three sides illustrate your project scope, budget and timelines. The area inside the triangle represents the degree of quality you will be able to deliver within the Triple Constraint of Scope, Time and Cost.

We cannot change the length of any one side of the triangle without changing the length of at least one other side, or altering the size of the interior space (our Quality) – it is that simple. At least one other element will have to give.

This little drawing will help you explain to team members and sponsors, stakeholders of all kinds, that you cannot arbitrarily change elements of a project without having some kind of consequence.

Use a Charter. Always. Every Time.

Standard

A project is unique. What it creates has never created before. You need some kind of definition of what it will be, how much you want to spend, and when you want it done.

You need a Charter.

OK, you might call it a project authorization sheet, or Budget Approval document, or any number of different names depending on your organization. What it HAS to do is authorize you (or a team) to start detailed planning. I must give formal permission to start using resources. 

It HAS to give a high level description of the ultimate goals, the thing being created. It HAS to limit Scope. It HAS to define (in broad terms) what is is you are after. You could probably manage to do without early budgets, early timelines, early Risk Analysis. You can get these done during planning (although it is best to give some thought to this before you start). You might even get away without a business case, and trust to planning to reveal the feasibility of the project. Not best practice, but it might work. 

But you HAVE to have a signed Charter that defines what you are after, and formally empowers you and your team to pursue it. (Notice all the absolutes here. HAVE to. HAS to. MUST. No kidding around.)

You, as a Project Manager, must insist on this foundation document, signed by the bosses. If your company refuses to use a Charter, or refuses to sign a charter, or refuses to allow you to create some kind of controlling and empowering document, start looking for your next job. They don’t deserve you, and they probably won’t be around long anyway.