* How to identify what's critical
The last newsletter discussed the fact that the conventional wisdom in our industry is that IT organizations need to offer service-level agreements internally within their company. That newsletter also pointed out that in many cases the SLAs IT organizations get from their WAN service providers are not that impactful and raised the question of what should IT organizations do differently to ensure that their internal SLAs are impactful. This newsletter will provide a part of the answer to that question.
As we mentioned in a recent newsletter, we strongly recommend that IT organizations establish internal SLAs for a few key applications and services. Few people would disagree with that recommendation. However, while it is easy to make the recommendation, it can be very difficult to actually implement it. For example, in many IT organizations it is not culturally acceptable to publicly state that some IT resources (e.g., applications, WAN links, servers) are more important than others.
The problem that presents is if the IT organization insists that every IT resource receive the highest level of attention from the perspective of both planning and ongoing management, then every IT resource must also receive the lowest level of attention.
Assuming that the IT organization can get over that cultural hurdle, the next challenge is not to identify the critical applications, that is usually pretty straight forward. The next challenge is how does the IT organization market this information? Does it, in an attempt to ‘align IT with business’ tell the company’s business unit managers (BUM) which of their applications and services are deemed to be critical and which are not? That approach leaves the IT organization vulnerable to pushback from the BUMs that all of their applications are critical. Analogously, asking a BUM to identify which of the applications that support their business are not critical, may not be the best approach.
Some companies have an IT steering committee comprised of BUMs and functional managers. The typical role of an IT steering committee is to make recommendations on the IT budget as well as to assist in the prioritization of key IT initiatives.
If such a steering committee exists, another option is for the IT organization to make recommendations to this committee to identify of the company’s key applications and services. In some cases this will cut back significantly on the amount of pushback that the IT organization experiences. In those instances where this approach will not work, the IT organization may decide to set SLAs for a few key applications and not bother to make a big deal out of this outside of the IT organization.
Assuming that the IT organization follows the steps that we will highlight in future newsletters, this positions the organization to better support the company’s key applications. For better or worse, this approach simultaneously requires that IT organizations be ready to apologize whenever the performance of one of the company’s other applications begins to degrade.
We continue to seek your input about your experience with SLAs. In addition, the next IT Roadmap conference will be held in Chicago on April 2. If you are in the area, try to attend as we will continue the discussion of how IT organizations can best cope with the current economic challenges.
