Search in Features

Outcomes vs Specifications

Tuesday May 10th, 2011

By Terry Street, Principal Consultant and Procurement and Outsourcing Product Manager, Socitm Consulting

Outcomes are hailed as the all-new future-proofed approach to procurement specifications that let you ignore how it’s done and just focus on the results.

Well, that’s the theory. But how well does it stand up in practice? The social sector has been dealing with outcomes for a considerable time and is well versed in, for example, bidding for funding based more on what difference funding an investment (say skills training) will make in the employment levels in the target community than on how the outcome will be achieved. Yet even in this example part of the issue is that other factors can influence employment, not just skills training; so how do you measure its impact on the outcomes? Do you still need to look at some form of outputs and benefits achieved, such as how many were trained, in what skills, and how many succeeded in gaining employment?

In ICT we haven’t been working with outcomes for that long. Whenever I run courses on the subject I am generally faced with a high level of cynicism. There is a certain degree of comfort in a highly detailed functional specification; of course even this is not risk free. I recall a student registration system designed around a specification that went into the nth degree of detail about what information should be collected about each applicant. Where it fell down was on performance and achieving the essential outcome of registering all the students in the narrow window between exam results and offers at the start of the academic year – many registrations were still incomplete at Christmas. The system was written in a high-level language that was ‘load and go’, meaning ages were spent compiling code. Also the database design was not set up for high levels of new inserts, which caused database admin problems. The question is: would an outcome-based specification have avoided this? Possibly it would have, if it focused on the aim of getting x-thousand students registered in four weeks. Although, if throughput was still a problem, trying to pin the responsibility on the software provider and not the users’ speed of entering their information might have been fun to watch.

So ICT outcomes do have their place, particularly if entering into a strategic relationship where the supplier is in effect the architect as well as the builder. You need to evaluate how well the supplier’s ideas for the future shape of ICT services dovetail with the authority’s goals and its vision of ICT in the future – is it a cost centre or a savings generator? The vision is that outcomes transfer the risk to the  supplier: functionality is not a concern of the purchaser.

How real is that vision? Can you get a deal where the supplier pays all the costs of purchasing, installation,  tailoring, training, etc and then sits back and says: “When you get round to having a play with the new system we sweated blood to install we’ll raise an invoice”? Well maybe not, but some deferred costs and some ‘pay as you go’ mechanism should be considered.

And what happens if the benefits are not realised? You still need a contract which makes it very clear who is responsible for the benefits and any resulting savings. For example, a document management system might save on storage space; but does that convert into cashable savings? What is the trigger for payment to the supplier? Is it enabling benefits or the realisation of actual cash savings? How much of the outcome is directly related to the ICT services? Seldom is it a direct correlation, as there are always other factors involved. What part do others play in achieving outcomes? How is this catered for in the agreement?

So what’s the message in this blog? Maybe the moral of the story is that outcomes are all well and good, but when it comes down to who changes the baby’s nappy you cannot beat a prenuptial agreement – or in the case of ICT one based on a comprehensive set of terms and conditions. A good example is the OGC ICT services model. You may also need a guide to fitting all the schedules together and making sure that you cover the exits too (see my last blog).

If you’d like to discuss any aspect of this, contact me on 0845 450 2317 or at terry.street@socitmconsulting.co.uk or post a reply or comment below.

Leave a Reply

debug