A couple years ago I wrote an article, "From Process to Discipline," that outlined the need for variable levels of process and discipline based on the two project characteristics ofuncertainty and repeatability. I wrote that article in response to two misconceptions: 1) traditional process driven projects are obsolete in today's world, and 2) agile projects don't have any processes. The truth is, every project needs some level of process, explicit or implicit, to get work done.
In my experience, there is a tendency to get carried away and over-engineer the natural flow of a process into inflexible and prescriptive procedures, in an attempt to account for all possible permutations. I'd like to think that this is a product of the technical nature of most of the teams I work with, but I have also worked with sales and business teams and am continuously surprised at the inherent propensity to
over-think things.
Procedures define activities, not outcomes. Solid procedures are necessary when the task is either very complex or very mundane; it ensures the task is performed with consistency, in order to get the same predefined outcome each time. Procedures are intended to make something happen in a certain way by defining specifically how things are done, not just that they are done. It can be a daunting task to accurately document the primary flow of a process, and downright impossible if you try to account for every possible exception. If we are less concerned about how something is done and are more interested in the result, we can save the mental gymnastics of creating rigid procedures. It's much simpler to monitor the process by just visibly verifying the outcomes.
Processes convert inputs into outputs. They create a change of state. So when it comes to simplifying a process, more often than not I have found that a simple checklist will fulfill 80% of the process governance requirements with a fraction of the effort and frustration. Checklists define the undone and done states through a simple binary process. It is either done, or not done. It tracks the process through examination of empirical evidence that something exists and can be visually verified. It can be checked off. You can't get much simpler than that.
The other cool thing about checklists is that they define the outcomes before the work is done. In a sense, they are the WBS-at least at some level. (I'll hedge that comment or my PMI purist friends will blog me to death.) Or, if you just reached for your PMBoK, you can think of checklists in terms of the inputs/outputs or entry and exit criteria for a process. When the people doing the work are smart and capable (and you wouldn't have them on your team if they weren't, right?) they will relish the opportunity to apply their creativity as long as they know the intended outcome.
But perhaps the thing I like the most about checklists is how familiar they are. Who doesn't make lists, even for things we know how to do well? Life and projects are busy, with a lot going on. Lists keep us organized so we don't forget something in the process. Grocery lists, to-do lists, and punch lists are all part of our daily habits. My father had numerous hobbies, and for each one he had an "entry checklist." Flying planes, running model trains, going fishing or hiking all started with an "are you ready for the process" checklist, mental or physical, depending on the risk. When flying his plane, the checklist was detailed and laminated. The consequences of a missed item could be fatal. When day hiking, it was just a quick confirmation: Compass, check; knife, check; matches, check; water bottle, check; mosquito spray, check. Done.
Besides, what is more gratifying than crossing something off your list? I get such satisfaction from crossing things off my list that I sometimes put things on my list that I have already done, just so I can check them off. I'll bet I'm not the only one that does that. Several years ago my wife saw me write something on a list I had already done and then cross it off and she accused me of being obsessive. OK, maybe that is a bit fanatical, so I no longer do that. Honest. Instead, when I start a list, the first item on my list is "Make a list." That way, when I'm done making the list I can cross it off and feel an immediate sense of satisfaction. (I didn't say I was cured, I just have things under control, most of the time.)
Because checklists aren't prescriptive, using them does require discipline. They offer flexibility while maintaining enough consistency to develop accountability-yet still allowing for self-learning and exception handling. They give you the wiggle room that is necessary and comforting, while providing sufficient structure and boundaries through short-term deliverables. This leaves you the freedom to do it your way, as long as at the end it can be checked off the list.
When I work with teams to define a process I often ask them to put their completion criteria in the form of a checklist of nouns. The use of nouns instead of verbs avoids the temptation to immediately dive into the how and keeps them at the what. A simple checklist like this is easy to put in place and maintain, easier to remember, and simpler to govern and administrate, all while being flexible enough to change. If the checklist isn't sufficient, add another deliverable. If there is something extraneous, take it off the list or make it optional. Simple as that.
Of course, not everything can be managed through a simple checklist. Checklists assume a level of competency on how to define and deliver on the checklist items. Therefore, checklists may not be enough if people don't know the how, are just learning, or if you are trying to overcome sloppy or lazy behavior. Under these circumstances, the prescription of a procedure may be needed for a while, to develop the competencies. However, once the competencies are built, it may be possible to simplify the procedure back to a checklist over time. If your procedures have become shelfware, you are probably there.
So, the next time you have to define a process and are tempted to do your best imitation of a swim lane diagram in Visio, I would challenge you to try starting with a simple checklist. I know it's low tech and not very glamorous, but chances are it may be just what is needed, and nothing more. Just start with one or two things and let the list grow. Then you can check "Document the procedure" off your list.