Uncontrolled changes in a project’s scope or Scope Creep is a risk in most projects. It can happen by a big amount of reasons but the main it’s not being aware of it.
So, I would like to review some tips about how to take care about it:
Initiation
- Scope Management starts before the project starts,
- Be sure you understand the project vision through the major deliverables,
- Understand the priorities of the stakeholders,
- Review the Change management process with the client.
Planning
- Define your deliverables and have them approved by your client,
- Break the approved deliverables into actual work requirements. Break it again till you be sure about there is nothing lost or defined wrongly,
- Break the project down into major and minor milestones,
- Evaluate the project schedule as a director visualize a movie before to film it,
- In this evaluation check that you achieve the deliverables,
- Be sure the Project Definition is completed and communicated to all stakeholders before you start your project. Once it’s done, get the approval.
Executing
- Expect that there will be scope creep. It’s there!
- Educate the project developers about change management processes,
- Document your efforts before you begin them,
- Ensure that all team members are aware of the agreed-to scope and have read and understand the scope as documented in the Project Definition.
Monitoring and Controlling
- Remain alert to small, nonessential changes the team may be making informally, thinking that they are delivering better service to the customer or increasing client satisfaction.
- Scope changes, even small ones, need to be evaluated in light of their overall worth and their impact on delivering results on time and within budget.
- A small change late in the project usually requires unanticipated, extensive rework in related parts of the solution.
- Keep on top of your issues. Many project changes will arise from project issues.
Closing
If you are alive about Project Creep in this stage of the Project, you did it! If not, you probably are delayed and you need to close faster than desired.
I forgot something,
Scope Creep doesn’t exist in agile projects, it’s supposed that scope is going to change.
Scope Creep is actually an Issue rather than a risk. It is something to be managed as part of the project.
Scope Change Control is the straight forward way. If the customer wants a change, then the Change Control process can deal with it. An assessment of the cost and schedule impact as well the technical impact is done and if the result is acceptable, the project plan is change.
The notion that agile makes this go away is nonsense. Change occurs in all projects from the smallest to the billion dollar ones. How you manage in the “presence” of this change determines how these changes impact the project.
All agile does is push the Change Control outside the development process, back to the customer. But ignores the impact analysis as a direct accountability.