This blog was originally published on LinkedIn Pulse.
Many times over the past several years, I have been called “a process guy,” or worse, “the process guy”. Although it was meant to be positive, I always heard the undertones of “Oh no – more process”. People seem to have a fundamental dislike of process. Ironically, so do I. So then, why am I “the process guy”? I have spent some of my career in computer programming. What is the difference between machine instructions and process steps? Unlike in human-implemented processes, the machine implements the instructions consistently and without complaint.
Are processes a means to program people? Yes. Is that a bad thing? It depends. If you ask our customers, they expect that our staff performing time-sensitive service work, such as service desk tier 1 and tier 2 activities, will follow processes to increase the speed and predictability of outcomes. They believe that this rigor will improve service to the end users. This would absolutely be true for computers. For people, not so much. Our customers also expect our software developers to follow processes to avoid developing systems that fail in the field. They believe that developers should practice repeatable coding standards with clear documentation, comprehensive error catching, and rigorous code reviews. Are they wrong in expecting this? Of course not.
The simple fact is that most people do not like following processes and often refer to their jobs as “death by process”. Our managers see implementing new processes as the cure-all for major issues. How many times have we, as managers, responded to a major event by saying we will create or revise the process so the issue never happens again? This is one of our go-to management tools. Why is it so difficult to give our customers what they want and what they expect? The answer is surprisingly simple. It is impossible to program people; they just don’t act like computers.
Daniel Pink has done extensive work of determining what motivates our workforce. His YouTube video, “Drive: The surprising truth about what motivates us,” shows us that people are not motivated by money, but by more personal factors. Without giving away his three factors that motivate people, let me just say that following processes is not one of them. So how do we get people to follow a process? Do we just throw away all processes and let people do what they want?
No. Instead, we need to adjust our management style to motivate people rather than push process on them. Every good process has a reason to exist; most times this reason is not explicit in the process documentation. For example, how many times have we seen a process to back-up a system that explains the reason why it is so important? Does the process address restoral time, data quality, or other factors that reflect the quality of process execution? Our staff needs to know the expected outcomes and the benefits of these outcomes before diving into the process material. If they know that their performance is being evaluated – such as against our goal to resolve all actionable tickets within one hour – they will read the process because they want to consistently beat that goal. At the risk of being the process guy yet again, below are three-steps to put your processes in the right perspective.
Step 1 – Clearly articulate the expected outcomes and value of each process
For each process, make the expected outcomes clear up front. Why is this process important? What is the value to the end user or customer? Identify the required outputs. If fields need to be updated, state these at the beginning, not just buried within the process documentation. These can be stated as succinct completion criteria. If the process supports a key measure, identify which one and how it supports it. This provides the important context to the reader and helps them to own the outcome, not just the process.
Step 2 –Make detailed process optional
For larger processes, such as stage gate reviews, the gates themselves are not optional. However, the detailed processes, such as work instructions, should be considered as one possible set of steps necessary to achieve the desired outcomes. As long as the completion criteria is achieved and the measures are supported, the actual steps taken are not important. People abhor following unnecessarily detailed processes. They feel that the process belittles their creativity, their humanity. The detailed steps are still required, but consider these as training material more than rigorous work instructions.
Step 3 – Manage to outcomes
For this approach to work, our managers need to motivate their team based on the outcomes of their work. If the outcomes were not reached, the manager can reference the process as the guidance to help the team understand how to achieve the desired outcomes. Focus needs to change from implementing a process to achieving the desired outcomes. Let’s let the team determine the best approach to achieve the outcomes – they may improve the existing process and enhance the actual outcomes.
I offer this three-step process as guidance only, as long as we achieve the outcomes of consistently higher performing teams.
About the Author
David Page is Director of the IT Service Management Innovation Center. David has over 35 years of technical, business, and organizational development experience and brings the expertise and strategic perspective to help Salient CRGT stand out from its competitors. He created and developed CONNECT, a web-based tool to manage and track staffing on large programs and provide complete real-time visibility to customers. Prior to Salient CRGT, David was a vice president at SRA International where he held multiple positions leading complex customer programs, heading new initiatives, and improving organizational effectiveness. David has consulted across numerous federal agencies and led a program of over 200 individuals supporting the Joint Staff at the Pentagon.