How the CEO Should Move the Monkey
for Major IT Projects

by Walter Adamson

Achieving complex goals in unpredictable environments is risky. Yet all too often the people closest to the task are not asked to explore and contribute to the total solution. Major IT projects fail, and millions are wasted, because CEOs and senior managers allow themselves to be managed and to carry the monkey for the delivery of these major, and sometimes transformational, projects.

There is a better approach, whereby not only is the project risk reduced, and the business benefits tested en-route, but where the monkey is moved to the back of those most able to explore the risk and recommend the solutions.

Project managers typically measure the success of a project by its meeting their project metrics, yet often successful projects do not deliver business success. A new type of cross-functional team needs to be established to explore the white space risks, to identify real organisational integration issues, and to deliver fast-track business benefits. By moving responsibility to these new teams, the monkey will be shifted, the risks will be contained, and the business results will be better.

Why does the CEO have the monkey on his or her back for failed projects?

In Kenneth Blanchard and William Oncken's book One Minute Manager Meets the Monkey the authors tell managers not to take on problems if the problems don't belong to them. They tell them how to give back these monkeys, thus increasing production and reducing stress. Typically the monkey for major project implementations - projects that have enormous white space risk and integration risk - lands on the back of senior managers, and even the CEO.

The Standish Group's studies of the past few years document a 70% failure rate for IT projects. Some 30% fail outright, and another 40% drag on for years, propped up by huge cash infusions until they are finally shut down.

In a recent survey conducted by KPMG more than half of the major companies questioned admitted that they have experienced failed IT projects in the past year. The research, involving 134 listed firms in the UK, Europe, the US, Australia and Africa, found that the average cost of failed projects was US$10m. One firm admitted that a single project failure in 2002 had cost it US$200m.

This research raises two vital questions for CEOs and senior managers:

  1. Why are they holding the monkey for such projects - which have such an appallingly poor likelihood of success?

  2. Why do these projects have such an appalling record?

They do not have to hold the monkey, and in fact if they let it go the chances of project success will improve!

You can get this monkey off your back AND significantly increase the chance of delivering success from major projects by understanding some simple techniques. These techniques are not magic; they are just not commonly practiced. Why should they be? The project teams are happy to manage the boss and leave the monkey right there - on your shoulders.

It is time to put the monkey back where it belongs. Remarkably, this will not only bring you relief but it will also grow your team and produce superior results, especially for major transformational projects such as large-scale IT projects.

Why projects fail - according to project managers

It is certainly not fundamental technical problems that cause most IT project failures. The wave of failed enterprise resource planning and customer relationship management (CRM) projects in the past few years have not come about because of problems with the technology. Almost all have resulted from a failure to mesh the project effectively into the business, and to implement the business process changes required to reap the benefits.

What does that last statement mean? According to traditional analysis it means this, taken from a highly respected UK online IT management journal: "The reasons why we keep ignoring these lessons cuts to the heart of what is probably the biggest single issue facing business IT today: the disconnect between the IT function and the rest of the business in most organisations."

The gap in alignment between IT and business strategy is certainly an issue, but solving it will not necessarily reduce major project failures. (For a framework and method to solve the Business-IT Alignment gap see my website and the menu item "Business-IT Alignment").

If we ask the experts themselves, the project managers, we get a another view. According to a UK survey of project managers the major reasons for IT project failures were:

  • Missed deadlines (75%)
  • Overrun budgets (55%)
  • Poor communications (40%)
  • Inability to meet project requirements (37%)

And perhaps even more interestingly the main success criteria were given as:

  • Meeting milestones (51%)
  • Maintaining the required quality levels (32%)
  • Meeting the budget (31%)

The surveyed project managers were very experienced managers, having taken the lead in integrating large systems in Times Top 100 companies across the finance, utilities, manufacturing, business services, and telecommunications sectors.

Therefore, things are transpiring as we suspected - project directors measure the cause of failure and success of major projects from an implementation perspective, from a delivery milestone perspective and from a sense of pride as a project manager. These are all internal perspectives. We could even position these indicators as lagging indicators, although they are commonly perceived as leading indicators. Even at best, if you find it hard to consider these traditional measures as lagging indicators, they are definitely only hygiene factors.

But all of these factors combined can only measure whether a project has been delivered successfully - and even then they are barely capable. However, no combination of these factors will measure if a project has delivered success - that is delivered business success. Therefore, most remarkably, the traditional analysis does not yield any insights.

Improving project management skills in doing better what the surveyed project managers are already doing will not necessarily yield better business results. More training for project managers will not get the monkey off the CEO's back for failed major projects.

Major projects fail because we don't know everything until we get to the end

I don't want to let this one slip by you, so let me say it again. Major projects fail because we don't know everything until we get to the end.

So we need to do things to help find out what we don't know before we get to the end.

It can be done, and, most remarkably, by getting it done it also moves the monkey off the back of the CEO and senior managers. Because traditional project management techniques focus on fine details and activities they tend to narrow people's attention onto progress and recommendations and partial solutions on the track to the final result.

In paying attention to the details, two global project-killers often go unseen and therefore unheeded (1) the integration of the final components, and (2) the identification of important elements of the white space between project streams.

The integration issue is important because even if all the right things have been anticipated, their integration often has not. It is very hard for management to predict all the activities and events that will need to be brought together in the final implementation.

The white space refers to those things that are critical to a project's success yet are not identified as issues additional to the actions and tasks that are being managed in detail.

The result? Project teams, including large IT teams, perform well and deliver a project successfully. Unfortunately, although the project is delivered successfully, it does not deliver success to the organisation. The unresolved issue in large-scale project delivery is how to move from successful delivery to delivering success, and the unspoken issue is how to move the monkey off the senior management's back.

Moving from successful delivery to delivering success

In analysing successful delivery, as against delivering success, what is most often found is that management and their project teams have jumped to a larger transformational solution than is prudent. They have often done this because of impatience and a lack of respect for a process of taking transformation through pilot benefit delivery projects.

In many instances I have witnessed management reject these pilot projects as being simply more planning, or accuse them of being time-wasting or brand them as half-baked. In these organisational cultures once an end goal is seen the managers then leap in and dismiss everything other than taking the most direct path to the fully-blown goal as being indecisive and wimpish.

The solution is to go back to ABCD and to have patience in learning how to deliver transformational projects by backing bite-sized mini-projects which deliver rapid benefits. The ABCD of project implementation is as follows:

  • A is the current state of the project environment - from where the organisation is starting;

  • B is the intent, the goal, the organisational vision of the end-result of executing and implementing this project - this is, the vision of delivering success;

  • C is the set of constraints that may restrain or guide or shape the way in which the project is delivered. Here in C we should also identify the white space risk; and

  • D is the development of rapid benefit prototypes - mini-sized rapid implementation modules which test the project assumptions and deliver real business benefits.

The D-type Monkey Moving Business Benefits projects (M2B2) are a series of mini-projects that deliver a vision of B, what the overall project is intended to deliver as business benefits. They are not traditional inter-disciplinary mini-projects where different streams collaborate to investigate and resolve project implementation issues. These M2B2 projects deliver the real outcomes that build confidence in the ability of the total project to deliver success.

Why are senior managers carrying the white space and integration risk? Because they rush past the careful consideration of the D-type mini-projects and head straight for the B goal. In the rush to prove how macho they are, at the end of the day, these managers incur massive losses to their companies and shareholders. The absolute legion of failed big-bang IT projects, with the billions of dollars washed down the drain, speaks to those inclinations.

Moving the monkey to the people with the knowledge

Consider how large projects are often run - specialised teams are formed to tackle major streams of work to deliver the project, and these teams run in parallel towards the final cut-over date. Figure 1, below, illustrates this typically parallel team approach.

Figure 1: Typical project streams building towards a final integration

The recommended M2B2 approach tasks additional cross-functional teams with implementing mini-versions of the final outcomes. They may do this by focussing on a small subset of customers, a subset of the organisation, a subset of the functionality, but importantly they aim to produce a business result. See Figure 2, below.

In producing a business result these teams will discover the missing white space items, and learn of the integration risks and challenges first hand. These M2B2 projects, as part of the D step of management, test the criteria and constraints that have been identified in the C step of the ABCD process. In testing the constraints and criteria, they also extend the boundaries of those criteria and in parallel reduce the risk by increasing the understanding.

Because each M2B2 project gets progressively larger in scope, as the confidence grows, they continually scale-up the white space issues and integration issues as the project progresses. And incidentally, these M2B2 projects also scale-up the delivered benefits.

Figure 2: Delivering incremental business benefits from vertical projects

The benefits are very simply stated: by using these M2B2 teams important issues are identified at the earliest possible time in the project lifecycle.

We all know that issues identified early are easier to correct than issues which are hit later in the cycle. The issues which we want to surface are those often hidden challenges associated with integration of the work streams and things which have just been lost in the white space.

Typically, a M2B2 team will comprise members from each major workstream and from the beneficiaries themselves e.g. in a business the business users would be part of the team, and perhaps even carefully selected customers.

Rather than being horizontal and project-task oriented, the M2B2 teams are vertical and success-outcome oriented.

They should be timetabled for short-term results in comparison to the total project schedule. Typically the project goals should be achievable in no more than 90 day timeframes, along the lines of the Cisco model for rapid delivery projects.

Part of the skill in getting the best incremental benefits, and in reducing the risk, is to know how to select scope and scope the M2B2 projects. As a guide, an experienced management team needs to look across the areas of the horizontal effort, and think about the nature of the organisational change, and then pick the areas of white space where they see red flags. That selection process description is not very scientific, but it also lies at the heart of using the full knowledge of the organisation to bring to bear on white space and integration issues for major projects.

You need to think about where the greatest cross-integration risk lies, and focus a vertical M2B2 project down through that vertical. The real challenge for CEOs and senior managers is to let go. To let go of the desire to control and own the risk, and to let go of the monkey they subconsciously pride themselves on wearing on their backs. Letting go of the white space risk, and integration risk, is an art not a science. Giving people space to manage the white space and reduce integration risk in complex projects is a management discipline.

The difference between monkey-moving projects and typical cross-functional teamwork

Major projects, structured as in Figure 1 with horizontal streams, often also do include cross functional teams in their project plans. Although cross-functional teams and reviews are used, these groups are not typically tasked with producing mini-results. More likely, they are meeting to resolve inter-stream issues associated with the mechanics of project delivery. This will certainly ensure that the project gets delivered successfully, but the evidence shows that these teams are not able to improve the chances of delivering business success.

Figure 3: Typical project cross-stream teams

In the best case they will be trying to theoretically conceive of the white space risk - typically expressed as trying to watch out for things that might fall through the cracks (between the major teams). But unfortunately the goaling and scoping for these types of projects does not provide a platform to bring together the dual unknowns of white space risk and end-point business integration issues.

The essential goaling for a M2B2 project is to produce real business benefits. The primary goal is not to solve project implementation issues - that is a means but not a goal. And this difference in goaling is the essential difference in the M2B2 approach as compared to the typical cross-functional project implementation tasks.

This is illustrated in Figure 3, above, where typical cross-stream project teams are represented by the vertical ovals. This graphically shows the difference in philosophy between traditional cross-functional teams and M2B2 teams. The typical cross-stream teams are not formed as a result of the ABCD business planning process, nor as a result of scanning across the white space for the transformational organisational integration challenges.


By implementing Monkey Moving Business Benefit fast-track projects CEOs and senior managers move the responsibility for identifying white space and integration issues to those closest to the action.

Because of the progressive nature of these M2B2 projects the internal fit of the organisation - the way it is aligned behind the business strategy and project goals - will be bought into a step-wise alignment with the transformational project outcomes.

The M2B2 approach is really part of an organisational change program requiring selecting, sequencing and timing interventions to achieve results. It has the added benefit of moving to those who are best able to act, the responsibility to identify the white space risks and the integration challenges in delivering real business benefits from the project.

By being selected and given responsibility to run a M2B2 project a manager is clearly being given responsibility to confirm or challenge the real world benefits of the major project. These managers are being charged with the challenge of closing the white spaces.

In terms of selecting M2B2 projects, the selectors must be skilled at scanning the environment, understanding the implications of change across the organisation and choosing appropriate scope and objectives having regard to the organisations wider strategy.

By moving the monkey, and at the same time getting faster to real business benefits, major projects are sure to succeed more often because you will know a lot more about what you don't know before you get to the end of the whole project.

Walter Adamson is the Founder of Digital Investor, based in Melbourne, Australia, where he helps IT service companies design more effective value models and strategic partnerships. He also helps CIOs develop the commercial maturity of their company's IT management strategy - in particular the challenges of business-IT alignment, developing value propositions, and designing effective sourcing strategies for IT services. Interested readers should contact Walter to arrange further discussion or an interview. If you are responsible for IT in your organisation you might like to read my CIO Business Innovation Series of free White Papers at my website Walter can be reached at and phone +61-403-345-632.

Many more articles in The CIO Refresher in The CEO Refresher Archives


Copyright 2003 by Walter Adamson. All rights reserved.

Current Issue - Archives - CEO Links - News - Conferences - Recommended Reading