Releasing Big Software Systems: Just do It

This blog entry is a result of a WSJ article dated 09/25/2007. The article was covering the release of Oracle Payroll ERP in the Arizona State University where the information technology department decided it will be more effective to stick to rigid deadlines, releasing the software on schedule even if all the kinks hadn't been worked out- and try to fix the problems on fly. The software was released in an unconventional way but painful approach. The approach was Admit from the start that there will be mistakes and hten work through with glitches in production with the actual users.

Every large system implementation is mired with schedule, cost and scope issues. It has become a question of whether it will happen or not but when it will happen. The software industry and the project management thought gurus continue to be baffled by the continuous lack of maturity of the software system implementations. Project management outline of processes, tasks, measures are all modes of reducing the risk but do not eliminate the inevitable. Every time a project encounters a miscue, process mania creates more controls and communication models that suffocate the individual output and productivity. But there is no one on the project team (customer, vendor, and other stakeholders) to challenge the process overkill. The progress and the output are measured on project charts and schedules. There is often a quote ‘We will finish this project on Microsoft Project’. The ability to see the big picture is increasingly lost and every issue is deemed detrimental and becomes a stalemate. Subsequently the project team morale goes south since things are not going as planned and finger pointing and CYA mindset sets in. It is tragic and highly debilitating to all the parties involved that no one can see beyond the petty issues. I guess the root cause of this malaise is the expectation setting at the start of any project. The projects are sold as the next best thing after the slice of bread. It is not that the system and solution are not going to improve the overall business process efficiency but the bar is too high. The yardstick is contradictory to the ground reality. The systems take time to mature and they are not right in the first go round. (The fact is that most of the software system/solutions take 3-4 versions before they deliver the actual desired benefits and their design goals. The earlier versions of windows were dismal and it took almost the 4 version to get it to an acceptable and desired threshold of acceptance among the user community. Today it is the age of perpetual beta software’s (Google Gmail continues to be a beta product after 4 years in existence). But somehow that reality check is missing in the business community and the message from the software community gets distorted by the time it reaches the business community. The funny part of the story is that key drivers of the project understand this challenge but they choose to ignore reality. It is either under the aegis of ‘not my problem’ or ‘we are bound contractual boundaries’ that people shy away from facing the brutal reality. As we ignore reality we are actually caught in a downward spiral. The occasional messiahs are shot down by reference to historical facts. The players become so risk averse to the point of negative returns.

Is there a way out of this rut? I guess it takes some individual champions who have the political and leadership clout to ignore the noise. Yes it will ruffle people since you ignoring the cynics, it takes political and mental fortitude to call the shots and make progress. For software implementation you can choose the University of Arizona route of implementation (albeit some will see that as political suicide) or never come out of the vicious cycle of over planning, feature creep, scope change, schedule slippages and risk multiplication effect. I am in the doer category of things whose motto is ‘ Just do it’. I will like to leave you with two quotes from two respected entities in the business world

“We have a ‘strategic plan.’ It’s called doing things.”—Herb Kelleher

“We made mistakes, of course. Most of them were omissions we didn’t think of when we initially wrote the software. We fixed them by doing it over and over, again and again. We do the same today. While our competitors are still sucking their thumbs trying to make the design perfect, we’re already on prototype version #5. By the time our rivals are ready with wires and screws, we are on version #10. It gets back to planning versus acting: We act from day one; others plan how to plan—for months.”—Bloomberg by Bloomberg