7 Simple Rules for Process Design

by David Mainville on July 13, 2022

Business Process Management

Approximately four years ago, I wrote a blog post entitled "7 Simple Rules to Design a Process". It's been a popular blog post on our website, and some of my colleagues encouraged me to "bring it up to date," – so here we are…

What makes me qualified? I have been a process practitioner since 1980, as a consultant designing & implementing processes, and, ultimately, as the CEO and co-founder of Navvia, where I am accountable for ensuring our company has practical operational readiness and compliance processes.

I know much has changed in the "process design" world since I wrote the blog post.

The rising popularity of new frameworks and approaches such as Lean IT, Agile, and DevOps emphasize self-organizing teams & collaboration over the process.
Service Management tools have moved into the cloud with an ever-increasing number of SaaS tools for IT Process Management.
Focus is shifting from process-driven ITSM tool implementations toward implementing "out-of-the-box" processes and tools.
A backlash against ITIL processes (demonstrated by an increasing number of articles and blog posts with titles like "The Death of ITIL" or "How ITIL is Killing Innovation."
A significant decline in the attendance of IT Service Management events, conferences, and Local Interest Groups (evidenced from our position as a conference sponsor and attendee)

Is there still a place in this world for "process design?" Am I wasting my time updating an article on how to design a process?

In a single word – NO!

IT professionals are being challenged to move at an ever-accelerating pace. IT staff face more releases, faster deployments, and stringent uptime requirements, all against increasing security risks and threats.

Process design is more critical than ever.

Never before has process design been more important, and if you think process is irrelevant, then consider the following:

How does a factory improve manufacturing throughput?
How does a logistics company get a product to its destination quickly and reliably?
How does a retail organization ensure consistent, high-quality service?
How does a power company ensure the lights stay on?
How does a hospital deliver emergency life-saving treatment?

The answer is well-defined and repeatable processes.

The Pendulum Swings

It was the late 1980s, and mainframe computing was in its prime. Datacenters were fully automated "lights out" operations with availability and reliability approaching 100%.

Robust IT processes ensured everything was under control. However, that came at the cost of agility and speed. The business became frustrated as applications took longer to develop, changes to deploy, and "alignment to the business" – well, that was wishful thinking.

Then came the client-server and distributed computing revolution. Software vendors bypassed IT and sold applications directly to the business. The business began running mission-critical applications on machines sitting under their desks. Yes, the company could move quicker, but it came at a cost to reliability, availability, and operability. Those systems ended up repatriating back into the data center to implement controls.

Well, the pendulum has swung once again. The business remains frustrated; process is a 4-letter word, and frameworks like DevOps are, to many, a code word for bypassing process and improving speed.

It's not the processes per se that are at fault. It is poor process implementation and management that results in frustration.

So why is it that virtually every industry utilizes a process to improve cycle time, throughput, quality, and efficiency? Yet, we in IT (the ones who automate the business process) view internal processes as a hindrance?

Based on my experience, it comes down to poor implementation and governance.

Most IT organizations do a terrible job designing and implementing right-sized processes for their organization. I'll go one step further and say that too many folks have taken frameworks like ITIL as gospel and tuned them into rigid and inflexible doctrine.

The next question is whether ITSM processes still apply in today's fast-paced world of Lean IT, Agile, and DevOps?

Of course, it does!

You cannot do more things faster and with fewer errors without following a process.

Let me give you a couple of examples.

One of the principles of DevOps is continuous testing, which requires creating automated test scripts. What is the process to ensure test scripts are updated to reflect the changes in the application? How do we ensure the test scripts themselves are tested & deployed correctly?

One may argue that this is just part of the job. However, in larger organizations with many different applications and people in the mix, there needs to be a way to ensure this happens – and it is called process.

Another example is a new release with several new features and some "known errors."

How do we ensure that the service desk is updated so that they are aware of the changes? This communication is essential whether you follow ITIL, Lean, or DevOps.

I believe IT organizations implement flawed processes because most IT professionals don't have the skills to design, automate, manage and improve them properly.

So let's bring this back to my original "7 Simple Rules to Design a Process".

They are:

Know the gaps
Don't start from scratch
Don't go it alone
Automate (don't be a technophobe)
Validate
Educate
Govern

Know the gaps. Suppose you want to implement or improve a change or release process. Start by finding out what isn't working today. Are approvals too bureaucratic? Do releases take too long to package or deploy? The best way to uncover the gaps is by talking to the people involved with the process – don't assume you know what the issues are.

Don't start from scratch. I have learned from my many years as a consultant that organizations are more alike than you may think. Your challenges are very similar to that of other organizations, which is why "best practices" can even exist. There are excellent resources available that cover Agile, DevOps, and Service Management that you can leverage – but remember, these are guidelines and not the law. You must listen to your stakeholders and deliver something that meets their needs. For a process to work, it MUST meet the needs of the business. Best practices can shape the process, but the design work drives out the details.

Don't go it alone. The best way to get buy-in and adoption for your processes is to involve your stakeholders in their design. Dr. John Kotter, the author of The 8-Step Process for Leading Change, speaks to the importance of getting people on board and making them part of the improvement effort. The gap analysis I described in point 1 is a great way to start. Still, it would be best if you also involved the stakeholders in the process design, implementation, deployment, and ongoing management. You must also communicate your processes' vision, goals, and objectives. Remind people that change management doesn't make things difficult, but it exists to mitigate risk and ensure changes go smoothly. Emphasize how having robust processes will make their jobs easier. For goodness sake, LISTEN when they provide suggestions for improvement.

Automate (after gathering requirements). The best process is an automated process. But you will never be able to automate without the proper requirements gathering. ITSM tool vendors love to push OOB (out of the box) implementations. The reality is that for most organizations, OOB is not sufficient. Vendors will say their products align with ITIL. Still, frameworks do not get into the necessary details – like who approves a change, how many levels of approval are required, or what integrations are required. Another issue is that many process designers pride themselves on "keeping things at the 50,000-foot process level". That isn't good enough. You must ensure that your process initiative includes someone skilled at gathering technical requirements and with experience in the target technology. If not, you will be surprised when you go live and find out your stakeholders don't have everything they need to do the job.

Validate. Iterative process design is one of the best ways to stay focused and demonstrate progress. Consider using show and tell sessions to validate your implementation. You never want to be in a situation where you've spent weeks designing a process only to find out that the stakeholders have issues with it. Show and tell sessions allow you to frequently and continuously validate the process with your stakeholders to make the necessary course corrections and garner buy-in.

Educate. One of the best ways to ensure consistency and adherence in your processes is to provide process education, including what's in it for them and, most importantly, why this new process will make their work lives more manageable. This is essential in driving organizational change.

Govern. So here we are at the last of the seven simple rules for designing a process, and I saved the most important rule for last. You can spend significant time and effort developing a process and thousands of dollars on ITSM tools, but it's meaningless if people refuse to adhere to the process. The value derived from your processes will be directly proportional to adoption. There is no sense in having a Change Management process if every change is urgent and many go undocumented. Good governance requires establishing accountability for the process, assigning the appropriate tasks, and measuring that they are getting done. This discipline will ensure you reap the rewards of all your hard work.