Feasibility of working on a problem

[Brian1]

Hello Everyone, wanted to post this to our brain trust to see what (if anything) people are doing on this front. As the problem manager for my organiation I have been tasked with creating a cost/benefit statement to determine if IS should commit resources to working on a particular problem. This is a departure form how we have operated in the past (current economic climate I suppose) where our criteria for identifying and workign on problems reactivley as a result of incidents was enough. So after thinking about this I have developed a crude worksheet to input as much incident information as I can along with estimates for effort to determine root cause. Then using some math convert everything into hours as my common term and then use that to create a "rating" where everything above 1.0 means we save money and below 1.0 means it costs money to work on that specific problem. I've shared the line items below so you have an idea of the questions I am asking. I am really interested to know if anyone was undertaken this kind of evaluation in their process and if so, how are you doing it?

Thanks,
Brian


A Impact Thus Far
How many Incidents Logged?
Avg. time to restore service?
Avg. priority of incidents?
Avg. urgency of incidents?

Resource Impact
Business Impact

Total Impact of Problem
Avg. Impact per Incident

B Potential Impact in next 12 months
Avg. # of Incidents per month

Potential Impact over next year

C Estimate to determine Root Cause & Solution Options
Estimated # of hrs of PbM Mgr
Estimated # of hrs of PbM Assignee
# of SME's required
Estimate # of hrs of SME

# of months to determine RC

Commitment Required

D Feasibility Calculation

Potential Impact
Commitment

Feasibility Rating

[UKVIKING]

Brian

Not bad as part of the PM - reactive process. but you need to add a section of proactive PM

which may override your spreadsheet
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[JoePearson]

I support any move to make the decision more objective as to whether to work on a specific problem. And the details you've laid out seem to be a good basis.

I think you could extend it quite easily to plan for avoiding incidents that haven't yet occurred - addressing some of the "proactive pm" that John mentions.

But you might also need to include some scenarios or risk/likelihood of fixing. (Maybe this is in your feasibility part.) After all, it's pretty rare that we know in advance how long it's going to take to fix a problem.

[UKVIKING]

Joe has it right

You usually can not tell how long a search for a solution would take

My advice - come up with a rough number of Activity hours ( 1 person doign for 4 hours is 4 a.h while 2 people doing 2 hours is also 4 a.h)

This is usually called ManHours but..
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[Brian1]

I'm positioning this as a method to get as far as root cause only because to all of oyur points, you have no idea what the solution is going to look like. I'm going to tackle the proactive part next, wanted to get the easy part done first then build on it. Thanks for the sanity check.
Brian