An IT Parable
September 29th, 2017There was once a CIO with some money to spend (you can already tell this is a fictional account). He went to three project managers and gave them each a million dollars to implement an IT project that would add value to the organization.
The first project manager hired a consulting firm and developed a set of best practices for change management across the IT organization and even included the customer offices in the organization in the discussions. In the end they had a change management toolset that was adopted across the organization with full buy-in from all stake holders (again, fiction right?)
The second project manager assembled a team of crack developers and ran a flawless agile project, producing a social software package that integrated with Facebook, Twitter, YouTube and your internet enabled microwave to reach out to the organization’s consistently underrepresented twenty-something demographic.
Finally, the third project manager developed a plan to replace some of the organization’s aging IT infrastructure. He wrote a grant to the local power company and personally staffed a bake sale to fund the replacement of their energy hungry servers and ran a pilot project to run fiber-based networking between key pieces of infrastructure, improving the performance of key services and earning him a Nobel prize in IT Management (because, like, that totally ought to exist, right?).
Upon completion of their projects, the project managers came to the CIO. He asked them to explain how they had added value to the company. The first project manager said, “The change management practices and tools we put in place have dramatically reduced the number of change-related outages and improved overall communication both within the IT organization and between the IT organization and the customer offices.”
The second project manager said, “I increased our market-share in the 18-24 demographic by 130% and the 25-32 market by 295%. Our Facebook app is being used by over two-hundred thousand individuals in just the first two months and we project a user base of over a million by years end.”
The third project manager said, “I improved our company’s green image and I project we’ll save over $75,000 in utility costs in the first year alone. Our dedicated fiber channel initiative has improved the reliability of key infrastructure and will be rolling out across the enterprise in the next two years.
And they all lived happily ever after…
No, wait…
Why don’t projects usually go this way? Lets look at each project.
Project one was a change management project. This type of project generally requires more time talking about policy and practices than it actually takes to do the technical implementation. These projects require a balance between involving enough viewpoints to ensure the output of the project meets the intended need without stacking the project with so many viewpoints that they can’t all possibly be met. It is critical in these kinds of projects to have a highly engaged sponsor because there will invariably be conflicts between the priorities of the different stakeholders. It is especially critical for these kinds of projects to be output (quantitative) and outcomes (qualitative) and for the sponsor to prioritize them. Without this kind of guidance, these types of projects tend to fail.
Project two was an innovation project. Most organizations take on these kinds of projects from time to time. One of the challenges with these types of IT projects is that there are a lot of unknowns, perhaps because the initiative is on the bleeding edge and there aren’t any best practices for the tools being implemented or the practices being defined. It is critical that these types of projects are allowed to happen and just as critical that some of them be allowed to fail — in fact, leadership should expect that there will be failures in innovation projects because the level of unknowns tend to make them more risky. These types of projects are perhaps the best fit for agile development methodologies because they allow a team to “fail fast”, looking for the riskiest parts of the project and trying to tackle them as early as possible in the project schedule. Note that fail fast doesn’t necessarily mean that the project will fail, just that a particular aspect of the project may fail. But early identification of failures provide time for fixes that can make the project successful.
Finally, project three is about addressing technical debt — ageing infrastructure. The first challenge for these kinds of projects is getting them rolling in the first place. It’s easy to let entropy kick in or overlook technical debt. There are always other projects that are more interesting or can present more clear return on investment. Projects that address technical debt deliver more subtle value but they are all about building capacity — either by improving the performance of existing tools or enabling the enterprise to expand. Recognizing the value of these types of projects requires strategic thinking, considering the long-term cost of technical debt and the value of addressing it.
There are certainly plenty of other reasons why IT projects fail, but these are some of the most common I have run into.