More on Operational DNA – Keeping your Documentation Procedures up to Date
“We had some great documentation but it is now out of date from all the changes we made in the past years”
How many times do we put the effort into constructing something only for the projects we run to invalidate it. This is especially the case with operational documentation. Organisations get it in place for a whole host of reasons but so many just ignore updating it when they run a project which becomes a false economy as the update job will happen at some time. Once they are established in a job, the organisation forgets that useful asset and ignores it when they make changes to the way they work.
When we look at a typical change project it usually delivers a combination of three things: changes to operational procedures, changes to software or systems configurations and changes to physical assets and/or hardware. Traditionally, the financial disciplines have forced organisations to keep their asset registers up to date every time they change (although I am sure we all know some companies who do not know what they own and where it is!). The rigours of updating asset databases, lists, recording moves and changes is now normally part of all business change projects as well as operational improvement initiatives. Likewise, most organisations now have a fairly well established software development lifecycle with code control tools and developers workbenches taking the software through a lifecycle from initial draft ideas to final released versions.
But what about operational documentation? Many many organisations fail to apply the same version controls and quality processes on this vital resource as they apply in the software and physical asset world. Documentation is in effect software – in the same way as computer code is the instruction set to get work done – operational documentation, if correctly applied and updated, is the instruction set of the way the work is really done including the vital human element. We can apply the same disciplines to the documentation set as we do with software. The same basic techniques of defining a standard lifecycle, from draft through checked to assured to ready for release to live to applied version control, can be used for documentation in the same way as for code. Tools like Business Optix allow users to plan these life cycles and manage their procedures with the multiple versions needed to handle change. For all change projects, three vital documentation elements should be in place:
Next time you are starting a project, ask yourself if your organisation is actively managing one of its most important intellectual assets – its operational procedures.