I was presenting at the IET’s conference on innovation recently and I heard a fascinating presentation on the changing nature of technology in defence.
One of the observations was how the UK MOD has changed its procurement approach, and how it’s getting better value as a result.
Apparently, the MOD used to precisely specify all the components for its equipment. This of course constrained the suppliers bidding for the work and there wasn’t much to separate the bids. And this was in the context of where equipment functionality was the main driver rather than speed of delivery and the ability to evolve it. (Sound familiar??)
Recently the MOD has taken a different tack. It’s been specifying _what_ it needs the equipment to do, but not _how_ it should be engineered to do it. This is fostering innovation and suppliers are proposing different types of equipment to do the job. And moreover the MOD is focusing on defining the outcomes it wants rather than how the equipment should be engineered.
And this got me thinking about the typical IT lifecycle…

We often seem to have a tendency to focus on specification and _how_ we’ll engineer the solution as opposed to the business outcomes we seek early in the lifecycle. Because we know we’re going to engineer something at the end of the day, we bring the necessary engineering rigour up-front.
With every project failure we increase our determination to add more engineering rigour earlier in the lifecycle. And we’re getting better as an industry at engineering solutions – but we seem to be getting worse at providing ‘really useful IT’ people actually want (when it finally is delivered after all the engineering rigour has been applied!). ‘Shadow IT’ – the world of the post-it note, email, spreadsheet, Google and personal networks seems to be growing not shrinking – despite all the engineering rigour we’re throwing at corporate IT systems.
Without throwing the engineering baby out with the bathwater – engineering rigour is absolutely necessary and we should continue to invest in increasing professionalism – perhaps we should consider how to re-balance the IT lifecycle so business outcomes – the what – as opposed to the engineering how – are kept front of mind.
Agile techniques, model driven architecture, domain specific languages et al are evolutions that may help – but these are still based in engineering. In parallel the human focused evolutions in natural language and ‘behaviour’ driven systems keep progressing. Maybe when these meet in the middle in a beautiful moment we’ll take a big step forward!
Until then, perhaps we might take a step-back every now and then. So when we’re in our process and IT engineering trenches against the usual time and budget deadlines we might remind ourselves of the original intended business outcomes. This just might help us pass the Ronseal test and for it to be the right tin more of the time!