Stakeholders and Service Level Expectations

Information Technology hardware, software and services are becoming an increasingly integral part of organizations. Along with this come many users who rely on one or more systems that IT supports. With this said, different groups have different needs.

For example, payroll may need access to the payroll system only from 8 a.m. to 5 p.m. whereas production may need access to the scheduling system 24 hours per day and seven days per week.

Thus, in order to appropriately implement service level management (SLM), an Information Technology (IT) group must understand who relies on their services and why in order to assign resources, budget, etc. This "stakeholder mapping" is essential to building a strong foundation of a SLM plan and is the topic of this column.

What is a Stakeholder?

A stakeholder is someone with a vested interest in what IT has to offer. Stakeholders can be viewed individually or grouped together. For example, John Smith in accounts payable is a stakeholder of IT in the he has a computer, printer and uses a variety of applications. He can likely be grouped with all of accounts payable to create a general picture as to the needs of that team.

What is an Expectation?

Expectations can be viewed as pre-conceived needs of the user. In other words, the user, or group of users, believes that certain things should be a certain way. For example, they may expect the system to be available whenever they need it and have sub-second response time. Now, whether their expectations are achievable is another story and this is why it is important to understand what the users expect.

Many times, conflict with IT arises from unrealistic expectations from the users or simply IT's failure to understand true expectations. This is the "ivory tower" scenario wherein IT makes erroneous assumptions about the user community's needs and fails to either provide effective solutions or manage expectations to realistic levels.

Variables to Consider when Mapping

The best way to determine expectations is to actually meet with users and discuss needs. Be careful to hold discussions with people at the appropriate level. If the people are too high, then the tactical real-world needs may be overlooked or misunderstood. At the same time, if the people are too low, then the direction of the team may be missed and seemingly abrupt changes will be due to a lack of awareness.

With this said, there are a number of variables to consider. Some may warrant discussions with the stakeholders, some with the organization's upper-management and some will require IT to make decisions. This negotiating and subsequent common understanding are at the heart of establishing effective service level agreements.

At any rate, some initial topics to cover include:

1. Stakeholder Group Identification (For example, "Production")
2. Date of stakeholder interview
3. Date last reviewed by IT
4. Hours of operation
5. Contact information via an escalation list
6. Itemize the:

Hardware used

Systems used

Services used

7. For each hardware, software and services line item, detail the following:

How critical is this item to the stakeholder's operations?

What happens if this item is unavailable?

What value per hour does this generate?

What cost per hour is incurred if this line item is unavailable?

How long do the stakeholders feel they can operate without access to this line item?

How critical is this on a scale of 1 (low) to 10 (mission critical)?

8. How vital does management view this team's function?
9. How long does management feel the organization can afford to be without this function?
10. What is IT's perspective on the stakeholder and their line items?

What are the issues associated with each line item?

What are the risks?

How can the risks be potentially mitigated?

This list should not be viewed as all-inclusive but rather as an example of the types of items to document in a map. The data collection can be readily done in Excel or Access and it helps to consolidate the map data and look at the needs from an organizational level. In other words, be sure to look at the data from a consolidated high-level as well as at a departmental or team level. The intent is to use the maps to identify expectations from which requirements and action plans will be developed.

Keys to Failure

There are two key issues that you need to remember. First, IT has finite resources. When discussing needs with the stakeholders, be very careful not to set expectations that things will be perfect and all needs met. It is far too easy to accidentally change or set expectations through miscommunication.

The purpose of the mapping process is to collect data from which plans will be assembled and/or reviewed. Be careful during the process to not set expectations that can be very problematic later on. In other words, without a consolidated organizational view and careful review, it is dangerous to make commitments with each stakeholder. This goes to the adage of "You cannot be all things to all people."

Second, meeting with the stakeholders is not a one-time event. The mapping process needs to be done regularly to assess the needs of the stakeholders. As the organization evolves over time, so too will the needs of the users. Be sure to communicate with the stakeholders the review schedule so they can have the proper expectations about the formal process. It is vital that stakeholders understand the purpose of the mapping and the reason it needs to be formal versus something that changes every day!

Summary

In order to begin planning or review current plans, IT must understand the needs of the various stakeholders. One way of identifying needs is to conduct interviews and create stakeholder maps wherein the various IT hardware, software and services used are identified along with data concerning the vitality of the group and each of the identified line items.

It is very important to understand stakeholder expectations in order to have a foundation upon which to keep IT aligned with the organization's needs. Far from being a one-time event, stakeholder maps should be reviewed routinely to ensure that expectations are clearly understood such that appropriate actions can be taken. Managing those expectations is a tall order and will be the topic of a future article.