Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
In his book, Project Management for Musicians Jonathan Feist talks about several ways to mitigate risk, and they aren’t the ‘avoid, mitigate, reduce, transfer’ approaches that you are used to. Those are good, but they are approaches, they aren’t actual measures that you can take to mitigate a risk. Here are the 7 ways that Feist suggests you can reduce the likelihood that something will become a project issue.
1. Good project management
Yep, following good project management principles is top of the list. Of course, having a lovely Gantt chart and an up-to-date risk register won’t guarantee project success but it does give you the best chance of putting in place plans to mitigate that risk.
Make sure your risk management processes are up to scratch and that you are able to easily follow through on mitigation actions. Good project management also helps manage against risks of going over budget or missing milestones, because you’ll naturally be doing the things to stop these becoming a massive problem.
2. Written agreements
While you always have to factor in how someone else will interpret your written communications, putting things in writing can limit misunderstandings. It also gives you a sense of formality when it comes to contracts and agreements. Getting it all down on paper increases the chance that nothing is being missed.
3. Checklists
I love checklists and I use them all the time. As Feist says, “Checklists help you remember important details: procedures, gear items, points for conversations, people who need certain information, and more. Checklists are among the most effective tools used to reduce risk.” I have recently written a peer review checklist for my team – one of the many ways you can use checklists on a project to look at potential areas of concern and do something about them.
4. Cross-footing
This means calculating data in several directions to confirm that it’s correct. You add rows as well as columns on your spreadsheet, or check the data in a dashboard as well as a tabular report. Find different ways to double-check your maths or working, even if this is as simple as having someone else check for you.
5. Empowering competent people
If something does go wrong, you want your project team to be able to act appropriately and make decisions quickly, not sit around wringing their hands until you come in to the office to sort it all out. If you have competent people on your project team (and I hope you do) instil a culture where they can make their own decisions. Set levels to their decision-making power as appropriate so that they aren’t deciding to spending another million dollars on the project without anyone else approving it, but give them the freedom they need to do the right thing.
Feist says that the higher the risk, the more you want to make sure that if you are delegating tasks they go to someone who is a safe pair of hands. This isn’t the time to be delegating work to a junior colleague as a ‘learning opportunity’!
6. Developing emergency plans
Having a Plan B is important, and a traditional risk management technique that you are probably familiar with. Sometimes just having a back up plan is enough to make sure that the risk doesn’t happen. However, in case you do need another approach to dealing with a problem, it is useful to have already thought through what you will need to do in the emergency. Get everyone involved so that they can swing into action if and when they are required.
7. Written instructions
Like checklists, these are a great help if you need to distribute detailed instructions or have tasks that need to be done over and over again. Written instructions can also help clarify expectations. For example, on an IT project with a testing element, written instructions for the testers will help get standardised results and ensure consistency across several testers.
Have you used any of these methods on your projects? Let us know in the comments.
Posted on: December 09, 2013 06:51 AM |
Permalink