Scope Changes, Good or Bad?
Have you ever been responsible for a project where the client repeatedly asks for changes? Or worse, the users who have no responsibility for cost or delivery date, keep asking for changes that prevent you from wrapping up the project and getting it done?
Of course, product scope changes are not inherently good or bad, but they are always disruptive in one way or another. Aside
from the obvious impact on cost and schedule, there may arise an even more intractable problem. After an "excessive" number
of changes, the team may simply not want to make any more changes at all. They are fed up, they've already worked hard and perhaps
done a lot of paid or unpaid overtime, and they just want to get the darn' thing finished.
So, the issue is this, what should you do about scope changes? And the answer is, as in most cases in project management, it all depends! It seems to me that it depends on several factors:
- How good is the relationship with your client?
- Does the client recognize that every scope change, of whatever sort, has an impact on the work?
- Is the client willing to pay for the consequences in both time and cost, especially if it means rework?
- How many changes have been requested already, and are they genuine and reasonable?
- Although the changes may seem superficial, how deeply are they embedded in the project technology?
- And finally, what is the current state of your team's morale?
Assuming for the moment that the answers to the first four questions above are favorable, then the typical reaction from most project teams is to just go ahead and make the changes. But for the project manager there is a more telling metric:
- When in the overall project life span are these scope changes now being requested?
The impact of this last question is best illustrated by the graphic shown in
Figure 1.
Figure 1: Adding value versus cost to change
Figure 1 shows that up to some point in the early half of the project's execution phase, changes can add value and be beneficial.
However, later on, changes become progressively more destructive to the well-being of the project. That's typically because
of the extent of rework involved, including redesign and retesting, and the feeling that the prior work was wasted and, who
knows, maybe this next work will also be wasted? This is very demoralizing for the project team, so the quality of work suffers
and inevitably the quality of the resulting product.
This situation may be further exacerbated for a variety of reasons. There is a feeling that the project has gone on for far too long and people just want the project to end. Or perhaps because the deadline date is being held firm and more overtime will be required. Or perhaps relations with the client have not always been that smooth or even that this has been because relations between the client and their own users is strained.
All of this puts the project manager in a tough position because his or her team is no longer motivated to deal with the changes. So now is the time to show strong project manager leadership. Here are some suggestions to consider.
- Get the client and the users involved. Explain the disruption being caused, and ask if the change really is worth it? Could
it be postponed to a separate subsequent project so at least it is possible to get this one finished? Make it clear to the client
that if they are not careful, they may not get a useful product at all. Try and get a commitment to round up all "last changes" for
one last change - in other words hereinafter freeze the scope!
- If the change is justifiable, then to your team, stick to the facts of the background and the justifiable circumstances. That is, talk through the changes that are needed and why they are important from a business perspective.
- Acknowledge the pain. Let the team know that you understand that they may not want to make the changes and that morale could be better. Don't dwell on it - but acknowledge it.
- Be motivational. Appeal to your team's sense of working together and the value they are providing to the organization. If there is a particular hold out, talk to the person one-on-one. Listen to his or her concerns and get a personal commitment to keep going. If that fails, perhaps consider releasing the person from the team, explaining that they need a rest - or at least a change.
- Get your own management involved. Perhaps they would be willing to make a presentation explaining the importance of the product, or customer relations, and so demonstrate the project's visibility with upper management.
- How about a few perks? Donuts in the morning and pizza during the extended hours provide energy - even if they do put on weight!
Keep everyone informed of the state of the project and the time and effort remaining. Perhaps some additional milestones are required that can be celebrated. If things are really bad, then progress by inch-pebbles!
The project manager's job is more than just "telling people what to do", it's about creating camaraderie, a sense of ownership and the goal of ultimate product success. Viewed this way, it is quite possible to get through some tough situations involving "destructive intervention".
|
