The best way to deal with scope creep is relentless transparency.
Typically, when the scope of a software project increases, the team has two choices:
- absorb it
- force a change control process
If the change is minor, and there is no negative consequence to absorbing it, then there is no problem (change the button color from red to blue). However, most likely the situation we find ourselves in is that it is a change the team can NOT absorb without impact, yet the timeline/budget remains the same.
Very few projects have all the time/resources/money to do everything
Most projects have some form of scope creep and scope change. This is fine. The idea is to engage in relentless transparency.
This transparency first starts with a list of requirements that are prioritized, so we know what is most important to build, and what is less important to build. In this way, when a new requirement comes into the picture, our business partners prioritize it as well. If it comes in at a higher priority than something already on the list, we have a conversation.
What is not so great is that our backlog contains 200 points of work. Right now, we are working based on the priority you have given us. The highest priority items will be worked first, and the lower priority items will be worked last. Since we have more items than we can absorb, we will most likely get about halfway down this list before we run out of time and funding. I wanted to make sure you understood that so our expectations are clear on both sides. If some of these items past the 100 point mark are indeed necessary, we have a few choices, we can get more funding/time, or we can shuffle things around to ensure the backlog matches with your priority. Please let me know how I can help.”
