If you search my blog, you will see that the last article posted was on March 10th, and focusing on what to do after the emergency resulting from the unrest, to be precise:
I had been preparing for some time an article on logistics- and I obviously postponed it, as it overlapped with the current emergency.
I did not know that it would be followed by yet another emergency- the earthquake and tsunami, with the following longer-term side-effects.
I will postpone again the article on logistics- and focus just on one aspect that affects any human activity: the logistics of knowledge.
First, let’s start with a shared, neutral definition (from the Oxford Dictionaries’ website)
late 19th century: from French logistique, from loger ‘to lodge’
Can you spot the inherent weakness in this definition? It lies within just one single word: complex.
Who is the wise person that decides how complex is an operation?
It requires an agreement on the definition of complexity- and a level playing field on the knowledge about the operation.
Meaning: all those accepting the definition need to have access to the same information required to accept the definition as correct.
Also if, most often, they assume that the others who agreed before them knew better, i.e. they “de facto” informally delegate the decision.
Just imagine what happens when the first ones are just trying to see if their idea is correct, or stimulate the discussion and do not see it challenged… I found myself in that spot as a facilitator in brainstorming: sometimes, it seems that no idea is weird enough- a chilling perspective.
Back to the basics: fixing a door can be simple- if you know how to do it, i.e. if you learned the associated pattern; but if you don’t… you can end up with a larger damage than the one you started with.
Or, at least, with a series of scattered components that you have no clue whatsoever on how you could assemble them together.
But this article is focused on a tiny founding block that is part and parcel of any operation: knowledge.
As knowledge is never neutral, and knowing how, when, why to deliver it, i.e. its logistics, has side-effects that range from the irrelevant to the dramatic.
Adopting a Lego(tm) approach
No issue is too complex, if you know how to part its components.
A lesson that I am re-learning in my Chinese writing exercises, but that I observed in my experience in business since 1986- and before that in other activities.
But there is a risk in disassembling something that is not based on a true/false logic: oversimplification.
In business, I saw often this side-effect when, as part of efforts to introduce computers or other technologies/processes/changes in activities that have been delivered manually for decades if not centuries, instead of observing and listening first, the analyst was asking those involved to rationalize what they were doing, why not even presenting first “the” solution, and asking them to concur.
I will not get again on the issue of rationalization (search this blog for other articles on the issue), save to say: if you want to disassemble a Lego(tm) brick construction, you have first to identify the bricks.
At the beginning of my career, I remember the jokes about the “small technical issues” that made impossible to use or deliver what promised: and, when it wasn’t for changes in the environment (human, legal, technical), almost always it was due to a “tunnel vision”, developed by all those involved, by getting so much focused on the structural integrity of their own solution, to remove any chance that it could be actually survive the encounter with reality.
Lego(tm) bricks are relatively easy to disassemble, but you need to have some spatial visualization ability to position each brick in the appropriate order required to build something new- with a minimal number of steps.
If you have infinite time, space, etc… you can just toss the bricks around, and, eventually, you will get your desired results (probably, with a timespan stretching over an infinite number of years).
- Well? What do you think of my new poem?
- I once read that given infinite time, a thousand monkeys with typewriters would eventually write the entire works of Shakespeare.
- But what about my poem?
- Three monkeys, ten minutes.
Timing and knowledge
Moving from the disassembling and assembling of components, I have to leave beyond the Lego(tm) analogy, and introduce the “time” dimension.
I have been a project manager since 1990, but the first large project budget that I developed was in 1986, and before that I had few instances in politics, computer and book sales, and ghostwriting activities where I “discovered” how time can be critical when you are not the only person involved.
Useful lessons- that I applied, on a larger scale, while I was serving in the Army, and I had to prepare either the daily schedule of services (yes, my first real service management activity :D), and learn what meant to prepare all the appropriate steps required for a training exercise.
But considering what is happening now, my clearest, unforgettable lesson on logistics and timing came out when, after Libya launched missiles on Lampedusa in Spring 1986 (1986-04-15, I was few weeks from ending my compulsory service- yes, Libya right before another nuclear accident, Chernobyl, 1986-04-26), I was eventually assigned to lead one of our Jeep-equivalent.
Well… “lead” is a big word: how can you move something that practically lacks an engine?
We had been on alert for quite a while, usually with few going out, before it was called back stating that was an exercise.
But one day, it seemed that we were bound to leave the barracks, so I said to the guys on my vehicle: get ready to jump and push, if the one in front of us moves, as we have no engine.
And that was timing: the exercise was called off immediately before we too were to move.
Ok- I was supposed to give the order- but I would say “tell”, as I had no rank whatsoever, I was just the guy planning their services and petitioning for their holidays, as I had refused twice to be promoted (easy, if you work in the office: I was the one typing the promotion list, so I could ask to be removed from it…).
In this case, I had the knowledge, and I could have kept it to myself until the last minute.
I knew that there would be time-wasting owls of protest, so I preferred to defuse the situation, so that, when needed, everybody would be ready: we were a conscription army, therefore…
But a gloomier example comes from the Cold War: what is the point of having shelters etc, if the warning time is less than the time needed to transmit the order through the communication chain (my older American friends will remind that old cartoon “duck and cover”)?
Over the last few days we have been flooded with details and information about the issue at the nuclear power station in Japan, and, more recently, the operations in Libya.
A lesson that I applied often in business: having the knowledge implies also knowing what you want to do with it, and monitoring constantly when it is more appropriate, or if anything changes.
Otherwise: it is just akin to those who collect dates, names, etc- so, they can tell you when, where, how somebody relatively famous was born, married, buried… without any insight on what meant what they did, and why they did it- as they felt that it would have been too complex to get beyond their skin-deep erudition.
I have been working with decision support systems and business intelligence and data warehousing since a long time: in plain English, corporate number crunching.
But while often this implied collecting hundreds, or millions of data, the “knowledge” was produced by few simple charts or summary table.
Stockpiling data requires then managing their lifespan, to gain a general overview of what is going on, its trends, and the actual results- and as this implies additional costs, you have to decide how far and how deep you need to keep information.
As an example: in banking, each information attached to a banking account should be relevant and kept for as long as the account exists, plus some legal statutory limits.
But in retail, try keeping just for 12 months all the details available about each unit of each product: technically feasible also on a souped up PC, nowadays (not so just a decade ago), but is it worthwhile? Or could you be a little bit more selective, e.g. keeping some details for days, others for weeks, and others for months?
In my experience: for “reporting” (i.e. stating what happened) the more, the merrier (up to a point, of course: nobody needs to know the colour of the shoes of their employees- unless they want to give shoes as a perk; and see also the example about the retail industry).
For “analysis and insight/forecast” (i.e. why it happened, or what could happen, or what you need to produce the desired results): only as much as relevant.
As a practical example: you can remember the general trend of the news about the current events; or you could also note down the actual details reported each day.
If you live on the other side of the World, and are just an ordinary citizen trying to be informed, probably the first information is enough- also if newspapers report both.
But it is up to you to extract from your sources what is relevant.
And to ensure that you have access at what is needed, when it is needed- i.e. you have access to knowledge that is “actionable” (not like the “duck and cover” I described above).