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

• Organizational Impact: How will the different business areas and processes be affected, and are the key stakeholders engaged?
• Sponsorship: List the key stakeholders names - get some involvement.
• Technology Alignment: How does this project match up to your IT group's current and planned architecture?
• Metrics and Measurements: Sometimes, the only metrics are milestones...

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 magic size is a single piece of paper!
• You are forced to be succinct, focus only on the important stuff
• You can use both sides of the paper - but only one piece!!
• No decision maker is so busy that they can't read a single piece of paper.
• The sections should lead the reader where you need them to be; don't be subtle and creative, make it plain and simple ...
• Project Objective: They've already read the charter, this is just succinct enough to remind the reader what we're talking about
• Hard Cost / Benefit: Measurable savings and costs
• Soft Cost / Benefit: Note that most projects are justified by the hard cost / benefit, but many projects are approved because of the soft benefits (like "productivity")
• Strategic Benefits: If you're working towards some business, organizational, or technology master plan, call out how the project supports this. These can often be the softest of soft benefits, but decision makers like to see the balance of long and short thinking.
• Resource Requirements: Who and for how long; be specific, name names. This is often why folks slow-walk decisions - the resources are often already busy with other things ...
• Timeline: Not too detailed, maybe just the start / end dates of your major project chunks (like Design, Development, Test, GoLive)
• Concerns: this is key - you must call out specifically why there is the need for the reader to actually make a decision (because the rest of the organization is stuck on hold, waiting for the call ...)
• Options: this is also key - if you specify the options, you should be able to eliminate the dreaded "come back with more information" non-decision.
• I'll say it again - that whole thing needs to fit on two sides of one sheet of paper.

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.