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:
Description: What are we trying to accomplish here?
What is our ultimate goal?
Objectives: These are project objectives,
not business objectives. How will we know we are done?
Benefits: Why should we consider doing this? What
are we getting?
Alternatives: Are we dead in the water without it,
or are there any workarounds?
Dependencies: Does this project require another
project to be completed?
- Resource Requirements: Small, Medium, or Large;
should be enough to give us an idea of people, cash, and time
Project / Process Ownership: Who's got a stake in
this project? Who will help drive this through?
- 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
- Sponsorship: List the key stakeholders names - get
- Technology Alignment: How does this project match up
to your IT group's current and planned architecture?
- Metrics and Measurements: Sometimes, the only metrics
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
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
- The magic size is a single piece of paper!
- You are forced to be succinct, focus only on the
- You can use both sides of the paper - but only one
- 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
- 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,
- 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.