Think global, act local - well actually, just think simple!
It was a pleasant sunny day in mid-spring when I approached the offices of MRI Ltd. I was in a place called Hampton Wick, a pretty Thames-side suburb of London. What a great place to work I mused, as I strolled past blossoming trees. Church bells pealed in the distance. At one with the world, I approached a small office building tucked between Edwardian houses.
The tranquil setting felt like an antidote to my stress of the previous two months. My last job had ended messily when I realised my boss had been embezzling cash from the mother company in France. I pushed all that from my mind as I took a seat in reception and waited for Mick, my new boss, to collect me. On the wall opposite me was a map of the world with the letters D, H, & L in deep maroon, emblazoned across the bottom. For a moment I wondered why the map was in such a prominent position in MRI’s reception. My reverie was broken by a Tigger-like character bouncing toward me. He took my hand and shook it warmly as if meeting an old friend. This was Charlie.
“You must be the new chap starting today?”
I confirmed that I was and that I was waiting for Mick who was to be my new boss.
“Oops…, you’ll wait a while! He’s in Brussels today” Charlie replied, and added “I’ll show you to your desk and get you set up.”
There were misunderstandings in both directions between Charlie and me. The first was that Charlie assumed I was a trainee programmer, when in fact I was joining MRI as a Business Analyst, with several years under my belt. This misunderstanding dawned on me when Charlie explained the role of a trainee. After an hour or two, I felt I’d better clear things up. Trying my best to be tactful, I explained that I’d been an analyst programmer for five years. Luckily, Charlie saw the funny side of his mistaken assumption. I never quite got to the bottom of this as I can’t recall a trainee starting around that time - had she/he got lost?
The second misunderstanding was mine. Now, this is going to sound weird, to say the least, but I didn’t realise that I was joining the world’s largest international air express business. I don’t know how that detail hadn't come up in my interview! My contract of employment was with MRI. All I knew was MRI had offices in Hampton Wick and Brussels.
I asked Charlie why there was a DHL world map in reception. He explained that MRI stood for Management Resources International. MRI was a separate legal entity for tax purposes but at the centre of the DHL family. Its sole function was to be the worldwide headquarters for DHL.
DHL was an unusual business. It had a presence in around two hundred countries with very little top-down control. It was a highly dynamic a meritocracy, where ideas and experiments were encouraged. In retrospect, DHL’s culture provided the environment for fresh thinking. We didn’t know it at the time, but the seeds of Adaptive Change Design were sown through the collective thinking of DHL employees. Together, Mick, Charlie and I were a typical DHL team. Our combined strength being the diversity of our backgrounds & perspectives that produced novel ideas and pragmatic solutions. Mick was a quick thinking pragmatist and energetic networker. On the other hand, Charlie was an enthusiastic ex-British Army Officer with a strong focus on outcomes. And I had a background in business analysis for information systems and process modelling & design.
Skipping forwards to around 1990, I was part of a global team within DHL who had been established to flesh-out the company strategy. I worked alongside other IT and business operations colleagues in a sub-team focused on improving the flow and use of shipment data globally. At the same time, other technical teams were in the process of upgrading distributed computers and implementing a global data network, the largest of its kind at the time. We were deploying Open Source platforms and Internet standard communications globally. DHL was recognised as a groundbreaker in its use of technology.
The first challenge we faced wasn’t the technology. It was reaching a common understanding of business processes and a variety of operational procedures around the world. A large part of DHL’s success and rapid growth, was its light-touch approach to centrally mandated policies. It behaved more like a collection of loosely coupled franchises. Each country operated within a minimum of central rules. ‘Think Global, Act Local’ was the corporate tag line. The customer must experience a ‘global’ service was the only golden rule. While, the local operation was free to operate as it needed. This, in part, explained why there were so many differences country to country, across the globe The more we looked into it the more we understood this was ‘requisite variety’. For example, import processes in Japan were necessarily different from those in France. This was often to meet regulatory needs. DHL knew the importance of getting ‘Governance’ right. It knew too much central governance would stifle local innovation and hinder business growth. Equally, it knew when simple global principles & policies were needed.
One of my favourite examples of these valid differences, was when the US team were proudly demonstrating an in-truck data download solution. When they asked if Hong Kong might want to deploy the same technology, they didn’t expect the answer they got:
“Our couriers don’t have delivery vehicles. They’re taken by bus to their assigned route in the morning and collected in the evening.”
“So, they walk the route?!”, one of the Americans asked , with wide-eyed incredulity.
“Well, not quite. They spend most of their day in the elevator. You see, our buildings are so tall that one or two buildings will constitute a route.”
Although, I didn’t know it at the time, this ability to innovate at the edge of the business yet at the same time, govern the movement of shipments and data globally was to be a model for firms in the Internet age. I led to a different style of governance.
One of our early hurdles was how to document the operation in each country. Business Process Modelling (BPM), was in vogue, so we tried that for a couple of months. The problem was, the country staff trying to create these models weren't familiar with BPM. The result was either a very detailed model, on the one hand, or a high level ‘fat-arrow’ diagram, on the other. Another way was needed. Enter ‘Business Service Specifications’. It turned out this technique worked better than expected. Here are the primary reasons why:
Simple to complete & easy for anyone to understand and contribute.
Quick to produce a first draft that is then improved through iterations.
A description of a Service not a Process - focused on WHAT & WHY rather than HOW.
Capture of key information:
Information Exchanged between services.
Triggering events, failure conditions and responses.
Relevant policies, rules, metrics and procedures.
Business Service Specifications, while easy to complete, proved to be more useful than a typical process models. For example, service failures were more likely to be addressed earlier in the analysis. We also found we could use exactly the same method for describing a manual operation and a software component - both could be described as a ‘Service’.
And in particular, for Design Thinkers interested in the people, process and technology dimensions of change.
Jumping forward again to 1997 when I left DHL. Apart from many fond memories of working with some great people, I felt the tools & techniques I’d played a part in developing would be applicable elsewhere. In particular, one little side project of mine was a simple thinking framework to be used in ‘Business Service Specification’ workshops. It didn’t really have a name. It focused on three dimensions: Policy Event & Content (PEC). This was simply a way to focus discussion on each of these dimensions that helped us to define message types, event triggers and data payload.
Moving on to 2005, the PEC framework and Business Service Specifications proved themselves over and again. I had started working for Capgemini in the summer of 2005. My first project was with the UK Criminal Justice System (aka Department of Justice). It was there that I teamed-up with Carl Bate, and together we created VPEC-T, by adding Values and Trust to PEC .
By 2019 I had gathered several dozen use cases, some my own, but many others from practitioners worldwide. One such practitioner was Matt Pearce an independent consultant who works with international businesses. It was the autumn of 2019 when my phone rang, and it was Matt. After two-way apologies for not being in touch for a couple of years, Matt asked if he could create a variant of VPEC-T he proposed calling VIPER; swapping ‘Content’ with ‘Information’ and ‘Trust’ with ‘Reliance’ .
To cut a long story short, I’ve used VIPER in business contexts several times since. I have to say, I was very pleased when I overheard a client respond to a challenging question - let’s VIPER-it!
The reason I tell this story is to illustrate where Adaptive Change Design came from. It was a result of pragmatic experimentation on a global scale. Looking back, I can see how DHL was ahead of its time.We were unconsciously applying many of the principles of Design Thinking.
Since those days, It surprised me how much Design Thinking has been developed and adopted by the armed forces (John Boyd's OODA Loop for example). Another 'execution' focused logistics organisation. If you are interested in understanding more about the DHL can-do culture and their success focused on simplicity, I'd recommend Ken Allen's book 'Radical Simplicity'. But if you want to learn about a set of tools that embrace the same philosophy across an equally simple four stage lifecycle: SCAN, FOCUS, ACT and REFLECT - then I invite you to explore Found In Design.