Pattern: Lost Champion/Buyer’s Remorse

This is a new pattern, one not explicitly called out in my original white paper (though hinted at in a few places).

Summary: A client starts a large IT project that involves one or more outside firms (consultants, vendors, developers, manufacturers). Within the client organization, a champion arises (or is appointed) for this project. The project moves ahead with the typical bumps and setbacks, but the champion keeps it moving forward. Then the champion disappears from that role: s/he leaves the client, gets transferred, gets reassigned, gets fired, or even (as in one case we worked on) dies. With the champion gone, the client starts rethinking the project. Whoever inherits the project (within client management) may have other priorities, goals, and/or projects and has no particular investment in this one. The client decides to scale back or cancel the project rather than push it to completion.

Causes: Extensive literature exists on the champion’s critical role in project success (e.g., this). The simple fact of the departure/demotion of the original project champion can have a significant impact on the project’s success. However, what I have seen time and again is more than the mere absence of the original project champion. The underlying dynamic is that the individual who inherits the project typically has little invested — professionally, politically, or personally — in seeing the project to completion and often has conflicting priorities, often (though not always) budget-related (hence the “buyer’s remorse”).

In such cases, the new “project owner” starts looking around for a way to bring the project to an end. This often takes the form of blaming the developer — legitimately or otherwise — for alleged or real problems with the project. The customer may suddenly withhold all further payments, in spite of contractual agreements; may suddenly expand the scope and/or contract the schedule of the project; or may simply halt the project altogether. From the developer’s point of view, this sudden shift is completely unexpected and may even be in direct contradiction to what the customer was saying just weeks or even days beforehand.

In fairness, the customer may well take these steps for a truly troubled IT project, and with good reason, up to and including removing the existing project champion. But that’s not the situation I’m talking about. Here are a few real-world examples:

CASE #1: One national office of a global firm had agreed on a multi-year, fixed-price plan to phase in modified off-the-shelf software and phase out their existing home-grown systems. The vendor had first taken the customer through two short-term pilot projects to ensure feasibility and to more accurately judge the scope of the main project. The CEO of the national office was the project champion. A project review (several months into the main project) by the firm’s global CIO and CTO resulted in approval for the approach and progress to date. Yet a few weeks later, the same CIO came back, claiming the project was unacceptable, that feature delivery would have to be accelerated, and that no further funds would be paid until the project was completed. The vendor was stunned, and the firm’s national CEO was doing his best to mediate things — until he died, unexpectedly, due to undiagnosed health problems. The dispute ended up in mediation, with the vendor claiming various contractual payments that were still due (the vendor won).

What we found out (via discovery) was that during those few weeks between the global CIO’s glowing review and the sudden change of demands on the customer’s part is that the firm had appointed a new regional director over the part of the world where this project was going on, and that regional directory had held a meeting with the global CIO to review all IT projects in that region. After that meeting, the global CIO suddenly had a completely different viewpoint about the project.

CASE #2: A professional services firm retained a mid-sized consulting organization to come in and replace its existing, home-grown, UNIX-based mission-critical customer management and accounting system with commercial off-the-shelf accounting software and a custom-developed customer management system. The consultants went through a very detailed requirements gathering process and produced a detailed (200+ pages) specification along with a fixed price bid. The customer did not want to pay that much, and so features were removed until the fixed price bid was acceptable to the customer. The consulting firm started work and successfully delivered the first three (out of four) milestone deliveries.

However, by this time the original project champion had left the customer’s firm, and the firm’s CEO had taken over project oversight. When the consultants delivered the fourth (and final) milestone delivery, the customer did not formally accept or reject it within 7 days (as was called for in the contract); instead, the customer came back and started asking for features to be added back in that had previously been removed to get the fixed price bid down. The consultants accommodated up to a point, but when it became clear after several weeks that the customer was trying to go back to the original full specification without paying any additional money, they ceased work on the project (which the contract explicitly allowed them to do in the event of the customer’s failure to formally accept or reject the delivery). The dispute ended up in mediation (the consultants won).

CASE #3: A major utility firm hired a major utility-oriented development group to come in and replace their existing, mostly home-grown systems with a mixture of custom and off-the-shelf software and hardware. This was a multi-year, multi-million-dollar project. The developing firm went through a rigorous methodology to not only specify the deliverable in the project but to specify and have both parties agree upon the conditions under which the deliverables would be accepted. The project moved ahead for many months, with all deliverables being formally accepted by the customer.

However, nearly two years into the project, the utility firm was acquired by a multi-state utility holding company that already owned several other utility firms. The holding company brought in its own private consultants to review the project. Discovery later indicated that these consultants were specifically tasked to find reasons to halt the project, since the systems under development were customized to the utility firm, and the holding company wanted to use standardized systems across all its holdings. The utility firm halted delivery of the software literally days before the first major production software delivery by the development group, then put the entire project into limbo without making the contractual payments required either by a suspension or a cancellation of the project. The dispute ended up in mediation, but eventually settled.

Recommendations: Champions matter, and they especially matter when they disappear or otherwise lose influence. I saw this pattern often enough in IT systems failure lawsuits that I contacted my former boss, Tony Gibson (of OSG Incorporated) and told him that this was a major risk factor that he should monitor for all of OSG’s projects with its customers. Any vendor/developer/consulting firm should carefully track the political dynamics within its customer organizations; you may not be able to prevent an abrupt course change by your customer, but you may be able to prepare for and soften the blow.

About the Author: bfwebster

Webster is Principal and Founder at at Bruce F. Webster & Associates, as well as an Adjunct Professor for the BYU Computer Science Department. He works with organizations to help them with troubled or failed information technology (IT) projects. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan. He can be reached at 303.502.4141 or at bwebster@bfwa.com.