Minimal IT logo and link to home page
Research, training, consultancy and software to reduce IT costs
Home | About | Newsletter | Contact
Previous | Next Printer friendly
20 November 2012

Problem density

By Andrew Clifford

Problem density could be a valuable new concept for measuring IT.

The term "problem density" cropped up in conversation with a colleague. I had not heard the term before, so I searched for it on the Internet. The term is used occasionally in healthcare to measure the the number of problems that patients have. It is particularly used to assess drug addiction, where the patient may have many problem associated with their addiction.

Problem density could be a good concept for us to use when measuring IT. Most of the measures that we use are measures of general "goodness", or of compliance to standards or defined processes. We tend to use percentages or maturity levels. These are OK, but it is easy to lose focus on what is important. The scales that we use do not emphasise the situation well. What does 50% compliant mean? How much worse is maturity level 2 than maturity level 3? Bounding the numbers in a range (0 to 100, or 1 to 5, or whatever) does not give enough emphasis on what is really important.

Measurement of the number and severity of problems would give much easier-to-understand figures. Saying that one situation has a problem density of 1 and another has a problem density of 10 is easy to understand. Although it is an arbitrary scale, you can see that one situation is ten times worse than the other. It is also more accurate. We know that some situations give us hugely more problems than others, which is difficult to capture on a 1 to 5 maturity scale.

Problem density can be applied to both business and IT situations. We could devise scales for aspects of IT, such as measures of systems, projects, services, suppliers, and so on. But we could apply it to business situations too. We could measure business issues, such as task complexity, data errors, operational problems, rework, and so on, by devising a problem scale.

Solution density is the corollary of problem density. When we implement new solutions, whether they are procedures or systems or a mix of both, we can measure the breadth, complexity and variety of problems that they are intended to solve.

Comparing solution density to problem density would be a really useful analysis. IT solutions are intended to address problems, but they also introduce problems. Taking a ratio of the problems they solve (solution density) to the problems they cause (problem density) gives us a really useful management tool for identifying what systems are worthwhile. Looking back at my time working as an integration architect, this would have been really useful. I could have used it to illustrate how a lot of integration solutions have a solution to problem density lower than one, meaning that they cause more problems and complexity than the problems that they are intended to solve.

I will try introducing problem density into the IT measurement work we do. It will be interesting to see whether problem density is a more useful management tool than the measures we usually use.

Next: Why programming takes so long

Subscription

Subscribe to RSS feed

Latest newsletter:
Magical metadata

We use the term "metadata-driven" to describe IT solutions in which functionality is defined in data. Taking this to the extreme can provide unparalleled levels of speed, simplicity and versatility.
Read full newsletter

System governance

System governance helps you implement high-quality systems, manage existing systems proactively, and improve failing systems.

Find out more