Wednesday, September 29, 2010

A process for your process

The HR Bartender talks about how Proper Processes Yield Good Outcomes and how not following a good process can lead to "grief."  But implied in this advice is that the process actually is good.  I've seen plenty of processes criticized and ignored, meaning they simply aren't followed.  So if you want people to follow a process, you need to give people a reason to follow it.

There are four questions I encourage my team to always ask when establishing or formalizing a process:

Is the process needed?
Not everything done in the workplace requires an official process.  There are just times when you have to trust individuals to perform certain aspects of their jobs however they see fit.  I once started working with a department and found that they had a very specific, documented process for opening Microsoft Word documents.  It had users first launching the Word application and then using the File/Open function in Word to navigate to the appropriate network drive where the document they wished to open would be found.  It didn't matter if the user had the network drive already open on his computer and all he had to do was click on the specific document to open it; the process was simply how it had to be done.  But plenty of people in the department were familiar enough with both Word and the Microsoft operating system to understand there were a number of ways to open the document they wanted.  It turns out the process originally came about because it was the only way the department manager knew how to open documents, so she at one time insisted that her way be made into the department way, and she actually reprimanded people in her department if they tried anything else!

If people perceive a process as unnecessary, they aren't going to use it.  And if a workplace has enough processes like this, people will start to wonder if any of the processes are useful.

Before creating a new process, ask yourself if it really is needed, and why.  You need to give the process a reason to exist.

Does it make sense?
There's an urban legend that goes something like this:
A new bride is making her first roast.  After pre-heating the oven and seasoning the meat, she cuts off each end of the roast.

"Why would you do that?  That's the best part!" her husband says.

"Because that's the way my mother always did it, and the roasts always turned out great!"

And the husband has to agree that the roast is delicious.  Proud of herself, the bride calls her mother to share her culinary success story.

"...and I cut off the ends just like you always did!"

"Honey," responds the mother, "I only did that because my pan was too small."
What would cutting off the ends of the roast have to do with how it would taste?  Maybe there's a very logical answer to that question (as was the case with the mother), but left unasked our bride never learned that doing so really didn't make any sense when it came to making a roast in her kitchen with her pan.  Try to shoot holes in each and every step of the process you create.  Wonder aloud as to what might happen if a particular step isn't followed.  Be able to justify all the components of the process.  Each step should move the process along towards completion.  If one doesn't seem to have any impact on the process's goal then it probably doesn't make sense and should be removed.  Leaving them in will once again give people reason t question the process and consider avoiding it entirely.

Is it efficient?
Eliminating unnecessary parts goes a long way towards ensuring a process is efficient, but it isn't the only thing to be considered.  Just because a process may be needed and it makes sense doesn't mean it gets to be a burden on those utilizing it.  Effective processes need to be mindful of people's time.

Most processes aren't created from nothing.  What usually happens is you have a person that had to insert
Widget A into Cog B to create Product C from time-to-time but recently it was realized that more people were going to have to perform the same task on a more frequent basis.  So you need to formalize a process for the sake of consistency.  But if the ultimate process takes the original person twice as long to complete than it did before the process existed, you're probably not maximizing efficiency.  Likewise, take the need for creating a new process as an opportunity to leverage off history, experience and expertise to identify inefficiencies and correct them whenever possible.  If people find that a process allows them to complete more with less effort and time, they're more likely to embrace it.

Is it well-documented?
Once a process is established it needs to be documented in a manner that not only comprehensively explains how to use it but is also easily understood by those who will follow it.  In my experience, IT is one of the worst offenders when it comes to this.  Because their knowledge of a process they may create is very technical, they'll often use extremely technical terms when outlining a process for relatively non-tech-savvy users.  Documentation must speak to the lowest common denominator in the audience.  If merely explaining a process is over a user's head, there's a good chance they'll be too intimidated to utilize the process itself.  A good way to ensure a process is easy to understand and follow is by having a person who will have to follow the process create the documentation.  They will be able to approach it with a better feel for the audience and provide appropriate context based on what the larger audience does or does not already know.

It's also important to document the why behind a process.  Here are seven words that make me cringe whenever I hear them:
Because.  We've.  Always.  Done.  It.  That.  Way.
If I had a nickle for every time I've asked a person or work group to explain to me why they do something and heard those words, I'd probably be writing about all the fine restaurants I dine in as I travel the world in a monkey-piloted hovercraft as opposed to this.  As important as it is for the how of a process to be well-documented, you simply can't forget why that process came into existence in the first place.  An effective process can last for years, frequently outliving the people who created it (or at least their careers).  As departments evolve and workers come and go, somewhere should be a document that gives some background on how the process came to be and why it's important to follow it.  And not only will it serve to tell people why something is done, but it also might let them know why it shouldn't stop.  There's nothing worse than eliminating a process because nobody knows why it's followed only to find out larger business operations are adversely impacted by its absence.


Are these the only ways to ensure a good process is created?  No way.  But I view them as a good start, and if you can answer yes to at least these four questions you'll do a world better in building a process than if you hadn't asked them at all.

What are some ways you go about creating a process?

No comments: