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.
Work starts off with an idea.
We then evolve a structure around that idea. The structure achieves the following:
Deliverables are created from this structure. These deliverables are actionable or executable in some form, and could be:
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.