How to Keep Your Project From Being a Runaway Train

How to Keep Your Project From Being a Runaway Train
By Harry Hall

Have you ever been handed a project with too many requirements right from the beginning?

How many times have you experienced feature creep? You know the drill – you elicit and document the requirements – you receive sign off – you continue to see changes to the requirements with no controls. Many projects experience 10, 20, 25-percent change in requirements over the life of the project.

If you are successful at avoiding too many requirements or feature creep, you may still encounter developer gold-plating. Developers love to try new things even if the features were not requested, especially when they have new tools. These experiments cause adverse impacts to the schedule, budget, and quality.

Project managers pay a big price when failing to understand and manage project scope. Projects turn into runaway trains. Let’s define some terms and look at some practical steps to get you the results you’re looking for.

Scope Is Not a Mouthwash

You cannot manage what you do not understand. Let’s get our arms around the concept of scope. The Project Management Body of Knowledge (PMBOK) defines scope as the sum of the products, services, or results.

When we use the word scope, it is helpful to specify the type of scope – product scope or project scope. The product scope are the features and functions of the product, service, or result. The project scope is the work to deliver the product, service, or result.

Imagine that you plan to have a painter paint your living room. What are the deliverables? Here are some questions related to the product scope:

• Do you want the walls painted?
• Do you want the trim painted?
• Do you want the ceiling painted?
• Do you want a coat of primer applied before the first coat of paint?
• What color do you want for the walls, trim, and ceiling?
• What brand and type of paint do you want?
• Do you want a second coat of paint?

What are the tools and equipment that are needed? What work will be done to deliver the product? Here are some questions related to the project scope:

• Will someone remove the furniture from the room before the room is painted?
• Will the painter clean the walls and trim before painting?
• Will the painter tape the trim before painting the walls?
• Will the painter use a brush or a paint sprayer?
• Will someone inspect each step before the painter moves to the next step?

Want more clarification on product and project scope?

Read Your User’s Minds

When it comes to requirements, I wish I could read my user’s minds…something like what you see on Star Trek. Unfortunately, collecting requirements is challenging. Project managers should consider engaging an effective business analyst for large projects.

A critical part of projects is defining and managing the project requirements. Requirements are the capabilities or conditions needed in the product, service, or result. They are specifications of what should be developed or implemented.

Like the word scope, it is helpful to use an adjective when talking about requirements. There are different types of requirements. Check with your organization to see if there are standard definitions for different types of requirements.

I typically use the following terms. Notice the cascading levels of requirements. We begin with high-level requirements and progressively elaborate the requirements into greater detail.

• Business requirements – the high-level business goals of the project (e.g., Increase customer retention by 5% by the end of the year).

• User requirements – a task of a user group (e.g., Quote an insurance policy).

• Systems requirements – the detailed specifications of the features and conditions needed in the system (e.g., The system shall invoice customers at month-end).

How to Eat an Elephant

How do you eat an elephant? One bite at time. We all know the saying. Project managers can use this principle for any size project. Use the Work Breakdown Structure (WBS) to break your projects into bite-sized pieces.

The WBS is a hierarchical decomposition of the work to be performed in order to meet the project goals and create the deliverables. The lowest levels of the WBS are the work products and deliverables used for scheduling, estimating, monitoring, and controlling the project.

Keeping Everyone in the Dark

A mentor of mine says, “People are down on what they are not up on.” How true.

Do not make the mistake of waiting until the end of a project to unveil the product, service, or result to your stakeholders. Periodically show the prototypes or deliverables to the customer(s) and the sponsor. When the deliverables are mature, seek formal acceptance. These steps can greatly reduce the risk of rework.

By the way, this mistake occurs more with traditional waterfall projects than agile projects. Whether you take a waterfall or an agile approach, keep your key stakeholders informed.

Keeping Everything in Sync

Project managers should meet with their teams on a regular basis to compare the work completed to the project scope baseline (the defined deliverables, assumptions, and constraints). If there is variance, determine whether corrective or preventive action is required.

Change Happens

Many project managers think their job is ensure that no changes occur. Make no mistake about it – change happens. Expect it!

Our job as project managers is not to stop all the changes but to ensure the necessary changes occur in an organized and agreed-upon manner. Don’t get me wrong – project managers should not just add anything that is requested. Requested changes should support and align with the overall goals of the project.

Take changes through a change control process. Analyze and report the impact to the project sponsor. Seek approval when necessary before proceeding.

Arriving at the Train Station

Why do trains turn into runaway trains? It’s usually not one thing…it’s a combination of things. The engineer may fail to have a good travel plan. The engineer may get distracted or they may fail to check the speed and slow down at appropriate locations. Perhaps there are communication problems with others.

Likewise, project managers face a multitude of scope risks. Be diligent up front in your project to develop a scope management plan. Seek to understand your user’s needs. Engage appropriate stakeholders on an ongoing basis. Regularly compare your work against your plan and make needed corrections.

Before you know it, you will safely arrive at your destination with thrilled travelers. You will continue to build a great reputation. Individuals will line up at the ticket booth to get a ticket to your next destination.

Question: In your experience, where do project managers most struggle with defining and managing scope?

Harry Hall, PMP, PMI-RMP, is the Director of Enterprise Risk Management at the Georgia Farm Bureau Mutual Insurance Company, one of the largest domestic insurance companies in the state of Georgia. You can read more from Harry on his blog.