Structured Process vs. Drift: A Question of Worklevel?

Forrest ChristianComputers/IT, Managing, Organizations, Reviews - Articles Leave a Comment

Claudio Ciborra, who unfortunately died too early recently, left a rich quantity and breadth of writings on information systems from a sociological perspective. Here I look at one of thisClaudio Ciborra. 2002. “Design, Kairos and Affection“. From Managing as Designing: Position Papers [?], Cleveland: Case Western Reserve University.

… if speed is the main characteristic of this activity, then in many circumstances coping with a faster tempo would condemn the agent to using preplanned, repetitive procedures to keep the performance going. In other words, higher speed may encourage, not improvisation, but a sudden reversion back to old ideas and routines.

What role does drift and bricolage play in development of IS systems? I worked at a very large US-based property and casualty insurance company where their old, outdated mainframe systems had been developed over thirty years of additions, corrections, changes, kludges, and jerry-rigging. They were trying to develop a replacement system in newer technology, since getting COBOL to interface with the web was thought too difficult. They were also having a hard time getting good personnel, since few of the young hotshots saw much of a future in COBOL.

However, their ten-year plan to replace their old systems with a brand-spanki-new one had problems. There were serious concerns that the developers would be able to capture all of the many intricacies that the system had grown (or evolved) over the last few years.

Which all makes me wonder about the role of structured processes (some form of development methodology with a serious of deadlines, etc.) and evolutionary processes, where the social interactions with the technology change it in a variety of ways, every now and then moving it into a new way.

  1. It’s obvious that great systems cannot always simply be replaced. Even some of the greatest developers around have found replacing “home-grown” systems daunting and even impossible. The shere amount of variables that go into them, after years of support programming (which makes up 80% of all development time), surpasses their ability or the ability of their methodologies.
  2. Yet we all need some form of structured plan to get any work done.
  3. Not everything in life that you build is like building a building. And even buildings grow and change over time, as Stewart Brand showed in How Buildings Learn (Penguin, 1994), at least when they are of service to their occupants. I’ve written about this before in an unpublished article (“If Buildings Can Learn, Why Can’t Software?”) from a couple of years back, and I don’t think my mind has changed any.
  4. So there must be some interconnection between planning (the saying that we must do this and this) and improvisation (Ciborra: “a special case of situated action. Quick, sudden and extemporaneous, and highly contingent upon emerging circumstances it acts towards unifying design and action” [Stantz, 2005]).
  5. Improvisation involves having the ability to control your work.
  6. There is a interplay between the need for creativity and hierarchy that Jaques and co. seem to understand better than anyone else.

There is definitely a need for the natural growth of social systems, of which IS systems are but one.

Leave a Reply

Your email address will not be published. Required fields are marked *