Tuesday, December 01, 2009

It's War, and It's a Project

I work in Information Technology, and that means I work on projects. A project is nothing more than a description of an outcome that we want to happen - an application will be made that let's users do something, some information that we will discover from data will help solve a problem, or maybe there is a plan for improvements to an existing system. 

We make project plans. They describe what the project is going to accomplish, and how, and when. They also establish deadlines. A deadline is made for the entire project based on the deadlines for all the discrete tasks that make up the project. Every task has a deadline. It's pretty rational.

Sometimes, people launch projects with no deadline. Those projects are never completed though, because there are always other projects with deadlines, and they always take precedence over the projects with no deadlines. In Information Technology, we call the projects without deadlines Failed Projects or Dead Projects. Sure, resources get assigned to them, but work is always deferred so that work on live projects gets done.

It's simple project management.

That's the difference between Obama's plan for Afghanistan and Cheney's plan. Cheney had no plan, and no deadlines. Meeting deadlines takes courage, planning, skill, calculation, estimation, work, and will. All these things were lacking in the Bush/Cheney regime. Their plan was endless war and occupation. And endless cost.

Obama has the balls to bet his presidency on his plan for Afghanistan, and he just placed the bet with his speech tonight. Bravo.

Putting a deadline on the effort in Afghanistan demonstrates a will to actually succeed, rather than just to throw lives and money at the problem.

Now, the question is will the American people buy in - because we only lose wars that the people don't support.

1 comment:

  1. Many project plans include a large section near the beginning called Analysis. That portion of the project is usually characterized by analytical thought - or at least it should be. During that portion of the project, it's important to weed out ambiguity, and do away with erroneous assumptions and biases.

    Some people don't give enough credit to the Analysis phase. These people think that if you're not developing code, you're not making progress. The risk of bypassing the Analysis phase, however, is that time and money are wasted building the wrong thing.

    The McCain argument is that you don't tell your enemy when you're leaving. If you do, the enemy will just hunker down until you leave. That argument doesn't consider what our troops will be doing between now and when they do leave, and it incorrectly assumes that the Obama policy is to leave irregardless of the state of the conflict.

    There is also a parallel to the process that Obama just went through and a similar process that Bush went through prior to the surge in Iraq. The Bush process was detailed in a Bob Woodward book (I believe it was State of Denial: Bush at War, Part III). What was different about the Bush process is that the public was being told that the war in Iraq was on track, but the Bush administration was scrambling for a new plan in secret because the they knew that it was not going well. Pundits were not criticizing George Bush for taking too long because the pundits didn't know that the process was going on. In Obama's world, there was no deceit.

    With regard to IT and project management, there are some other displines called Agile and Scrum that conflict with some of the more traditional project management methodologies. Some people in the Scrum world may do without the traditional Gantt style project plans that we've grown accustomed to (e.g., Microsoft Project plans). I have some familiarity, but I have only used bits and pieces in my work. These mthodologies are not restricted to software development, and several success stories exist in manufacturing (e.g., Toyota). You might find those linked pages interesting.