Lead IT or Lose IT

It’s a well-known fact that IT projects often end in failure. But many people will be surprised to learn that it’s often the project owners with final responsibility who are to blame. IT projects often fail because of poorly defined or constantly changing goals, or an overactive senior management doing more harm than good. This form of board room mismanagement often goes unnoticed. Some IT companies make executive failure in Holland all too easy…

IT in organizations is becoming increasingly an off the shelf affair. Custom-built IT systems are becoming rarer – people prefer to buy and implement standard software. There are plenty of options available to them. A manager needing to select an ERP package and have it implemented in the organization will probably not have much experience with making such choices. Neither will a health care manager who happily plunges into a brand new HIS (Hospital Information System). Lack of experience leads to insecurity. A persistent misunderstanding among executive managers is that you need to be an IT expert in order to be a good executive project owner.

Also, because of their dubious reputation, IT projects are not exactly popular amongst those with final responsibility. They are regarded as expensive, difficult to control, high-risk and overly detailed. ‘I know nothing about IT projects and I prefer to keep it that way’ is a standing joke among executive managers. Instead, they prefer to delegate project ownership to someone who ‘knows what they’re doing’: IT specialists, or delegated project owners. And that’s where things start to go wrong. When project goals are formulated or developed at a relatively low level of the organization, they are likely to be too technical or feature-driven and unfit for successful project management. In the project chaos that ensues, hardly anyone will notice that inadequate executive project ownership is at the root of the cause.

65 million Euros, five years, and zero results The non-committal attitude of executive business management and badly orchestrated executive project ownership are the most important causes of failed package implementations. The study shows that more than half (53%) of IT projects with standard software end in either partial or complete failure. Four in five of failed IT projects fail before information technology is even involved. The failure is not caused by technical problems, but by miscommunication and – very importantly – by convulsively ruling out all risks in the software selection and implementation process. Not even the project goals are always clear. The study mentions an IT project estimated at over 50 million Euros, that failed completely. The goals of this particular project remained unclear for a very long time.

An insider said:

The first year the goal was ‘phasing out existing IT systems’. After that, the goal changed into ‘working more process-oriented’, and finally it became ‘customer value’. With the last change of the formulation of the goal, it turned into a business goal and IT was forgotten. That’s why it never really took off. The first business case was a good business case. It was positive, but parallel reorganizations started to occur. Because of these reorganizations the savings that were calculated in the business case were already achieved. After three years, a new business case was made. But then that business case was negative, because the credit side had been partially achieved already. Then they said, it’s necessary to do this after all, so let’s do it anyway.

What is typical about this huge project is that at first, the goal is defined in terms of IT: ‘phasing out existing IT systems’. When that did not work, they look back at the function of the IT systems and the goal turns into ‘working more process-oriented’. But that didnt deliver the desired results either. IT service providers and program managers kept walking into walls. Heads rolled where the chaos was at its worst: at operational level in the project. One last try. The goal became (in even more abstract terms) ‘customer value’. Again this didnt work out. In this project IT and business goals were juggled for years, without either of them being assigned its proper place. The project was discontinued after five years and a ‘confidential’ amount (of somewhere around 65 million Euros). Hundreds of people had worked for years on something that eventually rendered almost nothing. It is a hilarious and very costly example of disastrous executive project ownership that wholeheartedly deserves the qualification mismanagement, but otherwise goes unnoticed.

Executive project owner lets it all happen The study shows that in 40% of all failed cases, the projects go wrong in the quotation or contract phase, and the phase after that, the definition phase. In another 40%, the cause of failure lies in the design of the particular application of the standard package. Generally, about four in five failed IT projects fail before the technical realization had even started.

The executive project owners who were interviewed all have a different view on what was the moment of failure. Almost unanimously they think that failed projects only start to go wrong towards the end of the project: when the standard software is being tested and taken into use. The difference in perception of the moment of failure is understandable, as to a executive project owner the results of the project do not become visible until the system is being tested. But it also means that the executive project owner has not been in control. It is safe to say that the collaboration process during the preliminary, design and development phases, during which the executive project owner (often the business owner of the system) signs off on the deliverables for each stage, apparently insufficiently predicts the project results to an executive. This is a case of inadequate executive project ownership.

It turns out there is far too little attention for the coherence between business management and IT. In the study this shows in poorly focusing the project, especially by not writing a business case, or not using it for project controls. Moreover, using business-driven acceptance criteria poorly or not at all is a typical example of inadequate executive ownership. Closing an imbalanced deal for the delivery of IT services is an important cause of failure. The executive project owner often have the process made watertight legally, thus frustrating a good collaboration. Executive project owners often fail to ask the right questions. They are therefore not keeping track of the progress of a project effectively. As a result, these executives do not notice the project will fail until the IT system has been designed and it is being tested. Then it turns out that while the system may operate at a technical level (after all, it is standard software), it does not fill the needs of the organization. The IT systems is at odds with the organization: it cannot be used, or not sufficiently used for the business processes. It is too late to turn it around, because all the money has already been spent. Failure is a fact.

First cause of failure: an ill-defined and changing goal When we take a closer look at the causes, an ill-defined and ever changing goal turns out to be one of two monumental causes of failure, which can both be traced back to poor executive project ownership. But how can a project have ill-defined and constantly changing goals? The cause often lies in the way of thinking and working, combined with a lack of leadership. IT specialists tend to make IT project propositions which have a general or unclear goal at first, because they expect they will be able to clarify the goal of the project as they go along. This approach, polishing a project goal from ‘coarse’ to ‘fine’, is considered a normal part of a project-oriented IT approach. According to many IT specialists, project goals can only be defined in general terms and fine-tuned over the course of a project. It sounds logical and convincing. The problem is, however, that the people involved all too often overestimate their ability to direct the developments in the direction they have worked out for themselves (and which they consider useful).

Without the help from the top business management, failure is more likely than success. Project management is often delegated to a level that is too low within the organization, and so they lack overview and authority. Any practical obstacles IT specialists may encounter are usually only dealt with in the second half of the project. These can occur in many forms: the necessary alignment of business and IT doesn’t work out, or the IT architects from the head office won’t cooperate, or the strategy behind it is unclear, so system owners don’t know what they want yet, or the software package is unsuitable, or the infrastructure is not compatible or not finished yet, unit managers won’t cooperate or constantly come up with new demands, etc. Endlessly muddling through is the only result. The root cause turns out to be bad executive project ownership, resulting in bad project governance and ill-defined goals at the start of the project. All respondents in the study – this includes business owners, project managers, the interviewed specialists and the project members who took a survey – give this as the main reason for failure. In the online survey, respondents were asked to complete the following sentence:

Projects end in failure because…

• ‘the client doesn’t support the project sufficiently in the organization.’
• ‘the organization strategy and company goals are unclear.’
• ‘mistakes were made in the goals phase.’
• ‘they don’t pick the right tool for ‘the problem’.’
• ‘they want to do too much at a time.’
• ‘the client is insufficiently clear about what they want to achieve.’
• ‘they focus on the goals and the business case is overlooked.’
• ‘they don’t know what they want.’
• ‘the organization isn’t ready for the new way of working.’
• ‘the decision takers think a package implementation will solve all of their problems.’

These randomly selected answers from the project employees (consultants, project leaders etc.) show a sense of frustration. They too see ill-defined basic principles and goals as the most important causes for failure.

Second cause of failure: the firm hand from the executive management The second major cause of failure, I would say, is the ‘firm hand from the executive management that throws a spanner in the works.’ Allow me to explain. Executive project owners usually have little experience with large-scale implementations. The average senior executive has only supervised/commissioned one or two organisation-wide IT projects. So they lack vision on how to deal with uncertain factors in the project before the start of a large-scale project with standard software. One way of dealing with this uncertainty is ‘the firm hand from the management’. There is a lot at stake and failure is not an option. So the scope, budget, and planning need to be 100% clear beforehand. Encouraged by the legal department and the procurement department, the executive project owner signs a contract with the IT service provider when all specifications of the IT system to be realized are 100% known. Senior executives often prefer a so-called ‘fixed price contract’. This seems to provide most clarity.

The most important lesson to be learned from failed IT projects, is that it is simply impossible to pin down the scope, time and budget of a complex project beforehand, and to specify the system fully before its realization. Most firmly managed fixed price contracts go awry. This is because fixing the scope, budget and planning does not just influence the price and other conditions of the project, but also the collaboration with the external IT company that assists in the implementation of the system. That is a little known fact among executive project owners. Fixing a project budget does not resolve the uncertainty, it just transfers it onto the IT provider. This leads to all sorts of nasty consequences that get in the way of a successful partnership. The IT provider works behind a façade of false certainties. The quality of the collaboration is lower because the information flow from the IT provider to the executive project owner is incomplete. The study shows that projects that have been fully fixed as regards time and money, disappoint more often than those where those factors have not been fixed beforehand.

In both examples the approach seems convenient and structured. In the first, the goal is loosely defined and will be specified in the course of the project, and in the second everything is specified up to the smallest details. Under the supervision of professionals, such as procurement agencies and management consultants, the project is kicked off. In both cases, however, more than half of the projects fail either partially or completely. The financial damage for organizations can run up to millions of Euros.

Dutch IT companies make failing all too easy Organization-wide IT projects require controls that rise above separate disciplines, so an overarching strategy that includes ‘business’, staff departments, and (external) IT specialists. That is why IT project executive ownership should by default be done by general management. Knowledge of IT is not a requirement, but good executive project ownership is! The biggest cause of failure is the ‘delegating boss’ who cannot see the need for these controls, but the Dutch IT service providers also contribute to the failure of a project. IT service providers were asked: which percentage of your own IT projects exceeds both time and budget or is broken off?

• Provider A    92%
• Provider B     12,5%
• Provider C     33%
• Provider D     30%
• Provider E     0%
• Provider F     10%
• Provider G     20%

Source: interviews with IT service providers: Accenture, Capgemini, CRMWaypoint, Deloitte, IBM, Innoveer and Ordina.

No less than 92% of the projects of one large ‘renowned’ Dutch IT service provider fail fully or to a degree. With other consulting companies it is not as much, or none of their projects fail at all; that is also something to consider. The study shows that there is a clear connection between the use of IT management tools by IT companies and their internal percentage of failure. IT management tools can be used to focus (on company/business goals) and keeping an IT project focused. They can be used for writing a business case (and using it during the project); controlling the project according to business acceptance criteria, using a project phase test based on the company strategy, etc. The fewer of these instruments an IT service provider uses and consequently insufficiently monitors the functioning of an executive project owner, the bigger the chances are that the project will fail. This simple fact provides a basic indicator. If the process running up to an IT project went well, the executive business manager has been called upon frequently. If the process did not go well, and the executive business manager was hardly included in the project in his temporary role as executive project owner, it is very likely that the project will fail.