Iraq as a Case Study in Project Management Mistakes

Before going into politics, George W. Bush spent time as a businessman, including some CEO stints. Interesting, then, that the war in Iraq displays some of the same classic project management mistakes I see all the time in corporate America when it comes to implementing big IT projects. The difference is, in Iraq, we all get to see the mistakes played out 24/7 on CNN.

Thanks to these and other mistakes, large IT projects fail far more often than they succeed. Let's take a look:

Classic Mistake #1: Unclear Business Case

Under the spell of charismatic salespeople or industry buzz, companies sometimes buy new technology without fully understanding the business benefits. In the runup to the war, many different reasons were cited for invading Iraq, ranging from finding WMD to enforcing the U.N. Security Council resolutions (over the objections of the U.N. Security Council) to the fact that Saddam Hussein was clearly a very bad man. Out of this mishmash, however, there was never a single, clear reason for going to war, with an unambiguous ROI (Return on Investment).

Classic Mistake #2: Inadequate Consideration of Alternatives

Many technology projects move forward because an executive decides that his company is going to have a shiny new TLA (Three Letter Acronym) implementation, come hell or high water. This system is rammed through the approval process without adequate consideration as to what it is supposed to accomplish, and whether a cheaper alternative might do the job. Similarly, little consideration was given to alternatives short of going to war: for example, indefinite containment, a negotiated settlement, or a less expensive means of achieving regime change.

Classic Mistake #3: Quashing of Dissent

Related to the first two mistakes, when a marginal technology project is being pushed through, individuals who raise objections or propose alternatives are often ignored and silenced. This creates the appearance of consensus where none exists, but leads to project decisions being made without a complete picture of all the facts. In the months before the Iraq invasion, domestic and foreign critics were ridiculed (most notably the French), and there have been persistent reports that U.S. intelligence reports were cherry-picked to create the impression of imminent danger from Iraq. Contrast this to the invasion of Afghanistan, where there truly was domestic and international consensus.

Classic Mistake #4: Ignoring Half the Problem

Often, the technology implementation is the easy part of an IT project. The hard part is making the new system useful to the company, by using it to solve the needs of the company and employees, and getting buy-in from a critical mass of people. Many companies succeed at implementing the technology, but find that few employees want to use the new system because their needs were ignored at the planning stage. The invasion of Iraq was masterfully planned and executed, but planning the occupation was almost completely ignored until we actually got there. As a result, we have succeeded in toppling Saddam's regime, but direct benefits to America have yet to be realized.

Classic Mistake #5: Failure to Test the Business Case

When a salesperson presents an ROI model for a new technology implementation, most people know to be skeptical of the numbers. After all, the salesperson is paid to sell the project, and most of the assumptions are smoke-and-mirrors. Amazingly, though, few companies actually test the ROI assumptions directly. For example, before launching a $10 million IT project, you would think most companies would spend at least $100,000 on a test project or two to find out if the goals are realistic. Almost none do. Similarly, in Iraq, there was no interest in spending a few months of time continuing the existing inspections regime to find out if the WMD actually existed or not. As it turns out, they do not exist, so the project goal of finding WMD is not feasible.

Classic Mistake #6: Unrealistic Timelines and Budgets

Many projects, in an effort to show a faster ROI, and as a result of underestimating the scope of the project, are given unrealistic budgets and timelines. Often, when the timeline is proven to be unrealistic, the response is to throw more money at the project, in an attempt to complete the whole thing on schedule. The inevitable result is a project which is both late and over-budget, or simply cancelled. The proper response is to scale back the goals so that the new goals are achievable within the original timeframe In Iraq, we see the consequence of setting an unrealistic timeline for the end of the occupation. For apparently political reasons, there is a deadline of June 30th to hand over autonomy to an Iraqi government. Since almost no infrastructure currently exists for such a government, it is hard to see how this goal will be achieved in four months. To the Bush administration's credit, they have been responding properly by scaling back the goals as the original timeline is shown to be unfeasible (remember that the June 30th date was originally supposed to be for U.S. troop withdrawal; then for a democratically elected Iraqi government; today the goal is just some sort of Iraqi sovereignty).

There are others: for example, the regrettable aircraft carrier landing by Bush is an example of leadership taking premature responsibility for project success; and the continued insistence by some that WMD might be found is similar to the way executives often try to save face when a pet project fails.