Project Success: Managing Scope Creep and Customer Expectations
Project Success Defined
We achieve success on a project when we deliver what the customer wants and we also make the customer happy. To do this, we manage both scope and expectations.
Project Success is Customer Satisfaction
We achieve success on a project by doing two things:
- Delivering what the customer wants, when they want it, for the price they want to pay.
- Satisfying the customer, or, even better, delighting the customer.
To succeed, we have to do both. Anything less is not success.
As I trained over 4,000 project managers in 10 years, I found that a poor scope definition was the beginning of project disaster. Project success begins with clear scope, and moves forward with effective customer communications and managed work.
Most Projects Deliver Disappointing Results
Most projects fail. The Project Management Institute has been tracking that fact for years. And, for all their efforts - and certified Project Management Professionals do have a higher success rate - overall success rates haven't improved much.
There is a simple reason: to succeed, projects have to fight against human nature! And human nature isn't going to change. Two basic facts of human nature make it hard to deliver projects successfully:
- People don't like commitment.
- People always want more.
Project management succeeds in giving people what they want if they define it clearly and commit to it. This is the essence of Scope Definition, which is crucial to project success. So if our customers don't like commitment, then they won't be comfortable with the agreement they signed. This opens up the project to scope creep and sets us up for dissatisfied customers.
People always want more, and they are going to push for it. As they ask for more, new requirements creep into the scope of the project. If they are formally added to the project, we have scope creep, and can't deliver on time and within budget. If they aren't formally added, then the customer gets what they signed up for, but it isn't what they really wanted. That leads to customer dissatisfaction.
Sounds like a total mess leading to lose-lose, doesn't it? Let's unpack the problem a bit further, and then solve it.
The Problem: Vagueness Won't Work
As project managers, we are being asked to commit to success for our customers, whether we are working internally (for the same company) or externally (as hired consultants). Yet customers don't like to get very specific. And how can we promise to deliver "whatever you want, even if you never tell us what it is" by a specific date for a specific price? Yet customers have many reasons for not being clear and making commitments:
- They just don't understand how much time will be wasted by misunderstandings. We have to teach them why clarity matters.
- They don't know what it takes to create clear specifications. We have to teach them how, using effective requirements elicitation.
- They are doing too many other things. They don't want to take the time to get it right; they just want it done. We have to explain that only they know enough to really define what they want.
- They don't want to commit. Nobody wants to commit.
We need to be firm. We need their clarity and commitment as much as they need ours. Allowing vagueness early in the project is like leaving the door open the day you buy a new puppy. He's sure to run out into the street and get run over. You don't want that to happen to your project.
So clear scope definition is essential. After the definition is complete, what about scope creep, that is, new ideas being forced in on the project as it moves forward? That is too costly, as well. To prevent it, we start by finding every project stakeholder and getting their input. We explain that anything they ask for now is reasonable; asking the for the same things later may be unaffordable. Then we make sure we understand what they want and need. We put it in a written plan and get their commitment.
When everyone who is affected says the plan will work, we can move ahead.
A Change Costs More Than You Think
Work that is not well planned takes, literally, ten times longer than well-planned work, and costs ten times more, as well. This is an engineering fact that has been tested dozens of times in every type of project.
So, let's say that a customer wants to add a feature that, if included in the original scope would have cost $800 and taken one day to implement. Working it in as a change to a project already under construction or in development will cost $8,000 and take ten days. A few changes like that will guarantee we are delivering late, running way over budget, and disappointing the customer.
The solution: To ensure project success, we must manage scope creep.
Managing Scope Creep and Changes to Scope
Let's say we've managed to finish a project plan with an excellent scope definition, and the customer has signed off on the scope, the cost, and the delivery date. Problems still lie ahead!
There will be pressure to change the scope. And some changes are legitimate. The challenge is to make the necessary changes work, and resist the scope creep, that is, the changes that would add bells and whistles to the project but add no real value, and would drive the cost and schedule out of whack so that we can't deliver on time and within budget.
Here are the keys to managing scope creep and changes to scope:
- Communication and Awareness: We keep in touch with the customers and stakeholders. If they get new ideas, we know it!
- One Item at a Time: Don't let changes pile up. Evaluate each one promptly, then either reject it (politely), or revise the project plan to include it.
- Now, Later, or Never: Evaluate whether a requested feature should be added or not, and also whether it would be better to add it in a later upgrade. Only add a new feature in this project if it is essential to successful use of the deliverable. If the customer can live without it for a while, schedule it for later. (To see why, read the sidebar: A Change Costs More Than You Think.
- Manage the Sources of Scope Creep: Don't let the changes creep up on you, Catch the critters before they hatch!
What the Heck is a Stakeholder?
A stakeholder is anyone who is affected by the work or result of a project. The customer is the central stakeholder. But everyone who will encounter change as a result of the project is also a stakeholder. Remember that new corporate headquarters? Everyone who works there is a customer. But every employee of the company, worldwide, who needs to know the new phone numbers and how to get to the new headquarters in a new city is a stakeholder.
How often we communicate with each stakeholder depends on how much of a stake they have in the project.
Communication and Awareness
If we lose touch with our customer and stakeholders, we will surely find the project invaded by scope creep and/or fail to meet customer expectations. People naturally dream that they will get everything they asked for, even when we said "no," and it is not in the project plan. Their expectations go up. Meanwhile, we can't do quite all that we planned. So our results go down. That gap can't be closed at the end of the project. It has to be managed steadily throughout the project. Contact each customer and stakeholder on an appropriate schedule.
- We contact the customer daily or weekly.
- Major stakeholders are sent updates monthly, or when major project milestones are met (or missed).
- Minor stakeholders are contacted about the planning, testing, and delivery of the specific feature that affects them.
Create a Project Communications Plan that keeps everyone in the loop. And remember, listening is more important than sending reports. Be sure to listen to or meet with each stakeholder on schedule. And no, an email from the stakeholder or customer saying, "I'm too busy to meet; I'm sure everything is fine" is not good enough. In fact, letting those slide by is a recipe for disaster!
One Item at a Time
It is best if you have a structured process of Change Control. Here are the basic steps:
- Give each change request a name and number.
- Make sure you understand what is wanted clearly. Resolve any ambiguity down to an engineering precision.
- With your team, evaluate the change? Is it essential? What will it cost? How hard will it be to do? What risks does adding this change add to the whole project?
- Decide what to do. Only add the change if it is truly essential. Otherwise, delay it to a future release, or, if it conflicts with other features or has no value, reject it altogether.
- Inform the stakeholder who requested it of your decision. Do so politely and professionally, of course. If you are rejecting the change or delaying it to a future upgrade, be sure to explain why in terms of cost, risk and consequences, in a way that the customer will understand.
- If you are accepting the requested feature, update the entire project plan (all nine areas under management), and make sure that everyone knows about the change.
I could share many disaster stories of projects with poorly managed change: a computer programmer who stayed up all night writing a module that the customer had decided to drop; a whole company that nearly went out of business due to one defect in a new machine that was otherwise perfect, and on and on. Take care!
Now, Later, or Never?
Here is a great way to manage scope creep and delight your customers. From the very beginning, plan two sequential projects. The first delivers the working core of whatever the product is. The second delivers requested changes and improvements. That way, the first project is not thrown off course when the customer comes up with new ideas. And the second project gives them everything they dreamed up while they were waiting for you to finish.
If you plan this in advance, the customer is expecting you to say, "We can do that in the upgrade." You've managed scope creep by not changing the original project, and you've delighted the customer by giving them what they want and meeting their expectations.
Manage the Sources of Scope Creep
Everything you've read so far works, but it isn't enough. It assumes a kind of ideal world, a world where nothing much will change between the date the project plan is approved and the date that the project is completed. And the real world has far more change than that. Here are some examples:
- A new customer. What do we do if the customer is replaced in the middle of the project? Suppose we are designing that new corporate headquarters, and the CEO gets fired. What if the new CEO doesn't like the new building? Or what if he just wants to make his own mark with a whole new image? This kind of thing happens more often than you would think. We need to explain the project clearly to the new customer. We also have to be open to changes, as long as the customer will approve the additional money and time to make them happen.
- An unexpected discovery. What if excavation for the extension to the new corporate center uncovers an ancient Native American burial ground and the project is halted until anthropologists clear the site? Stranger things have happened! Here, we simply have to deal with the reality when it is discovered, at whatever time and cost.
- A change in the environment. This is not too likely in a construction project, but it happens all the time in information technology. What do we do if we're developing a new software application for Windows, and, in the middle of development, a new version of Windows comes out? Do we release an out-of-date project, or extend the project to make it work in the new operating environment?
- A real need to move the goalposts. In the middle of building our new corporate headquarters, we learn that the company has just acquired another division. Now, the new building is not large enough. Do we finish it and plan an expansion? Or does the project undergo major revision? Both are costly, and careful planning and negotiation are needed.
Even this list makes it sound easier than it is. The reality is that most workplaces today are chaotic and full of constant change. Keeping our own team on track is a full-time job, and knowing what is going on around us (much less managing it) is another one! Keep an eye on all these factors: Changes among customer and stakeholders; discoveries; and genuine need to change the requirement. Manage them as best you can. Communicate clearly, be a tough negotiator, and deliver the best you can when you can at reasonable cost. Life brings surprises, and no one could ask for more.
Interfering With Customer SatisfactionClick thumbnail to view full-size
Beyond Spefications: The Problem of Customer Expectations
If we defined scope clearly and manage change requests and scope creep well, we are likely to deliver the specified results on time and within budget.
You would think that that would make the customer happy. And it does, sometimes. But people being people, it doesn't always. Here are some things that can get in the way:
Something more important gets in the way
Picture this: A guy sits down to watch a football game, and all he cares about is that his team wins. Then, at halftime, his girlfriend comes by and proposes to him. He decides to get married. He's kind of paying attention to her. The football team goes and wins the game that, a couple of hours ago, was the most important thing in the world to him. Meanwhile, he's gone on to other things, and he couldn't care less!
Our customers can be like that. Between the rah-rah time of project launch and actual delivery, something more important may have come up.
Something Less Important Gets in the Way
Or, picture another one. Suppose at half-time, the team introduces a new mascot. And our fan at the TV thinks it is pug-ugly. The mascot has nothing to do with winning the game. But he thinks that it is so awful that he decides he couldn't care less about his beloved team. Well, we project managers can make the same mistake. If we communicate poorly, or allow something unprofessional to happen, we can disappoint our customer, even if we win the game - that is, complete the project on time and under budget - for him.
A Bigger Dream Gets In the Way
This time, our fan is watching the game, and he sees his team is pretty sure to win. He starts thinking, "Wow! If they win this one, they could get to the top of the Division." Pretty soon, he's picturing them winning the Super Bowl. His team wins, and he's not happy. All he can do is say, "But will they make it to the Super Bowl?"
Our customers dream and they want more and more. It's human nature. But it creates new expectations. Even if we meet the specifications, the customer won't be happy if we don't meet their expectations, as well.
Managing Customer Expectations to Customer Delight
The solution to managing customer expectations is simple, but it is not always easy. The key is to keep in touch with customers and key stakeholders. Email is not enough; it must be personal contact, at least by phone. And general chit-chat is not enough, either. We must get the client focused on the project (even if he just got engaged to be married). We must give the client pictures and prototypes, engage their attention, and, hardest of all, get them to really think about what they are seeing.
During the project, we want the customer to imagine the project results delivered, and in action. If they like what they see, they will remain enthusiastic. If they don't like what they see, they tell us, and we have an opportunity for good customer service. We can understand and address their concerns. If possible, we make a small change that makes a big difference to the customer. If we can't give them what we want, we can at least acknowledge that they want it and show them that we are doing our best. That kind of personal attention actually can go further to create a good relationship and a delighted customer than saying "yes" to everything.
Let's work to understand our customer, and make them feel understood. Then we can also work to have them understand us, and be reasonable about what can be done within the limits of completing the project on time and within budget. When people feel understood, they understand in return. In that kind of relationships, problems are solved, or accepted. This effort at communication can take a fair amount of the project managers' time, but it's well worth it. It pays off. The job is easier, and, in the end, the customer is delighted.