Sunday, February 22, 2009

Writing down (or up) what you do

Once you can say what you do and do what you say you do repeatably, you are ready to start documenting what you do.

But why? What if you get run over by a bus tomorrow, how will the person that ends up doing your job know how to do the job as well as you have learned to do it? In addition, in order to grow the business, more than one person needs to know how to do a job to keep up with the demand of a growing company.

Start simple! Start with a simple check list as an aid to make sure that the steps of clear, complete, and the ordering. Once you are sure that you have the right information, you can continue to expand it into more of a guide. Note that the amount that you write should depend on how frequently you have to rewrite it. Change is inevitable and increasing at an alarming rate.

Note that it is important to use the concept of a "Guide". Each person that uses the guide will add their own way of doing things to accomplish the same end results and each project may require a slightly different use of the guide. Thus the reason for calling it a "Guide".

Once you can document what each person does then you are ready to document the interactions between their roles or the dependencies in the processes between individuals. Note that usually there is some level of information or physical result that is passed between the individuals, some times referred to as a "deliverable". Eventually you need to document what these deliverables are so each person is clear about what they need to provide and what they can expect from the other person. Note a diagramming technique called "swim lanes" may be very helpful here to get down the high level process between organizations. [http://en.wikipedia.org/wiki/Swim_lane]

In order to keep the complexity manageable, each person maintains a written process for that role. To be able to manage the complexity between roles, just the dependencies and deliverables between roles should be documented in a higher level document. This way the lower level role processes can change without having to change the higher level document so long as they don't change the dependencies or deliverables. [http://en.wikipedia.org/wiki/Business_process_modeling]

At this higher level of abstraction of the dependencies and deliverables between roles, the number of items to track can be measured in the hundreds. It may be useful to form the dependencies and deliverables into group sometimes referred to as "stage"'s (or phases).

Note that you will need to also start to document a consistent terminology that everyone agrees to so that they can understand what the written materials mean.

Note also that the proof that a documented process has been internalized by an individual is to have them teach it to someone else (and basically run off at the mouth about the documented process).


Note that it is really hard to measure accurately and see historical trends until you have can write things down. The information that you can have written down in such a fashion as to aid your analysis later will determine the level of optimization that you can achieve. In order to do this, you need to consider the tools that you are using and how they will be used at the next level for "Racing".


Also if you have written it down, there is a less of drag on you by new employees since they can read (then do) what you written down to do.


This also accelerates getting new personnel up to speed as fast as possible by handing them a doucment on the first day of work and say read and do these things first. New hires will feel less lost in their new environment if you have a check list of things for them to do in what order to get up to speed.


You are now ready to "Run".

No comments:

Post a Comment