Make or break
- 05 October, 2010 01:00
When IT projects fail, the usual reaction for CEOs and the boards is to blame the software, third party consultants, or the IT department, says Sarah J Runge, director of Corporate Profiling Global at ITPSB Corporation in the US.
"They simply do not understand that massive investments do not necessarily guarantee success," says Runge, who has been involved in IT project delivery for 25 years. "My research points to the quality and rigor of pre-investment decision making and pre-implementation planning processes from the outset, as being the determining factors in the success or failure of IT projects.
"Many organisations claim to have these processes in place, and I am sure that they do," she says. "However, the prevalence of IT project failures reflects either a lack of process due diligence, a lack of rigor or poor quality input." This input can come from inaccurate sources and self-appointed experts.
Runge started her IT career in Wellington as a computer operator and trainee programmer, before moving to Australia in 1985.
For the past five years, Runge has been based in Los Angeles, where she works as a business consultant, specialising in corporate profiling for IT projects.
Runge has distilled her research into a concept called 'corporate profiling' that she has detailed in her book entitled Stop Blaming the Software.
She believes the pre-investment and pre-implementation planning processes for IT projects should be standalone processes that are driven by the business.
She warns that when these processes are "shrouded" in IT governance frameworks, or interwoven into any other associated processes or functions, they simply do not receive the amount of due diligence from the business and executives that is required.
She says there are extreme cases where pre-investment decisions are made based on what she calls the "HIPPO" principle, or "highest paid person's opinion. This is also done unilaterally or in isolation with very little consultant with the CIO, the IT department or the users, she claims.
When these projects fail, the CIO is the one left to explain the outcomes to the stakeholders. "CIOs need to manage a way to ensure that business units and executives are accountable for their project input and decisions," she says. "CIOs need to bring their CEOs out of their ivory towers and into the driver's seat of the IT investment decision making and pre-implementation planning phases, as well as getting business involved and accountable for the non-technology aspects of an IT project."
In an interview with CIO, Runge expounds on some of the key issues she tackles in her book, including when to pull the plug on a project.
CIO: Have you personally been involved in stalled or failed IT projects?
I have had the good fortune of being involved in successful projects, but sadly, also projects that have stalled.
One typical failed IT project that comes to mind involved constant requirement changes right up until the "go live" date. The "expert" from the customer's organisation who documented their requirements hadn't actually consulted their end users, and so to appease this powerful customer, the IT department allowed these changes to be made. Unfortunately the system ended up being unusable for end users.
This case demonstrates why IT should not be directly involved in customer/business liaisons. Instead, user departments and business need to be separately accountable for their own unique requirements.
CIO: What are the factors that lead to the successful project implementation?
The factors were predominantly sociological rather than technological. Too few organisations spend sufficient time or resources at the critical pre-planning phase, and even when they do, often the people involved are not qualified to perform their roles well due to weak selection processes. For example, there are too often "self appointed" experts or those based upon the "HIPPO" principle.
Runge believes the critical sociological factors that need to be in place to ensure successful project outcomes include, but are not limited to, the following:
• Chief executive level involvement in all strategic decision-making during the pre-investment and pre-planning phases, all of which are underpinned by rigour, visibility, collaboration and accountability.
• A clear indication that the full support of executives, stakeholders and users has been obtained.
• Clearly defined and articulated success and progress measures that are communicated to all the involved parties.
• User input and involvement at the outset to ensure that needed factual requirements are gathered from all affected parties.
• Upward, downward and sideways communications through appropriately appointed individuals and channels, including the external value chain.
• A well-established and rigorous IT governance and risk framework and a solid and proven change-management process.
• A best-fit vendor needs to be selected. Don't succumb to incentives that favour the most popular vendor only.
• Adequate investment in training and process development.
• Visibility of the organisation and its extended value chain to identify key people, processes, requirements and information sources accurately.
CIO: What then, are the roles for the different people involved?
The key people need to be carefully identified and selected from all levels of the organisation, as well as from the external value chain. They should be involved in facilitating and building a solid foundation for the project during the pre-implementation planning phase, she says.
The roles played by these key people fall into the following groups:
Decision-makers: Thorough pre-investment strategic decision-making and pre-implementation planning should take place prior to authorising an IT project.
System implementers: Technical capabilities and skill sets should be appropriate to the scale and complexity of the project.
Communicators: To facilitate tri-directional communications. Utilise both business and technical communicators to ensure that all identified parties are included in communications and all appropriate parties have a voice and are heard.
Project supporters: Those who support the project and are committed to it are needed for positive ongoing support, guidance and management.
System users: System users should be involved to ensure that complete and accurate business and user requirements are gathered and maintained.
CIO: What can an IT team do to remedy an already failed project?
First, identify and obtain a solid and accurate consensus on the reasons why the project is considered a failure.
Only then can you accurately investigate and analyse what went wrong with the project. What in the team's opinion specifically contributed to the failure, for example skills, budget overrun, technology, business processes, sociological reasons or third parties?
Lastly, can the identified causal factors successfully be rectified and salvaged with a reallocation of financial and or human resources or other corrective action?
In the event that the project is clearly a runaway project that cannot be remedied, don't throw good money after bad. The hard decision, but the right decision, may be to euthanise the project immediately.