Maintenance--for IT Systems as much as for Cars

I thought this observation about "IT Nuisance Requests" had a lot of merit. It's more exciting to build something new than to maintain what you have. Of course, neglect maintenance long enough, and then you have no choice but to replace with new. So it creates something of a self-fulfilling cycle.

From an IT perspective, the request to change the report structure or one of a myriad of other request is simple enough but it is also small.  This type of project often goes onto a maintenance list prioritized against one another and demands for more strategic projects.  The open request is also a nuisance for IT...It is easy for both parties to overlook the list of nuisances.  Business and IT executives undervalue these individual small requests when prioritizing them against larger investment projects complete with business cases.  The natural inclination is to assign resources to the investment portfolio and address enhancement projects on a best effort basis.

I have seen this play out repeatedly, at different companies. A big project is commissioned, to replace the old, unloved system with the next-gen system. The project winds up being years late and over budget. More often than not, the new project winds up being canceled. Even when not canceled, it often comes in short of expectations, with the result being that the old system is not fully de-commissioned.

This result has a couple of implications. One, if a fraction of the money spent (wasted) on the next-gen system had been devoted to overhauling and maintaining the old system, success could have been obtained, far more economically, far sooner and with far less risk.

The other consideration relates to the overall IT environment. In the past 10 or so years, a huge focus of large, corporate IT departments has been in retiring/sunsetting/de-commissioning/harvesting redundant existing systems. This is far from the most exciting work, but it has become absolutely vital, because the cost of maintaining multiple, redundant systems is crushing IT budgets. So when a big project limps across the finish line, short of expectations, so that the old system is kept alive, this contributes to creating the kudzu-like corporate system environment that, as we have just observed, carries a very high price for maintenance.

Re-Factoring

Dave Winer: As I build layers of software, the simpler I make each layer, the higher I can build. If you don't design to hide complexity behind interfaces, you get overwhelmed by the complexity sooner, and your project can't do as much. Early in my career I often scrapped multiple levels and went down to the roots and rebuilt. Once I understood what the higher levels looked like, it exposed deficiencies in the lower levels. Reworking the lower levels allowed me to build higher.

This almost never happens with in-house corporate software development. Where I have seen large companies go wrong, repeatedly, is that they fail to find a way to start a large project by biting off a small chunk, learning from that, and using that hard-won knowledge to revise their approach. Instead, one way or another, sometimes in total ignorance, sometimes despite better intentions, they wind up making a huge, multi-year bet on a big-bang delivery. And in my experience, that typically leads to either total failure, in the form of outright cancellation, after several years and millions of dollars expended, or substantial failure, in the form of a stunted delivery accompanied by a pro-forma declaration of victory, after several years and millions of dollars expended[1].

Here are some reasons this happens:

1. The proof-of-concept is too small. This is probably the least common reason, but in this case, leadership is smart enough to realize that they need to test the waters. However, the test devised is much too small to provide the kind of reality check needed to provide insight into the much larger project.

2. Gross under-estimation of project scope. This is a common one. If you start out believing the project is medium-sized rather than jumbo, then you won't be thinking you need a significant trial-run. Two comments here. One, I personally feel like I have seen this happen enough to recognize the warning signs, so I would question whether this mistake could be avoided 80% of the time, if companies found a way to tap the experience of their senior people--including being open to bad news. Second comment--even if you accept that this will sometimes happen, despite best intentions, it is a problem that can be recognized before it is too late. The first time that 9-month project is extended to 15 months is a huge warning sign to take a big time-out, and ask--okay, what can we deliver in the original 9 months scope? Then we take stock and re-plan the project. And at this point, we face the facts--its not 9 months, its not 15 months, its going to be at least 24 months.

3. Insistence on business value. Several times I have seen companies that do want to break the delivery down into phases, but they are very insistent that even the very first phase must deliver business value (delvier ROI). This is a huge mistake. It just doesn't usually work this way, any more than the foundation to a house delivers significant value, without the rest of the house sitting on top of it. The tragic result of this approach is that the first pass winds up being way too big and high risk to start with, and more often than not gets expanded from there, as other stakeholders become involved in the project elaboration, and add more requirements.

Here is the right way to look at it. The only value that the pilot has to deliver is to give you the information you need to assess how big the full project really is (still guessing, but less wildly), whether it is worth doing, how much resources it might take to get done, and what different, creative approaches might be employed in planning the project. If you spend 10-30% of your estimated total budget on this phase, and the only result is that you conclude that the project should be scrapped, that is a HUGE win. Because in that case, you clearly were way off in your pre-project estimates, so the ultimate project budget would have been 3-5X that initial estimate--and you still probably wouldn't have gotten what you hoped for. Think of it like buying insurance--a relatively small and manageable outlay to provide a huge risk-mitigation.

4. Unwillingness to take the time to do it right. This is where the corporate reward system, as well as plain-old human impatience, take their toll. Experience tells us that major projects take years. Often, management is not willing to spend a year on a pilot, just to find out whether a larger multi-year project is feasible. Instead, they would rather pretend that the whole thing can be done in less than 2 years.

__________
NOTES

[1] Incidentally, the partial failure may be more expensive in the long run than the complete failure, because this is the kind of thing that leads to the old system remaining in place for certain functions that were cut from the new system. This contributes to the problem of an increasingly complex, rigid and expensive-to-maintain systems environment, which is also something that seems to burden many/most large companies.