Dear Bob ...
We (the developers) are once again being put in the position of needing to "sell the rewrite" to CEO. The current system started as an Access database, and has now metastasized into a classic ASP / VB com / SQL monstrosity that is becoming increasingly hard to maintain and even harder to extend. We're being asked to implement features which are made difficult -- if not impossible -- by the current implementation (e.g. lots of 1 to 1 relationships). And of course we're being asked to do it in 1/4 of the time that we think we'll need for a proper job.
On top of that, phrases like "10 year old technology", "object oriented", and "best coding practices" don't mean anything to the guy who holds the purse strings...he wants it all in terms of "return on investment", "new features", and "how can I sell it". (I don't necessarily think this is unreasonable, after all it's HIS money and HIS company...he's a salesman, not a techie.)
How best to make this sale? Shouldn't the considered, unanimous judgment of his IT department be sufficient? How do you put a dollar value on things like "morale", "extensibility", etc?
Thanks!
- Selling Technology by the Pound
Dear Seller ...
While it isn't clear whether you're talking about an in-house system or a product your company sells, the only real difference is how sharply the problems will become apparent to the company.
First of all, I agree that phrases like "10-year-old technology," "OO," and so on aren't relevant to the discussion. Even less so is the abused phrase "best practices." Your CEO will hear these and think, "Smoke, smoke and more smoke."
The unanimous judgment of his IT department should count for something. The ability of the IT department to explain its unanimous judgment in clear, businesslike terms will count for a lot more, and will do a lot to enhance IT's persuasiveness in the next important conversation. To that end:
You're better off explaining that over the years, too many design decisions were made without enough of an eye to the future, sometimes because the developer was only solving today's problem today, other times because the company wasn't willing to invest the extra time and money required.
Regardless of the reason, the result is that you're now pretty much painted into a corner, which means each additional change and enhancement takes more time and money than is necessary.
If the discussion is about your company's product, you should also mention that smart customers pay close attention to a solution's internal architecture, and yours won't pass inspection - you'll lose business to competitors because of the design problems with the current system.
Acknowledge that this is a big decision. If at all possible, chart an incremental migration path as well - big rewrites very often turn into big fiascos. Even if the incremental path requires "scaffoldware," that's better than trying to create a complete replacement all at once. Most CEOs care a lot about risk, and this approach will go a long way to provide reassurance.
- Bob
Powered by ScribeFire.
Posted by Bob Lewis on June 11, 2007 05:19 AM
