I sit down with the client to discuss their requirements. We are both stoked about the project and its potential. The conversation goes into all the nice feature we will build and how the whole world will love us. After, I settle in for the hard work of coding it all.
After several weeks of coding I have something to present and request a meeting to show progress. That is where everything goes down the drain. You see, in the time that I have been working on the code, the client has been thinking of many more features that she could add. Features that would make the product even more awesome! And now that she can see what is presented even more ideas are now flooding her mind.
While I expected a “congratulations now finish this” what I got instead was a “great, now lets change it all and add all this other stuff”!. Negotiations about budget? schedule? She will have none of that. You committed to getting the project done and there is a contract to prove it!
I wish this was an isolated event, but it actually does seem to be the rule in software development. In fact, i would hazard that this is a right of passage for all junior developers looking to change rank to seniors.
The easiest way to deal with this problem would be to resolutely refuse any new changes to requirements and stick to what was originally agreed. Bonus points if you have the requirements in written form.
This strategy unfortunately rarely works and even if it did, it would still be bad practise. The reason is that the client introduces changes not to spite you but to increase the projects business success.
So then what you need to do instead is manage the incoming changes. Below are some strategies to do so.
You will never be able to build everything that the client or even the market wants at one point you need to prioritize.
Start by working with the client to distinguish between the needs and the wants. Then from the list of needs prioritize them into three lists:
- Must do
- Great to have
- Will do if there is time
Ensure you get client buy-in on this lists. Put in a reasonable constraint to the length of list of Must dos and Great to haves. A good number would be something like 30 and 50. For any feature that is added to the must do one feature must be bumped down if the list is full. Same case for the Great to have. The “Will do if there is time” the list can grow to infinity if you wish so.
Ensure to finish all Must dos before picking features from any other lists.
In this way the client is forced to make a trade off on the requirements for the systems.
Make expectations clear
XP places great values in metaphors. The development team and the client select what would make a great metaphor for the application. An example for a movie recommendation engine would be “Your local movie store attendant who knows all the latest movies and knows your taste”.
A clear metaphor is a great communication tool.
During the requirement phase you want to go beyond what the clients want to why they want it. Remember to consistently ask
- Why do you want the product that way?
- Why do you need the product to start with?
- Why would anyone use this product?
Getting this answers will give you a clearer picture of what is going on in the client’s mind.
Check out this great resource by Simon Sinek
Draw the scope with your client
In the story I started with, I literally went home with just my memory. In actuality what you need to do is have the scope in written or drawn form that both you and the client agree on.
Key to this process is defining a product vision.
A product vision is the long term strategic concept of the ultimate purpose and form of the system. It encompasses everything that the product will do to satisfy a user’s needs.
In 1997 Jeff Bezos practically wrote the playbook for Amazon’s success. If you were the developer building the system you better have read and understood it.
When the change finally comes
So far, we have done everything we could to get the real needs of the clients on paper. But eventually the change request will come, this time we are ready.
First thing to do is to put in the new request on the lists defined during prioritization. This gives visibility to how the new feature/change fits into the overall.
Once this is done and the change is actually on the Must do then we need to estimate the effort required to build the new feature. We can then estimate the implication to available product resources including:
- Developer time
- Financing for the project
- Product quality
- Chance of eventual success
If after all this it still makes sense to make the change then go right ahead and revise the estimates to reflect the new changes, you just landed yourself a winner!
How do you handle scope creep in your own projects? Tell us in the comment section below.