Rewriting a system from scratch: what do you include in proposals?

Question

Let's say I have an older system/framework that's showing its age a bit, but will soon be leveraged to do much more than it was first intended to do. It's a web app that didn't have a lot of common codebehind in it, so I've proposed that it will be less man-hour effort in the long run to rebuild it using more forward-looking code, with an eye for reducing maintenance effort (I've owned the legacy system for some time now and believe this to be true). Keep in mind the architecture of the legacy system does end up requiring a lot of troubleshooting and TLC: I don't care that it's not "pretty" or written "properly" if it works, but it doesn't "just work" as it is right now. I've done rewrites before successfully with a similar system, and it looks like the powers that be are open to me doing it, provided I propose it correctly.

So now it's up to me to sell the idea. The previous system I mentioned I successfully rewrote was nothing formal, sort of an in-my-spare-time, but this has immediate impact on project timelines if I spend some upfront time in the rewrite. This means I better know my stuff. Having not officially justified a complete rewrite before, I'd like ideas on how to pitch it.

Immediately I'll need to scope the rewrite, of course, but after that it's fuzzy. It'd help to have numbers proving the maintenance costs and savings after the rewrite, but that's tricky to estimate. Anything else?

Answer 1

I've pitched this pitch several times successfully, and here's my general strategy. This is based on our company culture, which is more progressive in terms of the use of technology than others in our line of business, but I believe these strategies will work almost anywhere.

First and foremost, you'll need to make them understand the need and the financial benefit to the company. If there is none, don't bother. If you can come up with concrete numbers, do so. If not, give your best estimate, and tell them it's an estimate. if the number is a complete unknown, try to find out what the number is from someone who might know. Then here's the general pitch format I use.

First, I describe what the program does and how it benefits our company. Point out how it saves money, or gives you a competitive advantage. Make them see that this system is critical to our success.

Second, go through the issues. Describe how the issues impact the business, not how they impact you as the maintenance programmer.

Be sure to include the pain of any end users. (such as, they need to wait for the system to be repaired and their productivity drops, or we could be missing opportunities. Or they need to calculate numbers manually, which takes time and wastes labor. Something.)

If you can honestly say how long it would take to re-write than to leave it go, you'll need to show that you spend x amount of hours per month/week/period/whatever, and it will take this much time to re-write.

If it will take longer to re-write than you spend on troubleshooting, be sure to include the time wasted when there are issues.

Basically, you need to think about the bottom line. The bottom line is about more than money. It's also about providing opportunities to be better than the competition (which is why companies spend on IT in the first place - to keep up or be better than the rest.)

Edit

And also, don't forge to include improvements that can be made by upgrading, and how they can give the company an edge as well.

Answer 2

• Who is using the web app? Get their support for the rewrite or you might be in trouble later, when something doesn't quite work out ("Why did you change it? Now it's worse than before!") A good way to do this is to ask what they want to be fixed. Make sure they get something for the pain of a new system.

• Estimate how long it would take to fix the bugs with the current system and put that next to the number of your estimate to rewrite it. Be honest.

• Check how many hours you spent in the past to fix issues. Make it clear that you'll bring that number down.

• Make really sure that you have to rewrite everything from scratch. Often, it is safer and more simple to migrate the existing code bit by bit with refactoring and lots of unit tests

• If you want to avoid being alone in case of any trouble, get an important person in your company to support this. Look for a decision maker, someone higher up in the hierarchy, someone whose voice has some weight.

Answer 3

Many companies would rather continue to patch something that is working, even if the maintenance cost is high, than go ahead with a risky rewrite. Especially if that function is business critical.

You have a chance though in that you need to add major functionality, and that can be leveraged as a risk of not changing to a rewrite.

However you might just need to get to a "working prototype" implementation before showing what you have. Provide a migration plan, and compatibility testing plan.

If the rewrite was going to take you 6 months in total over the next year, then make sure that the savings are greater than the cost of keeping the existing system. Many people won't care if the savings are only achieved over three or more years.

We're rewritten systems, but they were systems with significant yearly licensing costs that were central to the business. A six month rewrite and 2 days / month maintenance was an easy sell, never mind other benefits such as increasing the accuracy of the system vastly (resulting in redundancies for the people who were required to mentor the old system). All in all, the savings helped keep the company more alive during the recent downturn, and will give us a competitive edge going forward.