As a faculty member at Brown University’s Executive Masters in Science and Technology Leadership Program, it was an honor to address the distinguished group of CIOs and IT leaders at Novarica’s 12th annual Insurance Technology Research Council Meeting. My presentation reviewed some general best practices for technology leadership, with a focus on death march projects: what they are, why they happen, and how to avoid them.
Coined by Edward Yourdon in his 1997 book, a death march project is one that takes twice as long, consumes twice as many resources, and costs twice as much as originally planned. In other words, they’re projects for which everything that could possibly go wrong does, in fact, go wrong. These projects are unfortunately much more common than anyone would like, and many in the insurance industry have either witnessed or directly been involved in one.
So why do death march projects happen and what can be done to prevent them?
- Unrealistic expectations. With the rapidly increasing complexity of technology, major projects are requiring more functionality at lower costs with less manpower. Naïve optimism needs to be countered with regular level setting and expectation checking. A healthy partnership between IT and other business units is a great way to keep everyone involved on the same page.
- External pressure. Intense competition caused by globalization and new technologies can lead organizations to move too quickly and gloss over critical steps. Projects should prioritize finding the best technology to fit a customer’s needs, not forcing a customer’s needs to fit into the technology. Pressure caused by new and unexpected government regulations is also a factor to contend with.
- Management gaps. Proper management is critical to the success of any project. Inexperienced (though well-meaning) project managers, promises made by marketing, sales, or senior executives, and skipped steps such as a thorough risk assessment stage can all turn a project with solid potential into a death march. Managers should also be responsible for evaluating a project after it’s done. Sometimes, teams do a post-mortem on a project, write everything down that went wrong, but then file it away and forget about it. It’s important that the information from past failures be explicitly discussed and reflected on to prevent the same mistakes from being made again.
Major technology transformation projects will and should continue to take place, but death marches don’t have to. The key to avoiding a death march project is learning from past experiences, both successes and mistakes.
Add new comment