Many IT project managers see risk assessment as “just box ticking”. And if the techniques used really are no more than window-dressing, how will this situation ever change?

Even in 2007, risk assessment is arguably still an embryonic skill. Asked to identify “key risks” for a new project, the competent IT director can rattle off all the usual suspects, from “the business won't help us specify a new system” to that old one about the project manager disappearing under a bus.

But isn't every project different? And if it is, how do managers draw out the pitfalls specific to a new project so that unpleasant surprises can be avoided?

Here's five tips for brainstorming risk:

Have a formal risk-management day.
This has to involve every stakeholder in a project. The chair should be a business representative, not a technical expert, so the business feels “bought in”. The purpose of the session should be mapping business processes at the highest level. Not just how they could fit to technology but also what will happen if these process are disrupted – and whether all processes actually have been mapped.

Try a different outlook
But be careful not to do the brainstorming for the business representatives. Rather than asking “what happens is this particular element of the system goes wrong?” ask them “what is the worst possible situation in which you can imagine yourself – IT-based or otherwise?” They are more familiar with their own business processes and so will have more “material” to work with to imagine disaster.

Try a third outlook
IT people are often optimists. BPG's experience is that, when considering risk, they focus on the positive consequences of acting rather than worrying about the negative consequences of not acting. For a new way to brainstorm potential problems, write a checklist of how every participant in a project could “not act” – and how that will affect progress.

Pay the vendor to identify problems
Vendors get a lot of bad press in IT. But BPG's experience is that, bar a few who over-promise, generally vendors are as keen to make projects work as their customers. But there is one critical difference. A customer can “afford” to spend more resource on important IT projects. A vendor, meanwhile, has to juggle resources across a range of customer projects – with a lot “wasted” on non-profit work like scoping new projects, a service that most project managers expect for free. If the vendor is paid for scoping, they can provide a higher level of resources.

Make accountability clear
We can't stress enough how most IT problems are caused by a lack of accountability. An IT project can be seen as much like a conversation over a walkie-talkie: the first person speaking must indicate they no longer need “control” of the conversation by saying “over” before the second person is allowed to take control. It may be a more time-intensive way to communicate but you're never confused about who is in charge.

In the same way, projects require formal frameworks to pass control between partners. If it's not clear who is in control – who is accountable for fixing a particular issue - odds on it will not be fixed. The problem falls through the cracks and you are lucky if anyone even realises it needs fixing before it is far too late.

That's five suggestions – and observant readers will not that none of them are technical.