Umami

By Andrew Clifford

Like the taste umami, there are aspects of IT management which we all vaguely recognise but which we have not defined well enough to manage effectively.

Since the time of Aristotle, we have subdivided our sense of taste into different individual sensations.

Different traditions have divided taste differently. In the West, we have traditionally acknowledged four primary tastes: sweetness, bitterness, sourness and saltiness.

More recently, based on sharing ideas with other traditions and on better scientific understanding, a fifth primary taste has been acknowledged. In English, there is no word for this taste, which could be described as "savoury" or "meaty", so we have adopted the Japanese word umami. Acknowledging umami, and understanding the scientific basis for it, has enriched our understanding, and given us new insights into how to create new flavours in the food we eat.

What has this got to do with IT management?

IT management comes in rich and complex flavours, but we acknowledge only two primary tastes:

• Projects. These are significant lumps of defined change, characterised by objective and scope definition, planning, work assignment and tracking.
• Processes. These are repeatable, ongoing activities, characterised by defined processes, metrics, and continuous improvement.

There is another primary taste which, like umami, languishes unacknowledged.

This unknown taste flavours a lot of what we do. Here are some activities rich in it:

• IT review
• Software selection
• IT governance
• Information security
• Legacy system management
• Application portfolio management

These can be characterised as systematic investigation, analysis, recommendation, prioritisation and justification. In English, I have struggled to find a good word for this. Perhaps it is "evaluative management", but I will stick with "IT umami" for now.

IT umami is separate from projects because it is not a defined change.

Although it may look like an ongoing process, IT umami is not simply process management in the same way that, say, software change control is. IT umami does not deliver value directly itself, but through the information and recommendations that the activity delivers.

Although we recognise it vaguely, we do not have a well-defined sense of IT umami. We attempt to achieve it through projects and processes. Many projects include a lot of investigation, and yet anything that needs a lot of investigation is ill-defined and hard to manage as a project. Our service delivery processes are peppered with all sorts of reviews, but it is hard to find time for these because of the pressures of day-to-day delivery.

Acknowledging IT umami as a distinct primary contributor to IT management would hugely enrich how we manage. It would give us fresh insights and help us to develop new methods and new tools. It would reduce uncertainty in projects. It would give us better insight and justification for the reviews we carry out as part of service delivery.

Most importantly, properly acknowledging IT umami would help us achieve the things that fall outside our current project and process management. It would give us a clearer sense of direction. It would help us to control and secure IT properly. It would help us halt and reverse the decline into legacy.

But to start we need a better name than IT umami. Anybody?

Subscription