- In search of one piece flow
- Value Stream Mapping
- From Worst to Best in 9 Months
- Using CFDs
- Regular Expressions Tutorial Table of Contents
Notes on stuff
I think I’ve just caught myself out in a “one rule for me, another for you” attitude over something… A conversation across several blogs made me realise that I was facing both ways on an issue and hadn’t acknowledged it – oh the power of the internet!
Earl Mardle posted about Information Architecture as Scaffold based on a conversation with Ton (More on Ton’s position here). The gist of the view expressed by Earl and Ton is that all this “knowledge” that companies are seeking to “manage” is really only accessible through relationships, and once the relationship is established then the information that was part of the initial exchange is no longer relevant:
And that, my friends is what information does; it provides the scaffold that bridges the gap between people. A bridge that we call a conversation. And once you have built the bridge, you can take away the scaffold and it doesn’t make any difference, the conversation can continue because it no longer has any need for the information on which it was built, it has its own information; a history of itself, on which to draw and whenever the relationship is invoked, it uses any old bits of information lying around to propagate itself.
Earl then expands his view that in the real world of work, when you need to create some kind of output, you do it based on your own knowledge and the knowledge of your team, rather than through re-purposing some previous piece of corporate “knowledge”.
Several of us joined in the conversation in support of the view – in particular I made the point that the key thing that stands in the way of re-using the typical corporate knowledge artifacts (i.e. documents) is the lack of contextual information about why they were created in the way they were. A good provider of context would be a record of the conversations that happened around the document creation (e.g. through blogs and wikis) but that is still too difficult to add on if it requires people to learn new tools.
As a good counter to all this virulent agreement, Taka disagrees strongly with the concept of information as scaffolding around conversations – in his view the information is the conversation, the scaffolding is the network of relationships that enable the conversation. That’s probably a difference of opinion over the meaning of words, where it gets interesting is what Taka goes on to say:
This is what I call the McDonalds question: how do you get low-skilled, inexperienced trainees to consistently produce hamburgers and fries to an acceptable level of quality? Process. And it’s the same thing in a corporate environment: how do you get people, who generally don’t really give a toss about what they’re doing, to write proposals and reports and all the other guff to an acceptable level? Document templates and guidelines.
Coporate KM and other such initiatives are our typically short-sighted attempt to find technical solutions to what is actually a people problem. There are plenty of people selling solutions and processes and methodologies to “fix” the information management issues that exist within companies because it’s an easier problem to tackle than the real underlying issue: how do you get people to actually give a damn about what they’re doing?
Which Earl extends and restates;
Underlying what I was talking about in the other post is to make explicit that very fact; organisations that think of their people as fungible will be lead inexorably down the path of document management and “knowledge capture” solutions that will not help them survive, and they don’t deserve to.
The kicker for all this came from Euan Semple the other night who told me about a company rep who asked him, “how do you stop corporate knowledge leaving with the person?”
So, to reiterate a point that might have been a bit buried in the verbiage, organisations with a future do not need KM systems because they have active, engaged people who know what the hell they are doing.
And that is where I did the metaphorical forehead-slap.
Because I’m all for work practices based on conversation and shared context where they involve me or my colleagues – of course we are wonderful knowledge-workers who thrive in such an environment! But, as I realised, when it comes to speaking with suppliers of IT services, or designing how our organisation should inter-operate with their organisations, it’s always about process.
In part that’s about how they work, and when I am in that purchasing role it’s not directly my concern about how they can deliver good consistent service to the company I am representing, rather a matter of being sure what they deliver, but I’m sure we throw out quite a lot of baby with that bath water. We struggle to find ways of getting the sort of human, responsive service we want at a price we are prepared to pay.
So why is this a problem? The clue is in the words I used – “good, consistent service”. The whole world of out-sourced services companies is about consistency. The way services are usually measured – “x% of faults fixed within y hours” – is about aggregation, statistics, removing variability. The companies who supply these services, in their turn, are looking for ways to meet those contractual arrangements that allow them to make a profit. The major costs in any service are the people who deliver it, so inevitably there is downward pressure on salaries and a drive to make everything a process that can be automated as far as possible.
In that sense, modern out-sourcers truly are the last bastions of Taylorism. Almost as a foregone conclusion, there is low job satisfaction in these bastions of “service”, leading to high turnover of front-line staff, leading in turn to increased management pressure for process and consistency.
I think there are several conflicts at work here:
The simple answer to all of this seems to be “work in small teams” and only use small suppliers, but it’s not clear to me how that scales. When I think about small teams, I can see how a wirearchical approach works when there are several companies involved (in the limit, several individuals), but again, I feel various mental blocks when I think about scaling that. I’m still struggling with these, and other dichotomies, which is probably a good sign that it’s time to draw the CRT! Food for a later post I suspect.
Clarke Ching points to Network Rail’s document Consultation On Capacity Study For East Coast Main Line [PDF, 546kb], which documents a Theory Of Constraints approach to managing resource capacity – in this case on a strategic rail route.
Clarke quotes the introduction which sets out the way the methodology was adapted, within the body of the document there is more on how they assessed capacity at the various constraints along the route.
Another quote relates to how the first list of probable constraints was found:
The starting point of the analysis was the selection of the potential constraints to be considered. A draft list of locations to be studied was produced using Network Rail’s detailed working knowledge of the East Coast Main Line. One approach has been to discuss potential issues with the Network Rail Timing Specialists who have a timetabling responsibility for the area of interest. Commonly they have been asked ‘which location / locations are likely to prove problematic?’. One of the tenets of the ThOC is that the over-riding constraints will be widely recognized. The locations selected for analysis have been discussed with each of their operators and they have each indicated their agreement. It is reassuring in this respect that the locations studied to date feature prominently in the responses of consultees to the applications.
Although the document is 85 pages long, I think it is worth at least a skim as an example of application of the approach to a new field.
What seems especially valuable to me in this example is the evidence that even in the complex multi-company and government environment of the UK railways, the use of a logical approach such as the Theory Of Constraints was capable of gaining support from the parties involved.
It is this aspect which, I think, points to the wider usefulness of the example as a learning tool which may point to new areas where application of constraints thinking could be useful. For example I can see possible application in the media production industry where application of digital networked techniques to complex supply chains will inevitably lead to contention over common pieces of infrastructure.