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.