I am currently running a series on the blog looking at the reasons why big IT projects fail. I have been asking experts on this subject to contribute and I have featured their individual contributions in blog posts.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Click here to see the last one, which contains links to all 14 featured so far. There are more in the pipeline. James Martin, who used to be European CIO at Lehman Brothers, contributed part 4 of the series.
James has now contributed with an article looking at the reasons why successful IT projects succeed.
Here it is:
Why IT Projects Succeed
By James Martin
“Computer Weekly recently ran a feature on why IT projects fail so I wanted to respond with some thoughts on why IT projects succeed. There are a few signals to look out for in a new project or programme which could help predict if it is more likely to succeed or could be heading for trouble from the start.
If any of these aspects are weak or absent, they can provide an early warning sign that a project may be late, over budget, cancelled or fail to deliver its promised benefits. If action is taken when these issues arise, the chances of a project completing successfully may be dramatically increased.
Many firms have rigorous project approval and budgeting processes but sometimes this can be more about going through the motions rather than taking a meaningful look at the cost, risk and probability of delivering the anticipated business benefits.
The firms I’ve seen do this best managed the process like an investment pitch involving the regional CIO, business sponsor, end users, finance, subject matter experts, vendors and external advisers. The meetings were like a blend of ‘The Apprentice’ and ‘Dragon’s Den’ TV shows with the IT and business team pitching for project investment while being quizzed or challenged by their peers and experts from other departments.
This helped improve the quality of business cases as people didn’t want to be shot down in such a high profile forum. The same process was used to review projects in flight. If a business case or project had deteriorated since original approval, they could be cancelled and staff redeployed to more valuable work. It was a very Darwinian approach but ensured limited budget was generally focused on the most worthwhile investments.
This is not a scientific or theoretical list, it’s a collection of practical observations made since the mid-1990s working in IT management roles for a number of large financial organisations.
Robust business case
Is the business case robust, clear and compelling? There either needs to be a realistic and achievable return on investment (ROI) or a “cannot avoid” situation such as a regulatory requirement or IT security issue. There are other “must do” examples like systems capacity and performance, replacing unsupported platforms and old hardware. If the business case could not withstand questioning in Lord Sugar’s Boardroom, re-think it before going any further. Claiming a hypothetical benefit like saving 5 minutes a day for 300 staff doesn’t count unless the staff cost will genuinely decrease or you can show how the bottom line will be directly improved. Talking about ROI over 5 years may not make sense if a new solution has an expected useful life of 2 years. There can be a lot of hot air in business cases so it’s better to vent it at the beginning rather than get called out and cancelled half way through when the organisation figures out what’s going on.
People close to the sponsors of a project probably think it’s a great idea, but they would because they may have come up with it and then approached the most agreeable executives for support. A wider group must review proposed projects and think about them in terms of organisational objectives and whether or not the work is properly aligned with business priorities and timing. If organisational appetite is low, the project is setting itself up for potential cancellation or de-scoping later on. For example, one organisation refused to approve the most important strategic IT project requested by a business division. What the division did not know at the time was the parent firm was about to exit that line of business and did not wish to invest a substantial sum at that time even though the business case looked excellent at face value.
Learn from regulatory projects
Regulatory projects are often more successful than other types because the objectives, deadlines and consequences of failure are laid down by the regulator. This takes the “what?”, “when?” and “why?” questions away from an organisation and only leaves the “how?” problem to solve. As the consequences of failing to deliver a regulatory project often have greater impact than the failure of other types, organisations tend to take more care of them. Take a look at how your firm’s regulatory projects have been structured, who was involved and how they were managed. If your project is missing any of the key ingredients you’ve seen in a successful regulatory project, proceed with caution.
Have you ever been in a project meeting with a group of really smart people and wondered how they collectively made some very poor decisions? It happens and it can be difficult to overcome if individuals feel they would be speaking out of turn or criticised in public for going against the grain. It’s the corridor conversations afterwards that sometimes come up with the right answers, but they often don’t make it back into the fabric of a project. If you sense a divergence between the formal view of a project and what people are talking about in private, it could be heading for trouble. Find out more about the issue and fix it before it develops into a full-scale split and throws the project off track.
In large organisations it is not unusual for people to have complex and diverse objectives, so making sure a project is at low risk of becoming a political football is key. You may find some people support a project because they think it’s genuinely valuable and others may simply go along with it so they can show later it was a bad idea and step in with their own proposals. It pays to think about who might be interested in using a project as an example of ‘what not to do’ and dealing with it at an early stage. If a project has been widely communicated and all parties have had a chance to comment, this should flush out those who may not be in favour and provide an opportunity to resolve it before going further. It can be a bad sign if a project has started quietly without giving people a chance to comment. The project may be vulnerable to political disruption when it becomes visible later and those who were denied the chance to comment take steps to sink it.
Process vs progress
Project methodologies, processes, documentation and reporting are very important but must not be allowed to overshadow delivering the project itself. If an organisation has an unusually heavy emphasis on project administration, this may be in response to a recent history of unsuccessful projects. Unfortunately this can enable people to hide behind the method or overhead if a project fails. Sophisticated methodologies, timesheets and reporting tools are unlikely to save a project if it is fundamentally flawed in other areas. A consistent approach is vital for large organisations but the most successful projects are run by skilled managers who navigate expertly through a methodology rather than blindly apply it by the book. It’s the difference between a true artist and somebody painting by numbers. The focus must always be on delivering the project benefits with the methods and tools providing a means to that end, not an end in themselves.
Too big to succeed
If a project is longer than about 10 months, technically complex, delivering into a fast-moving business or spans more than one budget year, it faces higher risks and should be split into smaller, deliverable components each of which have some value as a standalone modules. With budgets running on an annual cycle, projects which span a fiscal year-end can risk losing funding in favour of higher priorities. Technical complexity can lead to unpredictable time or cost extensions and if the business opportunity has evaporated by the time the project lands, the effort may have been wasted anyway. For a large project to be successful, it needs to be structured as a flexible programme of smaller projects which provides staged benefit delivery and exit points if the organisation needs to change direction or priority along the way.
The right structure
The right structure and organisational participation is key to the success of all but the smallest projects. An IT team may be very capable of developing a solution in isolation but it is unlikely to be successful as a project overall. It may sound obvious to insist on user representation during a project but it is always worth running through the whole organisation chart and considering whether finance, audit, compliance, HR, operations, facilities and any other departments should also be represented. There is a balance to be struck between keeping project involvement tight and making sure the right people are included. Once the full scope of involvement has been established, the structure and roles must be designed carefully so everyone knows what their level of involvement will be. A successful project needs to be integrated effectively into an organisation, not tacked on like an afterthought.
Focus and dedication
Splitting key resources across several projects is often a recipe for disaster as people have a natural tendency to spend time on the things that interest them the most or are the least problematic. If key resources are split between multiple projects, a trend can emerge where certain projects are absorbing more time than they should making it difficult to manage or forecast progress. Timesheet systems are supposed to help control this but I’ve not yet seen one used effectively over a meaningful period of time. If a project is important, it should be important enough to warrant dedicated resources in its key roles. If it doesn’t, it may say something about how important the project really is to the organisation. There are exceptions, but if a project is worth doing, the best approach is often to allocate people full-time and get it done fast rather than spin it out for months in parallel with a host of other work.
People who mean it
The people who get projects done most successfully tend to be people who believe strongly in what they’re doing. They may not always be methodology or subject matter experts but they know how to get from A to B and sweep people along with them. They’re not just there to follow a recipe and take the money, they’re on a mission to reach a goal. A project needs people like this in its leading roles to drive it forward, steer it through challenges and motivate everyone else involved. These people can be tough for an organisation to deal with, but if you don’t see any of them in a project, you may never see the end of the project either.
It’s easy to criticise project failures with the benefit of hindsight but there are some basic steps that can be taken to improve their chances of success. The reason so many projects go astray is probably more to do with organisational culture than it is about the inherent capability of a project team, so providing the best environment for projects to thrive is essential. The right environment can help deliver even the most tortuous projects but a poor environment can cause even the simplest of endeavours to be bungled, often at great expense.
1 Business case Ensure it would survive a grilling in the Dragon’s Den
2 Organisational appetite Confirm the organisation wants it, not just the sponsors
3 Regulatory projects Compare project setup to a successful regulatory project
4 Split perception Ensure formal and informal project viewpoints remain aligned
5 Political football Identify, manage and neutralise political footballers
6 Process vs progress Focus on delivery, the method is only a means to an end
7 Too big to succeed Break long or complex projects into ‘valuable modules’
8 The right structure Fully integrate the project into the organisation
9 Focus and dedication Get the right people in the right roles, full-time if possible
10 People who mean it Fill leading roles with people who are on a mission to deliver”