Risk is something I never understood as a developer, optomistic is not a strong enough word to describe my approach. My favorite example was the day I independently decided our windowing system needed a complete rewrite (1988, pre Microsoft Windows 3.0). I announced to my boss that I would work through the night to get it down, and expect resolution in 24 hours. Well, two weeks later I had removed the last major bug (can someone say "whoops"?). If I had been managing by risk, this would have been approached completely differently (I.e. Peer design review, estimate assessment, plan B fail-over plan, business interruption consideration, and the list goes on...).
Managing by risk is asking the question "What could go wrong? What might not work as planned?", predicting that likelyhood, and planning mitigations and contigencies. I will often ask my team to include top 3 risks in project status reports as a mechanism to bring risks to the fore, and believe this to be a best practise. My experience has been that known risks can always be managed, and that unknown (or ignored) risks are the ones that cause grief.
Sharing a risk is itself a mitigation, and also serves the purpose of quantifying and qualifying it. (That idea alone would have saved me 20 all-nighters). Yes, I've ignored risks. Yes, I've had grief. But I've learnt my lesson enough to know that a focus on risk is a key to success.
Tuesday, May 22, 2007
Ignore Technology Risk at your peril
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment