How should a project manager capture decisions?

Question

As a project goes through the planning and design phases, many decisions will be made. To develop with technology X instead of technology Y. To leave feature z off of the plan for this version of the release in order to hit a hard deadline. Many decisions, large and small (and sometimes the decisions about what will not be done are as important as decisions about what will be done).

How can a Project manager best capture and share the decisions that were made so that they are not continually revisited throughout the project? Should the "why" and the "who made the decision" be documented as well? How should the project manager balance the communication of key decisions without overwhelming uninterested parties with minutiae? When is it okay to revisit a decision that seemed like a good idea at the time, but does not bear out in practice?

Answer 1

The vast majority of the decisions are taken in the context of meetings. For this reason, I choose to document decisions in meeting minutes.

Every project I am running has its own repository of meeting minutes shared and visible in a collaboration tool such as a wiki so it is easily accessible by all and easily searchable.

When documenting meeting minutes, I mark decisions items with [Decision] prefix. I also document the rationale behind the decision, alternatives that were discussed and the context of the decision. Since the decision is documented in the context of a meeting, the participants of the meeting and who took the decision are also documented.

This methodology allows anyone to search for [Decision] and get all the decisions taken for a project.

Answer 2

The important point in the original question is to document them somewhere that is easy to go back to. It is much less important how you record them but you should be consistent throughout the project. It is also very useful to be able to easily see all the decisions in one view regardless of when they were raised which is why I prefer to track them independently to meeting minutes.

We use SharePoint to manage all the documentation for our projects and therefore also use it to track decisions. We have created a custom content type based on an Item (but you could just as easily use a Custom List type). We captured a brief summary and a more detailed description of the decision along with the date. We then use an Approval workflow to have the decision approved by the appropriate people. That way we have a good audit trail to show who approved the decision and when.

Answer 3

I too minute meetings and use a key to track decisions; all bullet points in my minutes start with one of the following:

I: For information

A: For action, with the action owner at the end in bold [Like This]

D: For decisions

In addition, I keep an assumptions slide in my monthly project board/ steering committee pack and highlight in bold anything that has changed since last month. We review this in the board meeting to ensure that everyone is happy with the decisions.

Answer 4

According to the PMI, decisions should all be documented in the Project Charter (I believe), along with the reasoning behind the decision.

The reason is to first answer the question future people ask of "why did they do X?" and the second is to keep a paper-trail in case things go wrong -- not to blame, but to understand.

I think the easiest way to capture decisions is in a publicly viewable document; you can categorize them, starting with major decisions (like technologies or features), and putting sections for other areas for people who care (eg. finance decisions, technology decisions).

It's tough to say about revisiting decisions, so I'll say this: avoid it personally (except in cases where you're 100% sure you made the wrong decision) because allowing it means anyone, anytime can challenge the decision, and you end up having the same meetings again and again and again.

Answer 5

Read Decision Analysis and Resolution Process Area in CMMI for Development 1.3.

Answer 6

I use a simple Excel sheet for capturing issues/actions and related decisions.

Those decisions that need SteerCo approval are recorded in the monthly Project Status Report, updated with the results of the SteerCo meeting.

Answer 7

I've experimented with a few different strategies for logging decisions. Like mentioned by Stephen above, I had one tab in my status excel sheet as an issue log. This issue log is where I tracked any questions/answers that came up that might not make their way back into the requirements.

I agree with the poster above who records it in meeting notes. This is a good way to get the context. I like to do that and also note the decision where I have details for the task being done. When you have a collaborative tool like LiquidPlanner this can be easy.