Anyone who has worked with or around IT folk knows they don't like change. In our IT careers we've probably been part of an implementation of at least one major new service that might not have gone as well as we'd hoped. The key to surviving the next "big one" is learning to change the way we change things.
As IT professionals we live in a highly dynamic business and technical environment, and as much as we’d like to "stop the world and catch up" we really can't; nor can the organizations we support allow us to do so.
As today’s IT shops are forced to transform themselves into a new breed of service provider they must adopt a much more rigorous approach to the way new services are introduced into the IT infrastructure - I’m talking about a much broader scope than just ITIL’s Change Management and Release & Deployment processes.
I’ve used the term service provider in the past to describe the type of organizational approach IT shops need to adopt if they are going to be successful in supporting technology enabled business processes.
When one looks at what external service providers do to be successful it becomes obvious that they focus on the transitioning of their clients on their new service. They’ve developed the necessary rigor to ensure a trouble free experience for their client and to ensure the new service meets their expectations with the minimal amount of disruption and it provides the utility and warranty expected.
Below I’d like to discuss the “baker’s dozen (or so)” steps that internal IT shops can learn from our “professional” counterparts in the external service provider world.
This requires a well-written and comprehensive policy that establishes the intent of business and IT management, and includes the realization that new or improved IT capability involves all of the stakeholders (internal and external).
This also demands management commitment, not just involvement with ensuring that only fully defined and documented services are approved for design, development and deployment. This ensures not only that IT governance over IT resources align with business goals, but also that clearly articulated and measurable business outcomes have been identified so that value and the achievement of that value can be measured.
We’ve probably heard someone lament that they “don’t have time to do Change Management and get their work done.” These are normally the same folks that seem to find time to fix the stuff that didn’t work as the result of the change they just put in. So, what is a good manager to do?
The short answer is that there is no such thing as “change lite” and that following the process is not optional. Therefore the establishment of a “new normal” is required (nope it’s not optional either). To some people this may sound a bit too strict or too rigid and takes away personal initiative, but it isn’t if you do it right. Implementing organizational change is probably the hardest part of implementing any form of Change Management process. The only real guidance on this is it’s a “management 101” issue and should be treated as such. You don’t need to go to an ITIL training course to figure out how to do this.
There are a whole bunch of really smart people in the world and a lot of them have written books and courseware and contributed to extending the overall body of knowledge about managing and delivering IT Services.
ITIL probably has achieved a de facto standard status and has the grassroots support of the everyday practitioner. While ITIL shouldn’t be consumed with Kool Aid, it does represent a serviceable framework for the design, development, deployment, operation and improvement of IT services. When combined with other frameworks such as COSO and CobiT, and combined with well-established methodologies that deal with quality, program, and security management, a reasonable model can be developed that addresses the vast majority of the issues that today’s IT organizations face. Adopt and evolve; don’t invent.
I suppose we’ve all heard the joke about keeping old ties since they are bound to come back into style. We can probably say the same thing about existing processes, procedures and tasks associated with change related activities.
Often IT organizations have processes in place, and sometimes they are even followed. Before reinventing the wheel yet again, check to see what is in place, documented and used. There may be a “disconnect” among the three, but it at least gives you a starting point and can save significant time. The existing processes, procedures and task represent the current state and using them as a basis for the evolution of new processes, procedures and tasks will save considerable time, effort and money. In other words; “recycle.”
At the risk of belaboring the point, it’s a good practice to ensure the business is involved at all stages of a change to an IT service for a number of very good reasons. The business is required to ensure its needs are being met and that consideration is given to potential interruptions to the normal business cycle and other aspects of business operation. While this seems to be painfully obvious, we can all remember what happened to the Victoria’s Secret website when their now famous ad ran during the Super Bowl. Enough said.
While we don’t need to sit around the campfire with our business customers making s’ mores and singing campfire songs, it’s always been a good practice to ensure your stakeholders are aware, informed and committed to the changes that are being undertaken. This avoids plausible deniability should things go wrong, and when someone can’t duck responsibility the only alternative is to do things right. While that may seem a bit cynical, it’s just good practice to keep your stakeholders close. Crunch time is not when you want to find out your stakeholders were involved but not committed.
The control I’m referring to is the control of the resources required to bring about the development and deployment of new or improved IT services. Any change to the infrastructure must meet the objective criteria established to ensure the benefit to the business of any new IT service or the improvement of an existing one. The same goes for the mitigation of risks associated with any change to the IT infrastructure. Governance (control) must extend from the top to the bottom of the business and IT organization (don’t forget the vendors too) to ensure the most efficient and effective utilization of IT resources (people, information, infrastructure & applications).
Peter Senge created a major cult following with the publication of his book The Fifth Discipline. In the book he talks about the “learning organization” and how it creates, retains and manages knowledge for the benefit of organization. This doesn’t happen by accident, and IT organizations must actively plan for and adopt good practices for managing knowledge.
Very seldom do we come to work and do something truly new and unique; yet all too often this knowledge is disseminated within the organization by word of mouth, on the job training and other transitory means of communication; it becomes “tribal knowledge.”
When you lose a tribe member you lose the knowledge that tribe member has accumulated. ITIL’s Service Knowledge Management System is a structured way to ensure the knowledge of an organization is captured and organized in such a way that it is persistent in nature and reusable by those that may find it useful in the future.
This is probably another example of overstating the obvious, but how many times have we seen the “oops factor” crop up during the rollout of a new service; like launching your boat with the drain plug unscrewed … “oops.”
The whole idea of putting effort into planning the deployment of new services is to avoid the “oops factor.” Planning how a new service will be deployed requires thoughtful consideration of how the changes are to be packaged, tested, and deployed. That means that the business and IT sit down and think through all the aspects of what it will take to get the new service into production. Yes, it takes the coordination of both the business and IT resources to make it happen.
Really successful IT organizations have developed cultures that empower staff members to make decisions as far down in the organization as possible. This is not the same as letting the inmates run the prison, but rather a structured approach to pushing the authority down into the organization so the decision cycles are shorter and the organization can be more flexible, thus more responsive to changing conditions or opportunities. Care must be taken to retain control of the process, but not through passing decision making up and down through a hierarchical organization. With a clearly articulated plan, cascading goals, objectives and metrics and appropriate oversight the best people to make the decisions are empowered to do so.
This was the caption on one of Gary Larson’s famous Farside cartoons. Three buzzards are sitting on a tree branch overlooking a desolate desert landscape and one of the buzzards turns to the other two and says, “To hell with this waiting. I’m going out and kill something.”
I’ve always thought that cartoon as a great example of proactive management. Don’t wait for something to happen, go make it happen. This approach, when applied to the launch of new IT services is the key to uncovering and correcting problems before they become problems. The Japanese auto industry taught the American auto industry that you can’t audit quality into a product; it must be built into the product. That means the processes that produce the product must be continually monitored and reviewed to ensure they produce the desired outcomes with the optimal consumption of resources. That doesn’t happen without someone (management) going out and looking for problems; ensuring the processes work.
A quote often attributed campaign worker for the late Mayor Richard Daley of Chicago it reminds us that we need to get the stakeholders involved in the process of implementing a new service very early. Many times the business stakeholders feel that once they tell someone what they want all they have to do is sit back and wait … kind of like making toast.
While it’s true that not all stakeholders will be involved at the same level of detail through the lifecycle of a new service deployment it is imperative that the stakeholders become involved as early in the lifecycle as they can be of use and contribute to the overall success of the effort.
… or do you? For years and years IT’s dirty little secret was that lots of the time the “promised benefits” in the terms of ROI on new IT Services was not being delivered. Well, that is probably not totally accurate; the facts are that very seldom is there a structured effort built into the transition of new IT services that ensures the real benefits are realized. This is not an issue of playing “gotcha” but one of clearly articulating what was needed, designing it, building it and verifying that IT delivered the required value with the new IT service. Successful IT organizations, as a normal part of the IT service lifecycle, embed the necessary processes and procedures to assure the quality of new IT services.
While this may be true of steaks, wine, and whiskey it doesn’t necessarily apply to processes. It should, but it’s not necessarily true. What IT organizations should be doing as part of normal day-to-day delivery of IT services is to be on the continuous lookout for ways to improve those services. This doesn’t always mean looking at the technology, but also at the supporting IT service management processes. Continuous process improvement is one of the keys to the successful transformation of today’s IT organizations to tomorrow’s IT Service Providers.
Changing any IT infrastructure is fraught with danger. It’s something that should not be undertaken lightly. IT organizations that have mastered the “art” of transitioning services into the live environment have done it by turning it into a science. Probably the simplest way to think about the problem is to understand a structured approach for the development of:
The key to surviving the next “big one” is learning to change the way we change things. If we do that, we change our goal from surviving to thriving with change.