Scope Creep and Project Change Control
As well as defining the scope of the project in the planning stage it is also necessary to actively manage it. This is because there are two groups of stakeholders that will almost invariably apply pressure to change the scope of the project throughout its life cycle.
The first group can be thought of as essentially external and include project sponsors and end-users. These groups may not have got everything they wanted included in the initial project specification and use the 'requested change' route to incorporate elements that were not included during the initial development of the project scope statement.
This can also happen when stakeholders become aware of the potential of the new system and mistakenly believe that adding incremental improvements during the course of the project will create a better solution without increasing risk or cost.
 |
Project managers must always be aware that stakeholders are almost always tempted to increase the project scope via the back door once the project gets underway. They can justify this to themselves by believing that these changes are relatively small and yet will add a great deal of value to the completed project. Unfortunately this tends to prevent them from being totally objective when considering the additional resources required implementing these incremental improvements. This phenomenon is known as 'scope creep' and is endemic in project work to the extent that it is a major cause of project failure.
The second group who may champion changes to the scope of the project can be thought of as internal. These are project team members who are usually under the direct control of the project manager, for example engineers or analysts. Their motivation is quite different from the first group and usually has more to do with professional pride or intellectual curiosity than purely functional factors.
Their arguments for extending the scope of a particular deliverable usually begin with the words 'wouldn't it be great if…' and then go on to explain that the effort involved would be negligible. These suggestions can get a lot of support from within the project team from people who think that delivering extra or higher quality than was specified is a desirable thing to do because of the recognition that it will bring.
 |
Doing unnecessary work in this way is usually referred to as 'gold plating' and it is a very bad idea because it always brings with it additional risk and cost beyond what has been agreed. Anyone who wishes to impress their superiors by over-delivering should realize that it is far better to deliver early or under budget than to deliver more than was originally specified.
Scope creep and gold plating can become intertwined when end users and developers get together because both see their interests aligned in producing something that goes beyond the agreed functionality with perceived minimal risk. It can be very difficult for a project manager to persuade a team that real risks are involved and that the scope of the project has been defined the way it has for good reasons.
In addition, end-users can easily introduce scope creep through their feedback on early reviews 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 only realize what they want when they eventually get their hands on a trial version.
Remember, the biggest problem with scope creep is that the suggestions made to increase the scope of the project may be very good ones. The problems arise because accepting them implies changing something about the project objectives; the plan, resources and all of the things that have been so carefully matched to the original objectives are suddenly incompatible with the new ones.
Scope creep leads to problems in one of two ways:
1. The suggestion is accepted and the project is committed to do things that were not in the plan, which inevitably leads to cost and time overruns.
2. The suggestion is automatically rejected and this has implications for project team morale.
The second point is important because people may have put a lot of thought and effort into devising what they see as major improvements that have (in their opinion) minimal associated costs and risks. Team members who make these suggestions invariably have a sincerely held belief that they are helping the end-users and by extension they are helping the organization itself.
This means that not only do you need an effective scope management system in place; the reason for it needs to be made clear to everyone on the project team if you want them to stay motivated even when they feel that their efforts in 'improving' the project are being rejected out of hand.
Remember, at the point where the project scope statement is authorized, the scope of the project is frozen. Anything that implies that the actual project and what is defined in the scope management statement will be materially different should trigger the scope management process.
This process starts whenever something is proposed that may change the project scope (this can be determined by looking at the project charter and the scope statement).
 |
1) Get a written description of the proposed change with as much clarity as possible. The originator should describe the new objective but you may have to ask them to write this down in exact and neutral terms. Make sure that you do not suggest that this means that their idea is going to be adopted, only that it is going to be seriously considered.
2) Go back to the project plan and work out the consequences of accepting or rejecting the change. This should be done with reference to timescales costs and performance of deliverables as well as risk. There is always the option of revisiting these ideas once the core project is finished with a view to implementing them as part of a new project.
3) Discuss the results of the re-planning exercise with the originator of the idea and make sure they understand the consequences of their request. This is particularly important if the request has been rejected, as at least they will understand the reasons why this has happened even though their idea may fundamentally be a good one and confer advantages to the end-users and to the organization.
4) If the requested changes going to be approved for implementation then it will impact certain documents which need to be updated and reissued. If the change is sufficient to require a revision to the project charter then this may need to be submitted to a higher level for approval. If a major change is accepted then you will need to re-launch the project ensuring that all team members and all of the stakeholders know about the new objectives and plan.
As previously stated, the scope of the project is concerned with what exactly the project will deliver and the function of managing the project scope is to define and control the work required producing these deliverables.
You may also be interested in:
Project Scope Management | Scope Creep and Project Change Control | Planning How to Manage the Project Scope | Documenting the Project Requirements | Creating a Project Scope Statement | Creating the Work Breakdown Structure | Validating and Controlling Project Scope.
|
|
