What is the Minimum Information You Need to Describe Your IT Projects?

By Dennis D. McDonald

In Documentation Redux - a Shorthand Proposal Framework, and the PMO Surprise fellow blogger James P. MacLennan proposes a basic “table of contents” for the most basic information about projects that an IT department should have:

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.

MacLennan’s list grew out of a discussion concerning the difficulties of getting IT staff to thoroughly document projects and systems. I like the list and agree that, if an IT manager doesn’t have this information at his or her fingertips for each and every project that’s either being considered or is underway, serious problems may arise.

 
In my opinion, while all these listed elements are important, some are “more equal than others.” In particular, number 7 — “Project/Process Ownership” — is absolutely critical. At minimum, each project should have a “business owner” and a “technical owner” — even IT internal projects where both the business and IT owner are IT staff members.

I’ve also found it useful in some instances to adopt a “RACI” approach to defining the people associated with a project — who has ultimate Responsibility, who has Authority to make decisions, who must be Consulted about major actions or decisions, and who must be Informed about major actions or decisions. Basic stuff, but it helps keep things moving smoothly to have roles defined.

MacLennan also notes in his blog post that collecting, maintaining, and sharing the above types of project information can lead to a “stealth PMO.” Here are the comments I supplied about this point:

I like the list. Having such information available to and known to all would be a good thing and would contribute to rational decisionmaking about projects and priorities.

Whether or no a ”stealth PMO” would emerge is another question. While supporting goalsetting and prioritization is an important function for a PMO, a core service of the PMO should also be providing the tools and data to support rational resource allocation. Part of this is enabling management to know who is doing what for how long.

I mention this since I believe that project blogs maintained by project staff can be an important communication tool for an enterprise, especially when staff from different departments (both business and IT) are involved in the project.

One question is how project blogs can or should be integrated with the enterprise’s project management and time & resource tracking tools. The blog is an ideal medium for keeping information and communication about project goals and objectives front and center. At the same time, the project manager needs to know how actual resources are being allocated against those goals and objectives.

In the interest of simplicity, the integration between project blogs and resource reporting might at first be on the “loose” side and based on common language, links, and tagging as opposed to the exchange and manipulation of resource data describing hours or dollars. For example, it should probably be easy to get from the time reporting system to the blog, and vice versa. The extent to which the two should be integrated (if at all) is possibly a requirement that should be allowed to “emerge” as work progresses.

If I had to choose “the lesser of two weevils,” I would probably say that it’s more important to have project roles defined and communicated than it is to tightly integrate resource management and project communications; what do you think? Let me know by adding a comment below.