Skip to main content

Acting Without Thinking Too Much

As Project Managers when confronted with making important decisions, we always find ourselves carefully analyzing the situation before acting. We list all the alternatives, all the consequences, identify all the pros and cons for each option, and then employ very sophisticated tools to compute all utilities before reaching the optimal decision. Decision trees, linear programming methods, payoff tables and operations research are all at our disposal in the decision making process.

Sounds soothing and elegant, but the reality is that all the above are exceptions. In fact, I probably lost those readers by now who were interested in reading about real life Project Management. Just like life itself, our projects have become more complex with more uncertainty, which does not call for more sophistication, and further complications, but rather teaches us that “less is more and usually more effective”. The fact that our information processing capacity is finite, that we are unable to think through problems in any depth, coupled with the pressure of time, leads us to use heuristics for solving problems.

Heuristics refer to experience-based techniques for problem solving that give a solution which is not guaranteed to be optimal. They are not perfect, just simple, and easy to implement. They speed up the process of finding a satisfactory solution via shortcuts. Heuristics are really powerful when users are aware of their imperfections, and can become dangerous when their limitations are forgotten.

The word heuristic was derived from Archimedes’ famous exclamation ‘Eureka!’, when he discovered, during a bath, a method for determining whether King Hiero’s golden crown was in fact made of pure gold. According to the legend, Archimedes shouted ‘Eureka!’ (I found it!), and jumped out of the bathtub after finding the solution. Legend also says, that he continued shouting ‘Eureka!’ while running naked through the streets of Syracuse to finish his examination of the crown.

Heuristics are indispensable in multiple domains. Artificial intelligence relies heavily on heuristic algorithms, because, for example, to consider every chess move and entire chains of all subsequent moves would be beyond the earth’s computational power available today. Another domain, where heuristics are critical, is virus scanning and detection. Malicious computer code is ever evolving, which requires identifying new viruses or variants by looking for slight variations of code. Heuristic algorithms do that work.

In Project Management, we are most interested in heuristics in judgment and decision making. Facing complex problems with incomplete information and the need for speed make them indispensable. However, these rules of thumb can easily lead to errors, also known as cognitive (or mental) biases. 

In this article, I will describe examples of some common decision making heuristics, through examples from my most recent consulting work. The field of “errors in thinking” is growing fast and a comprehensive review of each heuristic is beyond our scope here. Thus, if the “heuristics” keyword gets additional hits on web search engines, then I did my part.

Recently I was the Project Manager for a large software modernization effort in one of the Ministries in the Ontario Government. The Ministry had just completed a multi-year project for documenting and cleaning-up the business requirements for the applications that needed to be replaced with a modern case management system. The next step was to finish and publish the Request for Proposal (RFP), which was expected to attract reputable systems integrators for the design and implementation of the new modernized system. My services were initially retained to plan and execute the project that was established for publishing the RFP, evaluating the incoming proposals and awarding the contract to the highest scoring vendor.

A major uncertainty for the project schedule was the number of submissions to be received. Estimation of this number was critical, because we needed it for allocating resources for evaluating the proposals, and for establishing a target completion date for this work. Originally, we estimated that ten vendors would submit proposals, because any of us in the project leadership team was readily able to recall ten or more vendors capable of implementing this large scale solution. This estimate was based on the Availability heuristic, which is a tendency to make a judgment about the frequency of an event or category based on how easy it is to recall similar instances. However, at the time when the RFP was published, we had adjusted the estimated number of submissions down to four, based on our observation of how many large system integrators attended our vendor days prior to publishing the RFP. (Vendor days were designed to educate vendors on Government’s procurement processes to avoid disqualification due to violations of the procurement policies). Luckily, we ended up receiving three submissions, which was close to our revised estimate, and required only minor adjustments to the project schedule

Anchoring heuristic was used by our Project Sponsor when he established a contract award date based on his departure date for a month long vacation. After this, all our schedule variances were explained in relation to this initial expectation, instead of relying on scientific calculations based on Project Evaluation and Review Technique (PERT) or any other rigorous scheduling methods. Anchoring heuristic is the human tendency to rely too heavily on the first piece of information offered (the “anchor”) when making decisions. Once an anchor is set, other judgments are made by adjusting away from that value, and there is a bias toward interpreting other information around the anchor.

Representativeness heuristic was in effect when project team members were skeptical about one of the contender’s seriousness, based on the clumsiness of their written proposal, and based on their lack of brand recognition. Representativeness heuristic is the tendency to judge probabilities on the basis of resemblance. The error that may be introduced with this heuristic is when probabilities are neglected. In other words, the fact that something is more representative does not make it more likely. We made inferences on the vendor’s capabilities, based on the look of their written proposal and their unknown brand. Fortunately, the procurement process required evaluating all proposals, and it turned out that all vendors met the scoring thresholds, and demonstrated being capable of building a solution required by the Ministry. Final selection ended up being dependent on pricing. Relying on representativeness heuristic alone to pre-filter proposals could have dismissed a perfectly viable contestant, and could have weakened the competition.

In everyday life you are invoking heuristics:

  • when turning on and off your laptop on its misbehaviour, instead of starting a painstaking troubleshooting exercise;
  • when you play lottery with computer generated numbers, instead of choosing numbers based on elaborate theories;
  • when you watch the movie Die Hard 5 based on your liking of previous movies in this series, instead of reading the reviews before you go.

What heuristics are you using?

Don’t forget to leave your comments below.

Comments (4)