This piece is about some thinking on problem evaluation. How to scope the solution according the the severety of the problem. Some failures are occuring. That sounds bad, but how many are there? It’s like risk evaluation … some would say it IS risk evaluation. What’s the Exposure and the Impact. But turned sideways to look at the effort to solve with expensive IT changes vs the expense to use a workaround. Everybody wants to say a ‘workaround’ is bad. But sometimes it’s a viable option.

Ask the 3, 30 or 300 question. Errors in critical transactions with customers, clients. But how many occurrences are of these bad things. Per hour, per day, week, month. Whatever makes sense in the context. If the question isn’t asked, but people are running around with hair on fire about the problem, thinking it’s 300 or 3,000 per day, week … But some clever person stops and says “wait a minute. lets look at the data”. And it turns out it’s a 3 or a 30 and not a 3,000! Good to check.

There are lots of really important things to be done in the management of the Enterprise IT through architecture and technology management processes. But in planning for investment, it is critically important to decide first the scale of each perceived problem and how much resource to devote to solving it.  

The presenter of the problem (business need, IT management need, infrastructure, corrective action) … should be challenged to look carefully and honestly into the source of the need.  How severe is the problem?  What is the actual impact (severity and likelihood)?  If there are perceived deficiencies in the business outcome (things ordered, procured, manufactured, processed, marketed, etc.) how often do these deficiencies occur – compared to the total volume of those things?  If the company doesn’t have good metrics on this already, add this to the list of things HIP understands and can help clarify and plan for.

How often does the bad thing happen?  3 times?  30?  300?  … and in what period of time (day, week, month).   If the number is medium or small, is it easier/cheaper to fix them on the side (manually or through a cheap fix it routine run manually in batch) ?

In risk management, there is risk evaluation, and this has two main dimensions: exposure – what is the likelihood of the bad thing happening and impact – what is the severity of the consequence of the thing happening (this can and should get complicated).

So, for evaluating whether to do nothing and fix bad transactions, records, documents manually, to do a cheap off-line batch cleanup process, or to implement costly solution upgrades, there should be a keen awareness of the frequency or likelihood of the bad thing and the severity of impact.  Lots of low-impact errors/quality failures or a few high consequence errors such as a security breach, corruption of data going out to business partners. Corrupt data coming in.

These include the architecture itself, in terms of roadmaps – high level and medium term plans from which individual projects drop into project management and SDLC execution.  They include management process such as Data Management, Information management, Security Management, Program Management and some others.  All of these are very important, but must be evaluated based on the actual need and impact on the business or the ‘business of IT’.

Metrics, Metrics, Metrics (managed)

Chris Hayes