Other topics
The conventional approach to deployment flow charts uses a flow chart drawing package, see pp 20-21, Deming's book 'The New Economics for Industry, Government, Education' (strongly recommended, if you haven't already read it).
However in the early 1990's RPS had very limited IT hardware and software and so began specifying processes in what might be termed 'deployment tables'. We used spreadsheets as a way of documenting who would do what, when... to achieve the outputs and outcomes required:
- Column headings name the participants,
- Row (headings) give the timeline,
- Cells are used to document the steps in the process (tasks), see
[Our original technology was the Works spreadsheet (not even Works for Windows) - see Midyear Reporting as an example of the level of detail we manage to included.]
Later we added a checklist column of the quality issues (the things that should be considered when evaluating the tasks in the process). Listing these made evaluation easier, highlighted what was important and move us beyond thinking solely in terms of 'problems' and 'good ideas'.
This approach is now well established. One of its advantages is that we have managed to get each of our major processes onto a single page.
Staff love this way of documenting processes:
- staff have their own column of tasks and
- they can see who does what before and after each of their tasks
- the documents are easy to improve and maintain
- they show (and thus acknowledge) everyone's contributions
- they are useful at all stages of the P-D-S-A cycle
We managed to document each major process on a single page (which we later placed on our intranet) - this made it very easy to maintain the documentation. And we updated each major process immediately after we have used it as part of our continuous improvement.
We also discovered (as you will) that processes took longer and involved more people in the organization than we had originally thought.
Some quality purists have been a little 'critical' of our practices and would advocate moving to conventional flowcharts. This is unlikely to occur. Staff are very familiar with our approach and it would be difficult to change. They are part of the culture.
IMPLICATION: Choose the technology that underpins your practices carefully because changing at a later date may be difficult, disruptive and even unproductive.