The failure rate of IT projects is somewhere between 40 – 70%, depending on various studies. Further, the larger the project, the greater the risk of failure.
The horror story of the government’s health care site introduction has become the Titanic of IT failures, though it appears to be surviving the battering of performance and functional icebergs to glide into the harbor of operation. Hey, at least www.healthcare.gov can be used as a cautionary case study in business and technology classes for years to come.
Why might large projects fail at a higher rate?
1. Too lengthy for sensible time-to-market. The vast majority of today’s products and services exist in marketplaces that morph and shift constantly. Today’s requirement is tomorrow’s legacy functionality. Prioritization criteria should include what can be delivered to make the time-to-market window. The last 20% of requirements can often eat up the lion’s share of the time. Ditch them or move them to ‘version 2.0.’
2. Too complex for reality. If the project plan, produces a Gantt chart the size of China, and requires a squad of project managers and a forklift, this might be a sign. Check that the overhead associated with managing the project doesn’t dwarf the actual work on the project itself.
3. Over-reliance on vendors. If you are too dependent on consultants and contractors, this might be an indicator of lack of organizational strength & readiness. We all need to augment capacity and capability, but the major subject matter expertise and decision making needs to be resident within the organization.
4. “Death of a thousand cuts.” In large projects, a major red flag should be raised if too many little delays sneak in. In a project of many months, what’s a couple days here, a week there? It adds up quick and before you know it 6 months are tacked on. Watch for small delays early, it may be a leading indicator of big risk and big delay.
5. Jumbo the Project Team. Not everyone needs to be on the team. Good collaboration is not achieved by dozens of people attending team meetings twice a week, and good leadership doesn’t require every executive on the steering committee. The team should be the core people who are responsible and accountable. Those who need to be consulted and informed can be brought in as needed.
Get the odds in your project’s favor. Avoid gargantuan and cumbersome; favor small and nimble.
Some recent interesting write-ups on lessons learned from project failures:
Department of Unemployment Assistance in Massachusetts by @mkrigsman: http://www.zdnet.com/massachusetts-grills-deloitte-over-large-it-failures-7000022638/
SAP implementation in California by Chris Kanaracus: http://www.infoworld.com/d/applications/california-sues-sap-over-failed-payroll-software-project-231553
- The TV White Space pilot at UNH is very cool. It is testing equipment that uses the old spectrum for broadcast television, to see if it can be used for WiFi. Read more about it at http://unhbcoe.org/technology/tv-white-space
- Speaking of WiFi, both conferences I attended this fall, Educause and Dreamforce were super except that the hotels and conference centers had appalling wireless broadband. In the hotels it is expensive and slow, and conference center IT folks, sorry, but you need to figure out how to handle big crowds. When a CIO can’t find a vendor booth because the mobile app with the information just ‘clocks,’ and can’t even call the vendor, failure to provide decent mobile coverage may have just blown an opportunity.
- One of my favorite moments over the Thanksgiving weekend was standing in a store looking at nifty gadget, and being able to order it online right there at almost half the price.
- Kudos to the Barnes & Noble service desk in Newington, NH for just doing it right. The associate walked me to the book I needed. The cashier was pleasant and swift. It’s so simple to get it right.
This blog is dedicated to my amazing daughters, who help me avoid confusion and delay in daily life. #voiceofthefamily