27 October 2007

A process can be a problem (sic)

I’ve written often of my disdain for rigid process – I particularly think that a branded or institutionalized process is a poor approach. Those that stand to benefit most from a highly defined, differentiated and branded process are those that intend to write the books, offer the workshops and then the consulting that always seems to follow. A process is rarely the solution for correcting poor results.

Certainly and currently, Agile is amongst the most annoying and of these recent process trends. Side bar: I have also had my fill of the consultancy branded user centered design process as well. It is not that I have anything against user centered design – in fact I am a fan and practitioner. I don’t even have a problem with many of the various brands of Agile other than it once again puts the inmates squarely in charge of the asylum. My problem is with establishing or standardizing process itself.

If the problem in your organization is wildly varying results, in other words, you get stellar output one day and the next is just awful - then normalizing and standardizing the process may help in the short run. If the problem is that your current system never provides the desired results, then you likely need different people or different tools.

The thing about normalization and standardization is that they generally only reduce variability. They rarely address or raise overall success issues. With a standard process you will typically get standard results. That’s great for an assembly line, a factory or any other repetitive deliverable. But if your task is problem solving… if you are designing or creating, then you will likely solving the wrong problem with a non varying process.

Structures, clear goals, accurate problem definition, and a range of tools are better answers for most designers and developers. So often with each phase of a complex project, we are bounding into the unknown. The process must match the problem, the culture and the team. These are rarely the same for designs each and every time.

I would like to propose a new approach to design and development. I would like to call it SIC. Yes, it is a SIC approach. A SIC approach would require that multiple phases of the project be accomplished SIMULTANEOUSLY. And, that the project progress in, of course, ITERATIONS. And lastly, that we all work… wait for it… COLABORATIVELY. Will you be able to mindlessly step through this like a recipe? Doubtful. You will most certainly need to learn the strengths and weaknesses of your team members so that you can assemble the best team for the project. Oh – and add in some due diligence, research, hard work and what is that old clique… thinking outside of the box?