Documentation Redux – a Shorthand Proposal Framework, and the PMO Surprise

McDonald sent a nice comment on my last post – he’s writing a lot about project management lately, and we even chatted about some research he’s doing around boomer flight. Since I don’t get a ton of comments, I thought I’d respond with a post, instead.

He poses the question:

I am wondering if documentation of the communications associated with coding and testing (emails, archiving of successive release of code, meeting recordings, archiving of test results, etc.) can in any way replace purpose-built documentation?

Well, not really – different tool for a different [knowledge management] task. For example – take the basic project proposal or charter. Most projects would benefit greatly from a succinct, yet complete, summary of what is important and relevant – the critical what, why, and how questions. In fact, he kinda answers his own question …

Probably not. If you are going to demand documentation — even from your “skunk works” projects — don’t you also have to state a basic model for what the documentation should include?

Absolutely. In my experience, most good project leads and domain experts really understand the needs, benefits, and relevance of their projects; they just have trouble succinctly framing the opportunity. There are many examples out there – professionally generated or home grown – that lay out what’s important to capture about a project. A super-terse “table of contents” might look like this:

1. Description: What are we trying to accomplish here? What is our ultimate goal? Should be short, to the point.
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? We’re not looking for a full-on ROI analysis, just a description.
4. Alternatives: Is this just a nice to have? Are we dead in the water without it, or are there any workarounds?
5. Dependencies: Does this project require another project on the list to be completed?
6. Resource Requirements: Could be as simple as 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? Remember, if this is not purely a technical / IT internal project, there must be business ownership – capture that fact early!
8. Risks and Constraints: Always nice to list possible risk mitigation, instead of just the doom and gloom

If you coach your project leads to capture the basics like this, and keep the answers nice and succinct, you can sneak your way into a Stealth PMO. Keep it simple – create a spreadsheet with those eight columns, and get folks to fill out one row per project. Now, I’ve got a handy list of all my projects, summarized into a format where I can do a high-level, apples-to-apples comparison.

The PMO Surprise: If you have an open, well understood Project Prioritization process based off a list like this, the Law of Unintended Consequences kicks in, with interesting results. You don’t have to “demand documentation” from your project leads; they will work on style and content, staying within the relatively strict limitations of the format, to help their projects get prioritized. A well-structured Project Prioritization process rewards well-documented efforts. (Sneaky)