Imagine driving down a country road when a street dog starts chasing your car? The dog â€˜attacksâ€™ the car but by the time gets it closer to the car, the car has moved ahead, and so the dog changes direction and attacks at new coordinates. This game goes on for some time, but because the car is faster than dog, dog loses the race never quite catching up the car! The resulting curve looks something like this:
In mathematics, this is known as the â€˜curve of pursuitâ€™ â€“Â a curve constructed by analogy to having a point or points which represents pursuers and pursuees, and the curve of pursuit is the curve traced by the pursuers. The dog is attacking the problem as it see right now, but by the time it reaches near it, the problem has gone ahead a few steps! So, a problem-solving approach like this is perhaps only going to prolong the time it takes to solve it, and also make is costly in the process (not to mention, create opportunities for additional problems to breed in that time). A far more prudent approach will be to anticipate tomorrow’s problems and address them today.
It is always a significant challenge to chase such moving targets â€“ but isnâ€™t life all about such non-trivial pursuits? In nineties, a popular slogan was â€˜quality is a moving targetâ€™ meaning the bar of quality keeps going higher every time. Similarly, whether we talk about performance of individuals (what is good this year might not be good enough next year!) or performance of companies (a company might be growing year-on-year but if it grows slower than the competition or the market growth, that stillÂ isnâ€™t good enough), similar sentiments are at play. This even applies to product development â€“ if your product development strategy is basically playing the catch-up game with competitors, you are probably only benchmarking against the â€˜presentâ€™ and making projections for your â€˜futureâ€™ but without a meaningful clue on what those competitors have in mind for their â€˜futureâ€™?
And we see the similar challenges in projects â€“ especially when the project is running late, or having major quality problems, falling behind on staffing targets, having serious attrition problems, major changes in scope, late design changes, late integration breakages, or some such significant deviation from the plan, the project manager is expected to fix the problems. That is natural and quite necessary, but very often the project manager becomes the proverbial dog chasing the proverbial car, which by this time has taken a life form of its own. So, the project manager starts working on fighting the problems of the day, and losing critical oversight of what lies ahead â€“ which means even if he as much as half-succeeds in solving todayâ€™s problems, some damage gets carried forward and come another day, there are new set of problems waiting for him :). It could sometimes deteriorate into a rat wheel situation â€“ a feeling of dÃ©jÃ vu every single day, or quicksand where whatever one does only seems to sink the project further. How can we eliminate, or at least minimise such curve of pursuit in project?
Here are three simple steps that I have learnt over the years – they can help you plan better to avoid curve of pursuit, or avoid the impact should such a problem still occur:Â
1.Â Do scenario planning for major potential disasters
Any well-planning project can easily survive one major project disaster, or reasonably manage two major project disasters, but perhaps canâ€™t survive two or more project disasters happening simultaneously. While risk management prepares one to address â€˜known unknownsâ€™ and having a risk buffer might even address â€˜unknown unknownsâ€™ to a large extent, not too much effort is spent in planning and analyzing scenarios â€“ doing a â€˜what-ifâ€™ analysis in event of major contingencies. For example, we are in 45th day of Mexico oil spill as I write this post, and we still have no clue how to fix the problem, let alone think of the day after scenario! Even if we are able to somehow magically bpug the oil well, we have no contingency plan to clean up the oceans, provide the so-important succor to threatened marine life in the affected region. So many infrastructure projects end up creating environmental aftermess that is never part of any plan.
2.Â Identify sub-team to handle project fires
The worst thing a project manager can in a fire is to get personally involved in firefighting until the complete fire is extinguished! While this could erode a teamâ€™s confidence in solving the problems, it could also lead to â€˜task saturationâ€™ and lead to other fires, or even bigger disasters. I remember attending a great training by Afterburner where they talked about a real-life example of how task saturation brought down a jetliner in the US in 80s because the pilots were fidgeting with the â€˜red bulbâ€™ and got so engrossed in troubleshooting it that they forgot the plane was on a descent! No one survived that plane crash. The NTSB video recreation of this event was chilling, and perhaps if one of the two pilots worked on the light bulb problem while the other one kept the plane on course, a grave human tragedy could have been averted.
The key is to identify the best people to fix the problem and empower them while maintaining complete visibility into the rescue efforts. These efforts canâ€™t be on the mainline at the cost of normal project plan, and hence it is extremely important that the project manager doesnâ€™t immerse himself in the problem.
3.Â Anticipate and plan for tomorrowâ€™s problems
A fire today needs immediate firefighting action, but no firefighting ever led to restoration of original status before the disaster struck! At best, it might just about prevent further spread of fire to neighboring properties. Similarly in a project, a fire today could bring with it unforeseen problems in future. When a firefighting team is facing the extreme heat trying to douse the killer flames, they canâ€™t think of the cost of reconstruction efforts. It is a good idea to initiate parallel efforts to keep an eye on how the fire is affecting the project, notwithstanding progress of firefighting efforts. And for all right reasons, the firefighting team or even the project manage is not the best choice for it. Have another set of team members to start thinking of Plan Bs and Plan Cs (that were created in point #1 earlier) and let the project manager, once again, keep a close eye on this scenario planning exercises.
I canâ€™t claim that I been successful in completely eliminating the curve of pursuit, nor I have seen many people who can do it well. However, there is merit in realizing how such small acts of short-sightedness can completely kill the project, or simply carry it from one fire to the other. Commensurate to a projectâ€™s criticality, adequate efforts must be planned accordingly.
How do you avoid the curve of pursuit in your projects?