Being an IT professional, I’m amazed that this keep happening. The Register reported today about yet another big government IT failure. Some of the highlights include an initial scope of $AUS 14 million and 1 year blowing out to $AUS 50 million, and 3 years. With the end result being a failure.
Among the findings the article mentions –
“… high turnover of SI consultants saw a total of eleven Fujitsu project managers during the three years from the start of the project until Phase 1 go-live in April 2012.” One of those project managers seems to have worked on the project for eight hours.
I’m amazed that all of these large consulting firms seem to be able to source these sorts of projects given their failure rate. I’m equally amazed that clients are willing to accept big bang waterfall approaches to tough problems even though most real technology firms abandoned them 7-8 years ago.
Our team has encountered some of these projects first hand. We try to set them straight when possible, but in some cases they have already committed to the big consulting firm and cannot extricate themselves. It is interesting to watch the dance that comes down to “If you try and change now and fail, it will be your fault. If you follow our plan for another 2-3 years and it fails, then you can blame us.”
For anyone on the business side reading this, if you get a proposal for a project that is to last more than 18 months, there are several questions I think you should ask the provider (whether internal or external) –
- Can I speak to several references for projects of this size you delivered successfully?
- Have you ever had a project of this size fail?
- Have you successfully delivered a project using the technologies you are recommending?
- What is your (our) team’s turn over rate? Rate of project reassignment?
- Can I talk to some team members that have stayed on the same project for 18+ months?
- How do I know you aren’t going to pad your resume for 12 months on this project and then move on to another project/company with your “new” credentials?
This may seem adversarial, but better you make them convince you up front than thinking about these things after you are dissatisfied.
(Pro-tip: The answer to the 2nd bullet point should not be “No, we’ve never failed”. It is either “Yes, here is where we failed and this is what we learned from that..” or “We’ve had several items that were headed towards failure, but this is how we detected that and the course corrections we made in order to succeed”)
When I read/hear of these types of big business project failures, I’m reminded of my days at NASA and meeting Gene Krantz. He said “Failure is not an option” when he helped lead a team of mission controllers/engineers work the Apollo 13 mission to return three astronauts home from a disaster in space. I wish I still had the picture of me shaking his hand (as the first person I sought to meet when I started working at the Johnson Space Center).
Noe –
The problem here is different though. IT project do fail. Heck even space flight does. The question is – how do you realize you are failing early and at low cost so that you can adjust, rather than waiting for a huge and expensive failure later on.
An approach that follow as “fail fast” philosophy also has the upside of “succeed fast” being possible.
Interestingly enough, the “fail fast” philosophy in space flight technology is through integrated sims (or simulations). In the case of Apollo 13, they faced an obstacle they were not prepared to face. But leaving that aside, “fail fast” is exactly about learning early enough what are the possible downsides of what we are doing and how will we adjust. One of the projects I remember is the four launch abort scenarios that three young flight engineers created based on an integrated sim they participated in. I was tasked to help them create the animations of the abort scenarios and it was pro-active thinking at it’s best.
Very good point. Never thought about the fact that simulations are both “fail safe” and “fail fast” for real world engineering.