Organizational maturity and the process of maturing an IT organization is a difficult and painstaking process. This can be accomplished – without losing your hair – by breaking the changes down into more manageable steps.
Recently we worked with a large government agency that maintains a worldwide network and provided IT services for a variety of government customers. Much like a commercial company, this Federal agency needed to address growing operational costs and speed to market issues with new technologies that were in demand by customers. The organization was in a culture of “one-offs.” What I mean is that the organization could best be described as a requirement-based engineering organization, which addressed each customer requirement with a unique engineering solution. As you can imagine, this was very labor intensive, and did not scale, which led to solution incompatibilities and long service delivery cycles.
Eat the elephant one bite at a time, and then laser focus…
Pick an area of high value that you build consensus around. In this case the focus at first was on automating the infrastructure and service provisioning process, mainly since the organization was at that time in the middle of the deployment of their next generation infrastructure. In order to accomplish this, the organization needed to move from viewing themselves as a requirements fulfillment shop to a provider of standard services. This change was well timed as it was begun just as the organization was working on a document to describe the services and capabilities that could be provided by their new network infrastructure. Standardization of the network infrastructure and services offered was necessary to enable automation of the infrastructure and services provisioning, but this regimentation also benefited the organization by minimizing the amount of documentation necessary for each infrastructure node installation and providing more predictable service characteristics. In addition, this led to a consolidation of network infrastructure and simpler architecture, which reduced provisioning from the normal days and weeks to hours and minutes.
Eat your peas please! (Document your processes)
Another key to success is documenting the organization’s business processes, which is necessary so that the processes can be enabled into a workflow management system. We all have processes on paper that sit on the shelf. Concentrate on processes that can be “enabled” quickly, leveraging technology for automation. I can see you cringing at the thought of this – endless meetings about boxes and arrows on a process flow diagram. Process documentation can be painful, particularly if the participants are not invested in the outcome. But as my father used to say, “this is why we call it work” or as my grandmother says, “you don’t have to like peas, you just have to eat them.” In our case, process documentation had been performed in the past, but had little direct impact because the organization was not required to follow the process flows. By “enabling” the process flows into a workflow management system, everyone in the organization was brought under a set of common business processes and metrics. As operational issues were addressed, adjustments were made to the workflow, which forced line level managers to think about how work within their unit affected other units involved in the overall process. The workflow management system became the common bond within the organization and dramatically reduced service fulfillment time.