Early in my IT career, I realized that the following process could keep you out of tough situations.
As I worked my way up through the ranks in IT I’ve found ways to meet requirements for documenting processes. To me, this meant taking the time to write down the sequence of steps required to complete a task. Sure, this task list came in handy when training fresh staff or showing leadership how you had executed on something. In some instances, I even put together a flow chart or workflow in Visio, as most of us do. So, I never really thought much about the relevance of a good process design practice. The simplified view of the processes that I used seemed to serve the purpose. This approach has been a customary practice in several companies that I’ve worked at, in network engineering, server support, and software development. Maybe it’s just the way I do things but no one ever corrected me or showed me a better way.
There is another way
Then one day during a discussion with some of my colleagues one of them began talking about how we needed a good process, for whatever topic we were discussing. He further described four or five things a good process should have and listed them out. I wasn’t really paying attention because I already had a way to document processes. The discussion ended without further elaboration and we all went about our business. As the days progressed, I couldn’t stop thinking about what was said and how much conviction my colleague had when describing what a good process should have. I couldn’t remember the details but was impressed by how he knew what it meant and described it with such confidence. I kept thinking about how I had delivered current processes to my current boss, the same old task list and workflow. There seemed to be more to this than I knew and I couldn’t let it go.
Stumbling on how process design should be
I started as everyone does these days with a google search. As expected, tons of complete information. The search returned so much data, that now I understood why the subject seemed so unapproachable to IT professionals. In all the information, nothing seemed to resonate with what I had heard. Oh well, I thought, move on and keep doing things the same old way. Later, I started preparing for the ITIL Foundation certification exam. Eureka! There it was, exactly as it had been described by my colleague. The elements of any well-designed process.
- A trigger, an event to kick off or initiate the process.
- Inputs, Data, forms, files, code, test results etc.
- Controls, A policy, objective, process owner, feedback loop, RACI chart
- Enablers, Tools and applications, test environments, people with skills and capabilities
- Activity, the workflow, steps to be completed in sequence
- Output, release notes, change ticket, code to production, playbook edits, etc.
- Feedback, reports, KPIs, error rates, adoption and compliance metrics, etc.
As I reviewed these and thought about how I had previously put together a process I realized that I had only been recording the “activity” element. As I read further about the policy and objective needed as part of the controls, it begins to make sense. I had to try it, I redesigned one of our current so-called processes using this model. I wrote a policy and identified the owner, created a RACI chart, holy cow Batman! I identified the trigger and enablers, what output was expected. As I reflected on the first draft I was stunned, what had I been doing all these years? Why had no one stopped me or shared the secret about this magical formula I redesigned two more processes and wrote the corresponding policies.
Why good process design makes acceptance easier
I begin to share one of the new processes using PowerPoint slides with illustrated process diagrams and covering each section of the policy including the objective. The ease of getting buy-in from up and down the team seemed much easier. Some of my staff actually thanked me. The difference was amazing, easier to communicate easier to get buy-in and easier to defend in a court of law if needed. Even better, it helps explain the process to the customer in a way that shows the value the process adds to the organization.
Featured Image by mohamed Hassan from Pixabay
