On a project, you can come across risks that, if they happened, would be complete showstoppers, stopping the project dead in its tracks. They will force you to either rethink the project or give it up. It is important to identify showstoppers as they call for entirely different handling. You can only handle them in two ways:

  1. Put them in project assumptions (you assume they won’t happen)
  2. Dump them at the feet of the client or project sponsor (as they are miles outside of your control)

It is really important to get the project sponsor to realise these are his to deal with, as they are beyond the responsibility of the project. So what do showstoppers look like? Examples include:

  • Product build is based on an OS that the supplier upgrades to an incompatible version (this has happened to me when SAP completely changed the architecture of their CRM solution)
  • Client’s company gets taken over or hits economic problems (had this one too)
  • Software built on top of a client’s system that falls out of support (pretty common with desktops not being capable of upgrade)
  • Mass resignations by team members due to pay dispute (has happened with offshore teams where rival offered more money)

You might be inclined to ignore showstoppers. If you can’t do anything about them, why bother? Remember, these are too big for you to control, so pass them up the chain of command. The project sponsor has to deal with project assumptions turning out false (and you can even put in the assumption that they will deal with them). Ignoring them doesn’t make them go away. If a risk doesn’t happen and you ignored it, doesn’t mean it couldn’t have bitten you. If you sail in a dodgy boat and get across the channel, it doesn’t mean you couldn’t have sunk. You were just lucky. Deal with every risk and make sure every risk has an owner.

Test driven planning

Test driven planning uses the same approach as test driven development to craft and know when your project plan is complete.

Test driven development

Any coder, no matter what the software, should always do test driven development. Why? Because it makes you think about the program and all the things that it needs to do. It helps you:

  • Understand the full scope of the program
  • Draw out the questions that need to be answered
  • Highlight areas of complexity
  • Understand the programming patterns to use

Only when you have a complete picture should you begin to code. The tests, in effect, become the specification for the program. Once the program passes the tests, you are done.

Test driven planning is the same.

How it works

You draw up a list of 'tests' (a checklist) your plan must pass before it is complete. This works equally well for a product backlog. Typical tests you might include:

  1. Is the full scope of the project included?1
  2. Are all the risks and their resolving actions included?2
  3. Have all the people and resources been identified?3
  4. Is every task covered by a real person?4
  5. Is there sufficient contingency for unforeseen events?5
  6. Has the critical path been identified?6
  7. Are people on the critical path covered in case of illness or loss?7
  8. Is there time for meetings and non-project activity?8
  9. Are people's holidays included?9
  10. Have several people and your team checked the plan?10
  11. Does it meet the project's constraints?11
  12. Has project management time been included?12

Hopefully, you get the idea. Do not release your plan into the wide world until it has passed all the tests. You wouldn't put untested software into production. A plan is the same.

  1. Work back from a finished product to identify all the things that need to be done. This includes not only the use cases/stories but also all the technical activities, user acceptance, documentation and so on. ↩︎
  2. Risks will bite you if you do nothing about them. ↩︎
  3. Not generic resources but real people. ↩︎
  4. Find out now if you have a resourcing problem. ↩︎
  5. Or suitably hidden, so some management genius doesn't take it out! ↩︎
  6. How fast you can really do it. ↩︎
  7. Very important if one name appears frequently. ↩︎
  8. The best you will get is 80% full project availability. ↩︎
  9. Don't go live in August or Christmas, nobody is a round. Allow for slow downs over these periods. ↩︎
  10. It is not your own private work of fiction. They need to buy into it. Better is to have everyone involved in drawing it up. ↩︎
  11. If it misses a must hit deadline or overspends, you need to go round again and work out options. ↩︎
  12. For big projects, there can be project office staff. ↩︎