Service Management efforts tend to be driven from the top down, but I have seen more often than I wish these efforts not fully germinate down at the technical team level. From my experience, the surest way to achieve success is to establish a culture of service management at the grassroots level, with the support and encouragement of the top levels of the organization.
The question then becomes how to do that. It is easy to take care of the top levels - with presentations, maturity assessments, roadmaps, and high-level project plans. At the grassroots level, though, what does service management look like?
Recently I had the pleasure of assisting an organization that was newly established as part of a reorganization. Bits and pieces were taken from this place and that to create this new organization. The organization had hit the ground running, so to speak, and was plugging away heroically to meet their daily demands.
We were brought in to assist with a particular project, and I was on the team to help our folks understand the client’s policies and processes and to ensure that our work was accomplished within them. On my first day, however, I discovered that little to no documentation could be found. They had standardized ways of doing things, but no one had yet captured them in a digestible format, being on sticky notes and pictures of whiteboard sessions saved on so-and-so’s phone. Truly this was the “tribal knowledge” state described in various maturity models – processes were passed on by word of mouth and the loss of one or two key individuals would impact the organization’s mission for some time to come.
The client asked if I would “document our processes”. What they meant by this was to capture the “how to” of their major activities and ensure that these activities were complete. But as a service management person, it is not enough to do just that – I wished to ensure that their activities support their mission and the mission of the larger organization, that everyone clearly understands their roles and responsibilities, that they have some way of determining how well they are doing, and that they are creating value. By doing so, a culture of service management could be grown.
After completing all that, the client asked me what approach I used so that it might be repeated within other organizations, and, upon reflection, it occurred to me that I actually had taken a structured approach without realizing it (how shocked I was!). For their benefit I captured how I thought about things and I present that here in these next few entries.
By defining these basic things for technical teams, the soil is made fertile for larger service management strategies. You must define your mission, activities required to accomplish that mission, the roles that perform the activities, the methods used by those roles to perform the activities, and the metrics that will determine how well things are proceeding. This is by no means all that must be done, but it goes a long way.
Figure 1 - Approach to providing basic IT organizational documentation
I’ll cover mission in this entry and deal with the other steps in entries that follow.
Mission
Determining an IT team’s mission always starts with the question “so what do y’all do?” (at least that’s how I ask it). The first answer is almost always technical in nature – “we manage firewalls and other perimeter security devices”, for example – and further questions must be asked. Ultimately the goal is to write a mission statement that does at least two critical things: relates to and supports the larger mission and reflects in some manner the value the team delivers to the organization.
Towards this end, the next questions are about where the team fits into the overall picture. Mission statements are needed from each of the direct line blocks on the org chart. In this way, the mission statement of the team may incorporate elements of the higher organization(s). Vision and strategy presentations from higher up the food chain may also provide inspiration.
Next, scope must be determined. The team’s mission may only be scoped to certain administrative boundaries.
Lastly, the value statement must be developed. My dad taught me that sometimes it is easier to understand what something is by defining what it is not, and value statements may be approached in this manner, at least for starters. What would happen if the team did not exist – if its mission were not being accomplished by anyone? This line of thinking can get you started on the road of determining value.
Take our example firewall and perimeter security team. If they did not exist (of if they fail at their mission), corporate and customer data would be at great risk, potentially resulting in loss of competitive advantage, reputation, trust, and the cascade of consequences that go along with that. Their mission statement might start with something like “To protect corporate and customer data by…” and I’d be willing to bet that the need to do so could be found in the corporate values and commitments to customers, therefore linking this team’s mission to the larger picture.
“To enable our company’s commitments to its customers and shareholders by protecting corporate and customer data, as well as corporate computing assets, through the operation and maintenance of a host (no pun intended) of perimeter security devices, preserving competitive advantage and contributing to a culture of trust.” Not perfect, I’m sure, but much better than that with which we started.
Linking the team’s mission to the larger picture and emphasizing the value the team brings sends a message to the team members that what they do is important – it’s not just a daily grind. It also demonstrates clearly to higher-ups that this team understands the big picture and is committed to helping achieve the larger mission – rarely a bad perspective for your boss and your boss’s boss to have on you.
In the next entry, we’ll look at the second step in this approach – defining the activities that must take place in order that the mission be accomplished.