<rant> Risk Analysis

Page may contain affiliate links. Please see terms for details.

Spinal

MB Enthusiast
Joined
Sep 14, 2004
Messages
4,806
Location
between Uxbridge and the Alps
Car
x254, G350, Duster, S320, Mach1, 900ss and a few more
Whoever created, throught about, or ever mentioned Risk analysis and Safety Management Plans should have been hung, drawn, quartered, shot and burned!

I've been up all night trying to hack together a safety management plan for a fairly complex system, and I'm nowehere near done! Its so tedious and so boring once you get started! Its the ultimate incentive to procrastination!

And don't even get me started on fault-tree analysis and FMECAs....

Where's that caffeine I.V. I ordered?

Michele
 
My dad used to do that sort of thing - risk assesment. Good luck cos I never understood it. Basicly, I think, you just get blamed what ever happenes.

Have a nice day!:)
 
Unfortunately risk assesment and all the other bull**** that goes with it is all part of my job. The single biggest waste of my valuable time, I hate it :mad:
 
:D I'm happy I'm not alone!

kjay: its being done as a last minute thing; (found out Friday, due Tuesday - and its for a system that is supposed to store and process medical records :S ) I'm going to emphasize that there is no way its complete and there will be issues... but it definetly will be better than not having one!

It was one of those "oh yeah, we need a Risk Assement thingy, don't we?" moments... :cringe:

Now, where's that courier - I have some password backup disks to mail...

Michele
 
It's what I do as part of my job too. Can be tedious at times as you are looking for risks that no really there or so unlikley to happen yet it all has to go in there and be documented then actioned and followed up:crazy:

It's all common sense but sadly so many people lack that basic quality :confused: :confused:
 
It's what I do as part of my job too. Can be tedious at times as you are looking for risks that no really there or so unlikley to happen yet it all has to go in there and be documented then actioned and followed up:crazy:

It's all common sense but sadly so many people lack that basic quality :confused: :confused:

The problem with common sense is that its not so common!

My problem is that I'm writing a SMP for a system that doesn't exist yet; the requirements I have are notes I took on a notepad (which I'm starting to think I should compile into a set of formal-ish requirements to cover my back...) and worst of all, the system will probably be comprised of :
-old OsX Webserver running some database and php
-database interface written in php
-client computers (lan/wan)

I could spend a month writing a SMP for any component of the system and still be nowhere near done! What really frustrates me is trying to predict
software failure. You know its going to happen; but you can't really calculate any probabilities. So its guesswork really. And you can't really explain the failure - if I could; don't you think I'de have fixed it by now!? :mad:

Hence, I'm basing my probabilities on lines of code! If the system has 100 lines of code, I'm making a "calculated estimate" (read "I have no clue and I took a guess") that its less safe than a code with 1000 lines of code. Poof! Failure probability within a week = lines of code * (1/1000000000)
(hope thats a big enough number that the code doesn't actually get that long :p)

Ugh - and I need to stop procrastinating! My mind is starting to reject the caffeine; I've had to swap to tea hoping it will keep me awake a bit longer... Might sleep for an hour or two around lunchtime though - I have a feeling tonight won't be any different!

Michele
 
<blinks as he draws the curtains>

its... sunny.... <recoils back in agony>

Just my luck the one Sunday I wouldn't mind a dreary day! :p

Michele the Vampire
 
Risk assessments are primarily an ar5e covering exercise. If you have done an RA for a particular task and it all goes t!ts up - then its your fault as you knew the risks involved and saves any nasty compensation claims against the company that instructed you to do the task in the first place. Its no different to being bombarded with 200 emails a day, mostly trash and inconsequential trivia. However, you go and do something that contravenes one of these - then its YOUR fault........."didn't you read my email telling you not to do that"?.....etc......etc......I am sure we have all been there.
The only way of staying out of trouble nowadays is to do jack and sit on your hands. Sad, but essentially true.
Anybody who displays an element of initiative and ability will not last long. And we wonder why the country has gone down in the worlds standing.
Someone has to realise and acknowledge that a calculated RISK is an essential part of business and finance. Take that away and you have stagnation.
 
Last edited:
It's what I do as part of my job too. Can be tedious at times as you are looking for risks that no really there or so unlikley to happen yet it all has to go in there and be documented then actioned and followed up:crazy:

It's all common sense but sadly so many people lack that basic quality :confused: :confused:

Part of my job, as well. Its become a huge, complex self generating process that adds little real value and adds complexity. Very frustrating:(
 
I think risk assessment is essentially the 'bosses' passing the buck and failing to accept responsibility, plus of course this horrible blame culture of 'Had an accident at work then phone 0800.......'

When something goes wrong it appears that we MUST blame someone and demand either renumeration or someone's head? Why oh why don't we accept things sometimes go wrong and move on. How much time, effort, paperwork and hot air is wasted on this ridiculous exercise?

John
 
Risk assessments are primarily an ar5e covering exercise. The only way of staying out of trouble nowadays is to do jack and sit on your hands. Sad, but essentially true.
Anybody who displays an element of initiative and ability will not last long. And we wonder why the country has gone down in the worlds standing. Someone has to realise and acknowledge that a calculated RISK is an essential part of business and finance. Take that away and you have stagnation.

Wow.. I'm glad someone else has the same thoughts.. :bannana:
 
Someone has to realise and acknowledge that a calculated RISK is an essential part of business and finance. Take that away and you have stagnation.

Sir you are correct. Risk assessment is all about establishing how much risk are you willing to carry, if you don't care, do a crap risk assessment. Unfortunately, like many of the processes in this world it's usually driven by insurance... :mad:
 
So what if a Action, item, piece of machinary or ancillary equipment has not been Risk Assessed should it have been.
 
Someone has to realise and acknowledge that a calculated RISK is an essential part of business and finance. Take that away and you have stagnation.

Sir you are correct. Risk assessment is all about establishing how much risk are you willing to carry, if you don't care, do a crap risk assessment. Unfortunately, like many of the processes in this world it's usually driven by insurance... :mad:

Totally incorrect! If you are sat on the crapper and someone the other side of a plasterboard wall has a Hilti shot fire nail gun and blasts through the wall and into you, that is deemed a calculated risk? I think not. And yes I witnessed such an incident many years ago on a building site. I have to do risk assessments and method statements every time we take on a sub contract and inform my staff and get the thing accepted on site by the main contractor, usually two or three per month and it has to cover all the tools, scaffold, trip hazards etc etc. I personally think it focuses the mind and covers my rear end should an untrained person operate machinery that he or she shouldn't.
 
Unfortunately, if you are the site manager, a risk assement probably will not cover your rear end should an untrained person operate machinery that he or she shouldn't because *you* should have ensured that it was isolated by training the person responsible for it. :(
 
Last edited:
My problem is that I'm writing a SMP for a system that doesn't exist yet; the requirements I have are notes I took on a notepad (which I'm starting to think I should compile into a set of formal-ish requirements to cover my back...) and worst of all, the system will probably be comprised of :
-old OsX Webserver running some database and php
-database interface written in php
-client computers (lan/wan)
Well with no formal statement for requirements it's totally pointless writing an SMP. How can you predict that the system will do what it's supposed to do and not do something it's not supposed to if you don't have a document saying what it should do in the first place. Similarly how is it going to be tested, signed off etc without statement of requirements to do these things against.

I'd suggest that the whole development needs looking at from scratch and a proper documented process followed throughout - with proper, testable, requirements, design and test documentation and the necessary review/sign-off points. Then the SMP job becomes much easier as it's really a matter of documenting what you have done in the process to ensure the requirements are correct and how the developed software is tested to ensure it meets those requirements. Then assessing the risk and impact of a fault remaining in either the requirements or the code.
 
Totally incorrect! If you are sat on the crapper and someone the other side of a plasterboard wall has a Hilti shot fire nail gun and blasts through the wall and into you, that is deemed a calculated risk? I think not. And yes I witnessed such an incident many years ago on a building site. I have to do risk assessments and method statements every time we take on a sub contract and inform my staff and get the thing accepted on site by the main contractor, usually two or three per month and it has to cover all the tools, scaffold, trip hazards etc etc. I personally think it focuses the mind and covers my rear end should an untrained person operate machinery that he or she shouldn't.
Probability: extremely low
Severity: moderate to high
Actions: sell all nail guns on eBay and make them use hammers instead, plastic ones preferably!

Well with no formal statement for requirements it's totally pointless writing an SMP. How can you predict that the system will do what it's supposed to do and not do something it's not supposed to if you don't have a document saying what it should do in the first place. Similarly how is it going to be tested, signed off etc without statement of requirements to do these things against.

I'd suggest that the whole development needs looking at from scratch and a proper documented process followed throughout - with proper, testable, requirements, design and test documentation and the necessary review/sign-off points. Then the SMP job becomes much easier as it's really a matter of documenting what you have done in the process to ensure the requirements are correct and how the developed software is tested to ensure it meets those requirements. Then assessing the risk and impact of a fault remaining in either the requirements or the code.
Tell me about it... Sadly the "whole development team" is comprised of my boss and 6 or so nurses; oh yeah... and me....

I've written about 15 pages of formal requirements, and while not exhaustive from a safety/risk management point of view it works a bit better than nothing! I'm going to quickly wham together some UML diagrams to get a rough idea of what the system might look like (after all, I have a sneaky suspicion is me thats going to implement it!)

Oh well, another night awake - I guess I'll be forgiven for falling asleep during the monday morning meetings tomorrow :p
Michele
 
IT risk assessments are easy:

Task: Send millions of items of confidential data to another agency
Hazard: Danger of losing items and landing in wrong hands
Probability: It's the post, so pretty damned high.
Action: Sod it, send them by standard post on two plain text CD-Rs.
 

Users who are viewing this thread

Back
Top Bottom