Last week on Twitter Kay Johansen asked, "Why do "rewrite" projects so often fail?" After all, rewriting an existing application should be easy, right? We are simply copying the business functionality, and not adding anything new. How could that possibly go wrong?
Actually, there are a number of reasons. The first one that I thought of came from the Standish Group's CHAOS reports, in which they say that some 45% of features in software are never used, and only 7% are always used. I can understand that some features of a commercial product may fall into the never used category - you may need to add a feature in order to stay even with a competitor - but I seriously doubt that those types of features account for 45%!
What that statistic does tell me is that there was precious little business involvement in the process of defining what features the software should have. Alternatively, the delivery cycles were so long that the business was tempted to cram in as many features as possible. Those two issues result in a lack of timely feedback that can be incorporated back into the software, and lead eventually to features that weren't really needed in the first place.
How does that lead to failure on a rewrite project? Well, if you blindly march into the process without re-engaging the business, you're potentially wasting 45% of time & money on features the business didn't really need in the first place!
Also, consider why a rewrite would be necessary. Was the software buggy? Was it not performing well? Was it so old that the hardware and platform software vendors didn't exist anymore? In the first two cases, the business people for whom the software was written likely weren't terribly happy with their system in the first place. As a result, they probably wouldn't want to devote a lot of time to the rewrite... "Just make it work this time!"
In the end, business involvement is exactly what is required when rewriting a system. I'm obviously biased towards Agile processes, but they force that involvement and are much more likely to deliver the system that the business needs at that time, rather than just what it did before. By focusing on the current business needs and providing constant feedback, there is much less risk of failure and a much higher chance that the delivered functionality will meet the business need.
Another factor that can feed into the causes of failure is the belief that the new system must be 100% complete before it can be released and replace the existing system. There may indeed be cases where this is a requirement, but there are likely as many or more cases where the business people could live with the duplication of effort for a certain period of time. At one client I had, a Lean Transformation in the business completely obviated the need for one rather large system - whiteboards and face-to-face communication had replaced the complex workflow that the system possessed and was no longer used. That system, however, was a "system of record" and data still needed to be entered for legal purposes. The business made a conscious decision to continue to use the system in as minimal a way as possible in order to satisfy the legal requirements. There was duplication of effort, but it was deemed worth it until a new system was in place (which will likely occur some 2-3 years after the manual methods were first used). Meanwhile, some simple automated tools were created to assist the teams working within their new process. All of this falls into Lean's principle of optimizing the whole rather than just certain aspects of a process. Completely replacing the existing system first would not have done so, and likely would have eliminated any benefits to replacing the older system. The replacement of that system is now taking place when the business understands their new process much better, and thus is much better positioned for success.
The real moral of this story is that a simple rewrite should be anything but. The business must be as engaged as they would during the development of a new system. The level of support from management needs to be the same. In the end, what is developed should be a new system supporting the current business processes, not what was in place when the system to be replaced was released!
Actually, there are a number of reasons. The first one that I thought of came from the Standish Group's CHAOS reports, in which they say that some 45% of features in software are never used, and only 7% are always used. I can understand that some features of a commercial product may fall into the never used category - you may need to add a feature in order to stay even with a competitor - but I seriously doubt that those types of features account for 45%!
What that statistic does tell me is that there was precious little business involvement in the process of defining what features the software should have. Alternatively, the delivery cycles were so long that the business was tempted to cram in as many features as possible. Those two issues result in a lack of timely feedback that can be incorporated back into the software, and lead eventually to features that weren't really needed in the first place.
How does that lead to failure on a rewrite project? Well, if you blindly march into the process without re-engaging the business, you're potentially wasting 45% of time & money on features the business didn't really need in the first place!
Also, consider why a rewrite would be necessary. Was the software buggy? Was it not performing well? Was it so old that the hardware and platform software vendors didn't exist anymore? In the first two cases, the business people for whom the software was written likely weren't terribly happy with their system in the first place. As a result, they probably wouldn't want to devote a lot of time to the rewrite... "Just make it work this time!"
In the end, business involvement is exactly what is required when rewriting a system. I'm obviously biased towards Agile processes, but they force that involvement and are much more likely to deliver the system that the business needs at that time, rather than just what it did before. By focusing on the current business needs and providing constant feedback, there is much less risk of failure and a much higher chance that the delivered functionality will meet the business need.
Another factor that can feed into the causes of failure is the belief that the new system must be 100% complete before it can be released and replace the existing system. There may indeed be cases where this is a requirement, but there are likely as many or more cases where the business people could live with the duplication of effort for a certain period of time. At one client I had, a Lean Transformation in the business completely obviated the need for one rather large system - whiteboards and face-to-face communication had replaced the complex workflow that the system possessed and was no longer used. That system, however, was a "system of record" and data still needed to be entered for legal purposes. The business made a conscious decision to continue to use the system in as minimal a way as possible in order to satisfy the legal requirements. There was duplication of effort, but it was deemed worth it until a new system was in place (which will likely occur some 2-3 years after the manual methods were first used). Meanwhile, some simple automated tools were created to assist the teams working within their new process. All of this falls into Lean's principle of optimizing the whole rather than just certain aspects of a process. Completely replacing the existing system first would not have done so, and likely would have eliminated any benefits to replacing the older system. The replacement of that system is now taking place when the business understands their new process much better, and thus is much better positioned for success.
The real moral of this story is that a simple rewrite should be anything but. The business must be as engaged as they would during the development of a new system. The level of support from management needs to be the same. In the end, what is developed should be a new system supporting the current business processes, not what was in place when the system to be replaced was released!
Comments