How to Handle Software Requirements Change After Implementation Has Begun

There is only one constant in software development: things are going to change. This is an immutable law. The first step to properly handle change is to accept this fact. It is so important that even in the Agile Manifesto principles it says: “Welcome changing requirements, even in late development.” So they are not going away, but that doesn’t mean that you can’t do anything about them.

Let's address why it happens first, because the people that don’t learn from history are condemned to repeat it, then learn how to handle them in a way that doesn’t create headaches.

To the human mind, it comes very naturally that when it is presented with a problem, it will come up with a solution. The inexperienced managers implement control over their departments by this approach: as soon something comes up, they will tell you what to do on the fly. This is called reactive management since everything is improvised. It is not possible for any human to foresee what situations we are going to be presented with, so this management style comes naturally. 

It is not possible to see the future, but the mind is also the greatest pattern detector in the world, and can find patterns even in places where there aren't any. Over time you will start noticing things that are repeating. Let's say we can see a cashier is being paid by a customer with cash or credit card. We cannot see the future but we can see the pattern so if a new cashier is hired, we can let him find how to handle this by himself when the situation occurs (reactive management) or we can create a little document and a training to let him know in advance what to do (proactive management). This is how processes are born.

Processes are the foundation stone of all enterprise software projects. Software developers create tools to let a user do their job more easily and quickly based on these processes since no computer on earth has the capability to come up with a solution of unpredictable situations. But the responsibility for those processes to be done properly lies with the person paying for the development of the software, not the developers, project managers, team leads, or even the Product Owners, who have the responsibility to document and manage the clients' processes for the project.

This is that way because, for example, if we are creating software for accountants, nobody on the development team will be an expert in the subject to be able to say how the software should handle the accounting, so it's nonsense to make them responsible for any of the development of the processes. They are responsible only for the technical parts and for properly implementing the processes, or business rules. There are some cases where the developers have made software for an industry for a lot of years and gain a lot of experience on that industry, but that is out of the scope of this.

When someone writes a new process we say it is immature because we only address the most common scenarios. If the previously-mentioned cashier is presented with new situations, like a client who wants to pay one part of the bill with cash and the other part with a credit card, our software can’t properly handle the change so we are in trouble and we need to change the process so it works properly. Then if the store wants to accept coupons, we need to accept mixed payments with coupons, cash, and a credit card. If the customer wants to use more than one credit card or if a new law is passed, we need to implement processes that accomodate these changes as well.

Things can get complicated easily from an apparently easy process, and they cannot always be predicted, foreseen, or be prepared for. The more situations a process can handle, the mature it becomes and usually, I have seen that that takes at least a year, so any software project is at least a year project even if we deploy in three months. Still, even with a high maturity level, something unpredictable will come up that the process won’t be able to handle and sections of the process also can become obsolete and have to be removed.

So, I hope by now is clear that not having changes during the development of the software and after is completely is off of the table. But that doesn’t mean that we can do nothing about it; it means that we need to integrate handling changes to our work.

Rookie projects managers tend to make project plans like nothing is going to go wrong during the project and the plan will be executed flawlessly. It is known that ships veer off-course but still they manage to get to their destination. How do they do that? They make corrections during the trip. That is the first and biggest secret to handle changes. You must have a process to properly handle them.

There are two ways to handle changes your own work processes. For the technical part, I've already written something about here.

On formal methodologies, the first phase of software development is the analysis, and after it is done, it will produce all the documents needed for the project. If something changes after the analysis phase, there is a process called a “change request” to handle those situations. A lot of literature has been written about this but the problem with that approach is that it's very bureaucratic and time-consuming. Also, a lot of people are not properly trained and poorly execute this methodology which leads them to believe it doesn’t work, but it does. For big projects, it is the way to work, but for small or medium projects is overkill, I would not recommend it.

In Agile methodologies, it is simplifies everything a lot. A Product Owner will create stories out of the requirements which are immutable. If you are coding a module and during the User Acceptance Test it's found that the story is incomplete or wrong, as long the developer does everything that was specified on the story, the story is closed and mark as done, then a new story is created to handle the changes. For small and medium projects, this works like a charm, but in large projects, I have seen that is not the best approach since the number of changes increases exponentially with the size of the project, which leads to having to do a software refactor for each new story. The bigger the project gets, the harder it is to make refactors.

The only thing I don’t like about Agile methodologies is that they don’t put a lot of emphasis on the processes analysis and technical design, and that is fine if the client has mature processes documented and the projects are small to medium, but for clients that their business is based on reactive management, the project will be a sure fail and big projects will suffer a lot with the code refactors.

There are things that lead to a lot of changes out of the scope of the methodologies. One is clients trying to implement improvements to their working processes because now we are creating software for them. Usually, these projects fail. Creating a new process is not an easy task, as we discussed. The process tends to get complicated very easily. Implementing working processes on the software is hard and expensive, trying to make improvements on the fly will lead you to mature those processes when trying to implement on production the software. Not having this vision will lead the client to have a false impression that the developers are doing a bad job. I usually don’t let a client try to improve the processes, I always say: Let’s first make the software work with the current processes you have, and after we implement it then we can improve all you want.

Clients who use reactive management over time start to have a lot of problems when controlling their departments. It is very common to wrongly think that buying software will magically solve the problem instead of implementing processes. You end up, not as a developer, but as a processes consultant and you will suffer a lot trying to get things right. For those cases, I recommend this technique.

Also, as you can see, you can have hundreds or thousands of different scenarios for a given process. You and your client need to be very clever on this, as not all the scenarios necessary need to be implemented or are worth it. For example, if I buy an item on Amazon, and when I fill in the address I make a mistake and put a wrong street number, I communicate this to the vendor to correct the mistake before the item was ship so it won't be delivered to the wrong place. In this case, the vendor instructs me that the order will be canceled, the credit card charge will be refunded and I will need to start over. It is just a simple correction, though; why cancel the whole order instead of just correcting the address since the item hasn’t been sent?

Well, let's analyze it for a moment. Remember that every scenario must be coded and coding costs a lot of money. If that scenario only happens very rarely it may not worth the money and the time invested on the coding to handle that situation; it will be cheaper to just cancel the order and hope that the client buys again (which I did and didn’t mind). This show us that the client and the developers' team needs to be very clever in which scenarios worth implementing to have a return of investment. It is better and cheaper to simplify the process than trying to make it robust.

So even if both methodologies have their pros and cons you must see that having a lot of changes is not about methodologies. It is about three things: poor quality requirements, poor project planning, and poor plan execution. The changes are going to happen no matter what, but you can decrease the amount of them during the project by gathering quality requirements. It is a lot better to prevent changes during the analysis of the project than to be very good at solving changes during software development.

I always recommend these two books that address the requirements more broadly: Software Requirements (Developer Best Practices) 3rd Ed., by Karl Wiegers and Joy Beatty, and the book Exploring Requirements: Quality Before Design by Donald C. Gause and Gerald M. Weinberg.