A Business Technology Place

The truth about IT processes.

Part 3 of 3 – The Truth is…. I’ll share some truths about developers, managers, and processes in IT.

Writing about processes in business and technology has a gravitational-like pull.

I’ve written more on the topic of technology processes than any other topic since I began blogging in 2008. Some of my favorites include posts on process improvement, hiding behind processes, simplifying processes, and the purpose of processes. Process management is a topic that we’ll always have because it creates the model and basis for the underlying flow of business transactions. Unfortunately it’s at the forefront as an underlying contributor to some of the dysfunction between IT groups and their partner business functions as well.

I have always aimed to create environments that use processes with the goal to allow employees flexibility to make decisions that help the customer. That statement sounds so obvious that you could say it’s a given. But I don’t think it’s a given because many processes I’ve been a part of in the past seem to be centered on the process itself rather than the customer. My career has been influenced by what I considered overly burdensome processes and watching employees make decisions for the sake of checking-off a process step instead of getting done what needs to happen. Jim Collins in his book “Good to Great: Why Some Companies Make the Leap… and Others Don’t” states that “Bureaucratic cultures arise to compensate for incompetence and lack of discipline, which arise from having the wrong people on the bus.  A culture of discipline involves a duality. On the one hand, it requires people who adhere to a consistent system; yet, on the other hand, it gives people freedom and responsibility within the framework of the system.”

Finding the right mix.

The duality that Collins speaks of is goal I set when I define a process within a group of IT professionals. That’s not easy in an IT group because programmers think in 1s and 0s or black and white. Something is or it isn’t. Here are a few examples:

  • Define a process that sets the criteria for when a work request is treated as a help desk ticket and when it requires review from a steering committee.
  • Define a process that set the criteria for when it is necessary to run a full regression test on a software product.
  • Define a performance management process for how to evaluate desktop/voice services personnel that use a job ticketing system for work management.

Some truths about IT processes.

  • Your opinion about processes from the IT group is highly dependent upon your role in the process. Those that have to follow a process to receive a service tend to try to find ways to take shortcuts. Those that have to follow the process to provide a service tend to like the process because it protects their time commitment and is correlated to their performance ratings.
  • IT processes are influenced by multiple sources. Standards organizations, litigation, process and frameworks are the most common sources. But sometimes processes are created to counteract bad behavior from IT employees and business customers. Processes that continue to add steps to offset bad behavior will lose sight of servicing the customer.
  • Every standards organization believes their process is the best. There are variations to software development lifecycles and spirited debates about what works best. The reality is that business environments and cultures vary. The best processes are the ones that fit and mold to the culture in which they exist and that stay focused on the customer.
  • Most people don’t avoid a process because they don’t believe it will help them. They avoid the process because they think it will take too long to get what they want. It’s the same concept as a driver that intentionally chooses to not get in a traffic line (stop light or interstate backup) and move forward only to cut-in-line later.
  • IT processes, like every other type of business process, exist to create standardized work, efficiency, and quality. They should never be considered complete but only in a state of production that includes measurement to see if adjustments are required.

Onward and upward!