Lately, I’ve been in to identifying the processes that make up the majority of my daily activities and getting them all down on paper (electronic paper that is). I currently have a group of developers who work for me, and while we’ve enjoyed some success, I can’t help but think that we would be that much more successful if we could consistently duplicate our successes while re-evaluating or eliminating the processes that have produced less than stellar results.

Why this may be important to You

The purpose for documenting processes is to optimize, automate, and more consistently reproduce the successes that you or your team has each day. In other words, try to identify things that you find yourself doing repeatedly at work, in your business, or personal life and document the steps that you take to accomplish these types of tasks. Once you’ve documented the process for accomplishing a particular task, review the process steps with a peer or friend and try to think of ways that you might optimize or more efficiently accomplish the task.

If you define your process in enough detail, you’ll ideally end up with a task that can be outsourced. That means a task that can be turned over to someone else all together for execution (e.g. co-workers, employees, kids, partner, virtual assistant, etc). The idea is that you work your way through all of your regular processes, optimize them, and then turn them over to others for execution. This should leave you with a lot more time to focus on the most important aspects your work, business, or personal life.

How to start?

Of course, the difficulty with documenting any large and/or complex system (like your life, work, or business), is getting started. When I approached it, it seemed so huge that it was difficult for me to just take the first step. My general philosophy when it comes to things that are overwhelming is to “do something… anything,” just to get the ball rolling. So I decided first thing Monday morning I’d start documenting whatever I happened to be working on and just see how it turned out.

Steps for Process Documentation

First, before we get started, I thought that I’d give you the run-down of the general procedure that I used for documenting my processes. I think that they are general enough that they could apply to most anything that you might run across.

1. List the steps involved in accomplishing the targeted task.
2. Review the process steps with a peer and ask for feedback.
3. Ask a peer, your employee, or partner to execute the process on their own as a trial run.
4. Evaluate the results realized by your process.
5. Revise your process and redo steps 1-5 until you are satisfied with the results the process produces.

Now Back to My Story

There were two processes that I targeted for the trial run. The first was our development team’s Iteration Tasking Process. This is the process that we’ve followed in the past for taking the stories that are defined as part of our development iterations and tasking them out so that work can begin on them. The second process that I tackled was the New Employee On-boarding Process. This is the process that we follow when a new developer is hired.

I wrote the first of the two processes, the Iteration Tasking Process, down prior to the Iteration Tasking meeting that I hold at the beginning of each iteration with my development staff. I first explained my purpose in creating the process, then I took them step-by-step through the process to orient them to it. I also gave them the opportunity to provide feedback to the process and if we all agreed that the suggestions made were good, we incorporated them right then and there. Once the process review was complete, I assigned each of them a story to task, instructing them to follow the process as closely as possible, and turned them loose. We planned to reconvene in a couple of hours to review the results. The results of the first execution of the process steps were mediocre and it was obvious that there would be some growing pains while the development staff got used to the idea of the new process. It also identified some deficiencies with the process where further elaboration would be required to be able to achieve the level of consistency that was desired. All-in-all, I chalked the test run of the Iteration Tasking Process up as a success. We not only defined a process that we could all live with but the process of evaluating and refining the process had already begun to improve it. A good first step.

Phase two of process testing was the New Developer On-boarding Process. This process happens to be complex because my development team works as government contractors (many, many forms and signatures). Luckily for this particular process, I had a good starting point: one of the team leads of one of the other groups had already created an on-boarding document with many of the required steps already included. So, I grabbed the document from her and started down the path of creating the New Developer On-boarding Process. This is one of those process that isn’t necessarily performed very often, but, if you don’t know what you’re doing when you have to perform it, it ends up taking a lot of time. The final test of this process will not be performed until Monday morning of next week, so the jury is still out on that. However, I fully expect that once we run through the process a couple of times, re-evaluate it’s shortcomings, and optimize it for efficiency, we’ll end up with a process that will save us a lot of time and effort when new developers come along.

So, my first attempts at process documentation and development seemed to be a success. It was also quite surprising how satisfying it was to see our processes down on paper, written out clearly, in a form that could be easily duplicated. The next steps for the process documentation experiment will be to continue to work through each of the many processes that make up the majority of what we do each day, putting them down on paper, and then testing and reworking them for optimal performance. My hope is that as we get more and more of our processes documented and optimized, I’ll be able to roll more and more of the day to day activities that require so much of my time off onto others for execution without the worry that the results won’t match my expectations.

You too can recoup much of the time that you spend each day on non-critical repetitive tasks by simply documenting those processes, refining them until the desired result is consistently obtained, and then handing the process off to others for future execution.

Tags: Automation, working the system
Posted in Automation, Work The System | 7 Comments »