Scope creep: 4 ways in which your dream project can become the project from hell
Your project started with so much promise. You understood the assignment, and was looking forward to delivering the outputs consistent within the agreed timeline. However, weeks or months later, the work you and your team have actually been doing is different from what had been initially agreed. Specifically, you all are doing more than what was specified in the project contract.
In some instances, the timelines have been relaxed, but in others, especially those that are government or donor-funded, the project completion date remains unchanged. However, more often than not, the project price is not adjusted (increased!) to reflect all the additional work that the client requires.
The scenario outlined above is an example of scope creep, which generally occurs when new features or requirements are added to the scope of an ongoing project, but the impact of those additions, such as with respect to time, costs, and resources, have not been clearly (and fairly) addressed. Although some changes in scope of a project may occur, ideally, they should be minor in nature, and so not unduly affect the methodology, resources, effort and/or timelines that had been envisaged, and upon which the implementation plan was developed.
Having said this, scope creep can be seemingly innocuous, and is only recognised when it is too late. Below are four ways through which scope creep can get a footing in our project.
1. Lack of clarity and depth to initial specifications
Frequently, this reason is at the root of the scope creep experienced. The project requirements being poorly defined could arise due to, for example:
- The person preparing the requirements did not understands the desired project outputs and the environment in which the project it to be executed
- The person preparing the requirements did not have the expertise to do so
- The requirements may have been fairly accurate when they were initially developed, but due to a lag between project conceptualization and implementation, the environment in which the project would be executed has changed
It should also be noted that, if it had not been done prior to contract signature, the initial project meetings still offer an excellent opportunity to clarify and confirm the specifications of a project.
As the technical expert that will execute the project, you are well within your right to question requirements that are not clear, or to confirm the context within which requirements are supposed to operate. Accordingly, you may be able to advise the client on imminent challenges likely – which should all be confirmed in writing (!) – and to manage expectations.
2. Permitting unmanaged contact between client and project teams
Although it is crucial for the project team to interact with the client’s team, especially those that will be using the project outputs, those relationships need to be managed. It is easy for one or more of the client’s employees, especially those who are to work closely with you, as the Consultant or Vendor, to begin to direct your work. Without warning, you may find yourself executing unauthorized tasks to help that individual (or department), which are beyond the scope of the project, but nevertheless consume your time and resources.
3. Customers are trying to get free work
Following from the previous point, clients can sometime expect that because they are already paying you for the project you are to execute, they are entitled to get as much free work out of you as they can. Further, the Terms of Reference and scope of works are merely considered guides, and so the client has the licence to adjust and expand the project, as he or she sees fit. Another scenario that could be at play is that the required project was quite ambitious, but it had to be pared back to meet the budget. Now that it is being executed, the client is trying to extend the effort to cover some of the tasks/activities that had to be omitted.
Hence, although the scope of work for a project is clear, you might find that a client is seeking detailed advice on matters not connected to the project at hand, or they are asking you to perform additional tasks (beyond those initially specified), without discussion of additional pay, or the impact on the original project.
4. Weak project management
Too often, we can get bogged down in the intricacies of executing the project, and not monitor the big picture – especially when the project has several moving parts, requires a lot of manpower, and/or is several months in duration, which must all be coordinated. However, even if you are the only Consultant or Vendor assigned to a project, project management is still crucial to ensure the assignment stays on track with the most efficient and effective use of resources.
In summary, some adjustment to the scope of a project is almost inevitable on most projects, as one moves from the theoretical to the actual – from project conceptualisation to implementation. However, the key is to manage it: what is permitted; and what isn’t. Once again, it means that someone, possibly you, ought to be monitoring the project execution process to ensure that the project deliverable match the agreed scope of work, and you, and your team, have not been unduly monopolised by a project that should have ended weeks or months ago, but for which there was no additional payments.
Image: Startup Stock Photos (Pexels)