In this paper we look at the ‘how’ of measurement-based transformation, presenting a structured approach to making confident, sustained changes. This transformational framework is fully realised in the Procertis Change Control Process that is an integral part of our Enterprise Range of products.

To find out more, download the white paper

In the value chain approach the basic product or commodity is surrounded with value add-ons that offer increased margin opportunities and better deliver the true needs of the customers.

One such business that is adopting this transformational strategy has also recognised that to climb this chain their IT must be better integrated with their business processes. To establish the current integration level between IT, the business and their future requirements, we are using our BizMaps® and AssessIT® products from our Enterprise RangeToolkit. These provide a clear, unbiased foundation on which to develop the necessary transformation programme of work.

The first stage of the engagement is to establish the set of services to be measured. Here, we found the business was keen to decompose IT into its commoditised elements – printers, disk storage, email servers etc. which is rather odd given the overall business objective driving this work is to move the company up the value chain.

After some discussion, the value chain mind set was applied to IT and yielded services such as document management, the company communication channel and remote working. These services were far more business relevant and will ultimately be easier to manage as part of the transformational strategy – in fact all the benefits a client would expect from services higher up the value chain.

In our experience, no, it isn’t. The real challenge is to understand exactly what it is all those servers are doing, and why. And that’s a whole lot harder.

How to support your organisation’s key business processes?

The right answer is to think about what it is your organisation sets out to do – it’s strategy. That leads naturally to what business processes enable it to deliver its strategy, and then what IT investment supports those processes.

Right answer, but, in practice, it’s easier to go and buy another server to sort today’s problem. Strategy can wait until tomorrow.

The problem comes when the organisation demands savings (and be assured, in 2009 the savings target will be bigger than ever). There have been savings for years, so getting another 10% isn’t going to be easy.

Be Radical!

That’s the time to recommend a radical approach. To really understand how all that kit, licences, space and power cost lines up against the organisation’s business processes. It’s not uncommon to find that more than 20% of an organisation’s servers are supporting stuff that nobody actually uses any more – if indeed their function can be identified at all.

It’s time to go back to the drawing board; understand exactly what supports what and get rid of the rest. In one move IT can create savings and efficiencies – all at the same time. To find out more, check out how our Enterprise and Clarity product ranges.

In this paper Richard Williams and Gordon Miller explore how traditional IT performance measures fail to tell managers what their real IT capability is, or how it’s serving their business goals.  They dare to suggest another way of looking at things . . .

But, can IT and business have an informed debate regarding the impact on service delivery from this demand? Can the same really be delivered for less?  A simple blanket demand to save money could result in aspects of IT services that are highly business relevant being slashed because of a lack of understanding.

And what of the future?  How does the business wish to position itself when the carnage is over?  What must IT deliver, and when, to support this vision?  In short, business and IT need to communicate effectively through a consistent, impartial mechanism. One that connects real business concerns and needs to IT service delivery, and which allows changes in one to be traced to changes in the other.  It needs to be a single map that captures the current ‘now’ position and traces the route required for IT services to align to business survival and then onward to business growth.

To upgrade to CMMI, organizations that are using one or more CMMs should compare their current processes and approach with the CMMI model and create an upgrade strategy that meets their business needs.  Many of the skills used in applying the Software CMM are useful in implementing a CMMI-based process improvement program, since many of the best practices, issues, and improvement approaches are essentially the same. Organizations close to a process improvement milestone using the Software CMM may want to measure their progress before upgrading to CMMI.

Nothing wrong with that, of course.  But it does highlight a major problem with model-driven capability management.  No matter how good your model, it’s going to evolve.  Since the model is designed to help you manage something else that’s evolving – your business and your IT – you’re going to find the goalposts wandering around the playing field from time to time.

To be clear, we’re not knocking CMM or CMMI.  We’re not knocking any genuine attempt to guide management with rational models.  If anything, we’re concerned to change people’s expectations about the rate of change in reference models.  Model versions should indeed be turning over – and turning over faster than they do.  Your business is fluid, and the tools you use to direct it and articulate its behaviour need to be dynamic.  Your tools need to be responsive to change.

The software profession’s engineering foundation and heritage means that there’s an instinctive affection for freezing models, organising training related to them, arranging accreditation, and so on.  Constructing migration paths between versions is another default activity.  Management techniques derived from software practices attempt to force-fit the business world into this release pattern.  But the goals and the tempo of business rarely match this software practice rhythm.  Perhaps product-centric companies behave in a similar manner – although many such companies are trying desperately to move away from the release pattern towards customer-driven production.  In service industries, the release pattern has no connection with customer needs, being driven purely by the organisation’s conception of its own efficiencies.  And as organisations of all types strive to become more agile, synchronising to a release pattern becomes an obvious inhibitor.

So, are maturity models doomed to redundancy in today’s fast-moving enterprises?  We believe that the maturity model concept is still valid – in fact, more valid and vital than ever.  But we question the label “maturity”.  Maturity suggests a defined threshold – a benchmark at which perfection is announced.  When we try to encapsulate “maturity” in organisations, we’re actually seeking to assess fitness-for-purpose – a more unwieldy term, but one which implies that the standard being measured against is context-dependent and likely to change.  By building the concept of fitness-for-purpose into our management models, we can break the release pattern and provide tools that evolve alongside the business they are designed to measure.

Here’s another way of thinking about it…  We’ve got used to the idea that we live in a digital age.  Well, actually, we live in an analogue age.  That’s right: we experience continuous change.  The environments we work in are in constant flux, as are the boundaries of those environments.  The discrete step changes delivered by digital-style release strategies will never fit the curve of real life with fidelity.  There will always be a mismatch.  So, to get closer to the truth, you need to embrace the analogue.

We’ll be publishing some white papers over the coming weeks that will develop this and related themes in more detail.  Watch this space. . .