In the first blog of this series I mentioned the possibility that storytelling began as a response to our conscious awareness of unavoidable death. Some scholars suggest that this gave rise to three major forms of stories or myths – nationalistic (us and them), religious (us and Him) and ideological (why and what). Perhaps after these existentialist tomes we evolved another type of story and storyteller to fill the gap between the unknown and getting through the day, night, week or the season. Abraham Maslow suggested that these stories fulfilled our motivational ‘need to know and understand’. Some less generous people call them white lies. However it is this type of story that can play a valuable role in the successful delivery of a project.
Imagine a scenario where you wake up one morning and the nice pillow that you laid your head on the previous night is gone. Your breakfast is disturbed, your commute to work distracted as you ponder the possibilities of the disappearance. How well would you work that day as multiple parts of your brain tried to put the pieces of this puzzle together?
Who took it? How did they get it? Where is it now?
This scenario, although rare for adults, happens often to infants who fall to sleep in the arms of their parents and wake up to find a changed scenario. The young brain struggles to reconcile the differences. Our brains are built to search for an explanation, a cause and effect solution that helps to build associated learning connections in the expanding brain – ‘neurons that fire together wire together’.
On projects we too struggle to put a cause with each issue or effect. The PMBOK references many tools and techniques that can be used to help identify possible causes and specifically names ‘Cause and Effect diagrams’ under the steps, Risk Identification and Quality Control.
Another technique available from operations management and systems thinking is the ‘5 Why’s’ technique often associated with Peter Synge of MIT. When faced with a troubling effect or issue we ask ‘why?’ and then ask the same question again of the answer, 5 times. To the novice PM it may sound childish but is an effective approach and is rooted in the idea that each effect has a cause and that by this series of sequential questions we can get to the root cause.
The Cause and Effect Diagram mentioned above is also called the fishbone or Ishikawa diagram , after Kaoru Ishikawa and can be used in conjunction with the ‘5 Whys’ to help identify the root cause.
It is here that we need to provide a word of warning for the novice project manager: The driving need and result sought by the ‘cause and effect’ approach is for better information and metrics to improve decision making. In essence it is the search for certitude. While this may be possible in operations environments it is frequently a futile effort on projects. Projects by nature (and definition) are ‘temporary and unique’ endeavours and therefore do not offer up either sufficient time or the quantitative data with sufficient accuracy to be useful in using this technique to help guide the project.
While the operations manager may have justification in his search for certitude, the PM is simply seeking to reduce the amount of ambiguity of various outcomes on the project. While the operations manager looks for the decimal point (or 6 Sigma equivalents), the PM looks to rein in the boundary conditions and increase the probabilities of various estimates and events. Therefore, in managing the project the PM needs to balance the innate or childlike ‘need to know and understand’ with the benefits of a more broad brush approach.
This difference of approach, often unspoken and poorly understood, can lead to friction and conflict on larger, cross-boundary projects.
In my book ‘Keeping Score’ I have two characters to represent these perspectives. Bob comes from a strong operations background and Edward comes from a purely project background. Neither man is particularly good at articulating their strongly held ideas and concepts. It takes a third character, Louise, to bang their heads together.
The operations manager can insulate the operations environment from the surrounding chaos of everyday life, whereas our project manager must plan to manage the effects of a chaotic world. The project manager must develop a flexible approach to contain possible future boundary conditions.
In my metaphorical mind I see operations management akin to collecting insects while project management is more akin to catching butterflies – a larger net is needed and a lot more energy is expended. This brings to mind the lovely quote:
“Fundamental to chaos theory is the phenomenon of sensitive dependence on initial conditions, commonly referred to as the Butterfly Effect. A butterfly flaps its wings in Peking, and weather in New York is different.”—Ian Malcolm
Perhaps on many projects the process goal is therefore not to develop and deliver on a detailed plan as much as to find the balance between planning for future environments and dealing with chaotic outcomes within contained boundaries. Most of us may benefit by the use of the Pareto Principle (80/20 rule) here with the larger share still going to planning.
And so if you do find your pillow missing one morning then you might do better to contact an operations manager and not a project manager.
What is your Story?
