In a recent consultation, the Process Innovation group at The University of Maryland, College Park, dealt with a department widely considered inefficient and difficult to work with. Their processes were perceived as cumbersome, costly, frustrating, and antithetical to their stated objectives. Several IT systems had been purchased and implemented to address these issues, which actually exacerbated the problems. Before this department invested in yet another system, an executive of the unit reached out to me to get a better understanding of their processes and how they could be improved in a way that would make the system implementation a success.
After a few weeks of working with the department, we helped them develop a holistic end-to-end process that significantly improved their service delivery while reducing the administrative cost to them and their customers. We found areas where inconsistent practices were causing inefficiency and developed solutions to bring them into alignment. In another example, we discovered where adherence to an outdated policy significantly slowed the process. We also uncovered several areas where the unit incurred additional costs to support processes that had no apparent value. With their methods purposely redesigned, the department was able to implement a technology solution to facilitate their process rather than experience the previous pain and high cost.
We have all seen it happen: An organization buys a shiny new piece of technology and then tries to implement it without first having looked hard at its own processes and people. The result? The vast majority of the time, the project doesn't live up to expectations — it exceeds the budget, takes longer to plan than to finish, or fails to meet the original goals. Even when "successful," too many times the new technology looks a lot like the prior technology in terms of how it works. People start saying to each other, "Why did we go through all this? This doesn't work nearly as well as the old system." This situation occurs because the organization embarked on a technology project without first looking at, and improving, the underlying processes.
For those new to process analysis and improvement efforts, they can seem daunting, often with little guidance available as to what to do and not do. Even those steeped in process improvement can find themselves making common mistakes. As a result, many process improvement efforts fail to achieve their intended goals or even make it to the finish line. Worse, some end up being counterproductive and a waste of organizational resources.
My purpose here is to address some of these problems by providing tips and lessons learned from my team's experience as well as observations made while facilitating or mentoring other process improvement groups. My team is itself deeply indebted to the mentoring and teachings of Alec Sharp.1
Problem 1: Details Before Context
A new process improvement project is an exciting endeavor, and often everyone is eager to get started. Subject experts, who know their jobs well, are ready to explain what they do and how they do it. You might even be handed a set of process flows already developed as part of an earlier effort. It is easy to let the conversation go straight to the details before describing the environmental context and determining what the individual processes are and how they relate to one another. Everyone needs to be on the same page contextually, and you'll need to emphasize the importance of discussion — or the project can derail quickly.
Suggested Practice: When starting a new process improvement project, you must set the stage for the work ahead. Be sure to discuss the overall process (or process landscape) and understand the related processes which come before and after, and those that interact with it. This activity will help define the scope of your work and put each process in context with neighboring processes. In addition, make sure it is clear how the process furthers the organization's objectives. Do not dismiss previous work you might be handed, but at the same time do not let those dissuade you from having the conversations to develop the context.
Problem 2: Artifacts Over Process
A common error both novices and experts make when conducting process improvement is to focus too heavily on the artifacts (diagrams, flowcharts, and other physical deliverables) without enough attention to the processes and conversations that build those artifacts. While these tools have some value on their own, much of their value is derived from the interactions and discussions behind them. If the artifacts held the value, you could simply borrow flowcharts from a similar organization and implement them. However, this approach rarely works well. It is easy to fall into the trap of gathering a few people (or worse yet, doing it solo) to sketch out some swim-lane diagrams and scenario lists and then feel the process work is complete. These efforts often end without the necessary context and commitment to develop effective recommendations. Similarly, it is ill advised to rely on the vendor to provide concept models, workflows, etc. The perspective of an external entity is not a substitute for conducting a rigorous process improvement effort.
Suggested Practice: One theme rooted in process analysis and improvement is the social nature of the endeavor, and a deeper understanding and likelihood of adoption arises through conversation and questioning. The focus of initial conversations should be around understanding the business process and related challenges. Existing artifacts can be useful for providing background information, but do not use them as substitutes for developing your own. Do not create your interview questions based on the documentation you plan to create, and always be open to conversations taking a path you might not have considered. The artifact creation should come later in the process or can be done as a group activity, which might facilitate conversations around the details and challenges related to the process.
Problem 3: No Case for Action
Sometimes groups find themselves well into a process improvement effort when rumblings start questioning the effort's rationale and purpose. Stakeholders may be confused as to the objectives, begin questioning previous decisions, or ask if the effort is even a good idea. Sometimes the answers to these questions are vague, but more often the ideas themselves are not clear, objectively defined, or universally agreed upon. This can lead to poor process analysis and weak recommendations when there is a lack of consensus as to the real objective.
Suggested Practice: Three questions must be clearly answered to make the case for action.
First, "What problem are we trying to address?" This question frames the effort of making sure there is agreement on the root issue. For instance, the initial problem might be identified as an IT system not working properly, while the appropriate process problem is the much greater issue with the end-to-end process within which the IT system was recently added.
Second, "Why is this a problem we should focus on?" This question requires a sense of urgency to find a solution and a shared vision of future problems if the problem persists.
Finally, "What are our objectives in improving this process?" Answering this question will get agreement on the effort's objectives (e.g. are we trying to reduce cost, provide better service, and so forth) as well as describe an idealized state.
At the initial project kickoff meeting, make sure of agreement and understanding around the answers to these questions as to the goals and objectives of the process. Ideally this will produce a single guiding principle, but it is possible to have two or three objectives. These objectives must include clear statements of what and why, but not dictate how or who (e.g. we need information to be available to multiple departments rather than that finance and human resources need a shared solution). This will help when determining where in the process to focus and what innovations and recommendations will align with those objectives. These conversations help build alignment around a case for action.
Problem 4: Not Involving Enough People
Business processes tend to be far more complicated than initially perceived, and many times process improvement efforts receive input from stakeholder groups that are too small. As a result, those who administer the processes primarily are also the ones who design them, so the outcome often aligns with their metrics and motivations. In addition, administrators can become overly focused on their own piece of a process (or sub-process) and look to optimize it, perhaps at the expense of the overall process. Do not allow yourself to fall into the trap of continuing to allow the process to have a single perspective. Instead, expand the perspectives and audiences from which you gather data. A successful process engagement and subsequent change management effort relies on including the perspectives of all of those involved, and not just the primary stakeholder and/or process administrator. The more input received provides more perspectives and details which may have been forgotten or overlooked by certain individuals.
Suggested Practice: Some people may be overlooked for many reasons when identifying your interview list. Sometimes no one knows about everyone involved; individuals can be difficult to identify because of confusion with the sub-process; sometimes political or interpersonal reasons interfere. Always err on the side of inclusion. The best ideas or insights can come from the individual everyone else tells you not to include. You might hear that they are difficult to work with or disagreeable. One of the process improvement team's roles is to uncover and bridge these organizational gaps. Many times you will be the glue that brings these disparate organizations together, and your facilitated sessions might be one of the few opportunities for them to share knowledge and process pains with one another.
A good framework for inclusion is to identify and include these six groups of people: actors (anyone who performs the work), customers, owners, partners, suppliers, and administrators of IT systems. The project sponsor often can provide a good initial list, but as you work through your interviews, make sure you listen closely and ask for additional individuals to talk to who are part of the process. Frequently the final number of interviewees will be two to three times the initial number.
Problem 5: Not Understanding the Stakeholders
Before diving into a process and asking questions about specific activities, set the tone of the conversation by identifying the goals of each individual involved in the process. Initially, it is important to spend a fair amount of time identifying who the users and actors are in the process and what they are trying to accomplish. Understanding this at a macro level (what are they trying to accomplish overall) and at the process level (what are they trying to accomplish with this particular process) helps set the stage for the analysis. It also ensures guided solutions according to "what people are trying to do" and not strictly by "how can we make what they are currently doing better?" The former can lead to innovation and efficiency improvements, while the latter restricts the analysis to efficiency.
Suggested Practice: Prior to the project kickoff, gather information through research or informal conversations to understand the process's actors and goals. This will give you a general understanding of the process and players so that you can dig a little deeper during the kickoff meeting. For example, you might discover that instead of fulfilling an administrative function (e.g. hire an employee), someone is actually trying to do something more mission-driven (e.g. hire elite staff who will improve their level of quality). Additionally, during one-on-one interviews, take the opportunity to ask probing questions to get to the details from various perspectives. Ask about changes in their role, changes in their industry, what challenges and frustrations they have, and so forth. Experience has shown that most individuals are receptive to such questions and appreciate your interest in understanding their world.
Problem 6: Failure to Define Terminology
Many problems in process work come down to language used and how different actors perceive the existing process. Those coming into a new process often assume that there exists a common definition of the language of the process. Usually we have found that this is not the case. Each group — even individuals within a group — has a different way of describing the process. Even general concepts such as "student" or "purchase order" may be used quite differently by different groups. This often leads to confusion and makes improvement more difficult.
Suggested Practice: Defining terminology, roles, and relationships will help both you and the clients develop a clear understanding of common terms (e.g. what is a student) as well as permutations of that term (e.g. full-time, part-time, on-campus, honors, ROTC, international). You need to establish a common vocabulary that all stakeholders can understand, reducing confusion. Creating a dictionary that ensures terminology alignment can serve as a basis for a data model developed later as part of a technology solution. Many of these terms might seem obvious, but forcing the shared conversation will help clear up misconceptions you or various actors have. Remember, you will be working with a broad set of users with different backgrounds. Do not be afraid to ask for clarification and confirm definitions of key terms and functions.
Problem 7: Solving the Problem too Quickly
Most people who engage in process work are problem solvers by nature. As a result, when encountering a problem, their first instinct is to immediately solve it. Many process specialists will start mentally designing a solution after speaking with a stakeholder, sometimes even during the interview. Trying to solve the problem instead of listening can close you off to new information and data that could be critical to understanding both the existing process and what is needed to improve it. It also creates blinders to possibilities raised in subsequent interviews; the analyst might even skip them. In addition, preconceived ideas or thoughts from earlier interviews could overly influence the recommendations, which might not lead to the best results. Overall, remember that it is difficult to listen effectively when your mind is in problem-solving mode.
Suggested Practice: When having conversations, focus on listening. While you are likely to see obvious improvements early on, do not start solving or leading your interview to the solution you created. If participants begin to suggest ideas for improvement, document their ideas. Also focus on understanding the current process. Assuring others that their visions will be captured and considered is often enough to allow them to refocus on the current exercise. One tool that might help is to start a project "idea incubator" or "holding area" for these ideas and remind participants that you can only get to those discussions after you have a better understanding of the existing process.
Problem 8: Too Much Technology
Many of us feel bombarded by announcements of new and exciting technology that promises to solve all our problems. However, the Law of Amplification suggests that technology only amplifies the process, so if the process is poor, technology has little to improve, and can actually make it worse. While technology is a powerful enabler of process improvement, it is only one of six that my team uses:
- Process flow
- Motivation and measures
- Policies
- Talent alignment
- Facilities
- IT systems and tools
Overly focusing on technology shuts out many of these other opportunities. We have found that IT recommendations are usually only about 30 percent of the total, with valuable improvements identified in all of the enablers.
Suggested Practice: Resist the temptation to see new technology as a way of solving problems in the process. Explore the other five enablers one at a time before considering IT systems and tools. Doing so will help uncover other often cheaper and easier to implement solutions as well as improve organizational process. The investment of time and effort in improving the process before the technology implementation will pay off many times over in simplifying the technology application and lowering the total cost of ownership.
Problem 9: Not Enough Detail
Most processes are far more intricate, with many more steps, than will be described by most interviewees. When dealing with activities people do repetitiously without much thought, it is easy to miss details. Opportunities for improvement can be overlooked when actors and stakeholders remain undefined. Essential stakeholders and actors probably would not receive recognition for their involvement if not included in previous discussions.
Suggested Practice: Write down the details of the process. Any verb or noun hints at an activity taking place. While it might be tempting to gloss over seemingly minor items (e.g. the admin who stuffs the paper into the envelope), do not skip anything. Describe the process and actors with as much fidelity as possible. It might benefit you to have someone unfamiliar with the process there to ask additional probing questions and help validate completeness.
Problem 10: Not Taking Action
Good process work requires a significant investment of time and effort, and the worst thing that can happen is neglecting the results. Process improvement efforts are designed to end with a set of suggested actions, and often another group is responsible for implementing those changes (e.g. the software development team needs to integrate a new solution). Challenges arise when there is insufficient transition between solution development and solution implementation. Other times the stakeholders might not feel comfortable with some of the suggestions or feel they don't have the necessary political standing to proceed. Process work is only successful once the organization is saving time and money or improving quality based on the recommendations. If no action is taken, the project is a failure.
Suggested Practice: Three suggested practices can help overcome this challenge.
First, setting a clear purpose and engaging a broad set of stakeholders will increase the opportunity for buy-in and alignment of purpose.
Second, have regular check-ins with the project's stakeholders to keep them abreast of progress, get their feedback, and make sure you learn of changes in the political and strategic environment.
Third, design the recommendations delivery briefing to be the start of the transition phase, not the end of the process phase.
By the end of the analysis, the staff doing the process work has gained significant expertise and can facilitate the transition to solutions development. This can ensure the recommendations are not the end of the effort, but rather a key midpoint in the solutions development.
What's Next
Process analysis and engineering has proven its value as one of the most cost-effective tools in an organization's arsenal. Successful process improvement projects can not only lead to financial improvements but also will improve the experience of its employees and customers. The activities undertaken as part of these efforts often increase interdepartmental communication and understanding. However, beware the common traps I've described. Process work is social work, and understanding the process from beginning to end is the best way to ensure that you make the right decisions. Becoming aware of some common challenges should help you avoid them.
Key Takeaways
- Both novices and those steeped in process improvement find themselves making common mistakes.
- Tips and lessons learned from a process improvement team's experience and observations made while facilitating or mentoring other groups address some of these problems.
- Understanding the process from beginning to end is the best way to ensure that you make the right decisions, and becoming aware of some common challenges should help you avoid them.
Via educause.edu
Note
- Alec Sharp and Patrick McDermott, Workflow Modeling: Tools for Process Improvement and Application Development, 2nd Edition (Norwood, MA: Artech House, 2008).
Joseph Drasin, D.M., is director of University Process Innovation, Division of Information Technology, at the University of Maryland.
© 2016 Joseph Drasin. This EDUCAUSE Review article is licensed under Creative Commons BY-NC-ND 4.0 International.
