Evolving structure

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:

• 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.

© Copyright 2012 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Unstructured methods

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.

© Copyright 2012 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

No OS for old men

Commercial software can be hard to learn, but free software can be hard to remember.

A few days ago I was working with a colleague reconfiguring a Linux server. We needed to change the network configuration, and because it runs as a virtual server, we needed to make changes to the underlying Xen virtualization configuration.

When we started we drew a complete blank. Although we had set the server up, we couldn't remember at all what to do. But examining at the server, we understood why. It had been running continuously for 688 days. It was a long time since we had needed to do any work on it, and we, with our middle-aged memories, had simply forgotten.

Contrast this with the chaos that is my PC. To prepare materials for clients, I reluctantly had Microsoft Office 2010 installed a few weeks ago. I have used the open source OpenOffice.org/Libre Office for some years, and earlier versions of Microsoft Office for ten years before that, but I had never more than dabbled with the new style Microsoft Office 2007/2010.

If you are used to a more "traditional" word processor, then Office 2007/2010 is a nightmare. Maybe some people find it more usable, but to my perhaps warped sense, it is a mystery. As a casual user, I spend ages searching for the correct options in the "improved" menus, and the rest of my time fighting the writing "aids".

I could give more examples. Some software just does its job quietly for years, so much so that you will forget how it works before you need to change it. Other software is constantly changing, and you are constantly fighting to remain up to date.

At the risk of generalisation, free and open source software tends to stability. Open source software comes into existence for a variety of reasons (personal and commercial) and is developed up to a point at which it "does the job". After that there may be some widening of functionality and deepening of options, but there is little to be gained by introducing major new ways of working that will just antagonise your user base.

Paid-for software is different. There is a danger that users will just continue to use old versions of software, and software revenue will dry up. To counter this, software vendors have to innovate. This can create valuable new features, but if there are no valuable new features to add, the marketing department will dream something up. Users are encouraged to "upgrade" to a "better" version, but may just be paying for change for change's sake.

I do not have any objection to commercial software, but neither do I see it as fundamentally better than free software. With commercial software, you may have to upgrade to new versions for the supplier's benefit as much as yours. It is expensive and disruptive, and forces you to relearn. In contrast, free software can be very stable.

So remember, if you install free software, make some good notes. Because you may have grown old before you need to touch it again.

© Copyright 2012 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Going exponential

Successful businesses are based on growing the value of assets.

If I am honest, I am not much of a businessman. Like a lot of people with a technical background, I don't feel at home in the world of commerce and deal-making. I haven't really adjusted to the idea of asking people for money for what I do.

But I do have one idea.

Looking around at businesses and individuals who have been successful, there are many different routes to success. But one thing that nearly all these routes have in common is that success has come from ownership.

This applies to all types of wealth. The entrepreneur who owns their own business. The shop that owns its brand and operations. The singer who owns the rights to their recorded work. The lawyer who is a partner and owns a share of their firm.

From what I can see, the key to success is to create and grow an asset, and then extract value from that asset.

This is very much the approach we have taken in Metrici. We aren't the most worldly of organisations in some respects, but we have a very clear idea of our high-level business strategy. We are trying to create and grow assets: software, materials, client base, partnership deals. This strategy drives what we do. We always try to grow the assets owned by the business rather than merely sell our time for money or to make a margin on putting deals together. We have worked to make our product offer and business model scalable, so that we can cope with growth.

What particularly attracts me about asset growth is that the rate of increase is exponential. The more you have the faster it grows. Even if you start with nothing (as we did), if you constantly create and grow assets, your business will grow. Initially, growth will be so slow you won't notice it, and there is a temptation to go off and do something more tangible, like sell your time. But gradually the speed of growth will increase, until you can see it grow every day.

We are just beginning to notice this exponential growth in Metrici. At a technical level, the materials and solutions we have built in the tool are coming together to build a more compelling whole. As more of the jigsaw puzzle of functionality is completed, our rate of development is increasing. We are adding functionality in a week that would have taken a month last year.

More significantly, we are beginning to land large deals. We have partnered with a couple of organisations, and are winning bigger and bigger deals with them. Each of these deals has the potential for larger downstream work, and most significantly of all, the work we are doing for current clients can be repeated many times over with others. And we have lot of potential work in the pipeline.

It is a difficult thing to get used to. What seems like just a few weeks ago we were plodding away quietly by ourselves. But now we are busy, and getting busier every day. It is difficult to keep up at times, but it is a challenge that we must, and will, rise to.

© Copyright 2012 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.