Many projects fail (are shelved, go over budget, over schedule, suffer serious scope creep, suffer serious scope “minimalisation”, etc.) because of inappropriate decision making.

Inappropriate covers a whole multitude of common mistakes, such as:

• Inaccurate
• Untimely
• Overruled
• Conflicting

Inaccurate decisions
It’s fair for a project manager to expect some support from the project’s stakeholders and any person or group who may have information to offer. We might refer to these persons or groups as centres of competence, i.e. folks who know a thing or two about how part of the project should work. For example, if the project required a list of activities that we could charge expenses to, we might expect to go to the payroll (or possibly human resources or finance) function and request it from them.

An inaccurate decision is one that the original centre of competence believes to be 100% accurate in their eyes, but is actually somewhat out-of-sync with what occurs in reality. Unless the project manager has domain-specific experience, it is unlikely that he or she will be able to spot an inaccurate decision (even with rigorous testing, inaccurate decisions will slip through the net).

Inaccurate decisions usually surface during an examination of workflow. The most common workflows through a project or system will be clearly defined, workflows that are specific to a small number of individuals or have special-case processing and calculation behind them, are typical candidates. Fortunately, if inaccurate decisions are caught early, their impact can be prevented from reaching project completion where the cost to rectify the inaccuracy is significant.

Luckily, if the project team is domain-aware and inquisitive, such inaccuracies may be surfaced through the use of a bottom-up analysis of the workflow and the decision. This involves the project team taking a pro-active role that plays the part of a “what if” analyser. Each step of the workflow is examined and the decisions that have been made are applied. Often this step will involve the use of mock-ups or worked examples that highlight the inaccurate decisions. The mock-ups and worked examples serve a second purpose: they can be used to invoke discussion that leads to the correct decision being reached. If this activity requires that a user of the said workflow is brought in to assist, so be it: they may have more questions that cause the decision to be invalid rather than just inaccurate. It’s better to let an decision become invalidated rather than assume that “it’ll come out in the wash” – this never happens, things always get worse rather than better.

Untimely decisions
These are less common. Such decisions are made too early in the project and are often geared up to get ticks in boxes or to endear decision makers to the project team and others outside of the project team (“Look at me, I’m co-operating on “high-profile” project”). In reality, early decisions are often revisited downstream as the circumstances surrounding the original decision and the question that prompted the decision to be made, change considerably.

Decisions that are made too late, i.e. after the fact, are just as bad. Not just because they are late, but because invariably a project assistant, a secretary or even a project manager have been repeatedly trying to get the decision made…and this will involve wasting a lot of time visiting the decision maker, e-mailing the decision maker and possibly even going to the decision maker’s upstream line manager (which does the project morale no good whatsoever). By virtue that time is being consumed chasing the late decision(s), the project schedule takes a hit as it is wasted resource (they’re not concentrating on moving the project forward).

Overruled decisions
Sometimes the simpler decisions are no-brainers and are often made by the project team on the premise that the decision maker will simply agree with their choice. The kinds of decisions we’re looking at here are the blindingly obvious ones. For example, a decision regarding XYZ has to be made. There are three possible choices for the decision maker to evaluate, however in reality only one will ever be acceptable: the obvious answer.

Despite their simplicity and their obvious answers, the decision maker steps in and overrules the obvious answer with one of their own. Sadly, this egotistic approach is often to the detriment of the project. A useful salt test for this scenario is for the project team to select the obvious answer and condemn one of the other obviously incorrect answers. The decision maker often homes in the condemnation and puts the incorrect answer forward as their decision. The time required by the project team to backtrack and undo an overruled decision can be considerable, invariably the project schedule takes a hit.

Conflicting decisions
In my opinion, these are the worst of all. These are decisions that give project managers a false sense of progress, they are decisions that allow ticks to be put boxes, near term work plans to be updated and the next set of tasks to be considered.

It’s only later that the real truth is discovered when another person or group provide their decision, only for the project manager and the two (or more) parties to realise that a conflict exists. Typically the conflict arises as a result of an uninvited person or group volunteering the decision or information surrounding the decision. At least with the conflict out in the open something can be done with it: we should therefore be grateful that an unsolicited conversation has resulted in the surfacing of a project impediment.

However, there are times when a conflicting decision arises because there are too many domain experts or too many stakeholders wishing to exert their influence on the project and its outcome. This is more commonly described using the phrase: Too many cooks spoil the broth… Such a scenario sees much indecision, much argument and much oneupmanship – none of which are good for the project or the sanity of the project team.

In summary…
Decisions really need to be timely and accurate and they need to be made by a person or persons who are qualified to make the decision. The decision maker also has to have the support from the project team, the stakeholders and those outside of the team such that the decision does not conflict and is not overruled. Decisions that affect more than just the person making the decision, such as employees, should be examined with a view to understanding how the decision will be received (consultation breeds acceptance). Decision making processes that demonstrate the first sign of oneupmanship should be terminated immediately and the offending parties advised of their faux pas.

If necessary, create a decision log, but be sure to include at least the following:

• decision scenarios (an explanation of the decision’s origin, why it needs a solution)
• decision originator (name)
• the decision maker (name)
• the date the decision was raised
• the date a decision was made
• the signature of the decision maker

And if you do create such a log, make it visible to the stakeholders, the project team and other interested parties. You would be surprised how quickly decisions are made when they are in the public domain and visible to more than just the original decision maker…more so if you’re able to colour-code decisions that are aging decisions.

In this series:
PM#11 – Management By Shouting Loudest (MSBL)
PM#10 – The truth is best…admit it…
PM#9 – Avoid duplication of effort
PM#8 – Multi-tasking is evil
PM#7 – High workload means lower productivity…
PM#6 – You were right and I was wrong
PM#5 – Whose schedule is it anyway?
PM#4 – Start it…finish it
PM#3 – Use e-mail properly
PM#2 – Focus on the project
PM#1 – decision making