When you work in a field that deals with clients outside of your company, there is always one issue that you need to look out for: requirement creep. Everybody has great ideas, but once they finally see them in action they realize there are a few things that should be different.
A change in requirements is ok, as nobody is perfect and you can always think of better ideas once you have a product in your hands. Sometimes change can be good, as you get to make the product even better, your client gets what they want, and the company you work for gets more business.
But sometimes a change in requirements can go in a not-so-good direction. Your client could believe that your company did not fully think the requirements through, or they may try to get more bang for their buck by finding ways for you to do extra work for free. Sometimes intentional but mostly unintentional, requirement creep can always happen. So here are a few things that you can do in order to make sure that requirement creep stays at bay, or to make sure that both sides play fair when the creep rears its head.
- Write Everything Down With Signatures
Everybody is human, and humans tend to forget. What becomes a problem is when people remember things incorrectly. Nobody tries to outright lie, but sometimes they are just remembering things a bit wrong. So when the requirements for a project are finalized, make sure both sides look them over, read, and sign the requirement document. This way you have something substantive to look back on that is approved by both parties and marked as so. The John Hancock is the ultimate reminder. - Rethink Your DDD
Once you have finished the Detailed Design Document (if you don’t have one, you should write one), plan on having a full day meeting with your client. During this meeting, both parties should be sitting down going through the DDD page by page. Every section should be analyzed to every detail. Which parts of the program does this part affect? Have we thought everything through? Often times you can find what are actually really big holes simply by having both sides read through the requirements. It’s a long and exhaustive meeting, but in the end you have a design document that is more complete than before that meeting, which in the end makes life easier for everyone involved. Just don’t be surprised if the DDD is twice as big once everything is said and done. - Be Overly Honest To A Fault
Clients and programmers come from separate worlds, and you would be surprised how much trust is required for a client to work well with the programmers they hire. So whenever possible, tell them the truth. Even if the truth is complicated and over their heads, the way you approach the situation will fill them with the utmost respect for you and more importantly, when the situation arises where requirements were forgotten to make the program complete, your client won’t think you are trying to rip them off. If they think you are ripping them off, they’ll want the changes done for free. If you are honest and truthful, then any issues are water under the bridge. Maintaining respect and honesty with your client should always be #1. - Have Your Client Help Create the Testing Plan
In our developing world, the client is the one wanting their idea turned into reality. While there are people good at translating these ideas to requirements, you might not fully understand what the client is expecting from the program. So sit down with them and have them help create the testing plan (often called the Acceptance Test Plan or ATP) for the application. Not only does this help turn the wheels and think about which parts of the application affects others (like going over the DDD), but it allows you to see what the client doesn’t want the program to do.This is especially helpful when it comes to any type of uploading into a data warehouse or other information storage. Both sides can see what should be rejected, what should pass and be allowed into the system, and all of the other intimate details of the process. Most of the final holes in an application can be found here, and there will be no surprises when the application is turned over the client for approval. Nobody likes surprises unless it’s their birthday. - Separate the New From the Old
Eventually some requirement creep may happen, and that’s alright. Especially with applications being based on theory, it becomes really hard to avoid this. What you want to make sure to do is recognize if the requirement creep is really adding a new section to your application, or if it is modifying and expanding on something old. The reason for this is for the stability of the application you are trying to create: Constantly jumping around adding new things and modifying old parts can eventually lead you to a jumbled mess of code!The best thing to do is take anything that would be new and delay it until the end of the project. This way you can focus on the current parts of the application that exist and need the work. Once that part of the application is designed, tested, and both sides agree is rock solid, only then move onto the new stuff. Your program will have better organization, your client will have more time to fully develop what they want that new piece of the application to do, and your goal lines and testing plans stay clear and focused.
In the end, nobody wants to deal with requirement creep. But if you use these 5 helpful tips, you can make sure that the requirement creep for your project is kept at a minimum and, most of all, it allows to still complete your project in an orderly and timely fashion. You can’t avoid requirement creep sometimes, but there are ways to make it very easy on both parties involved.
