Minimal IT logo and link to home page
Research, training, consultancy and software to reduce IT costs
Home | About | Newsletter | Contact
Previous | Next Printer friendly
27 March 2012

Evolving structure

By Andrew Clifford

Our job is to create order and structure, not to be constrained by it.

Last week I suggested that, despite what we might like to think, the methods and processes that we use are not typically structured, but that structure evolves as the work proceeds.

I am not suggesting that there is no value in structure or in techniques, and that we should muddle through in a chaotic fashion. Rather, for all but the most routine work, we should not preconceive structures for the inputs or the processes or the outputs. These evolve as the work proceeds, and defining structure in advance can prejudice the work and prevent us fully exploring it as we should.

What actually happens is something like this.

Evolution of structure

Work starts off with an idea.

We then evolve a structure around that idea. The structure achieves the following:

  • It communicates the objective or purpose of the work.
  • It is clearly and unambiguously defined.
  • It is agreed.
  • It is complete, it covers everything it should within its scope.
  • It is efficient or normalised, it represents the work without unnecessary repetition.

Deliverables are created from this structure. These deliverables are actionable or executable in some form, and could be:

  • A plan of action.
  • A changed process.
  • A computer system.
  • A decision or judgement.

Given this model, it is tempting to create a "method" for creating structure. But that would be missing the point. Structure evolves differently in different situations, and it would defy generalisation.

However, there are things that we can do to make the unstructured approach more effective.

We need to legitimise the idea. We are attached to the idea of structured methods, or their agile relatives. We also ought to recognise that for many situations we need a more fluid approach, in which structure evolves. Rather than falsely imposing a predefined structure on this work, we need to accept the situation.

If you look at other professions we admire people for the quality of the outcome. We don't admire Stephen King or J. K. Rowling for their great writing process, we admire them for their books. And yet in IT we hide behind our processes. We need to promote the idea that good IT professionals create structure and order, not that they are defined by it.

We need to think how work can be controlled. The need for control can drive us to inappropriate structures, such as huge project plans with an unrealistic level of detail. Large pieces of work need to be preceded by smaller pieces of exploratory work which define appropriate structure.

We should identify techniques that help. Obviously general skills help, such as writing, presentations, and simple analysis techniques like mind mapping. But other techniques are also good at building structure, such as data modelling and process modelling. Instead of constraining these as part of a pre-defined process, we should see them as a mental toolbox from which we select as the work evolves.

Next week I will consider some ways in which technology can help us make a success of unstructured methods.

Next: Using technology to create structure


To subscribe to the newlsetter, simply send an email to
Privacy policy

Subscribe to RSS feed

Latest newsletter:
Magical metadata

We use the term "metadata-driven" to describe IT solutions in which functionality is defined in data. Taking this to the extreme can provide unparalleled levels of speed, simplicity and versatility.
Read full newsletter

System governance

System governance helps you implement high-quality systems, manage existing systems proactively, and improve failing systems.

Try it for free!

Find out more