Imagine if you will...You're upgrading your service management processes and tools to deliver better outcomes to the business. You've selected a software vendor and perhaps hired a professional services firm to help. The consultants have called everyone into a meeting to discuss the new processes. They proceed to launch the new tool then ask the room, "So here is your out-of-the-box tool. How do you want it configured?"
Unfortunately, this is not a bad dream; it's a scene that's played over and over in hundreds, if not thousands, of companies around the world, maybe even yours. And while it may sound like an efficient, even agile way to proceed, it almost always ends in failure, re-work, and cost overruns. Except for the case of small companies, ones with little to no process maturity, this approach rarely works.
The flaw in this method is that it is more fixated on the tool and ignores the business problem the tool is supposed to solve. More often than not, it results in a replication of existing processes in a new product, with little to no improvement. Where is the value in that?
As someone who has made a career of "process," I sincerely believe that process design is a lost art. We have lost sight of the fact that effective process design is about first and foremost engaging the business, understanding their objectives, and translating that into repeatable processes, supported by tools and technology. Based on my experience, practical process design comes down to five things, which I like to call, my process for creating a process:
Let's take a look at each of these in more detail.
Step 1: Understanding
This important step refers to approaching process design from the perspective of the business. We don't create processes for the sake of process; we do it to improve business outcomes.
It's no accident that companies such as Starbucks, Apple, and Amazon consistently deliver an exceptional customer experience. Why? Because they take the time to understand their objectives and translate them into processes that produce results. In many cases, their methods are so good that the customer doesn't even realize there is a process in place. Think of it as the difference between designing an adequate customer checkout process or developing one that drives more sales and keeps the customer coming back.
To develop a superior process, you need to take the time to understand the actual business objectives in business terms. For example, we need to increase sales by streaming the online shopping experience and making it easier for clients to add items to their cart. This objective must be top-of-mind as the processes are developed and subsequently automated in software.
Step 2: Collaboration
The only way to understand what the business is trying to achieve is to engage them. You cannot design a process within a vacuum of information.
Engaging your stakeholders can be difficult. Often, they claim to be "too busy" to get involved. That is where your powers of persuasion become critical. As Simon Sinek says in his book, Start With Why, you need to communicate the value of engagement.
Once you have them convinced, you need to utilize tried and true change management practices to implement the new processes and to make them stick. For that, I recommend Dr. John Kotter's 8-Step Process for Leading Change.
Engaging your stakeholders makes them part of the solution and more willing to implement and adopt the new methods.
Step 3: Simplification
You can't follow a process if you don't understand it. Over the years, I've seen a lot of process documentation, some good, most of it bad. I've seen process flows that look like a bowl of spaghetti or are so complex that they have to be blown up to wall size to read. I get the fact that some processes are complicated, but that doesn't mean you have to create complex documentation. There is one thing I know for sure if you make your documentation overly complicated, people will either misinterpret the process or ignore it.
There are a few best-practices that I've adopted over the years. First off, create a standard way to document a process. Standardization will simplify the learning curve for your readers.
Keep your diagrams simple by adopting a hierarchy of information. Processes have activities; activities can have tasks or subprocesses; and tasks have procedures and work instructions. That way a reader can see the big picture and dive down into more detail when needed.
I also believe in having contextual documentation. Executives typically do not need to see detailed work instructions, but an auditor needs to validate the procedures exist. Understand your different audiences and serve up your documentation in a context that makes sense to them.
Lastly, create living documents that are easy to find. People can't follow the process if the documentation is out of date or if they can't find it.
People can't follow the process if the documentation is out of date.
Step 4: Implementation
Implementation involves the development of user stories to drive requirements. Ultimately your process must be implemented in a tool. For that, you need to understand the technical requirements of doing so. One of the best ways to do that, from my experience, is to borrow from Agile development practices and to create user stories.
User stories must be presented from the perspective of the user and told in non-technical terms. The construct for a user story is "As a <persona>, I want <feature>, so that <benefit>." Here are a couple of examples:
- As an unauthenticated user, I want to see the login link in the upper right-hand corner of each page so I don’t need to navigate back to the homepage or some account page to login.
- As a sales associate, I want to be able to pull up my current active leads, deals, and tasks on my iPhone so that I can still follow up with clients and update deal status while traveling.
You start by identifying all the personas (types of users) within the process. Then you create stories describing how each user will interact with the system. These interactions are then used to drive the technical requirements necessary to develop or customize the target software.
This approach has a few advantages. One, it makes sure all users’ needs are considered. Two, requirements can be easily validated with the users because they are in business terms. Also, user stories form an excellent basis for developing acceptance testing scripts.
Step 5: Sustainability
It takes a lot of hard work to develop and implement a process. All of that effort goes out the window if the process is not sustained and improved over time.
There is a story I like to tell about the IT department of a large telecommunications company. I was a vendor field technician at the time, called upon to resolve hardware issues. I was always intimidated by this client. Why, because they always seemed to know what needed to be fixed before I did.
How so? Their processes were so tight that they had compiled a database of known problems and fixes. Their command of process extended to other areas as well, and they enjoyed the highest levels of availability of any of my clients.
That all changed when they were "outsourced" and new management didn't see the need for process owners or all the process governance they had in place. It didn't happen overnight, but over the course of 18 months, they started seeing more outages and more failed changes. They went from being one of the most well-run IT shops to one of the least reliable.
The moral of the story is that processes requires care and feeding if they are to continue to deliver value. Here are some of the ways to provide that care and feeding:
- Reward positive behaviors to make process adherence part of your culture.
- Ensure that you have a good training program; you can't assume everyone understands the why and how of your processes.
- Consider implementing a process office that includes folks with the requisite skills to design, deploy, and govern processes.
- Implement a governance and continual improvement program by defining controls for your processes, validating results, and improving where needed.
Adopt the Lost Art
We live in a world where everyone wants a quick fix. There is a trend towards implementing out-of-the-box software to address business needs. But that approach is flawed. It does nothing toward differentiating you from the competition and allowing you to meet the specific requirements of your users.
Adopt the lost art of process design by focusing on understanding requirements, collaborating to build solutions, simplifying to improve adoption, creating user stories to drive requirements, and locking in these changes through education and governance.
David Mainville, CEO and cofounder of Navvia, is a passionate advocate of service management and a frequent presenter, blogger, and well-known member of the ITSM community. With more than 35 years of experience, David has held progressively senior technical and management roles allowing him to connect the dots between the business and IT. At Navvia, David leads the charge to bring innovative ITSM solutions to market, focusing on product development, marketing, and operations. Follow David on Twitter @Mainville and connect with him on LinkedIn.