Getting the Most from Project Staff
Get project staff on track quickly with these tips from Robert Half Technology.
The typical mindset of risk management is to completely isolate and prevent "risky" events from ever happening in the first place, or even being discussed much.
But an interesting opinion piece at Forbes suggests that since you can never truly eliminate risk, you and your team should wrestle with it a little, just to get a better picture of what it looks like.
Mike Duensing, the engineering VP at cloud collaboration and planning solution Mindjet, says he has adopted a "keep your friends close and your enemies closer" approach to risk management in his own IT team. It's an over-used term, but basically Duensing advocates an integrated (my term, not his) approach to identifying risks and ensuring that team members in all phases of a project intimately understand what can go wrong with their responsibilities.
He cites the well-publicized "5 Dangerous Things You Should Let Your Kids Do" video presentation from the Tinkering School as something of an inspiration for his approach. If a kid owns a pocket knife (an example from the video), they come to understand from an early age that sharp things can do a ton of damage. If your DB engineer is engaged in the architectural phase with a legitimate cost/benefit risk evaluation of a breach, the imperative to keep data under lock-and-key will be more immediate and real to her as she designs and implements her schema.
Duensing goes on to offers numerous tips on developing a risk management culture internal to IT project teams. I don't want to steal his thunder by repeating too many of them here (you really should check out his column, so here is that link again), but one of the most noteworthy pointers is to make risk a measurable with checkpoints along the way.
He also warns against allowing an elevated awareness of risk among your team to cripple your projects. Anyone who has ever worked on a large-scale project, even as an embedded stakeholder, will nod in agreement to this one. IT guys, particularly developers, tend to have the perfectionist gene; the idea that it's OK if certain things go wrong is not comforting to them. Getting a project team to embrace the concept of acceptable risk can be a management trick of the highest order.
That's a different take than you'll often find in discussions of the formal discipline of risk management and where it actually belongs in an organization. With so much emphasis in the trade press on centralized governance, risk and compliance (GRC) offices and software, Duensing's advice might well be viewed by some organizations as more of a Project Management tactic as opposed to Risk Management (note the capital letters).
But then again, looking both ways before you cross the street is a form of risk management, and you'd be foolhardy to try and manage that from a central office. Building a culture where everyone is mindful of acceptable and intolerable risk is just smart business, regardless of where the formal function lies.