Stamp Out Scope Creep!
If you've ever been to the beach when the tide is starting to come in, you may have a basic understanding of scope creep. Its a slow, insidious encroachment, one you may not even be aware of it happening and before you know it you are up to your ankles in water!
From InfoGalactic:
"Scope creep refers to uncontrolled changes or continuous growth in a project's scope. This can occur when the scope of a project is not properly defined, documented, or controlled.
Scope creep can be a result of:
- poor change control
- lack of proper initial identification of what is required to bring about the project objectives
- weak project management or executive sponsor
- poor communication between parties
- lack of initial product versatility"
So how due we push back against scope creep?
The first piece in controlling scope creep is a scope document that clearly! lays out the deliverables, and timeline for the project. Often called a requirements document, it should avoid jargon and tech terms. In some cases it may include the work involved at a high level. Also be sure to talk to everyone who has a stake in the final results. A business sponsor may not be aware of all the requirements the users are expecting. By including them in this stage, we avoid the addition of new requirements later.
Once this document is compiled it should be agreed to and signed off by the requestor (aka business sponsor), the project manager, and the manager of the team(s) actually doing the work. By documenting this, everyone should have a common understanding of what the project entails.
Because scope creep is inevitable, the second piece is a change control process. This means that once the project starts, if someone wants to add additional functionality or make changes to the agreed upon requirements, there is a process to handle them. The presence of this process doesn't mean that every change will be incorporated though. A change control process should have a mechanism to review the request, approve or reject it, and some way to adjust project timing, resource requirements and budgets. Keep in mind rejecting a change is not saying it can't be addressed after the current project is complete. It just can't be done in the scope of the current project.
Additionally a well-defined project plan goes along way towards containing scope creep. By laying out as much as possible the steps and milestons to complete a project, it becomes clearer to everyone involved what is needed to complete the work, what resources are needed when, and what the underlying elements are for each step of the process. In other words,if step 5 requires steps 2 and 3 to be completed before it can start, adding additional requirements that impact those predecscors will push out the time to complete the later step.
Finally, the last piece needed is good communication between the project team, and the stakeholders. For smaller scale projects, periodic emails usually no less than once a week, laying out the work that has been completed, and next steps to be undertaken is likely sufficient. Larger scale projects should have a weekly or bi-weekly project meeting with the team doing the work and the stakeholders.This meeting can be used to review change requests when they come up, and approved or reject them.
Lastly, watch the emotion
One last thing to remember is to keep emotion out of the process. By maintaining an air of professionalism, and being upfront about change requests and referring to the agreed upon requirements, and processes, you can go along way towards controlling scope creep.
Comments
Post a Comment