A Systems Approach to Iraq

Most of the time we look at Iraq from a political point of view but there are other ways that our occupation can be viewed.  One such way  is to look at Iraq from a systems point of view.  What is a systems approach?  It is step by step approach for reaching a defined goal.  The steps are interrelated with the output for one step providing the input for the next step.  Most systems approach models have the following components -  Analysis, Design, Development, Implementation, Evaluation.  Under a systems approach there is constant assessment of the effectiveness in reaching the goal and a mechanism for making adjustments (feedback).

So here is my critique of Iraq from a systems point of view.

You Can't Screw Up Analysis -

Since the output for each step provides the input for the next step, poor analysis will probably lead to poor planning which will probably lead to poor performance.  I'm sure most readers are familiar with the ways that the Bush administration got their analysis wrong - the existence of WMDs, the underestimation of the number of troops needed for the occupation, dismantling the Iraqi army.

"Just the Facts, Ma'am" -

In my opinion, an even more egregious problem for the Bush administration was the tendency to filter out any analysis that did not support what they wanted to do, even though much of it was solid, in favor of analysis that supported their arguments for invasion, even though much of it was suspect.  An example of this was what happened just prior to Powell's presentation to the UN.  Much of Powell's claim about Saddam having WMDs was based on an informant named Curveball.  It turned out that there was considerable concerns about Curveball's reliability (justifiable as it turned out).  These concerns were pushed aside.  Powell ended up using this "evidence" against the advice of his intelligence advisors.  As a CIA official said "Let's keep in mind the fact that this war's going to happen regardless of what Curve Ball said or didn't say.  The Powers That Be probably aren't terribly interested in whether Curve Ball knows what he's talking about."  The Downing Street Memo called this fixing the intelligence and facts around the policy.  One of my concerns about General Petraeus was the report that he tried to tone down some of the conclusions of the recent intelligence assessment on Iraq.        

The Need for Accurate Measures -

Feedback is dependent on having accurate measures.  Unfortunately as Fred Kaplan at Slate has shown the benchmarks that the Bush administration has used to demonstrate the success of their policy in Iraq are highly suspect.  Measures should not be subjective.  According to the Washington Post an officer in Iraq commenting about what defines a sectarian killing said "Everybody has their own way of doing it.  If you and I . . . pulled from the same database, and I pulled one day and you pulled the next, we would have totally different numbers."  That by definition is poor measurement.  Without good feedback you'll never know if you are achieving your goal and if you are not, what needs to be modified.

The Need for a Clearly Defined Goal -

What is our goal in Iraq?  Regime change?  Democracy?  Defeat the insurgency?  Reduce the level of violence?  The problem with Bush is that he keeps changing the goal and when he does provide a goal it is often fuzzy, that is it is difficult to know what you need to do to achieve it.  If you don't know where you are going, then it is almost impossible to make plans on how to get there.  It is what the Powell Doctrine referred to as a clear exit strategy.      

Whether you favor getting out of Iraq or staying in Iraq I believe that you need to look at the problem systematically.  Unfortunately we have an administration which has not demonstrated this ability.

< How To Dig A Hole In Iraq | Will LIFE imitate art or tell it like it is? >
  • The Online Magazine with Liberal coverage of crime-related political and injustice news

  • Contribute To TalkLeft

  • Display: Sort:
    A great way of looking at it, John. (none / 0) (#1)
    by Edger on Tue Sep 25, 2007 at 08:32:36 PM EST
    I've spent quite a bit of my past developing human resources business process software, and the methodology is identical:

    Software Development Workflow Process:

    Stage 1: Requirements Capture
    Stage 2: Requirements Analysis
    Stage 3: Solution Design
    Stage 4: Solution Development
    Stage 5: Integration and Testing
    Stage 6: Solution Implementation
    Stage 7: Support and Maintenance

    [Stage 1] describes both the initial meeting to outline the project, and any in depth discussion regarding the details of the final product.
    Sometimes, however, there are new requests for functionality or critical new information that was missed during the initial planning stages, which are deemed mission critical and that would seriously alter the functional design of the final product. When a major turn of direction is identified, it is necessary to re-convene a meeting with all stakeholders to determine whether the existing direction must be halted and the project brought back to Stage One again, or whether this new development can be implemented in Version Two.