Avoid the project incident pit

I have often coached my teams to avoid the project incident pit, so what is it?

The term "incident pit" comes from my SCUBA diving training with the British Sub Aqua Club more than 25 years ago. In the SCUBA diving scenario, the concept is that "as an incident develops it becomes progressively harder to extract yourself or your companion from a worsening situation." See Wikipedia.

In other words, if a relatively minor incident occurs on your dive then your tolerance for further problems is lowered, and if further problems do occur disaster can follow. The advice when diving is to consider abandoning your dive when even relatively minor issues occur.

So let's apply this to projects, it's unlikely any projects don't have some sort of "incident", such as a scope change, a delay in a critical path activity, a project risk becoming an issue, etc. Yet we clearly we can't abandon projects for simple issues.

If we accept that something will go wrong we need to consider our capacity to deal with the problem. Considering the project triple constraints of scope, time and cost you may need changes to some or even all of those to deal with your incident.

However, in my experience, the one often needed is time, even if only to understand how to manage the incident. So make sure the project is moving as fast as possible in its early stages, you never know when you will need that extra time to catch up lost ground.

"That's obvious" I hear you cry. Or is it?

• How are the dates in your plan communicated - are teams working to those dates, or are they working to be ready as soon as possible?

If you don't communicate the requirements teams may just work to those dates and no earlier, even for simple tasks. It's in part human nature, "the plan says my activity is completed by 1st March" that's the date in teams' minds so have they really assessed if they can deliver earlier?

• Look at the milestones in the project, what test, checkpoint or review activities exist?

Certain activities are worth doing earlier if at all possible. Any form of testing is a prime candidate. How do you really know the problems you have until you test or Beta them? So drive those activities as early as possible this will then highlight potential problems earlier giving you more time to deal with them.

I have often used "risk" processes to de-risk a larger project. This is basically performing activities ahead of their ideal date.

For example, we would risk build when hardware was ready and wait for final software testing. This gave us the opportunity to test the production processes, quality output and give full confidence that when the software was ready the product is ready to launch and put in customers' hands. The risk is that we are loading HW with non-final SW, the opportunity is that we can build confidence there are no surprises in the final HW ramp.

There is rarely if ever harm in doing things earlier, a good PM will work to establish the earliest possible date something can be ready from the subject matter experts not just tell them the latest date it's needed.

We often talk about performing an activity "at-risk" earlier than ideal but all too often we can ignore the opportunity that performing an activity earlier can bring in confidence or accelerating other steps.

Time isn't the only example, the cost would be the other triple constraint that frequently comes into play. What if a project were to spend more in earlier stages of projects to get critical path activities completed ahead of schedule and so giving the later critical path activities more time to deal with anything unexpected.

Does the incident pit analogy resonate with you? What other tips can you share to get ahead on projects?