How to Avoid Being Stalked By Scope Creep: The Project Charter

Scope Creep. Sometimes it’s politically motivated. Sometimes it’s intentional. Sometimes it’s a misunderstanding. But it’s always painful.

Download a sample of the Getting Predictable Project Charter

The dictionary defines creeping as, “moving slowly and carefully, esp. in order to avoid being heard or noticed.” The very definition sounds undermining and deceitful.

But Scope Creep has occurred on almost every project I can think of. Sometimes it’s trivial, and sometimes it can impact a project’s destiny.

So What Are We To Do?

I don’t have a silver bullet that helps manage scope creep. It’s going to happen, whether it’s embellishing a small feature defined within a single requirements document, or adding three months of work to a project by adding anew component or dimension to a smaller project, it will happen.

But I have found that if you start your project with a Project Charter, it can help everyone be more aware of when scope creep may be occurring.

So let’s clarify what I mean by a Project Charter.

The Project Charter Explained

A Project Charter is not a multi-page document that describes the business case in all of its detail. In fact, I typically describe it as being about one-half page of a Word document.

And for the jokers out there, no, you can’t use a 5-point font to get more detail in that half page. (Yes, this actually comes up in training.)

So, what does a Project Charter do? It typically covers four key areas.

1) It describes the current situation and why it must change. Be succinct. For example:

If you make a call on a cell phone and get someone’s voice mail, you typically hang up, bring up the text-message app and send a message asking them to call you when they are free. This is such a common exercise, the phone should be helping me do this automatically.

2) It describes the end result of the project. When do you tell the project team, “Hands up. Stop typing. You are done! You are successful!” – when are there high fives all around?

Describe what is true, not how it will work. For example:

The scope of this project is to have the phone automatically sense when I reach someone’s voicemail, then prompt me to text the caller telling them to call me.

Notice that I didn’t share how this should work. I didn’t explain in detail that the phone should know that it reached voicemail, or that I have lowered it from my ear, and that it should prompt me to text that message, and if I say yes, the phone should hang up and sendthat exact text message. A couple of pages of detail requirements might need to be covered. But not in the Project Charter.

3) It describes what is out of scope. Again, we are focused on the “what.” Continuing our example:

Having customizable text messages in the cell phone’s preferences is not in the scope. Determining if the phone you are calling is a cell phone or land-line is also not in the scope.

4) It states the business case for your project.  This may be optional based on the size of the project or culture of your company, and how they track projects. The business case is just a sentence or two explaining the targeted savings or outcome. For example:

We believe this change will increase your market share with corporate clients by 5% in your local market within six months. See the full Cost-Benefit-Analysis at <insert your link here>.

Start With The End In Mind

Think about the value of having project clarity at the start of your project. If someone wants customizable messages, this clearly says that they should make their business case up front. There is no slipping in this feature.

Before a project starts, I typically route the Project Charter to make sure everyone is aligned (I love that word), and I allow folks to challenge or clarify it.

It’s Like Having Guardrails

A final thought. When I describe the role of a Project Charter, I explain that it provides guardrails for a project. You should always drive within your lane. But if a curve is coming up and you don’t catch it, you’re going to hit the guardrail.

And challenging the charter is similar to hitting a guardrail because it can hurt. It can cause rework or even revisiting decisions that have already been made. But if you break through the guardrail and go over the edge of the charter, then you are really in a heap of trouble.

But Wait, There’s More…

For extra credit, consider holding a ninety-minute meeting with the project stakeholders and facilitating them in the process of defining a Project Charter. Hey, one can dream!

So what do you think?  Do you think this might help your projects?

Make sure you download the Getting Predictable Project Charter

Tags: featured, project success, teams

Category: For Decisionmakers, Requirements Definition, Team Efficiency, Team Performance