Wading through yet another complicated methodology the other day, my mind started to wander. Why are some of these documents so hard to understand? Why so repetitive?
Process complexity happens by accident
And I knew the answer really: the thing starts as a simple approach, and then gradually collects accretions rather like a stately ocean liner gathering barnacles, or a simple house getting extended as different families move in.
Little changes are made here and there to accommodate various special cases. Whole sections are added because of the need to think about accessibility, or to conform with ISO 9001, or because the organisation has adopted a new project management process.
Gradually, the original clarity and simplicity becomes complicated and verbose. The people using it stop looking in the actual document and instead, work to some vague approximation of it that they recall from their training a year or more ago. Corners are cut, projects do things differently for no good reason, and the fine methodology has become shelfware. Until one day, someone demands an audit and there are red faces everywhere.
In a negative plan, you say what you won’t do
So, what to do? How can we breathe continuing life into the methodology, quality process, planning procedure or whatever?
My suggestion: the negative plan.
No, it’s not a plan for making things go wrong (although we’ve all seen them). A negative plan is a project-specific document that states where the project is going to deviate from the mandated process. (Or, for process, read methodology, procedure or whatever. I’m going to stick to “process” from here).
The deviations can include omitting whole sections – or even, if you can persuade management and the client to agree, the negative plan can simply state ‘we are not going to follow X process at all’. I never managed to get one saying ‘nothing at all’ signed off, but the possibility is there.
It’s more fun deciding what you won’t do
Somehow the task of flipping through the process documents and deciding what doesn’t apply is less onerous than its opposite, creating lists of what you’ll have to do in a project that doesn’t have enough time or resources anyway. Often large chunks aren’t appropriate: not relevant in this case, only needed for much bigger projects, already done on the previous project for which this is an extension. Fairly rapidly, you’ve achieved these good things:
- reminded yourself about what the process really entails
- removed some unnecessary stuff from your lists of tasks
- allowed yourself to concentrate on the parts of the process that really do matter for your project.
And if you find that there is some part of the process that is rarely important – bin it! Cutting out a section from these complicated documents is deeply satisfying – and gets brownie points from the auditors because it shows that you’re thinking about the documents and actually using them.
This article first appeared in ‘Caroline’s Corner’, in the June 2003 edition of Usability News.
featured image by Port of San Diego, creative commons