In November 2012, the US Air Force finally decided to cancel its Expeditionary Combat Support System (ECSS) modernization project after spending US $1 billion on it. ECSS was intended to replace more than 240 outdated Air Force logistics computer systems, some over 40 years old, with a single, integrated system. The Air Force deemed the effort critical to the successful modernization of its antiquated and operationally costly logistics infrastructure. However, in April 2012 the Air Force’s comptroller told the US Senate Armed Services Committee, “We’re now approaching seven years since funds were first expended on this system…. I’m personally appalled at the limited capabilities that project has produced relative to that amount of investment.” The Air Force’s ECSS project leadership offered various excuses for the project’s failure, but the reasons all boiled down to the claim that they did not have adequate insight into the project’s implementation.
The Air Force’s claim of ignorance is curious given that there was a government mandate to provide detailed project status information to the US Department of Defense’s CIO, who in turn was required to review it and then post said information on a government-wide, publicly available IT dashboard along with her personal assessment of the ECSS project’s risk status on a quarterly basis. A quick look at the dashboard shows that the project was rated as only a moderate risk at its demise and had been “closely monitored” by the CIO for the past two years.
A better example of an ineffective IT dashboard for making project decisions would be hard to find.
The ECCS debacle leads to the interesting question of why a reasonably planned IT project using a dashboard would fail. (A “reasonably planned IT project” is defined as one that is technically feasible and has adequate resources of time, money, and people.)
Setting aside project suicides as a possible explanation, there really seem to be only three possibilities. The first is that project management doesn’t want to hear bad news; therefore, bad news doesn’t show up on the dashboard, or if it does, it is ignored.
The second is that project managers don’t understand what the information on the dashboard is telling them. This is always a possibility, especially if the dashboard provides too much information or presents it in a way that is confusing. Still, that’s unlikely for anyone with a minimal amount of professional project management training and a bit of project management experience.
The third is that the IT project dashboard doesn’t provide meaningful information to the manager responsible for the project. (Note that when I say “project manager,” I am including anyone on the project who has decision authority.) I further discuss what I mean by “meaningful information” in the Cutter IT Journal article “A Case for Decision-Focused Dashboards“, but we should remember that a project manager’s sine qua non is to monitor project status and, when required, to make decisions regarding changes or deviations to the project plan. If a project plan were perfect, you wouldn’t need a project manager.
But what is a project plan? A plan is merely a proposed sequence of activities to be carried out over a period of time to achieve some set of feasible objectives, given specific constraints and assumptions (which we call the project’s context). When the project’s activities or context deviate from what is expected — say, the activities were harder to complete than expected, the context changed, or what have you — then it is management’s job to intervene and try to adjust the project plan to achieve the original (or recalibrated) objectives given the changed set of circumstances. (Deviations may also be caused by opportunities to gain increased benefits from the project in less time and/or with less cost.)