Article Overview
Managing a project sometimes seems like playing Whack-a-Mole. If you are not familiar with Whack-a-Mole, it is an arcade game in which a player uses a rubber mallet to hit toy moles, which pop-up at random.
Table of Contents
- The Myriad of Emergent Events
- Proactive Measures
- Conclusion
You hit the moles to put them back into their holes. For us, it has become a metaphor for managing projects. The comparison of ‘moles’ to the unexpected potentially traumatic events that pop up unexpectedly in the project and one tries to “whack’ the ‘mole’ back in its place. Some of these things are anticipatable but even anticipated events often have actions associated as a response to the event – whack that mole.
Think about the numerous events that happen that can affect a project from meeting the objective. Not just many in number, to paraphrase Shakespeare’s Hamlet “when troubles come, they come not single spies but in battalions”.
This is not always true; some projects have what we (engineers) would call laminar flow, things just move along, quickly, and smoothly, without turbulence. Other projects have many things go wrong, and as you get one solved, a new one pops up, or worse still, these are not a serial string of difficulties but hit simultaneously, multiple moles pop up that require some response to resolve.
Here are a few examples we have experienced:
- talent out sick at a key time and for a long duration
- the change or loss of a key team member
- change the project manager
- last minute / urgent customer change request
- reassigned sponsor
- organization restructure during project execution
- unexpected/unanticipated regulatory change
- supplier issues
- late delivery
- restructuring
- union strike
- won’t start new work until the account is brought up to date
Now, realistically these things cannot be handled or go away with a stroke of a ‘mallet’, but just as the game, requires focus and quick identification of the anomaly, and subsequent response to the emergent event.
This is considered effective project management. In fact, with projects the complexity is so high end these emergent events often start out subtle, it is not very practical to respond as the symptom of the event becomes visible or apparent. This is the compelling reason for risk management efforts.
Risks versus Issues
Reviewing the list of examples above one could say they could be defined as Risks (perhaps should be part of our risk management identification activities) to be qualified and quantified. That would be true and accurate. But let’s look at one example.
How likely on a project, is the Sponsor reassigned or outright replaced? In our experience, it has never happened. Therefore, if this were identified as a Risk during the Risk Identification exercise it would score low in both qualification and quantification.
Perhaps even not included on the Risk Register. But let’s suppose one day it is announced that the Project Sponsor is leaving the company. An issue has popped up. The reaction is to ‘whack’ it quickly and move on. This issue has now produced some Risks. What if the replacement Sponsor is not as engaged as the previous sponsor? Perhaps this new sponsor does not perceive the priority of the project at the same level as the previous sponsor.
What if the replacement Sponsor supports the project at arm’s length? Their plate is already loaded and there is no time to give quality attention to your project. What is the chance the replacement Sponsor doesn’t truly support the business case of the project? On a very few occasions, sponsors have had a secret agenda or do not have the political savvy to defend the project at the executive level, the result, getting a project killed.
Risks and Issues are not necessarily interchangeable, but they are connected. Risks and Risk Mitigation can lead to Issues that pop up and require attention. Issues can lead to Risk-y actions, decisions, and consequences that become Risks to the health and delivery of the project.
Tip: Always have a live running Issues List that clearly identifies the Issue, Ownership, Resolution, Due Date, and any related Risk – new or previous identified. A stubborn issue, one with significant project impact, can make it to our risk management actions.
Trying to cobble a plan together while in the throes of a succession of potential project sinking events, is not the best solution possible.
Moreover, relegating response to an impromptu reactionary approach would not be referred to as proactive, it is reactive. Make no mistake, project management in the business context often comes with surprises, some of which perhaps we're not so predictable.
Competitive pressures can drive management decisions, which may have an adverse depending impact on the project objectives and personnel. Sometimes the project manager is not able to articulate the difficulties with the decision.
While it may seem impossible to develop a plan to handle exact Events and Issues that pop up during the execution of a project. A Project Manager could develop a plan of the first steps to take when a ‘Mole’ shows itself.
For example, what are the steps to be taken? Clarify an Event or Issue index. Which ‘moles’ can the Project Manager handle themselves – without others' input? Are there any? What type of ‘mole’ does the sponsor, stakeholders, and/or team need to be involved in the resolution process? As with most plans in project management, this one needs to be document and living. The PM must have the capability to modify the plan during execution.
What works, what doesn’t? Maybe there were warning signs of a ‘mole’ appearing, document.
We cannot anticipate all things that can go wrong in the project, and not all of these emergent events will fall to our risk register. Quick identification of these events as well as impact potential helps us to respond quickly. Anticipating may be a faster solution, but all things are not anticipatable or predictable.