This is an old link ... let me redirect you ...

(... or click here if the page does not automatically redirect)

Driving to a Decision on your Projects

I've written about the basic project proposal (for consulting groups) or charter (for internal IT) in the past. The point of any project summary document is to tee up the what and the why, using an outline like this:

  1. Description: What are we trying to accomplish here? What is our ultimate goal?
  2. Objectives: These are project objectives, not business objectives. How will we know we are done?
  3. Benefits: Why should we consider doing this? What are we getting?
  4. Alternatives: Are we dead in the water without it, or are there any workarounds?
  5. Dependencies: Does this project require another project to be completed?
  6. Resource Requirements: Small, Medium, or Large; should be enough to give us an idea of people, cash, and time requirements.
  7. Project / Process Ownership: Who's got a stake in this project? Who will help drive this through?
  8. Risks and Constraints: Always nice to list possible risk mitigation, instead of just the doom and gloom

I've heard of some nice additions to this list, including

To be an effective document, the proposal/charter should be complete, yet not too lengthy. I get a bit self-conscious when my proposals go more than 4-5 pages - it just depends on the scope of the project.

Still, there are times when you need to drive to a decision, typically the Go/No-Go Milestones. At these times, decision makers rarely want or need to digest a long treatment of the issues. We recently put together a very succinct document to tee up this kind of decision:

The form factor, and the succinctness of the content, distill the conversation to the relevant issues, and facilitate a quick decision to help keep your project moving forward.