Technology Delivery: We are doing it wrong

(This Article first featured on Gartner’s Cloud Advice Forum)

I have a saying I like to use from time to time: “You don’t need to know the colour of the drapes to build a house”.  If we were to build a house today the way most organisations have delivered technology, we’d not only have the drapes firmly squared away, but we’d have specifically defined the exact location of every coffee cup and piece of furniture before construction. The next 12 to 18 months would be spent building the house in relative isolation with both sides of the fence hoping they liked what they saw at the end! Throughout the project, there was very little room for change and certainly no room to be wrong. Then along came agile…

From a technology delivery perspective, agile provided a better overall experience for businesses; Higher engagement and flexibility throughout the design and construction phases and a greater focus on delivering what the business wanted, when they wanted it. This all sounds rather attractive except the core ideals and iterative nature of agile meant in many cases, sound architecture and engineering practices were left at the door. While agile methods on the whole were producing better results for business, was it really the panacea organisations were looking for, or has it just been a knee jerk response to the challenges of old?

So what’s the Problem?

Over the years, the relative virtues of the different delivery methods have been debated, at times with an almost religious zeal. Somehow, most of our current delivery practices still have the same two problems:

  1. Deliverables are aligned to more or less arbitrary milestones, as defined by the technology delivery method and not necessarily the technical or business challenges. Every task and activity lines up behind those milestones whether it makes sense to or not.
  2. Request driven and reactive, unless something is explicitly asked for, it may not even be considered. Which is fine until a small, perhaps obvious change in needs or requirements results in a complete (and expensive) redesign of the solution.

Despite all the pomp and circumstance brought by new delivery approaches in the industry, IT departments are still a reactive service, fundamentally aligned to their own ideas and practices. The divide between business and IT might be getting smaller, but focus seems to be on addressing the symptoms of this gap, and not the cause.

Perhaps it’s time for IT to stop trying to re-invent itself from within and start to look over the fence. Technology delivery may have evolved a long way over the last 40 or 50 years but the engineering practices of industries like construction have between 4000 and 5000 years under their belt. Technologists may think they’re pretty smart, but it’s hard to compete with that sort of maturity.

It’s about the requirements you don’t have

If you look at how a house is built today, there is a particular and fairly consistent process that is followed by pretty much every modern housing project. As the process progresses, focus is applied not to designing and building every detail of the house all at once, but rather ensuring just enough information is gathered for each particular stage of construction to commence. Design and build phases happen continuously in cycles of increasing detail, optimizing the delivery based on time and cost right up until the customer is relaxing with their feet on the coffee table of their new home.

This “Just in time” approach to requirements and design may sound familiar, but the focuses are very different to what you might expect. Proactively rather than reactively, it’s often the requirements that don’t exist (yet) which influences the particular phase of the delivery process as much as the requirements that do. Everything from the carpentry to the plumbing and electrical go through “rough in” stages prior to the final details being decided. There is definitely nothing arbitrary about the chosen gates and milestones. Refined over hundreds if not thousands of years between architects, builders, governments, customers, and financial agencies, they align not to the builders chosen style, the whims of the customer, or some nominal time period, but to a language with common meaning between everyone: Risk.

Risk is your friend

In IT delivery, we have a tendency to look at risk only to see what might go wrong; The tools, language, and even colours we use all paint an overtly negative picture for risk. We treat risk as an exception, something to be eliminated from our process, but risk can also be a good thing. It can help you achieve a new efficient way of doing something, or develop a new highly profitable product. Yet how many risk management approaches do you see that also have a reward matrix? perhaps it’s time we changed that.

With the introduction of concepts like Bi-Modal IT, organisations are starting to realise that not all risks are created equally. The need to manage elements of the IT ecosystem differently based on their individual risk profiles has led to the realignment of services within. But what about our delivery methods? Would scaling the concepts of Bi-Modal IT down to an individual project, activity or task level even make sense? It seems to work in construction.

What is evident is as we chase the almost mythical alignment between business and IT, we can’t just keep providing a translation service around a purportedly common language. Forward roadmap planning and delivery methods like agile or DevOps will only get us so far without alignment to something that bears a stronger common meaning between all parts of the organisation. Unless our delivery methods are tailored to suit, there will at some level, always be a disconnect.

Ultimately there’s unlikely to be a right way or a wrong way to deliver technology, and maybe our current methods aren’t so bad, but there’s almost certainly going to be a better way. The question is, is the path we are on really going to achieve it? Do we need a ground up rethink on how technology is delivered? or perhaps we just need to look elsewhere for guidance? Maybe looking to the construction industry isn’t going to get us all the answers, but even the aerospace industry has more runs on the board than IT. What harm would it do to stick our head over the fence from time to time to see what they’re up to.