| Sooner or later, every project manager develops some finely tuned antennae that are constantly listening for phrases like 'It would be much better if ...'. These phrases have a near-magical power to derail a project, and letting any instance slip through unchallenged can have dire consequences. When people say things like 'It would be much better if ...', they are often about to suggest changing the scope of the project. The suggestion could be to do with timing or, more likely, the performance of the deliverables, but the common theme is that the result will be clearly better and this makes it very easy to agree with the suggestion. It would be foolish not to agree to make things better, wouldn't it? |  | If you remember just one thing from this book, it should be that the main risk you face in your project is from scope creep. The sponsor and project manager need to manage scope creep firmly. Scope creep probably wastes more of taxpayers' and shareholders' money than anything else under the sun. | |
The problem with scope creep is not that any of the suggestions are bad: they are usually entirely reasonable. The problems arise because accepting the suggestion implies changing something about the project objectives, and so the plan and the resources and all the other things that were so carefully matched to the original objectives are suddenly incompatible with the new objectives. Unless it is properly managed, scope creep leads to trouble in one of two ways: -
the suggestion is accepted and the project is committed to do things that were not in the plan, usually leading to cost and time overruns, and/or compromised technical quality, or -
the suggestion is automatically rejected and the firm loses an opportunity somehow to improve the returns on its investment in the project. |  | 'Scope Creep. Adding features and functionality (project scope) without addressing the effects on time, costs and resources, or without customer approval.' PMBOK Guide (p.375) | |
This seems like a no-win situation. The escape route is a scope management process that allows you to keep the project objectives and project plan in line; suggested changes can be accepted but only if the consequences for the plan are also accepted. Before applying the scope management process, it is first necessary to recognize the dangerous suggestions. They can come from all sorts of directions, as the following examples show. -
Other staff within the firm might spot parallels between what this project is seeking to achieve and their own needs. A slight modification or enhancement to this project could make it solve a second group's needs in addition to the original user group's, and it might be much more efficient to satisfy this second group in this way than to run an entire project for them alone. -
Another common source of problems is the insertion of intermediate target dates or extra intermediate deliverables. These can greatly increase the return on a project investment, but adding a second set of user requirements part-way through often sets the whole project back almost to the beginning, while trying to produce additional mock-ups of the output in time for a public relations event can stop everyone on the team from working on the real outputs. -
Project team members are one of the most creative sources of scope creep. People will always try to do their best for the project and for the customer, and it is often hard to get people to understand that delivering output that does no more than meet the requirements is acceptable. Sometimes the behaviour amounts to technical showing off, but it often comes from a sincerely held belief that they know what is best for the end users, despite what was written in the user requirements. -
End users can easily introduce scope creep through their feedback on early previews of the project outputs. Non-specialists can have genuine difficulty envisaging a solution before the project starts, and so despite the best efforts of everyone during project definition, users sometimes realize what they themselves want only once a trial version is in their hands. Furthermore, if users get enthusiastic about the project, they can quickly generate a long list of extra things that it should do in order to give them even more benefits. Any and all of these changes to the original project scope may be necessary but we do need to recognize that scope and effort (and hence cost and timescale) are directly related. -
External suppliers can suffer from the same temptations to over-engineer a solution as internal team members. They can also cause problems when they provide cost and time estimates during the definition phase that are based on their own internal capacity at the time the estimates were generated. By the time the project is authorized and the order is placed, the supplier may have other work and so the contract must be given to other suppliers (involving an increase in the supplier management task), or the work taken back in-house (a clear change in the assumptions of work boundaries). -
Legal or regulatory change can change the nature of allowable project outcomes overnight. The need to stop and replan and to reconfirm that the new project is still attractive is usually obvious under these circumstances. One of the most common symptoms of runaway projects is that the requirements stated in the revised project scope statement no longer correspond to the objectives written down in the project charter. So every time that you hear anyone discussing doing things differently from the way you thought they were described in the project charter, alarm bells should sound. | 
