Best Practices for Process Documentation: Iterations (2 of 3)
Last time, I wrote about checklists, and showed the example of the B-17 preflight. Simple, fits on a single page, and hits all the critical steps, in just the right amount of detail. Plenty of processes in the IT department are made That Much Better if they are accompanied by detailed, effective Process Documentation.
Of course, that's all motherhood and apple pie - everyone agrees that the existing checklists are great. But how do you get started? I mean, assuming you can get the techs to agree to create documentation - how do you keep them motivated when they realize that the finished documentation will probably run to over 100 steps on multiple pages?
There's a really simple trick to make process documentation easy - and we'll steal it from the Agile Development teams. Time box your process documentation task; for example, you could schedule 1-2 hours before the work starts to develop some documentation (create or add to existing). Then get your work done ... and plan on another hour or two afterwards, making updates based on what you just experienced. Don't spend more than an hour or two - document what you can, then stop and get the work done.
You won't be finished, of course - but that's the beauty of electronic documentation and iterative development. The first step of any process is always "make updates to the existing documentation". You only have to start with a blank sheet of paper once - the first time. Each time you go through the process, you update the documentation - it will only get better.
Previously ...
Of course, that's all motherhood and apple pie - everyone agrees that the existing checklists are great. But how do you get started? I mean, assuming you can get the techs to agree to create documentation - how do you keep them motivated when they realize that the finished documentation will probably run to over 100 steps on multiple pages?
There's a really simple trick to make process documentation easy - and we'll steal it from the Agile Development teams. Time box your process documentation task; for example, you could schedule 1-2 hours before the work starts to develop some documentation (create or add to existing). Then get your work done ... and plan on another hour or two afterwards, making updates based on what you just experienced. Don't spend more than an hour or two - document what you can, then stop and get the work done.
You won't be finished, of course - but that's the beauty of electronic documentation and iterative development. The first step of any process is always "make updates to the existing documentation". You only have to start with a blank sheet of paper once - the first time. Each time you go through the process, you update the documentation - it will only get better.
- A very complex, step-by-step procedure gets a bit more detailed with each iteration
- Examples, exceptions, and critical dependencies get called out after you "get bit" - and you never make the same mistake twice
- Lessons learned at the end may shift around the order of events - improving quality, speed, and minimizing downstream freak shows
- Add checkboxes, page numbers, and space for follow up notes. Make the printed directions a working tool, a piece of paper that helps capture new learnings and process changes for next time.
- Add a spot to capture start/stop time or durations. Build up a history of time data - this makes it easier to estimate ETA, scheduling the event, lining up resources, etc.
- Rework the process document to function better on your corporate intranet - eliminate the need to print and distribute.
- When vendors introduce new versions of software, new features to implement, you'll be ready to incorporate those changes into your documen.
Previously ...
- Look your best with little effort - Excel, Project VBA for Page Formatting (June 11, 2006)
- Documentation Redux - a Shorthand Proposal Framework, and the PMO Surprise (July 30, 2006)
- The Law of Large Numbers - or, why Enterprise Wikis are Fundamentally Challenged (September 26, 2006)
- The Iron Triangle - Quality is a Feature that We Choose to Omit from Projects (October 28, 2006)
- Driving Participation and Contributions on Internal Blogs and Wikis (July 7, 2007)
- Optimizing the Wrong Part of Knowledge Management (March 16, 2008)
Technorati Tags: best practice, business value of IT, collaboration, documentation, Knowledge Management, operations, tech management,
Labels: business value of IT, collaboration, documentation, hands on, Knowledge Management, people management, tech management
posted by James P. MacLennan at 9:26 PM
| Permalink
| 0 Comments
