Insights

Is your IT Delivery Factory delivering?

02 Nov 2011 Agile Methodology, Business Intelligence (BI), Consumer Business

Why do seemingly sophisticated organisations buy into the idea of an 'IT Delivery Factory' when their design and build methodology is barely from the 19th Century, let alone from the 21st?

Following the recent death of Steve Jobs, I've been inspired to follow the example he set us, and look around the world at the very latest and best design, manufacturing and production technologies to see if there is something that we can learn from them.  One doesn't have to look too far to see some truly awesome examples of human ingenuity and expertise.

For example, aeronautical and motor racing teams are already making use of 'rapid-prototyping' to build production components in materials such as laser sintered Titanium.  With these technologies they can get from conceptual to final product design in a matter of hours.

Lockheed's Ben Rich showed a long time ago that you could build legendary aircraft such as the U2, the Blackbird, the Stealth Fighter and bomber from a tightly organised 'Skunk Works'. You can buy into this rapid design philosophy in just a few seconds. Check out this book.

Taiichi Ohno of Toyota taught the world how to build a car in around 10 hours using 'Just-In-Time' processes.

Zara is forcing the pace in retail with 'Fast Fashion'.

Over the last twenty years in the UK, we have adopted modern manufacturing techniques such as Kanban, SMED and Kaizen.  As a result, plants such as Nissan's in Sunderland; BMW Mini in Oxford; Ford and E2V in Essex; and Halewood in Merseyside are some of the most efficient and productive in the world.

Given that the UK has achieved all this in the manufacturing of physical products, it seems very strange to us that world-class companies that use SAP are being sold a Delivery Factory process that in our experience looks a bit like a very slow, linear, manual production line that goes like this:

The Delivery Factory process, as commonly seen by Bluefin Solutions

1. A business user has a new requirement: perhaps for a complex dataflow with new business logic in a new existing report; perhaps just for an additional characteristic in an existing one.
2. The business design change first has to be documented in laborious detail and then approved by a process design council or some such
3. Some kind of architectural decision has to occur, even though in some cases that the author has personally witnessed, the architect is too overloaded with documentation to properly understand what is being signed off.
4. The change is eventually approved and a budget to carry out the change is agreed. The budget is nearly always very significant, because there are always many more steps required to deliver the change.
5. The change is scheduled to go live at a point in the far distant future, to allow for all those steps; the change may not be available to the business for several months, even if it's just for an additional characteristic.
6. A functional specification has to be written, often by a 3rd party; and with resources that seem suspiciously inexperienced. The functional specification usually consists of the original business change document with a different header, contents page and some intimidating technical jargon.  The 'Delivery Factory' process mandates that the functional specification is signed off by the business user.
7. Mostly because of the intimidating technical jargon, the business user really can't be sure that the functional specification covers the original requirement, so relies on the 3rd party to have confidence that it will deliver. Time may be running short to review the document properly, or there are contractual clauses that drive an assumed sign-off, so there is pressure to simply pass the functional specification onto the next stage to meet the release schedule.
8. The functional specification is passed to the 'Delivery Factory,' where it's usually not understood, although no one will admit it.  Maybe the factory is in a different building, city, country or continent so communications aren't straightforward.  Perhaps the person that used to really understand the relevant process area has just left for a better job and the services contract for the factory hasn't covered that eventuality properly.  There are many reasons for failure at this point but I fear that I may not have seen them all.
9. A technical specification is written by someone in the factory who is making the best of a bad job, and this goes through one or many layers of approval.
10. The technical specification is eventually passed back to the person who wrote the functional specification.  What have honestly been seen at this stage are examples of poor documentation such as this: 'some tables will be written to, with the data that has come from the source.'

What is eventually delivered by a Delivery Factory?

I really can't continue to describe all the processes typically required in a Delivery Factory, even though I haven't started on the build, testing and cutover phases yet.  If you have seen a Delivery Factory in action, you'll probably recognise it from the above description already; and I would suffer from repetitive strain injury and want to gouge my eyes out with a spoon before I finished typing out the hundreds of steps required to actually take a solution live... that's if it ever does go live.

With enormous amounts of effort on multiple client sites, Bluefin Solutions has rescued critical developments that have been partially delivered using the above model and I can confidently say that it truly doesn't work. The only way that we've seen anything made to work using a so-called 'Delivery Factory' process is through one or more of the following:

• The business user has escalated a functional defect until a developer is relocated from the Delivery Factory to sit physically alongside them and build the solution side-by-side.
• The Delivery Factory process is bypassed completely and another 3rd party (sometimes, but not always, Bluefin Solutions) is brought in to sort the whole thing out.
• The business user just decides it isn't worth the effort and lives with a workaround that has been built as a fallback.
• The business user follows the official Delivery Factory process around and around and around until something sort-of useable emerges, at an often staggering cost.

So if the Delivery Factory doesn't work, what does?

What I know for certain is that it's possible to take genuine inspiration from modern manufacturing techniques in the delivery of superb IT solutions for highly demanding clients; because this country still sets some of the world's highest manufacturing benchmarks and Bluefin Solutions want to follow suit.

When you speak to an expert who can confidently work within a structure that allows efficient and high quality IT delivery, the solution delivery process should run much more like this:

1. The customer brings a new requirement to an expert, who listens carefully.
2. There is a business change framework in place to allow for small, medium and large changes to occur with appropriate governance, and an agreed call-off budget to ensure that the change process is streamlined. Because 'small' changes really are small, the budget required is much more reasonable.
3. The expert is empowered to build a prototype in a sandbox environment, supported by latest generation accelerators and appropriate automation.  In some cases, and with the right controls in place, the prototype can be built directly in the productive environment.
4. The customer can quickly test the prototype and suggest a few tweaks here and there.
5. The expert, or even the customer, can adjust the solution and after some final testing it is documented, ideally automatically.
6. The documented solution is approved by a design authority because such governance is not optional.
7. Where required, solution build is done pragmatically and flexibly.  Sometimes a single configuration tweak can be done quickly and locally; sometimes thousands of lines of code have to be written remotely by one-shore resource.
8. Testing and integration testing is done in a similarly pragmatic and agile way; with minimal process and optimal control.
9. The solution is taken live within the shortest possible time that the customer's change process can allow.  This is often beyond the expert's control and we've usually found that this is because the SAP transport strategy is managed by yet another 'support factory' that the customer has been sold.
10. When the solution is live, it performs exactly as the customer expected it would.

Compared with the earlier delivery model described, I would like to say that the customer is always ecstatic with the engagement, but you probably wouldn't believe me.  Let's just say that they're reasonably satisfied with the outcome.

IT manufacturing from the 21st Century, not the 19th

Efficient and high quality IT delivery should have very close similarities to modern manufacturing techniques.  When Red Bull competes with McLaren in Formula 1, we see two closely matched teams turning around high quality software and engineering developments in hours, or at most days.  They do this with local engineers and facilities in the UK and use rapid prototyping and production technologies to phenomenal effect.

When it comes to ensuring high quality and short lead-times, proximity to one's customer is critical and it's not just high-end motor racing teams that have come to this conclusion - European toy manufacturers such as Playmobil and Lego have both experimented with, and then rejected, more remote manufacturing in their operations.

If we look closely at the highly unproductive model that is sold to clients as a 'Delivery Factory,' what is often seen is a mechanism to convince clients that large amounts of billable activity is occurring, whether or not such activity is actually delivering anything of value; and the whole model is based upon an outdated vision of low value-add mass production on an ancient assembly line. 

The high initial investment to set up and run such a facility typically creates all kinds of perverse economics around the implementation of small changes.  Often, if the Delivery Factory underperforms, some contractual term can be brought to bear to enable the factory delivery partner to push costs back upon the client or keep the factory open when the client is desperate to move to a more efficient, or higher quality mode of delivery.

I believe that excellent IT delivery shouldn't follow such a Delivery Factory model at all, or at least not a factory with the kind of processes described in the genuine examples I quoted above.

Excellent IT delivery should use the methods and follow the path that modern product manufacturing has blazed for us in the last 20 or so years: Automation; Just-in-time; Cellular manufacturing; quality circles; small teams; continuous improvement; fast cycle times; single-minute-exchange of dies; higher throughput; better value.

If a client concludes that a Delivery Factory is the way forward, they need to ensure that it operates not with a 19th Century manufacturing philosophy, but with a 21st Century one; and when I've seen such a modern IT factory delivering effectively, it's had the name Bluefin Solutions attached to it.