One of the golden rules on projects is “Everything is Fine Until It’s Not.”
Large IT projects typically kick off with excitement and fanfare. Senior executives speak at a town hall meeting to rally the troops. Software vendor executives and consulting firm partners show up to slap backs, tell jokes and buy dinner. The project is christened with a galvanizing name, like Project Genesis, The 2020 Project, Vision, well, you get the point. T-Shirts are distributed to the team members. The timeframe is 15 months, start to finish, with three months of padding built into the schedule.
Maybe you are a manufacturer implementing ERP or a hospital implementing EMR. You could be a bank implementing an ATM upgrade or a retailer installing new point-of-sale systems. The project was approved by the Board and your company is on the way! Yahoo!
Three months pass. The teams are working hard! Discovery workshops are underway. Hosting is being organized and your development environments are being built. So far, you’re under budget! Monthly burn on OpEx was supposed to be $2 million, but it is running at only $1.7 million!
Another three months pass. No problems but there are rumblings about whether the promised functionality that your CIO used to justify the investment will work properly. The CIO reassures the board with a slick PowerPoint. Everything is rocking and rolling. Project Optimism is on track! The first delivery date is only one month away and the proof of concept mockups look great!
Another month passes. The proof of concept is not quite working and the consultants don’t know why. The software vendor is not responding in a timely manner and the CIO is at a weeklong technology conference in Las Vegas.
The chairman of the board calls the CEO asking for an update. The CEO texts the CIO. “No more than a two to three week delay,” the CIO return texts. "We need to redo a few of the use cases and then trial them through customer service."
Another month passes. The proof of concept is still not working. Forty percent of the consultants who kicked off the project have been switched away in favor of offshore resources. Your full-time employees are unwilling to take conference calls at 11PM with the consultants in India. Again, the CIO reassures the CEO.
Another month passes. The new use cases do not accurately represent the needed “to-be” requirements so the CIO asks for them to be adjusted to reflect “as-is” or better said, “as-was.” The as-was processes are the ones that were defined in the 1984 deployment of the original mainframe system.
The CEO sends an email to the board. He has the courage not to hide the failure of the proof of concept. What would you do if you were Chairman of the Board?