Making Decisions in Projects

Author: Neville Turbit

Overview

Any Project Manager, who has completed even a few projects, will understand the difficulty in getting people to make decisions. Making decisions in a project is potentially one of the most difficult challenges you face. It is often the reason projects run over budget and behind schedule. Decisions are made too late to enable the project to meet its deadlines. This white paper will assist you mange decision making in projects, and give you some tips to help you get decisions made.

Problems with People Making Decisions

We need to start with the reasons people don’t want to make decisions. There are many reasons however most can be categorised. The following list is not definitive but it will give you some of the most common reasons people are reluctant to commit.

No Clarity

Sometimes the problem is that people cannot see the pros and cons clearly. It is all a blur. The reasons ‘for’ and ‘against’ are so mixed up that they cannot make a decision because they cannot identify the reasons for following a particular path.

Fear of Making a Decision

People can be afraid of making a decision. They feel they do no have the authority or they do not want to take the responsibility. If it goes wrong, it might reflect on me.

Not Decision Oriented

There are people, and we all know them, who do not want to make decisions. They are happier to be led rather than lead. If anyone has read the book “The Dice Man” they will recognize the personality. The book was about a person who decided making decisions was too difficult. He started to lead his life by created options and then throwing a dice to decide which path to follow. Even simple decisions such as whether to get up in the morning were determined by a roll of the dice. As the story progressed he became a cult leader as other like minded people joined him.

Politically Motivated

There are Managers who will not move until they sniff the corporate breeze. They will only make a decision if they are sure it will be corporately acceptable. Any decision is driven by making them appear more successful in the organisation. The bottom line is that they will not make a decision that will harm their career.

Another Agenda

Some people may have another agenda that you are not aware of. An example. I went through a rigorous software selection process with a client in a branch office of an organisation. In the end we had a 60:40 decision in favour of Package A. At that point the CEO stepped in and decided on Package B. The reason was he had been instructed from his head office that they were about to select Package B for the head office. It would help if we went down the same path but didn’t tell the vendor until after the head office had negotiated a favourable contract.

Too Many Options

Another reason may be that there are just too many options. Too many reasons to follow each path. Not only is it left or right, there are 180 options between. The confusion in deciding between option 27 degrees left or 28 degrees left is just too overwhelming.

Where are the Decisions

Decision points in a project are usually predictable. A Project Manage should start a project by plotting the points where decisions will need to be made. Typically these are:

Should the project proceed to the next stage
What is the scope of the project
Should variations be accepted
Agreement to produce deliverables
Agreement to accept the deliverables
Allocation of resources
Agreement to the requirements
Agreement to move forward to implementation

Each project will have a separate set of decisions but many of those decisions are foreseeable and fit in the categories above.

Set the Scene

Escalation Path

The first thing you can do is to set the scene for decisions. Suppose you foresee a decision that will be required regarding scope changes. Most projects will have to make that decision at some point. The thing is to create the process for making the decision before the decision has to be made.

For example suppose you gain agreement that below $X the decision can be made by the unit manager. Above $X it has to be referred to the steering committee. Get everyone to agree, then when the situation arises, there is a road to drive down.

It is true that for every decision there are two questions.

The first is how to make the decision
The second is the decision we make.

If you can answer the first question before the decision needs to be made, you only have one question to answer.

The approach should be that during the project setup stage, you establish decision making authorities and escalation processes.

Decision Process

If the decision is to be made by a particular person, the same process applies. Ask the person what information they need in order to make the decision. How long will it take to make the decision? Who else needs to be involved, or sign off on the decision? What other actions are required before the decision can be made and ratified?

Here is an example. I was planning an implementation for a major system change. As part of that planning I developed a checklist of goals to be achieved at different times during the implementation in order for us to go live. We talked these through with all the Senior Executive team and eventually gained their agreement. The goals related to things like:

8:00 am Saturday. Data conversion complete with less then 2% rejected records
11:00 am Saturday. Application loaded onto the server.

These deadlines were different to what we had in our plan. Our plan had the data conversion completed by midnight Friday. The deadlines were based on the fact that if we didn’t reach these targets, we were unlikely to complete the whole conversion by Monday morning when the system was due to go live.

At 3 am on Monday morning we failed to meet a deadline. There was no arguing about whether we could delay going live for an hour or two. The decision had been taken weeks before that we must go live at 8:00 am Monday or revert to the old system. We simply reverted to the old system.

Some considered it a failure. I took a different stance. An unforeseeable event had occurred (in fact a power outage on the grid due to a lightening strike) and we had smoothly moved to Plan B. There was no disruption to business and we went live the following weekend.

Trying to get sensible decisions from people who had only had snatches of sleep for the last 48 hours would be near impossible. Getting executives out of bed to get their input would have caused a further delay. Although a lot of work had been done which would not have a successful implementation that weekend, the ultimate outcome was no disruption to business. It also made the following weekend conversion much more effective as we had an 80% dress rehearsal. When it came to making a decision, we had the road to travel down already planned.

Provide Options

A CEO I dealt with many years ago taught me something I never forgot.

“Always bring me options.”

Much of the decision making process is about trolling through the information and developing alternate paths. If you can do that pre-work before you talk to the decision maker, you are well on the way to getting a decision.

It may be that you go in with two options, and come out with a third as the decision. This is fine. Sometimes a different perspective will result in a different solution. The key thing is to brainstorm as many options as you can. Identify those which are less attractive and the reason they are less attractive, and come down to a shortlist of two, or three, or four that can be taken to the decision maker.

Normally I would not cover the rejected ones as they tend to muddy the water. If they are raised, my response is:

“We did consider that option but rejected it for the following reasons.”

I have also had a recalcitrant decision maker ask for more options. At this point I would bring out the rejected options and explain why each was rejected. At the end of that explanation I would ask the decision maker if they believed any of the rejected options should be considered, or if they had any other options.

Turn the discussion into one where only a handful of options are on the table. If there are five or ten options on the table, it distorts the picture and impedes decision making. From personal experience, I try to limit the options to a maximum of three.

Identify the Decision Maker

I am quite comfortable to ask a person what their role in the decision making process will be. They should fit one of three categories:

They will make the decision
Their support is required by the decision maker
They are interested but have no influence on the decision

In my experience, lots of time is wasted on Group 3. If you want a quick decision, focus on Group 2 – those who need to support the decision – then go to the decision maker. It may be nice to keep Group 3 informed, but that is done when you have the time to deliver a briefing.

Make sure with Group 2 that you conclude with two things:

“Is there any other information you need to support/make this decision?”

“So when will you be talking with the decision maker to support this option?”

If you can get support from all Group 2, it is sometimes easier to hold a meeting with Group 2 and Group 1 to ratify the decision.

Dealing with Indecisive People

This can be a very frustrating experience. Some people just don’t like to make decisions in their life. The key to this situation is to lay out the process in advance. Here is an example.

Suppose you have to get a decision made about who will be allocated to work for 3 months on a project. The manager has a number of people who are suitable, but cannot decide which to allocate. Don’t press for a particular person. Ask the manager what they need to take into account to make a decision.

Have a few prompts:

Who will cover for the person while they are away?
How well do they know the subject matter of the project?
What will be the impact on customers who deal directly with the person?
Will the person be able to participate fully in the project?
Are there any people who could be transferred from another area, and have some experience in this department?
Etc.

Once you get the manager to list the questions that will influence the decision, seek out the answers. Rate the people against each question. Look for ‘knock out’ factors. If for example, one of the candidates has some reason for not wanting to go on the project – perhaps they have children and the travel demands will not allow them to pick the kids up after school – it may eliminate one from the list. Work the person through a process to reach a conclusion. If they start to waver, go back to the list and ask what has changed?

Dealing with Politicians

Those political animals in the organisation are some of the most difficult to manage through a decision. The first point is not to hide the fact that their decision is politically inspired. It is like ignoring the elephant in the room. If they are going to make a politically motivated decision, talk to them about it.

“John, I know in making a decision, you want to ensure it is not ‘career limiting’. In fact the right decision can be a positive for your standing in the organisation. How can we ensure that we not only do the right thing, but be seen to do the right thing?

For example, can we meet with your boss to understand where he is coming from on this subject? Can we meet with him for his input regarding the options being considered prior to the decision being made? Who should we bring into the loop when we are considering options? Who are the key people we want to support this decision?”

Speaking on the same level the decision maker is thinking on, will make the process much more comfortable for both of you. A politically motivated decision is not necessarily the wrong decision. In fact given a 51:49 decision, I would always go with the one that is most politically acceptable. The one that is not as acceptable can be easily shot down by those who do not support it.

The Implications of Delays

Be sure that people understand the implications of delaying the decision. It can bring pressure to bear on people if they understand that their reluctance to make a decision is translated into time and cost to the project. Make sure it is not just mentioned in passing but included in status reports and reflected in the schedule.

If for example, an issue has a date for completion of the end of the week, and because someone will not make a decision, that date is not reached, identify the issue as overdue in a weekly status report. Don’t just change the action date. Raise it to the attention of the steering committee. Let people know the implications on the schedule. The Project Manager is employed to bring the project in on time and budget. It is their responsibility to the organisation to identify what is impeding them getting the job done.

Presenting the Options

Unless it is a very simple decision, never just present the options verbally. On a piece of paper list the options and the “For” and “Against” in a clear layout. It doesn’t matter whether they are called “For” and “Against” or “Pros” and “Cons” or even “Positives” and “Negatives”. Just make sure they are clearly identified. Leave some room under each “For” and “Against” to write down new reasons that may come to light during the meeting.

Reaching a Decision

As the discussion moves towards a decision there are a couple of questions to ensure are answered:

“Is there any other information you need to make a decision?”

“We agree you will let us know your decision by ….” Assuming the decision is not made at the meeting.

“So we agree that the decision is….”

Make sure the decision is confirmed in writing – preferably minutes of the meeting, and circulated to all involved.

Conclusion

Decision making is not often easy. The key is to create the path to travel down in advance. Make sure you know how the decision will be made before you try to make the decision. Look at the people and work out what will motivate them in the decision making process. As a Project Manager, it is up to you to manage the making of the decision. Don’t abdicate that responsibility by allowing someone to get away with procrastination.