Showing posts with label tempo. Show all posts
Showing posts with label tempo. Show all posts

Friday, October 15, 2010

OrgIntelligence in the Control Room

A control room provides a thin but panoramic view of everything that is going on. The French sociologist Bruno Latour calls this an oligopticon: he describes how Paris is controlled by a collection of separate control rooms, each focused on a different slice of reality; these control rooms may only talk to each other at the margins, or in major emergencies; there is no supreme control room commanding all the others.

"Water, electricity, telephony, traffic, meteorology, geography, town planning: all have their oligopticon, a huge control panel in a closed control room. From there very little can be seen at any one time, but everything appears with great precision owing to a dual network of signs, coming and going, rising and descending, watching over Parisian life night and day. No single control panel or synoptic board brings all these flows together in a single place at any one time." [Invisible Paris, pdf]

Each control room monitors and directs a particular set of systems, and has some responsibility for the smooth, efficient and safe operation of these systems. Except in a fully automated plant, such as a nuclear power plant, the responsibility may be shared with skilled operators and supervisors in the field, such as inspectors and engineers, bus and train drivers, policemen, etc., who not only pass situation reports to the control room (thus acting as the eyes and ears of the control room), but also may have a fair amount of autonomy and initiative to solve local problems, perhaps supported by up-to-date information from the control room or elsewhere. So we may regard the control room as the hub of a larger distributed control system, involving operational people as well as the control room staff.

My interest here is in the collective intelligence of these control systems. As the operational environment becomes more complex and demanding, collective intelligence becomes more and more critical in ensuring smooth, efficient and safe operation. Collective intelligence depends not just on the individual capabilities of the people, but on how the work is organized and how well the various technologies (information systems, screens, dashboards, communication devices) are designed and integrated to support the work. (In other words, we're talking about sociotechnical intelligence - intelligent collaborations of people and technology.)

Organizational intelligence has six constituents, so there are six areas we need to consider.

  • Information gathering - what signals and messages are fed into the control room, and are these sufficient to enable critical situations to be quickly recognized or even anticipated?
  • Sense-making - how well are complex incidents interpreted, and the possible knock-on effects predicted?
  • Decision-making - how well are resources allocated, problems prioritized and solved, operational policies suspended or adjusted?
  • Memory - how well are past situations and problems referenced in solving today's problems and anticipating tomorrow's problems?
  • Learning - how do we continually improve the performance of the operating environment, as well as improving the effectiveness of the control system?
  • Communication - how well do we communicate internally (within the control room), outwards (to people in the field), sideways (to other control rooms) and upwards (to management or other governance bodies)?
A control room or control system may have opportunities to improve in some or all of these areas, and the leverage yielded by such improvements can be very considerable. For example, with a fixed level of intelligence in a traffic control system, it may be impossible to increase traffic volumes without compromising safety. But if we can increase the effective intelligence of the control system, it may be possible to increase traffic volumes: for example, instead of having a standard minimum distance between vehicles, or time between signals, it may be possible to implement a variable rule that is more complicated, more difficult to enforce, but yielding more efficient utilization of resources. The point is that variable rules only work if you have enough sociotechnical intelligence in the control system to manage them properly; the more intelligence you can build into the system, the more variation (and therefore fine-grained and dynamic optimization) the system will be able to cope with.

A control room typically operates on at least three different tempi (speeds).

1. There is a real-time or near-real-time tempo, in which an event triggers an automatic or pre-programmed response, almost like a reflex. These responses are designed according to some pre-established operational model that allows the designer to reason about causes and effects, and should be monitored to make sure that these reflex mechanisms are working.

2. There will be a continuous stream of incidents requiring human intervention. The people in the control room will have to verify what exactly has happened, and then take appropriate action, based on their training and expertise, past experience, as well as practical common sense. The elapsed decision time may be measured in minutes or hours, and the situation as a whole may take days to clear.

3. Then there is a much longer-term learning cycle, where people are constantly looking for more effective ways of controlling the system and improving its performance. This might include analysing patterns of activity and identifying weak signals that would give early warning of possible future incidents, analysing system behaviour to check if the desired outcomes are being consistently met, exploring alternative ways of exercising control, experimenting with design improvements to the technical systems, and so on. The learning cycle may also include occasional crisis management exercises based around a simulated incident, to test the responses to a major emergency. In a rapidly evolving world, this kind of continuous improvement is a vital aspect of collective intelligence, to make sure that the control system maintains its ability to fulfil its responsibilities.

The relationship between 2. and 3. is an interesting one. Sometimes the people responsible for 3. don't actually sit in the control room, and may even report into a different part of the management hierarchy. But although we certainly cannot ignore the formal management structure, the real question here is about the effectiveness of feedback and learning, and in providing as many people as possible with the opportunity to contribute to the learning process, and therefore to the intelligence of the whole system.

Lots of interesting issues here then, both in terms of organizational change and technological change, with the possibility of producing large improvements at relatively small cost.


This is an extract from my eBook on Organizational Intelligence.
https://leanpub.com/orgintelligence/

Tuesday, October 2, 2007

Red Queen Effect 2

Dave Bayless has responded to Critiques of the Red Queen Model, including my comments on this blog (Red Queen Effect, see also Rates of Evolution). 

Dave chooses to define innovation as "launching new products". Both John Hagel and I believe that there are other kinds of innovation that are important. But I have a more fundamental concern with Dave's definition - if I don't know exactly what counts as a "new product", then I don't know how to count them. If this year's model has a slightly faster chip than last year's model, or a brushed aluminium case, does that count as a "new product"? Let's say the iPod is a new product, but is the iPhone really a new product, or just a fancy redesign of an old product?

Lots of people in product development have a vested interest in labelling everything as "new improved". Pharma companies spend a small fortune looking for variations on existing drugs, so they can get patent protection for the "new" formula. But if you take these descriptions at face value, you get a fundamentally distorted view of the underlying technology change.

This is why I think we need a rigorous model of technology change, which handles some of the complications I raise in my previous blog entries.

 


Update March 2022

Following a brief exchange with Dave on Linked-In, I have looked at another of his earlier posts, which refers to the work of Professor Charles Fine on industry clockspeed. 

In a paper written in 1996, Fine compared product technology clockspeed between aerospace (commercial aircraft) and media (infotainment). He noted that Boeing was launching roughly two new products per decade, while Disney was launching one new product per year, and concluding that media therefore has a faster clockspeed than aerospace. 

There are several problems with this comparison. Firstly, it doesn't seem to represent a fair comparison between the true rate of innovation in the two industries. If Disney films are made to a formula, and the basic formula doesn't change, how much innovation does each new film represent? This comes back to the point I raised in my original posts above.

Fine presumed that "Disney's product development teams ... work on a cycle time geared to the time between new product introductions". I don't have any inside information on Disney, and it appears he didn't either but from my experience in comparable media organizations I should expect multiple development teams working in parallel, with the ones doing the most innovative work taking several years to complete something.

Furthermore, Fine also observes that other parties in the Disney ecosystem (notably the distribution channels) have a much faster clockspeed. So he notes that "clockspeed may not be well-defined at the industry level since many industries are composites of others".

For John Hagel and myself, the more interesting innovation in the media industry was not Disney or Pixar churning out blockbuster films, but these firms converting themselves to platforms. But does the platform itself count as a product?

 


Dave Bayless, Is the Pace of Business Really Increasing (7 September 2007), Critiques of the Red Queen Model (1 October 2007)

Charles H Fine, Industry Clockspeed and Competency Chain Design: An Introductory Essay (MIT Sloan WP 147-96, March 1996) 

John Hagel, Disney, Pixar and Jobs (3 February 2006)

Richard Veryard, Technology Hype Curve (16 September 2005), Disney, Pixar, Apple and Jobs (6 February 2006), Red Queen Effect (19 September 2005), Rates of Evolution (3 September 2007)