In this series of articles we’re discussing a simple approach for managing projects – the ten D’s of project management.  So far we’ve covered Definition, Detail, Dependencies, Duties, and Dates.  Now it’s time to talk about project Dangers.

Project Dangers

In the Definition post we discussed the need to ask key questions before diving into detailed planning, and we used an everyday example of planning a meal/party.  In the Details post we created a hierarchy of work to be done, and in the Dependencies post we sequenced the work using a network diagram (flowchart).  Duties was about assigning a person’s name to each task that we had identified during the Details step, and Dates calculated an estimated schedule for the project.

So now we have a schedule of what’s supposed to occur – but we know things never unfold the way they’re supposed to.  Things happen.  Sometimes good things.  Mostly bad things.  Project Dangers is about how we prepare for these apparently unknowable events.

One option would simply be for us to deal with problems if/when they occur. That’s not unreasonable, but not very proactive.  This is probably not the first party we’ve ever been involved in.  We’ve seen problems on projects like this before, and without too much effort we could also imagine a few new things that might go wrong on our project.  How about we create a list of potential problems/Dangers we might encounter?  Here are just a few examples:

• A guest might not RSVP but turn up anyway.
• The wrong groceries might be purchased.
• The chef might not as be as capable as he claimed.
• It might be raining on the night of the party and people might get wet eating outside.
• People might drink too much to be able to safely drive home.
• You might not have enough time to purchase all the decorations.
• Chris’s old stove could stop working on the day of the party.

Note that if we already know that the chef is lousy, that’s not a Danger – that’s a known fact and we should plan accordingly.  The items on our list are things that might happen – we just don’t know.

Strategies for Dealing with Project Dangers

Now that we have our list, what should we do?  We start by focusing on Dangers that seem most important – either because they seem likely to occur, or because they would have a large impact if they did occur, or both.  Then there are four approaches we consider for dealing with each of the important Dangers.

1. Accept.  If it happens, it happens.  We’ll deal with it then.  For instance, if someone buys the wrong groceries we’ll just send them back to the store.  No big deal.
2. Avoid.  Make the Danger go away.  Plan to hold the party indoors and no-one will really care if it rains.  Problem solved.  Danger avoided.
3. Transfer.  Give the Danger to some-one else.   Recruit one your friends to research and purchase the decorations, or hire a professional.  Either way, they have to find the time now, not you.
4. Mitigate.  Reduce the importance or likelihood of the Danger.  Plan to call people who haven’t RSVP’ed after one week to check on their status.  Hire a reputable chef with lots of references – they could still be terrible, but it’s less likely.

With a little pre-planning we can reduce the number of unexpected party hiccups we experience and have a smoother running project, but we have to consider these things earlier enough for them to be effective.

In the next post we’ll look at the seventh D after project Definition, Detail, Dependencies, Duties, Dates, and Dangers, and that’s project Documents.