Decision requests or just do it?

 

On traditional projects, a project change management plan is supposed to provide guidance to project teams on the criteria that make a change significant enough to manage through formal change control.  On agile projects, change is an inherent component of the project as opposed to an exception condition, and hence such formality is rarely required.

The same degree of certainty cannot be stated about decisions - both agile and traditional projects spawn a variety of decisions, but how does a PM go about deciding what level of formality is required to manage those?

If the project team is aware of the triggers and thresholds that may require formalizing the decision-making process, then there should be alignment in approach.  One place to start is to understand the criticality of key requirements for the project - for example, if long term viability of a project deliverable is not necessary, decisions that impact sustainability may not require the same level of formality as those that affect a more critical attribute.

Having a brainstorming session early in the project's lifetime to identify those types of situations that may necessitate formality can help to build some "muscle memory" into the process.  Some risk identification techniques could be utilized for this purpose - for example, reviewing the project's WBS to attempt to identify the significant decisions that could emerge related to each key deliverable.

Of course, no approach is perfect, and it should be tuned based on the feedback from key stakeholders - if the stakeholders are pushing back regularly on the necessity of a formal decision request for a given situation, perhaps the thresholds are set too low.  On the other hand, a few too many "damage control" issues might teach a PM that a greater degree of formality is called for.

It's also important to ensure the decision making process is scalable.  Focus on who needs to be involved in the decision-making process as opposed to the specific mechanics.  A triage approach may work:

1. Decisions that are of so low impact that verbal decision making is sufficient, and informal communication to those who need to be apprised of the decision can suffice.
2. Decisions that are of moderate impact may need the formality of a verifiable audit trail - this could be an e-mail chain, or an e-mail confirmation of the decision to the key stakeholders followed by archival of the final outcome in the project control book.
3. Decisions that are of significant impact should require the use of a decision request document that is formally approved, logged and archived.

Having a peer-level support system, a mentor or a PMO could help a PM decide on a situational basis what makes sense.

The two process extremes are equally scary - a complete lack of formality increases the likelihood that critical decisions are made without involving all the right stakeholders and with insufficient analysis and communication whereas too much formality mires the project in unnecessary bureaucracy and reinforces negative perceptions about project management.

One more example of why judgment is one of the key differentiators of a great PM!

(Note: I originally decided to publish this article on kbondale.wordpress.com in March 2012)