Automate the Process!

Once upon a time, I managed an IT Infrastructure team. There were a few things that were consistently frustrating for all involved, despite my best efforts. The one that consistently killed both productivity and morale was our change control process. I'm sure any of you that have had to work in an IT environment with a formalized change control process can share your horror stories about how frustrating it can be. This isn’t intended to be a game of one-upmanship, even though I’ve yet to experience worse.

The Problem

For us, it was the single most terrible thing about our jobs. Why? Because it was the antithesis of a good process – completely manual, multiple different document types through multiple channels, each step duplicating data in some way or another. It arbitrarily changed often in response to the whims of the myriad managers involved, forcing us to restart changes already in process. All of these things led to endless frustration, because we had to have this process complete before we were allowed to do our jobs. And it could take months for a change to get through. And you had to answer the same questions over and over. And we had to follow this same process, even if the change was required by directive or regulation. Oh, there was a "fast track" option, but it wasn't much better.

I know, I need some cheese to go with my whine. However, it came to the point where people were threatened with discipline - up to termination - for not following it properly. In every change management meeting I attended, I would be on record saying "we need to automate this process". I repeated this phrase at least once in every meeting until it became a joke. I actually tried to find a company that would make custom Chatty Cathy doll with a recording of me saying "Automate the process!" when you pulled the pull string. I couldn't ever find one that was customizable to that extent. By the time I left the company, that process had been in place for something like six years (and I fought the thing the whole way), and it was still completely manual - and completely frustrating.

I hear you asking "Why didn't you take the reins and automate it then, Mr. Big Shot Manager?”. Believe me, I tried. I had meetings with developers, established a recommended workflow automation product, and even commissioned a fully working demo. It was ready to go. But senior management cited "other priorities", and killed it before it could go live. It never saw the light of day.

What's my point? I learned several things through this experience:

1. It's the process, not the people. If you have otherwise smart people getting confused by one or more of your processes, look at the process first, not the person. This is not exactly new - I've seen it many times in many different disciplines, as far back as the TQM movement in the '90s. Actually, the concept probably came about before that, but that's when I recall first coming across it. The key is that If you have to threaten people with discipline because they're not following your process, it's time to really examine the process. Of course, you'll get folks that ignore the process or can't learn it, but then you've got a different problem to solve.
2. Efficiency. You should be measuring your process to see where the bottlenecks are. Of course, it's easier to measure if you're using a workflow tool, but you still have to make sure you're capturing accurate data. Also remember point 1 – if you’re seeing a bottleneck at a particular point in the process, find out if the process can be improved before yelling at the people associated with it.
3. Communication is critical. And I do mean communication, not just shooting emails at each other. I hate meetings too, but sometimes that’s the best way to get it done. Gather all of the stakeholders in one room and ask the important questions. When possible, be sure to do things like send out an agenda ahead of time so that people aren’t blind-sided. Get to the point and make sure there’s no finger pointing – just find out what’s going on so it can be fixed.
4. Make it mistake-proof. The process needs to make sense and be consistently repeatable. Of course, you need a method for deviating from the process if the situation warrants it – someone needs to have the authority to authorize such a deviation in a reasonable amount of time. There are few things more frustrating than something critical stuck in an arbitrary process. Make sure to carefully document these deviations – it may indicate that a change needs to be made to the process itself.
5. Automate, automate, automate! Where possible (and it makes sense) remove manual actions. Don’t make someone start the process by sending a PDF by email then make them watch a folder for the approval to come in. For some organizations, emails work fine. Others use a system like SharePoint, or a separate tool altogether. Whatever it is, make sure it fits with the existing corporate culture to facilitate adoption.
6. Continuous improvement. It’s important to periodically review the metrics associated with the process (you are collecting metrics, right?). Interview the participants to see if there’s a better way to do things. Write it all down, including the reasons you’re doing things. You want to understand these things so that you can challenge the “we’ve always done it this way” mentality. If your company has a Six Sigma program, it can help to enlist their expertise in formally mapping the process and identify ways to improve it.

Once you’ve gone through all of that, and your process is as good as it can be, make sure you can explain it so someone that’s not familiar with it. In the course of explaining it, they will ask questions to clarify what you’re saying and challenge parts that don’t make sense. It’s a good time to validate that what you’ve put together will actually work in practice.

A Real-life Example

My most recent example is a change control process that wasn't working as well as it could (not the one I referred to above). My customer had a software development project that was at risk, and my job was to identify why and provide recommendations to right the ship. I found that a major contributing factor was their change control process. See, the development team was using agile development methodologies, wherein they would publish a version of the product into production, and the end-users would submit requests to modify the application where it didn't meet their requirements. However, they had a consistent problem – the results of those requests would come out in the next release of the product, but not be exactly correct. Follow-on requests would be submitted to fix that functionality, causing the schedule to slip further and more budget-busting funds to be spent. What I noticed was that there wasn’t a loop in their change process to verify that the requirements had been correctly captured – the requirement would go from the requester to the business analyst to the developer and into the product.

Following my suggestion, they implemented a loop in which their design documents were reviewed and approved by the requester before any code was written. The first one of these we reviewed revealed that the proposed solution had missed the mark due to differing interpretations of a single word in the request.

Conclusion

There are always reasons that a particular process or processes get out of hand. Usually, the people involved are well-meaning, and there are almost always outside forces that affect things. However, I’ve found that applying these practices have helped me make things better. Please feel free to comment if you’ve had similar (or different) experiences.

Communication Lesson Learned

I recently learned a profound lesson in communication. Very early in my career, I was told by my boss that I was a good communicator. I think he was right. And since hearing that, I've worked hard on improving that particular skill. One thing I fairly consistently observed, though, was that would occassionally find myself having difficulty communicating with some people. It happened most often when talking with smart people that have expertise in the same areas I do. I found that each one of us would want to move the conversation along by talking over the other, assuming that we understood what the person was saying without them having to say it. In fact, that ususally started arguments, and resulted in the exact opposite of communication.

What really solidifed this lesson in my mind was a really good example of how not to do it. I recently had an experience in which a co-worker and I routinely had conflict due to mutual failure to communicate. This person consistently failed to listen, even after I told him directly that he wasn't listening. After butting heads a few times and becoming exceedingly annoyed with this person, it occurred to me that I also do this to others and needed to change my own behavior. Through this experience, I've learned to be more aware of this and let the other person finish his or her thought before responding. I also try to paraphrase back to them to make sure I've understood. This has helped considerably with my communication abilities. However, there's a catch.

The catch is that I have to be less concerned about myself and my own position, and more concerned that I'm communicating effectively. There's a very real possiblity that what I was going to say gets lost as the opportunity to say it passes. However, by practicing this, I have found more than once that the other person actually says what I was going to say if I just let him or her finish.

Thinking about this reminds me of a time years ago, when I was part of a consulting team at a customer site. The primary customer point of contact was difficult to work with and didn't listen well. During a particularly contentious meeting, one of the executives sat quietly through the whole thing, and waited until the discussions/arguments wound down. Then, he very quietly summarized the problem at hand, and offered a clear way ahead. I was impressed with both his restraint and insight, and seek to emulate that now.

The downside? I now become more annoyed than I should when I observe that behavior in others.

So what am I really saying? Basically, I've finally internalized Stephen Covey's Habit 5: "Seek First to Understand, Then to Be Understood." It's critical to good communication, and it seems that it's not a natural thing to do for most people. You might say something like "everyone knows that!" Maybe so, but did you know that you can save 15% or more on car insurance with Geico?