Project Management 101, Part 5: To do or not to do - Making the Right Decision

You would think the process of decision making is pretty obvious as it’s something everyone does all the time. Some people just have the all the answers.

But let’s take a look at it from a Project Management perspective.

As a Project Manager, you’re making decisions every day. Most of these are simply to direct the flow of the project; when to order materials, when to set up a meeting, etc. These are all within the confines of the scope, schedule and budget of the project defined constraints. But every once in a while, a decision needs to be made that may significantly impact the course of the project. Though you may not have the authority to actually make the decision, you still have the responsibility to manage it, and keep your project on track.

Let’s break down the decision-making process:

1.?????Define the problem/issue

Write a narrative that clearly describes what the issues are that are driving a need for a decision, and what ultimately needs to be decided on. It’s going to come up, so don’t skip the why; or how the situation got to be where it is.

2.?????Define what decisions must be made: the choices

This will be determined from doing your homework: contacting Company SME’s, vendors, consultants, etc. Get a consensus and make a list. Consider using project management tools such as decision trees.?Every choice has its pros and cons, so make sure to list these out as well. If you feel one particular course of action it better than another, then include your recommendation. ?

3.?????Determine the level of authority: who gets to make the decision

If it’s your decision to make, make it with the best information you have at the time. Rush to inform, but not to decide. Again, do your homework and gather all the necessary information. Trust your experience and homework; not your intuition. Base your decision on facts. Guessing is not an excepted strategy in project execution.?

The responsibility (RACI) matrix in your Project Execution Plan should tell you who or at what management level the authority to make certain decisions lie. If it’s technical in nature, it probably should be made by the appropriate specialty or technical services group. If it impacts critical schedule milestones, or changes the budget, you may need management to make the decision.

It’s also perfectly OK to defer a decision even when you have the authority to make it. The matter may not be within your realm of expertise, or you just may not be comfortable making the call. It may not take away the uncertainty of the decision, but if you pass it on to a stronger authority, at least you’ll know you won’t be second guessed.

4.?????Execute the decision

Whether you or someone else makes a decision, it’s still your project and your job to see that it gets done. You may not have come up with the solution, but it’s still your problem. Prepare a plan for implementing the decision, including a schedule for all the necessary tasks and when it will be completed.

That’s great that we now have a process to manage decisions, but what’s really involved in making a critical decision? What factors to you really need to consider?

Some problems are technical and have clear and straight forward solutions, or it may come down to a few options. The project budget could also be a consideration. But since almost any decision will results in some sort of change, the principles of change management must be considered. The MOC process and the decision-making process work hand-in-hand.

Of course, not all decisions are the result of something bad: you may actually decide to improve on something. This should be celebrated. Capture this in the project Lesson’s Learned to improve the next job.

But most decisions leading to change are generally the result of an oversite. The oversite usually implies some sort of human error. Any oversite or mistake is probably the result of poorly or quickly reviewed drawings, straight forward mistakes, inexperience, distractions; all the ways that we humans tend to screw things up. Assigning blame (or cause) is part of the why in the decision analysis, but not in making the decision itself.

In the aftermath of the decision-making process, an autopsy should be performed. Then the process can be improved, including mitigation strategies for the human factors: procedures, guidelines, support systems, check lists, etc.

So, here’s some homework for you: take a recent change order from your project and spend a few minutes to break down how you came about to agree to it. See if you would have made the same decision had you followed this process.

?“If you choose not to?decide. You still have made a choice. You can choose from phantom fears….. I will choose a path that's clear” Canadian Popular National Anthem