Contributed by: Afidence
Yesterday my wife asked me to provide a safe method of transportation for our children. Immediately, I thought of the safest vehicle I could and placed an order for two tanks that will be delivered to our house in about six weeks. She is going to be happy with this strategy as our children will be very safe while they are driving to school or getting ice cream. They are well worth the $16 million dollar price tag. Like this example, some IT strategies just do not make sense.
A well-defined information technology strategy is critical to any organization. It allows the IT department to create a business-centric vision. The organizations with well-defined information technology strategies operate strategically instead of reactionary. A structured approach ensures the right technologies are available at the right time to support business needs. A strategy provides transparency to IT projects with clear accountability for expenses and resources. The work performed by the IT department becomes an extension of the corporate business plan. The work is not viewed as a separate entity that might hinder progress.
So at this point, you are probably saying to yourself, “No kidding. Everyone already knows all about IT strategies." But many companies have no IT strategy. Or the strategy is to spend as little money as possible on technology. The goal of this article is to focus on organizations that do have an IT strategy, but need help refining the policy.
Many organizations begin with the admiral intention of implementing a best practice process. Yet many end up with lackluster or even negative results. Why? Because they did not take the time to understand the ramifications of the change. While similarities can be drawn between most IT organizations, slight differences in methodologies or company culture can impact the effectiveness of a solution.
For example, consideration should be given to both the company culture and the information technology department’s culture before selecting a project management methodology. Introducing an agile or scrum approach into a strict top/down militaristic style organization will likely create a state of chaos. The people who are accustomed to receiving their requirements in a well-defined document before beginning the project will struggle to understand and adapt to their changing priorities. These organizations use a succession of information sharing processes to disseminate requirements while gaining concession or acceptance at each level. They are not designed to accommodate the level of flexibility required to implement an agile approach. In comparison, a business which employs creative and artistic associates adapting a waterfall methodology could experience feelings of stagnation and frustration with the formal and rigid processes. Most creative teams are not too interested in sitting down at the onset of a project to develop a charter, determine the project budget, and lay out all the definitive milestones.
All three of these methodologies have been used by multitudes of companies. But, that does not convey that all three are the right choice for any single organization. Understanding your team’s culture and composition will provide the best opportunities for success.
Another strategy trap that many organizations fall into is the belief that best practices are instructions to be followed and implemented exactly as they are written. This method can create a tremendous amount of effort and cost that is just not needed. Take the Information Technology Infrastructure Library (ITIL) for example. ITIL is a framework that is designed to standardize the way IT services are delivered to a business. It is an outstanding way for most companies to improve the effectiveness, efficiency, and predictability of their IT services. But at the end of the day it is not a plan, but rather a framework. The ITIL framework says that you should measure the delivery of your IT services and use those measurements to make improvements to your processes. However, the IT plan might state that you should reduce the time between the first notification of an issue and when the issue is marked as resolved by 10%. Companies must be ready to understand what parts of the framework are right for their organization and then adapt those elements to be effective.
A common area of struggle is with the classification of tickets within incident management. One approach has been used for many years. It requires service desk agents to select categories to classify the type of help needed. For example, if the agent has determined that the caller is having a problem with their word processor application, the agent might select the following categories:
Software / Microsoft / Word
Or the end user might be having a hardware problem with their desktop computer which would lead to these categories:
Hardware / Lenovo / Desktop / Model XYZ
Consider the number of permeations that would be needed to support a medium sized company with 2500 unique applications and 20-30 different models of desktops and laptops. Depending on how the categories are created, a company can end up with tens of thousands of possible combinations. The potential pitfall to avoid is creating categories and sub-categories that are not necessary. When planning categories, start with the end-result in mind. Consider what you are going to do with the data from the categories. Chances are that you will use this data for two functions:
1. Categorization will determine which support team is assigned the ticket.
2. Reporting and metrics to identify top issue types.
Every effort should be made to keep the environment as simple as possible. Avoid adding extra resources and cost to your support model. The issue is not so much with having to store the data. Rather, the issue is with the time spent by the service desk agents to pick and enter the data. If the service desk handles an average of 200 calls per day and each call requires 15 seconds to categorize, then the service desk is spending over 216 hours each year just entering data. This method may or may not be an issue depending on the value you receive from the effort. For instance, let's say you run periodic reports to determine the failure rates of various desktop computers. Then, you take action to replace the units with the highest failure rates. The cost avoidance you achieve by eliminating the end-user downtime coupled with the cost of supporting the failing technology may offset the upfront costs of capturing and analyzing the data. If, however, your organization has implemented a five to six year refresh plan for your desktop computers, and you are forced to stick to that plan regardless of failure rates, then there is no need to design and implement a system to capture and analyze the incident data. You can create a reduced set of categories that only facilitate ticket assignment and eliminate the costs associated with a more detailed system.
Excellent technologies, services, and methodologies are available to help you improve your IT delivery. Having a robust IT strategy within your organization is directly correlated to the level of success you will achieve. The heart of a strong IT strategy is common sense. You have the knowledge of your company culture. You understand how your team and your business customers will respond to different scenarios. It is up to you to put that knowledge to good use and make the intelligent decisions about your strategy.