Thursday, March 10, 2011

Bipolar Project Funding

"When can I stop funding this project?" asked the CFO, every month for about a year.  "When you decide to shut down the business," was always the answer.  Eventually he stopped asking, but I am quite sure it wasn't because he was satisfied by the answer.  Like many business executives, his belief was: software is written once, it should then just work and not require any more investment.  In an ironic twist, it was this kind of thinking that led to this project in the first place.

This project was the multi-year, multi-release, multi-million dollar overhaul of a large mission critical custom application that was the indispensable core of a $60 million per year line of business.  Due to years of neglect the application had been hindering business expansion, and worse, had caused several Wall Street Journal Events (the corporate term for accidents that require the CEO to perform a public mea culpa).  Which brings me to the point of this note: useful software has a lifespan of more than one release and requires care and feeding appropriate to whether it is a newborn, child, adult, aging, or elderly.

Simply, useful software requires continuous investment because its lifetime will be measured in decades and neither the business it serves nor the technology it is built with stand still.  Moreover, in the growth years (newborn to child), it is impossible to deliver all functionality that could be useful in one release because what is needed is unknowable: the act of using the software changes the organization hence exposing future requirements.  This is unavoidable co-evolution.  Of course, continuous improvement doesn't mean the investment amount is always constant, as some years require more and others less.

Too many organizations do not recognize this fact and impose onerous justifications for every feature, or worse, stop and restart the team.  Team is italicized because stopping and starting ensures that you will have many teams, not one, causing knowledge to be lost, ramp-up time to be added to every restart, and new features to be far more costly than they could have been.  The most efficient way for a software team to deliver maximum value is to keep it lean, minimize turnover, and maximize utilization by feeding them a constant stream of prioritized features.  And stop investing when the application is no longer useful.

So what happened to the project the CFO wanted so badly to end?  Eventually, the overhaul was completed and the business was able to overpower the CFOs desire to cut funding (again).  They kept a reduced, but capable, team to continuously deliver new value against a large backlog of prioritized features.