Project Charter Part 4: Define Release Criteria so You Know What Done Means & Avoid Scope Creep

So far, I've addressed how a project charter can help a team start a project fast and well. That's why the project charter must clarify product vision, the various project risks, and product risks.

And, it's equally important to know what done means. If the team does not know how little they can do to get to done, they (the product leader, various managers, etc) add too much to the project to accomplish that “done.” Often, we think of that as “scope creep.” The more creepiness, the longer the work takes. That can have serious consequences.

Years ago, I facilitated a retrospective for a product that shipped “late.” The VP introduced me and then offered a little context setting. He said:

“We needed to ship this product on May 31. However, it took us until August 30 to finish the last three, and most important features.” He named them.

There was an audible gasp in the room. One of the senior engineers said, “We had those three features done in May. Before the thirty-first. We thought you wanted these other three features (and named them) to finish the release.”

The VP sighed. “No, we added those because I thought you were so behind on the original date. The longer it took for us to release, the more I thought we needed in the release.”

That “scope creep” turned out to be the cause of many project problems. (It was also the cause of the VP's firing.)

Scope Creep Creates Cost of Delay

Scope creep means we accept additional work than what we planned. Sometimes, that's reasonable scope “creep:”

We realize our product vision is insufficient to meet the needs of the customers.
After we released a bit of value, we realized we did not understand the project driver, boundaries, and constraints. We need to change.
We created and ran an experiment and realized the architecture or design is insufficient to meet the product risks.

All of these realizations are risks. They require replanning. That's fine.

However, there is one too-frequent occurrence of scope creep that is not fine. That's when the team does not finish the previously agreed-upon work. Since the product is now “late,” managers ask for more work.

That creates a significant Cost of Delay. (See How to Calculate the Cost of Delay to Rank All the Work, Part 1 for one of my recent series about CoD.)

Adding more work, that “scope creep” problem creates these problems:

Instead of asking team members to collaborate on fewer things (decrease their WIP), managers add more work. That increases multitasking. See Flow Metrics and Why They Matter to Teams and Managers.
That multitasking makes all the work take longer, as it did for that company. That slow throughput and higher cycle time increased the perceived pressure for “more” work.
When the work takes longer, it's more difficult to see a demo or do a retro, because the team hasn't finished the work.

If you know what “done” means, you do not have to accept more work.

Know What Done Means at the Start

As I've said, we can change what done means, when it makes sense to do so. However, many projects can know what “done” means, if they have a product vision.

“Done” clarifies the value to the customer. “Done” also sets the boundaries for the team.

That's why the project charter needs to explain how to start, how to decide, and what done means.

The Project Charter Series

See my books: Manage It! and Create Your Successful Agile Project for what I already wrote about project charters.

Project Lifecycles: How to Reduce Risks, Release Successful Products, and Increase Agility will help you see your feedback loop needs. And help you decide how to instill more agility in any approach if you want to.

Project Charter Part 4: Define Release Criteria so You Know What Done Means & Avoid Scope Creep

Scope Creep Creates Cost of Delay

Know What Done Means at the Start

The Project Charter Series

Like this:

Related

Leave a ReplyCancel reply