20 March 2012

Unstructured methods

By Andrew Clifford

In IT, we like to think that our work is structured, but often structure only evolves as the work proceeds.

The typical IT mindset is very attached to structured methods and defined processes. We all like to know what we are doing, and having a foolproof recipe for success is very reassuring. Despite the complexity of our subject, structured methods and defined processes let us deliver "repeatable magic". For many parts of IT we have well-defined structures and processes, for example for project management and application development.

I fear, though, that the appeal of structure and definition blinds us to its limitations. Although we aspire to well-defined processes, we know that we rarely follow our own standards. We always cut corners in projects. Very few organisations could claim that their processes are as mature and effective as they would like. Hardly anyone complies to "official" standards. As an industry, we know that we are not very good at the broader parts of our roles, such as business cases and feasibility studies.

Despite not living up to our own structures, we are tempted to apply our familiar structures and processes to situations where they might not be appropriate. And we recognise that this problem occurs. We turn to IT solutions too soon, before we have fully understood business problems and opportunities.

To summarise the problem, there is a mismatch between our structured methods and the context in which we apply them. This can take many forms. It may be that we are applying the method to the wrong situation, for example applying an application development method to a broader business problem, before we have established that application development is appropriate. It may be that there is a mismatch of maturity, attempting to follow a method that requires more discipline than the organisation is prepared to take on. This is particularly true of iterative methods, which require a high degree of maturity to deliver benefits.

In reality, our working practices are usually unstructured. We do not work with defined, structured models, and we do not follow defined processes. We muddle through using multiple unstructured tools, such as documents, presentations, spreadsheets and mind maps, to explore and explain the situation. We constantly evolve our own "unstructured methods" for our work.

I think we need to recognise this situation. If we are honest, we rebel from structure as much as we crave it or aspire to it. And we know that our methods often do not fit the work we have to do. Perhaps, instead of constantly repeating the mantra of defined methods and processes, we should understand more about how we really work. Structure is not something we start with, but something that evolves as the work proceeds.

Over the next couple of weeks I want to explore this concept of "unstructured methods". I am not sure there is a simple answer, but we do need to think about how we can approach work in a more honest and realistic way.