Approximately 4 years ago I wrote a blog post entitled “7 Simple Rules to Design a Process”. It’s been a very 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 over 35 years of experience as a practitioner working with processes, 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 the right processes in place for both operational readiness and compliance.
I am well aware that much has changed since in the world of “process design” since I initially wrote the blogpost.
- The rising popularity of new frameworks and approaches such as Lean IT, Agile, and DevOps emphasizing self-organizing teams & collaboration over 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 towards implementing “out-of-the-box” processes and tools
- A backlash against process evidenced 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 process dead? 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. More releases, faster deployments, more stringent uptime requirements, all against a backdrop of an ever growing number of risks and threats.
Process design more important 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 product to its destination quickly and reliably?
- How does 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 Pendulum Swings
It was the late 1980’s and mainframe computing was in its prime. Datacenters were fully automated “lights out” operations. Availability and reliability was approaching 100%. Process was king and 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 longer to deploy and “alignment to the business” – well that was wishful thinking. Then came client server and distributed computing. 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 business could move quicker, but it came at a cost to reliability, availability and operability. Those systems ended up being repatriated back into the datacenter in order 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. The issue isn’t having processes. Poorly implemented processes have caused the frustration.
You guessed it – PROCESS!
So why is it that virtually every industry utilizes process to improve cycle time, throughput, quality and efficiency yet we in IT (the ones who automate 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 of designing and implementing processes that are right-sized for their organization. I’ll go one step further and say that too many folks have taken frameworks like ITIL, which are meant as guidance, and tuned them in rigid and inflexible doctrine.
The next question is whether having robust process still applies to today’s fast paced world of Lean IT, Agile and DevOps?
Of course it does!
There is no way you can do more things, faster and with fewer errors without applying process.
Let me give you a couple of examples.
One of the principles of DevOps is continuous testing which requires the creation of automated test scripts.
So what is the process to ensure that the 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 ensures this happens – and it is called process.
Another example, a new release has gone out with a number of new features as well as some “known errors”.
How do we ensure that the service desk is updated so that they are aware of the changes? This is a part of a release management process and needs to be done whether you are following ITIL, Lean or DevOps.
I believe the fundamental problem is that we end up implementing flawed processes because most IT professionals don’t have the skills to properly design, automate, manage and improve them.
So let’s bring this back to my original “7 Simple Rules to Design a Process”.
- Know the gaps
- Don’t start from scratch
- Don’t go it alone
- Automate (don’t be a technophobe)
And since our company, Navvia, is 9 months into a DevOps implementation, I am going to discuss each of these rules from that perspective – just to demonstrate that the rules still apply.
1. Know the gaps
If you are looking 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 ways to uncover the gaps is by talking to the people involved with the process – don’t assume you know what the issues are. The implementation of our DevOps program started with an assessment of everything from requirements definition through to development, deployment, operations and support. We used the results to implement process improvements that were nimble, rightsized and applicable to DevOps.
2. Don’t start from scratch
The one thing I have learned from my many years as a consultant is that organizations are more alike that you may think. Your challenges are very similar to that of other organizations – in fact, that is the reason “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 need to listen to your stakeholders and deliver something that meets their needs. For a process to work it MUST be designed to meet the needs of the business. Best practices can shape the process but it’s design work that drives out the details.
3. 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, 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, but you also need to involve them in the design, implementation, deployment and ongoing management of the of the processes. You also need to continually communicate the vision, goals and objectives of your processes. Remind people that change management doesn’t exist to make things difficult, but it exists to mitigate risk and ensure changes are implemented smoothly. Emphasize how having robust processes will make their jobs easier in the long run and, for goodness sake, LISTEN when they provide suggestions for improvement. I make it a point to regularly discuss our DevOps program with the team.
4. Automate (after gathering requirements)
The best process is an automated process. But you will never be able to automate without the proper requirements. ITSM tool vendors love to push OOB (out of the box), why – because it makes it easier to sell and implement their product so that they can move on to the next client. The reality is that for most organizations OOB is not sufficient. Sure, vendors will tell you their products are based on ITIL – but frameworks do not get into the necessary details – like who approves a change, how many levels of approval are required or what other system do you need to integrate with. Not to mention that many process designers pride themselves for “keeping things at the 50,000 foot process level”. That isn’t good enough. You need to ensure that your process initiative includes someone skilled both at gathering technical requirements and with experience in the target technology. If not, you are going to be very surprised when you go live and find out your stakeholders don’t have everything they need to do the job. In our DevOps initiative tools were chosen and configured to close gaps in our processes – not based on ITIL. We even took liberty with the processes themselves consolidating ITIL’s Change Management, Release Management & Service Validation & Testing process into a single process under a single owner – Remember ITIL is guidance, not the law.
Iterative process design is one of the best ways to stay focused and to demonstrate progress. In our DevOps program we validate utilizing show & tell sessions. You never want to be in a situation where you’ve spent weeks of time designing a process only to find out that the stakeholders have issues with it. Show and tell sessions provide you the opportunity to frequently and continuously validate the process with your stakeholders in order to make the necessary course corrections and to garner buy-in. One piece of advice, don’t confuse validation with the gathering of new requirements. Don’t be afraid to push back on totally new requirements, placing them in a backlog for a future release.
One of the best ways to ensure consistency and adherence in your processes is to educate folks on what needs to be done, what’s in it for them, and most importantly, all the reasons why this new process will make their work-lives easier. In our internal DevOps program we constantly communicate and educate on the value proposition of our processes as that is the best way to foster buy-in and adoption.
So here we are at the last of the 7 simple rules for designing a process, and I saved the most important one for last.
You can spend significant time and effort designing a process, thousands of dollars on ITSM tools, but it’s all meaningless if people refuse to adhere to the process. The value derived from your processes will be directly proportional to the degree to which they are followed. There is no sense in having a Change Management process if every change is urgent and few are documented. Good governance requires that you establish accountability for the process, assign the appropriate tasks and measure that they are actually getting done. It is this discipline that will ensure you reap the rewards of all your hard work.
Having robust ITSM processes is just as important in today’s world of DevOps & Agile as it was back in the day of the mainframe – maybe more so! Process has become a bad word for many folks – an impediment to getting their job done. But who ever said that processes had to be cumbersome, bureaucratic or onerous? It’s been my experience that poor process is the result of poor design. Designing good process takes a bit of work along with lots and lots of communication and collaboration. I hope you find as much value in our “7 Simple Rules to Design a Process” as we have.