It's not my fault! Exploring the role of the client in program performance

Dr Mark Johnson


We live in a world of increasingly complex programs. They are vital to the success of organizations from governments to corporations, yet many fail to deliver. Much of the analysis of failed outsourced programs has focused on the delivery side of the relationship despite the increasing evidence that much of the blame for failure is with the client. This leads to the plaintive cry of program and project managers that the failure really isn't their fault.

The purpose of this paper is to begin a conversation at this conference on the role (both positive and negative) that a client can play in delivery. As a provocation for this conversation, we identify 10 client behaviors—and provide illustrative cases—that are prevalent in failed and failing programs. These cases are by no means exhaustive, and we welcome further input to the debate we hope to start.

It is notable that these generally represent a low-level conception of programs and their management, and that to move away from these approaches would require a move from project-based to program-based thinking. We speculate, based on examples of where it has happened, that this change in conception and the accompanying behaviors will enable client organizations to understand how to become a better client, what we have termed an “intelligent client.”

Keywords: intelligent client, client behaviors, major programs, conception level

There Has to Be A Better Way…

“The common element in failed government IT projects is government”

—CEO, global IT outsourcing company.

In an article in The Times in 2009, Richard Ford said that “A Ministry of Justice IT project that is three years overdue and double its original cost has been condemned as a masterclass of sloppy government management” (p. 24). If we change the names of the people involved, the industry (construction rather than IT, for instance), sector, or nation, would we see a different result? There is plenty of evidence that the management of complex outsourced programs is problematic. The U.S. Government Accountability Office recently said the following: “In 2008, the cumulative cost growth in the Department of Defense's portfolio of 96 major defense acquisition programs was US$296 billion, and the average delay in delivering promised capabilities to the warfighter was 22 months” (Sullivan, 2009)

Such endeavors are complex due to their scale, the number of interrelated stakeholders, and the dynamic nature of the environment. They are also usually outsourced—adding an additional layer of complexity to their management. In responding to this complexity, they are now considered programs rather than large projects. It is the role of program management to gain benefits from managing all the multiple projects that make up a program that would not be obtained by them being managed individually (Office of Government Commerce [OGC], 2008). In the IT sector for instance, it has long been recognized that rather than simply putting in a new computer system, a provider is participating in IT-enabled business change (Benjamin & Levinson, 1993). That change takes place through a program involving business process redesign, hardware and software integration, training, and support, as well as helping the end users to deal with the changes to their working lives. The computer on the desk is not the requirement—the addition of an effective capability is. However, we will demonstrate that despite this recognition of the role of the program, many of the approaches being used today in procuring programs of work are reminiscent of project-based approaches.

Press reports on failed programs (prior to this latest case), the management literature, and published guidance have focused on the delivery side of the client-provider dyad, assuming this is the cause of failure. The report on the Ministry of Justice (MoJ) IT program is notable for its criticism, not of the providers, but of the government department that ran it—the client. Specific criticisms include poor governance, under-resourcing, lack of basic controls, the lack of wider business change to support the system, and the management of the suppliers (National Audit Office [NAO], 2009).

The purpose of this paper is to begin a debate about the role of clients in successful delivery. Our starting proposition is that they are central to providing the context within which delivery takes place. Therefore, their actions and interactions are critical to successful delivery. As a starting point for this debate, we identify 10 common—although not exhaustive—behaviors from clients that are evident in failed major outsourced programs. These provide a concise statement of current approaches that are ineffective. We show that these are common approaches, which have been derived from project outsourcing. Focusing on the client, behaviors are identified that together form what we term the intelligent client behaviors (NAO, 2006). Evidence from a number of sectors suggests that these will be more effective in achieving successful outsourced program delivery than those witnessed in the case of the MoJ. We begin by listing 10 behaviors prevalent in failed major programs.

Behavior 1: Like Partnering, but With Teeth

Various studies in the 1990s (e.g., Dyer, Cho, & Chu, 1998) showed that the largest Japanese automotive assemblers such as Toyota and Nissan worked closely with their suppliers unlike their Western competitors. Western automakers such as Ford, GM, and Chrysler relied upon relationships that were predominantly adversarial while the Japanese used these relationships as a central pillar of their competitive strength. The term partnership is now extensively used to describe the relationship between buyers and suppliers in a range of industries, not just the automotive sector, where the concept was originally developed and studied. However, when transferring the strategies of the original Japanese automotive companies into other cultures and contexts, some of the vital prerequisites get lost. Current partnering approaches within major programs retain the primacy of the contract and recourse to legal action when outcomes are not forthcoming. For instance, the much-lauded Copenhagen Metro opened in 2002, but seven years after completion, it was still mired in legal claims and counterclaims between the contractors and client.

One approach to working with contractors was recently presented by a department of the U.K. government. They described it as “like partnering, but with teeth.” It was clear that there is little sense of a mutually beneficial and interdependent relationship between client and provider despite there being ongoing calls for more relational contracts by academics from the 1960s onwards (Macneil, 1980) and their considerable successes (e.g., Gil, 2009). A major construction contractor on receiving notification of a partnership contract recently told one of the authors “I know they're going to use this to shaft us, I just haven't worked out how yet.” He did work it out eventually but that did not prevent that company sustaining heavy losses on the work. There is little evidence, even in a suppliers' market (as existed for some time in construction in many areas of Europe), of clients seeking to become the client of choice. Maintaining an incentive for suppliers to compete for work is essential to a healthy supply base.

Other characteristics of the original automotive benchmarks include long term rather than transactional arrangements (allowing the provider to carry out long-term planning gives them a stake in the future rather than just short-term success), cross ownership (Keiretsu,) and a detailed knowledge and involvement in the supply chain. For example, Toyota and Nissan regularly station engineers within the lower tiers of their supply chain to facilitate problem solving (Liker & Choi, 2004). Also, when Toyota developed the Prius, their engineers assisted in the design and manufacture of the batteries by Canon. Toyota never wanted to make the batteries; they wanted Canon to gain the best of their manufacturing know-how so that they would get the best products at the best price (Liker, 2004).

The context of outsourced program delivery is clearly different from the design and supply of automotive components or systems. Programs are predominantly service rather than product delivery and usually involve changing the organization receiving them. In addition, thinking of programs as non-repetitive processes may contribute to the use of a transactional rather than a partnership approach. Lastly, in Europe, Japanese-style partnership relationships do not conform to EU government procurement regulations. Thus, U.K. government procurement arrangements, including PPP/PFI, discourage buyer-supplier partnerships as this could be construed as unethical. They are still contractually based and have had variable rates of success (Kwak, YingYi, & Ibbs, 2009).

One conclusion to be drawn from this section is that partnering, while originally identified as providing benefits to all parties in the automotive sector, has not transferred well out of this context. The approach has been limited by established practice (contract, perception of legislation, prevalent behaviors) to the point where the term is now widely discredited. Yet it is clear that “real partnering” (as opposed to like partnering but with teeth) has many potential benefits and is a requirement of many of the changes in behaviors described in the following sections.

Behavior 2: Stay Local

Stay local represents a group of behaviors where the outsourcing organization focuses solely on the immediate issues—stakeholders, risks, opportunities, and making change are all dealt with in the manner that suits their immediate requirements. There are many affects of stay local on the performance of outsourced program delivery. Outsourcing brings with it the notion that the delivery becomes somebody else's problem (SEP) (Adams 1979). Furthermore, based on current practices, it is apparently believed that risk can be outsourced with the responsibility for delivery, pushing the risks into the supply chain.

Indeed, low-level aggregation of risk has been demonstrated to be ineffective (Goldratt, 1997). As a result, the strategic allocation of contingency in response to risks must be carried out at the program level rather than locally. However, this only covers the downside of uncertainty; some work will be completed more quickly than planned and this benefit should be passed onto the program. Other opportunities arise in complex programs and actively managing these opportunities across the program rather than locally are vital.

The benchmark for good practice in this respect has been BAA (the former British Airports Authority—owners of London Heathrow) during the construction of Terminal 5 (T5) at Heathrow (Davies, Gann, & Douglas, 2009). The phrase, “BAA owns all of the risk, all of the time” (BAA, 1998), was used to describe their approach. Taking risk away from the supply chain and using pooled benefits to encourage the exploitation of opportunities was a departure from conventional practice and shifted the focus from damage limitation, to a search for the best way to get the required benefits delivered. The result was a £4 billion program delivered on time and budget.

Another aspect of staying local involves making unreasonable demands and changes in demands on providers. In manufacturing, it has long been recognized that peaks and troughs in supply profiles are costly and wasteful, hence the considerable efforts to maintain stable demand (Forrester, 1958; Lee, Padmanabhan, & Whang, 1997). In program delivery, it appears that this principle is ignored at will with changes and their implication for the capacity of the supply chain ignored. Such instability is costly and the cost is ultimately borne by the client. BAA's approach in the T5 program was to realize that the procurement schedule would create a significant market for major items (from concrete to electrical components) and that buying these centrally would prevent contractors from having to compete with each other for potentially scarce resources at various points in the build schedule.

Stay local represents a limited and insular worldview that is inappropriate for complex outsourced programs. The current best practice examples are notable for the breadth of their consideration beyond traditional boundaries into the networks that contribute to or are impacted by the program.

Behavior 3: Don't Invest Up-Front

One of the differences between programs and projects is the degree of clarity of the outcome required. For projects, it would be expected that the outcome is well known, and the route to it well understood. Project delivery processes (the U.K.'s PRINCE2 (OGC, 2009) for instance) are intended for such a task. Where the focus is on a wider set of benefits (addition of organizational capability, for instance) and there is a larger solution space, a more adaptive approach is required. Indeed, the exploration and definition of project possibilities is actively excluded from both PRINCE2 and APM's Body of Knowledge (Association for Project Management [APM], 2008).

Evidence of failure due to such project-based thinking, comes from a number of sources. For instance, lack of up-front investment was one of the causes of failure in the procurement of the Nimrod MRA4 by the UK's Ministry of Defence (NAO, 2003). Scoping out the project and exploring the realities of developing such a capability received an investment of 0.1% of the budget. The result was that work began to develop the aircraft, following contract signing, but with unrealistic requirements of the technology. For instance, while it was thought to be a revision of an old aircraft design, the requirements resulted in an almost entirely new design, with huge implications for cost and time.

Up-front investment of time, money, and effort can narrow scope and reduce the level of unknowns in a program. Late changes can have extensive knock-on effects and these (as noted previously) need to be reduced. Up-front investment provides an incentive for such consideration and issues, including future proofing, to be included. Even though it does not change the reality that the solution has yet to emerge, it allows development of the ideas and requirements,—in short, it just reflects the reality.

Up-front investment on its own though is not going to remedy major program failure. Where success has been achieved, it has been through establishing real partnering (as originally intended rather than as currently practiced) and breaking stay-local thinking.

Behavior 4: Make it REALLY Difficult

One group of factors that make programs complex to manage is the number of stakeholders, their interactions, and level of engagement with the task. This is another area where the differences between programs and projects become apparent. While it is possible to map the benefits of a project (Ward & Daniels, 2006), aligning the benefits of a program for a wide group of interacting and dynamic stakeholders is another challenge altogether. Leaving such a job to an outsourced provider rather than dealing with the issues at a policy level has consistently been demonstrated to be highly challenging. The United Kingdom's attempt to provide an integrated IT system for the national health service and others are testimony to this. There are hundreds of stakeholders from government departments, to area health authorities to primary care trusts, all with differing legacy systems, requirements, and incentives/disincentives for participating in the deployment of an integrated scheme.

This issue appears different from many of the others raised so far. It is not clear, other than through policy, how to get alignment of benefits across wide stakeholder groups. An active incentive needs to be found for stakeholders to engage in a manner necessary to ensure that they contribute to both the solution and its delivery. Policy is one means to this end, but it needs to be coherently deployed.

Finally, the current approaches to large-scale procurement assume that there will be a suitable number of appropriately qualified suppliers ready and willing to bid for the work being offered. Recent experience in the construction sector in Europe has demonstrated reluctance on the part of many firms to engage in the expense of bid preparation. For instance, for the construction of the 2012 Olympics main venue, there were only two bidding companies.

Outsourcing does not relinquish an organization's responsibility for creating the context in which successful delivery can take place. The more complex the requirement to be delivered, the greater the risk; particularly where there is considerable organizational complexity. That risk increases the likely costs for all concerned, but it can be reduced by actively managing the complexity of the task in the first place. The wider view on this aspect recognizes the central role of the outsourcing organization in determining what level of complexity is outsourced.

Behavior 5: Over Optimism

Delivery failures present various logically possible causes. First, there is the logic that the targets set were simply unrealistic to start with—failure was assured from the beginning. Second, the delivery capability may have been deficient. While there may be some merit in the second, the volume and frequency of failure in delivery (e.g., Standish Group, 2009) suggests that the first is also worth investigation. One influential study showed that the means to get a program/project approved was (Flyvjberg, Bruzelius, & Rothengatter, 2005):

project approval = underestimated costs + overestimated revenues + undervalued environmental impacts + overvalued economic development effects

This demonstrated the affect of high-level optimism in the approvals process. The reality is that this optimism results in a misplaced sense of safety (see Stay Local). Moreover, the over optimism does not stop at the approvals process; as will be shown in Behavior 7, it is pervasive. The Channel Tunnel was both late and over budget. During an advanced project management course run by one of the authors following this debacle, two of the planners from that program discussed how it was generally known that the tunnel would cost double the original budget of £5 billion and take much longer than what was being publicized. It was also generally known that the true estimates were not considered to be “politically acceptable on either side of the English Channel.” In the language of organizational learning, “the undiscussable was undiscussable” (Argyris, 1993). Not only could the fact that the estimates were ridiculously optimistic not be discussed, the organization was not keen to even recognize that they were not being discussed. The true costs and durations were known, but rather than deal with this from the start, it was politically expedient for this to emerge once the work was well advanced. This approach is still having an impact today—due to the additional levels of debt that were built up during construction, it took 21 years from the opening of the tunnel for its owners to declare a profit to their long-suffering shareholders.

Determining the true levels of cost and time always presents a challenge to organizations. Systematic behavioral bias towards being over optimistic exists at the organizational, team, and individual level. Moreover, recent research has demonstrated that this bias often continues well into the execution phase, with similar behaviors seen in reporting. It is not unusual for progress to be reported as acceptable for some considerable period, and then for the performance to be seen to “drop off a cliff” as the original completion date approaches.

The future for managing complex programs lies first with recognizing that the traditional project-based approach to estimating is inappropriate. Over optimism before and during the work happens and while such behavior is prevalent, conventional estimates are likely to be unreliable. This compounds the effect of lack of partnering, for instance, where the rush to sign the contract adds to the lack of up-front investment and the failure to consider wider issues in the supply chain.

Behavior 6: Just Follow the Process

From the 1980s on, industry saw a number of related, but superficially distinct processes that promised to cure all that ailed. These included TQM, lean, agile, Six Sigma, and Lean Sigma. The popularization of “process is the answer” is a result of the application of the work of people like Dr. W. Edwards Deming in Japan. Deming's work in repetitive operations has been formative in the quality practices seen in most major manufacturing organizations, and has been, on the whole, very successful in transforming quality performance. Statements such as “90% of errors are the fault of the system, not individuals” are pervasive and have considerable resonance with most organizations. Where there are errors, fix the system and it will work OK. This logic is highly persuasive and to an extent will work, but in program-level work, we need to look beyond Deming.

Major differences between programs and manufacturing operations include the level of repetition and the reliance on technology for designing and pacing work. Both are high in manufacturing. Most of Deming's work was done where the system (e.g., the production line) determined what was done and how it was done. Highly repetitive operations in a factory environment are generally designed through work-study, and quality assured through statistical process control. Repetitive operations also exist at the task level in projects (e.g., some data handling, site-level construction activities, and testing chemical formulations). The application of a manufacturing approach is useful where work packages have durations of seconds or minutes, and the process or system for work to be carried out can be so designed.

However, reliance on one-size-fits-all processes may be misplaced for many program/project environments. The project that takes two weeks to complete and involves 10 people all within the same group or organization is clearly a different proposition to the program involving hundreds of stakeholders over a period of years. The management task will have some high-level similarities (e.g., the focus on delivery, balancing hard and soft issues, and dealing with fundamental uncertainties) but at a macro level, the level of complexity of process required to run each will be very different. In addition, the particular challenges will differ. Some programs will require processes to integrate diverse (and potentially conflicting) stakeholder requirements; others will not and will have to deal with a high degree of uncertainty. Uncertainty brings its own issues, and a potential conflict with process. For instance, where a high degree of agility is required, this will conflict with the structural rigidity that accompanies a high level of process focus in an organization.

There is a paradox here, though, that while the process-based approach appears to be inappropriate at a macro level, (where it is being promoted by a number of bodies); the process-based view has had little traction at the micro level in projects—certainly when compared to manufacturing. A change in emphasis on the utility of process-based approaches would be beneficial.

Basic processes are vital to provide an agreed way of working. Beyond this, the new focus needs to be on behaviors and how systems of work (particularly the measures—see Behavior 7) promote the behaviors that are needed. Standard operating practices are relevant for low-level work packages, but the approach for outsourced complex programs will rely less on one-best-way, and more on an ability to handle emergence and uncertainty, and to work with the complex socio-political systems that are modern programs.

Behavior 7: Believe the Indicators

In a recent study that we conducted, we encountered a senior manager who noted that, “All the indicators are green, but the client is still not happy.” The time and effort that goes into such reporting is significant, but it does not necessarily give the desired result.

Kaplan and Norton (2001) promoted an approach where they likened indicators to the pilot's instruments in an aircraft, which report the status of the aircraft to the pilot. This is the approach that many major programs have tried to use, though without consideration of the consequences. The analogy of the pilot's instruments is limited in its utility, as in an aircraft, the fact that you are measuring the airspeed, doesn't (significantly) impact the airspeed. The air doesn't try to compensate or correct itself to give you an OK reading. In a program, this certainly does happen—behaviors are affected by how performance is measured. One popular method of control in projects is earned value (Fleming & Hoppelman, 1996). Measure earned value and it encourages managers to begin packages of work and carry out the relatively easy work first, as this will boost earned value measures. In parallel, overestimation of percent complete of those tasks will give the illusion of progress and keep indicators “green.” This will be counter-productive as the started work packages can compromise workflow and obscure or deflect attention from critical work. The measure (earned value) drives a behavior that is counter-productive (starting tasks, over-estimating percent complete).

In addition, while it is not unusual for work to be outsourced, apparent control of that work is less likely to be relinquished. Contractors are not to be trusted of course. Consistent with this and deriving from policy described in the first point on partnering, we see that organizations involved in outsourcing often construct entire structures to shadow the outsourced work. This is non-value-adding and ignores the fundamental paradox of control in social systems—the more effort is put into control, the less real control one has (Streatfield, 2001). Real control comes from encouraging beneficial behaviors, not simply measuring conformance to a set of objectives. As the scenario at the start of this section indicated, while a contract may set out a particular and specific set of deliverables, these may not be what the customer really wants. While indicators and contracts are usually written in terms of product deliverables (relatively easy to measure), the real performance is assessed by the level of service that customers are receiving. As the service management literature tells us, this is not so readily measured, certainly not in objective terms.

Again, the concept that prevails appears to be that which was promoted for localized project controls—simple measures that can be assessed locally. Program level issues require that these are united and that the behaviors they engender are consistent with what is required by the program, not just small parts of it.

Behavior 8: Don't Worry About Managing Up

Changes to programs cost money. At one level, it is recognized that the organization outsourcing work is prone to change its requirements. At another level, this can be overshadowed by the impact of a single comment or statement to the press. Interestingly these same people frequently then express dismay that the impact of their action is so costly or disruptive.

The MoJ case illustrates what happens if the main client representative (the sponsor or senior responsible owner (SRO) doesn't manage up. Specifically, changes to requirements were allowed and expectations were not managed with other key stakeholders. The result was that rather than protecting the program by demonstrating to those stakeholders the impact of those changes (on cost and time particularly), the changes were simply passed on to be implemented. In addition to the disruptive effect on the program as a whole, this caused demotivation in the delivery organizations that saw completed work rendered useless by such changes.

While recognizing the emergent nature of programs, it is vital that this doesn't end up like Chicago's Millennium Park. Like many other millennium initiatives, this fell afoul of the Y2K project bug; while most of the world's software defied predictions and continued working at midnight on 31 December 1999, any project with the word “millennium” in it appears to have crashed. Millennium Park was a fast-track project, meaning that previously sequential tasks (e.g., concept, design, engineer, approval, ground works, and construction) were carried out concurrently. In this case (among other issues), because of changes required at the design and approvals stages, groundwork had to be re-done, causing considerable delay and great expense. The logic of task precedence still holds regardless of time or political pressures.

Failure to manage up can have interesting effects. In a recent study with a major infrastructure provider, we found that the single greatest cause of delay and disruption to work was, indeed, the client. The suppliers have known this for a long time, but it took considerable data to convince the client that their own people were at the root of so much delay.

Responses to this challenge have included the use of last responsible moments (e.g., Smith, 2007) for information or changes. These are highlighted points in the program where it is necessary for the client to have made a final decision. After this, it is made clear that there will be an impact on cost, schedule, or both. This sounds rudimentary, yet is rarely seen in action. Other responses include involving senior stakeholders in development work at an early stage as lead users, prototyping, and active rehearsal.

Traditional approaches to managing projects require information to be passed to key stakeholders. It is clear that for successful programs, broader and more active stakeholder management is required, including this requirement to manage up.

Behavior 9: Not Killing Off the Right (Wrong) Programs

Some organizations are excellent at killing off programs. For instance, in new product development, many firms will kill off 95% of ideas early in their life. This is treated as healthy, encouraging a good flow of ideas, and giving the opportunity for innovation without overloading an organization with change. The concept of running programs through stages (activities) and gates (decision points on whether or not to continue) is well established in many industries (Cooper, 1990). However, while gateways are well established in government projects, the gate appears to be always open. During a recent conversation with a major U.K. government department, the question was raised, “Do you use gates?” The answer was a clear, “Yes.” Then, when asked about whether any major programs had actually been stopped at a gate, the answer was an equally resounding “No.”

In other environments, when ideas do not pass a gate, they can be recycled, combined with others, reworked, or just parked. Consistent with up-front investment and managing up, the opportunity to bring ideas forward is enhanced by the opportunity to kill off programs. Yet around many clients, the objective just seems to be to keep the pipeline of work full, regardless of the consequences for the rest of the portfolio of work.

Killing off programs that are failing or are no longer required is likely to be politically unpopular and is frequently hampered by a commitment to sunk costs. However, limiting some programs may have unforeseen consequences, and it is in this area that the requirements are even further abstracted from projects and project thinking. For instance, in 2002 in the United Kingdom, South East Trains (who run the commuter lines from south of London into the capital) received a delivery of new electric trains or sets. The new sets differed from the aged rolling stock in many ways, but in particular in the comforts offered to passengers, notably air conditioning. However, each new set needed a much higher level of power to operate, and the program to upgrade the power system had been postponed. The result was that the overall benefit (passenger comfort) couldn't be delivered until all of the enabling works (increasing power capacity on the line) had been completed. This joining up of programs is the domain of portfolio management. Project-based views of the work are inappropriate. As for previous points, joining up benefits cannot be left to the project or be done at the task level.

Behavior 10: Learning Is Less Important than Doing

Learning in the program and project environment does appear particularly problematic. The reset at the end of a major piece of work seems to trigger particular behaviors in both individuals and organizations that result in moving on to new work without taking learning from the previous work. One major U.K. government department we conducted research with recently noted that at the end of projects, the now conduct “lessons identified” reviews, rather than “lessons learned reviews,” because “…we've realized we don't learn.” Another U.K. government department we have been involved with noted that their contractors did not synthesize and codify the learning from the project after completion because they were not required or incentivized to do so. When we asked to interview a contractor to discuss the success of the project, we were told that many of the staff had since moved to other projects and “What charge code should I book that time to?” These examples show that while organizations involved in program delivery acknowledge that learning is important, they do not have the time to do it due to the requirement to move on to the next task as quickly as possible. In addition, more worryingly, the need to synthesize the learning gets lost as their view is that someone, somewhere should pay for it. The reality is that organizations are already paying for it in increased costs and “sub-optimal” working practices. Moreover, when personnel change occurs in a project, all of the tacit knowledge and unembedded learning will walk out of the door. This leads to a kind of “program quick-step” where the incoming managers need to build relationships and learn the processes, slowing down the overall delivery of the program.

We suggest that the remedy is simple. Invest in the time and space required for the people involved to capture the learning gained through the program. The corollary of not doing this is considerable cost and waste, which in most industries goes unmeasured. A first step in measuring the scale of the issue will yield the business case for the investment in learning. A road is still a road, the methods of construction will not change dramatically, but some of the working processes may evolve. Without capturing what does, and doesn't work, program performance will not improve in the long term.

The project-based view stopped work at the completion of core tasks. A program-based view has a much broader view of the impact of the work on the organizations involved, for the present and in the future.

Final Remarks

In contrast to the behaviors identified, we have noticed that some organizations are working in a different manner. They are behaving as intelligent clients. These organizations believe that the buck starts and stops with them. They hold all of the risks all of the time and seek the win-win on behalf of the network not simply themselves. To ensure that suppliers are able to achieve greater performance, intelligent clients ensure that there are high levels of transparency, reciprocity, and sharing of processes and they are adaptive to the needs of suppliers. As they expect the solution to emerge, the to-ing and fro-ing facilitated through buyer-supplier adaptation of products, services, and processes is required. In addition, as things are not expected to emerge fully formed, intelligent clients understand that there will need to be learning on the job and trials will be needed as part of the budget. Without them, the program is likely to fail to meet targets. Intelligent clients understand that metrics do drive behaviors. They then go away and understand the behaviors that are necessary for effective program delivery and install the metrics needed. BAA understood that motivating the network of suppliers to work together was critical and set up the joint reward pot that linked to delivering the project on time and within budget.

Intelligent clients also manage their own and their providers' levels of optimism bias, and manage up—making sure that while a program must have the necessary top cover, this is not driven by political whim or the Daily Mail (a U.K. daily national newspaper).

The common thread through all of these issues is that current approaches used by government and industry to outsourcing programs of work have been based on those derived from project management. We have demonstrated that they are inappropriate for complex outsourced program delivery. Indeed, the characteristics of excellent program managers (Partington, Pellegrinelli & Young, 2005) demonstrate that most of the elements of “how to make a program fail” are otherwise called low-level conceptions. In order to enable intelligent client behavior, it is worldview and mindset change that is needed. Because if the flow of damaging and expensive failure is to be staunched, it is vital that clients move beyond the low-level conceptions of project procurement, to those appropriate for excellence in the world of complex programs. We have demonstrated here some of the aspects of this excellence and that this is not a radical or particularly new idea, but one that requires us to develop an alternative approach that starts with the client—the intelligent client.

It is our intention that this will generate a discussion with colleagues at conference that will lead to an agenda for what we believe is a fundamental and relatively undeveloped avenue for project management research.


Argyris, C. (1993). Knowledge for action: A guide to overcoming barriers to organizational change. Thousand Oaks, CA: Sage Publications.

Association for Project Management. (2005), Project management body of knowledge. High Wycombe, UK: Association for Project Management.

Benjamin, R. I., & Levinson, E. (1993). A framework for managing IT-enabled change. Sloan Management Review, 34(4), 23–33.

British Airports Authority. (1998). The T5 handbook. London: BAA.

Cooper, R. (1990). Stage-gate systems: A new tool for managing new products. Business Horizons, 33(3), 44–54.

Davies, A., Gann, D., & Douglas, A. (2009). Innovation in megaprojects: Systems integration of London Heathrow Terminal 5. California Management Review, 51(2) 101–125.

Dyer, J., Cho, D. S., & Chu, W. (1998). Strategic supplier segmentation: The next “best practice” in supply chain management. California Management Review, 40(2) 57–77.

Fleming, Q. W., & Hoppelman, J. M. (2000). Earned value project management (2nd ed.). Upper Darby, PA: Project Management Institute.

Flyvbjerg, B., Bruzelius, N., & Rothengatter, W. (2003). Megaprojects and risk: An anatomy of ambition. Cambridge, UK: Cambridge University Press.

Ford, R., (2009, March 12). Spectacular IT failure costs taxpayer millions. The Times, p. 24,

Forrester, J. W. (1958). Industrial dynamics—a major breakthrough for decision makers. Harvard Business Review, 36(4), 37–66.

Gil, N. (2009). Developing cooperative project client-supplier relationships: How much to expect from relational contracts? California Management Review, 51(2), 144–169.

Goldratt, E. (1997). Critical chain. Great Barrington, MA: North River Press.

Kaplan, R. S., & Norton, D. P. (2001). The strategy focused organization: How balanced scorecard companies thrive in the new business environment. Boston: Harvard Business School Press.

Kwak, Y. H., YingYi, C., & Ibbs, C.W. (2009). Towards a comprehensive understanding of public private partnerships for infrastructure development, California Management Review, 51(2), 51–78.

Lamming, R. (1993). Beyond partnership. Hemel Hempstead, UK: Prentice Hall.

Lee, H. L., Padmanabhan, V., & Whang, S. (1997). The bullwhip effect in supply chains. Sloan Management Review, 38(3) 93–102.

Liker, J.K. (2004). The Toyota Way: Fourteen Management Secrets from the World's Greatest Manufacturer. New York: McGraw-Hill.

Liker, J. K., & Choi, T. Y. (2004). Building deep supplier relationships. Harvard Business Review, 82(12), 104–112.

Macneil, I. R. (1980). The new social contract. New Haven, CT:Yale University Press

National Audit Office. (2003). MOD major projects report. Retrieved from

National Audit Office. (2009). The national offender management information system. Retrieved from for the full report.

Office of Government Commerce. (2008). Managing successful programs. Norwich, UK: The Stationery Office.

Office of Government Commerce. (2009). Managing successful projects with PRINCE2. Norwich, UK: The Stationery Office.

Partington, D., Pellegrinelli, S., & Young, M. (2005). Attributes and levels of program management competence: an interpretive study. International Journal of Project Management, 23(2) 87–95.

Smith, P. G. (2007). Flexible product fevelopment: Building agility for changing markets. New York: Jossey-Bass.

The Standish Group. (2009). The Chaos chronicles. Boston: The Standish Group International Inc.

Streatfield, P. J. (2001). The paradox of control in organizations. New York: Routledge.

Sullivan, M. J. (2009). Defense acquisitions: Measuring the value of DOD's weapon programs requires starting with realistic baselines. Testimony before the panel on Defense Acquisition Reform, Committee on Armed Services, House of Representatives, April 1, 2009.

Ward, J., & Daniels, L. (2006). Benefits management: Delivering value from IS and IT investments. Chichester, UK: John Wiley.

Table 1. 10 Behaviors Common to Failed Major Programs

1 We are partnering, of course, with our suppliers. This means I tell them what to do and kick them when they don't deliver, meaning that any failure is their fault and not mine. Result!
2 Stay local—localized protection of my interests works. I am the customer, the affect of my decisions on the supply chain is not my concern and making unreasonable demands is just part of my role.
3 There is no need for up-front investment. Trials and testing should be funded out of the contractors' profits, not the program budget. You should know what I want anyway (even if I don't).
4 Outsource anything REALLY difficult and seek to build internal and external buffers between you and the potential for you to be blamed for anything that might go wrong. This is particularly effective when trying to work between a number of government agencies. It makes sense that they are more likely to fall in behind a (politically neutral) contractor than your own organization.
5 Over optimism never hurt anyone. Believe all the plans you see, especially if they are printed in color or have flashy presentations. Never, ever involve yourself in the detail and remember: function always follows form.
6 It's all about following the process—everything would be fine if “they” did that. Also, if the current process isn't working, just add more processes…
7 Watch the indicators closely and as long as they are OK, don't worry that you are measuring completely the wrong things or that people are responding to the measures in bizarre ways.
8 Don't worry about managing up. Being blown with the latest political wind is a fact. So what if we waste vast amounts of public money on a whim? It's all about keeping the politicians happy.
9 Programs are an expression of a personal agenda. Killing a program invalidates that agenda and is an admission of personal failure. Don't worry about the implications of delays on other programs.
10 Programs are about doing not learning. The time for reflection is after the program has finished.
This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2010 Project Management Institute



Related Content