Criteria Based Decision Making

by John Astrello on August 6, 2009

Criteria based decision making, can go a long way to making your job as a Project Manager, Operations Manager, General Manager or Executive a lot easier. Whether you are trying to make decisions about Issues, Risks, Schedule Changes, Scope, etc; making sure that you use ‘Criteria Based’ decision making, rather than ‘emotional or arbitrary’ decisions will help you out.

That doesn’t necessarily mean that you have to have a go no-go decision making process whereby you simply fill in the blanks, and the answer pops out for you. What it does mean is that the information that is being gathered and analyzed so that you can make a decision, needs to be based upon good criteria. How many times have you seen Overall Status, Issue Management or Risk Management levels simply described by the old standby of ‘Green/Yellow/Red’? What does that mean???? Generally, one will find that what that means is a very tangled web of answers, depending upon the situation.

When someone wants a particular issue or risk raised to the highest levels, the easiest way to do that is to mark it Red – Bright Red if possible! This is especially true, if the person that is raising the Issue or Risk, is not the person that is responsible for it. I’m waiting for the Network Connectivity to be established, so that I can do my System Imaging and continue on with the build of the systems. The PM responsible for delivering the Network Connectivity has the project labeled as Green, and on track in the current status report. However, on the Infrastructure Build Out status report, the overall Status is Yellow, and a new Issue has been entered regarding the ‘obvious delay in the Network Connectivity’, causing the Infrastructure Project to be ‘Yellow’. The PM of the Infrastructure project wanted to put the pressure on the Network Team, in hopes of getting the connectivity delivered earlier – so hence the Yellow Status and new Red Issue. I’m fairly certain, that everyone that has been involved in Managing a project, has seen this behavior once or twice before.

The additional problem with this, for Management and Executives that are reviewing various Dashboard and Status Reports, is that it results in a Status being reported that is not at all accurate. Additional time and effort will now be expended by Management and the Network team, to ask the questions and flush out the answers to get everything back on track. All the while, the Infrastructure Team sits over in the corner, hoping that all of this ‘churn’, results in some improvement in the overall delivery.

However, that is not the biggest problem one will generally find in Status Reporting or other management systems. The bigger problem is that on a large program, each PM is generally using different Decision Making Criteria, to report their status. ‘We’re only 5 days behind schedule, on an 18 month project and will catch up in about 3 weeks – we’re Green’. The PM for one of the other projects, will generally use completely different criteria for their reporting. And so on. What Management or the Executive Sponsors see, is a report based upon Personal Preferences, rather than being based upon good solid criteria.

Therefore, one way to handle these types of problems is to establish some type of ‘Criteria Based System’ for all of your regularly reported on ‘status indicators’ – so that everyone is reporting based upon set guidelines. A Criteria Based System may look something like the example that follows. It is a status indicator/value that could be established for determining whether or not a ‘Schedule’ is on track, in trouble, or rolling down the side of the gully heading toward oblivion.

  1. Represents little or no impact to the overall project schedule. Can be handled within current slack and existing resources.
  2. Potential impact of a minor schedule slippage of 2-3 days. Likely to be handled by re-prioritization of existing tasks or re-assignment of some resources.
  3. Will impact the overall completion of the project by one or more weeks. Additional temporary resources, or scope change, could bring the schedule back into control.
  4. Significant impact to the overall project schedule. Overall project delivery will be delayed greater than 2 weeks. Additional permanent project resources required to control schedule slippage.
  5. Significant impact to the overall project schedule. Overall project delivery will be delayed greater than one month. Executive intervention required. Recovery unlikely without scope change (reduction). Additional resources will likely not correct situation.

A value of either 1 or 2, would result in a Green Status.

A value of 3, would result in a Yellow Status.

A value of 4 or 5, would result in a Red Status.

Given this type of criteria – which certainly can be changed to match the ‘Risk Tolerance’ of Management, Executive Sponsorship or the Company, can be established and used on an ongoing basis. It can also be combined with other factors, to determine an overall ‘score or rating’ of the project – thereby giving management a tool that reports overall program status based upon readily identifiable criteria, rather than selective, arbitrary or emotional choices that are seen far too often.

{ 1 comment… read it below or add one }

Hubert Talavera August 17, 2009 at 2:27 pm

Another status update that could benefit from this approach is the percentage of completion. My observation from participating in project teams is that the percentage of completion is often preceeded by “how far along are you. How far along would you say you are in…”

This is the result of listing tasks, but not doing a through enough job in the WBS definining the sub components of each task and their lead times.

Leave a Comment

Previous post:

Next post: