The market mindset means “your users determine value”
ITIL’s Service Strategy writes about adopting a “market mindset:” services are investments that should be added to your portfolio in terms of the value they provide. But to understand the “market mindset,” and how it can be helpful in higher education where we don’t really think about return on investment, please dive into what defines value.
All value is perceived value: witness pet rocks. Or, witness Google Wave: a technology with lots of whiz-bang first-of-its-kind Javascript and interactive content, but a technology that was never perceived as valuable and therefore failed.
Perceived value also changes over time. Email, as an example: in the 1980s, email was something you could brag about running; in the 1990s, your users liked being able to use IMAP to check mail; and in 21st century, the main goal of providing email is to keep people from being unhappy about it. In large part this is due to the commoditization of email, where people have free benchmarks like Gmail against which to compare your service.
Focusing on value ought to be very important to IT departments, especially now as IT is better understood by its users. In the second half of the 20th century, people just threw money at IT and trusted that something useful would happen. Now, IT must justify its budget, and it’s quite hard to start justifying a million-dollar operating budget. Although IT people recognize that technology changes rapidly, we sometimes seem to stick to outdated principles like that we know what’s best for users.
Here are a few simple, effective approaches for better understanding and delivering value.
First, listen to users. Many times people find huge value in things that IT overlooks. IT training is a good example: training people in that new tool you’re implementing takes very little effort, relative to the implementation, but can dramatically increase the perceived value of your service.
Listening here means open listening–checking in monthly with users and user groups and asking them how things are going with IT, or what they’re working on. This open listening is listening for things that aren’t on your radar right now, and it can be hard to do. But maybe you find that people are talking about a need for calendaring, and you already have a calendaring system that would work!
Second, find quick improvements to your current state. When people build services or improve services they often use absolute decision-making: let’s make this service the best it possibly can be. While it’s great to shoot for the stars, what are things you can do this week or this month to improve service?
For example, when I rolled out a new ticket-tracking tool, several people told me, “wow, I can finally submit tickets from off campus!” Just having a way to submit tickets–even a super simple way–was more valuable than what we had before.
Sometimes these improvements can be hacks–using cloud-based services temporarily until your new infrastructure is on-line, or hiring student workers until you can automate a process–but by delivering value you’re getting users’ attention and you’re helping ensure you can complete the improvement. Projects that don’t deliver value until the end are more likely to be cancelled.
Third, double-check your assumptions. When you think a service is delivering value, check with users to see if it really is. That new billing system may have been built to requirements, and users may have signed off, but they may not have realized much value.
I have a habit of sending emails that start with, “Just to make sure we’re all on the same page…” followed by my assumption. I send these when I think a group of people all are in agreement. I cannot tell you how many of these emails turn into a long email thread where I realize that people in fact were nowhere near the same page.
Fourth, build your architecture for value-providing services. As you understand what users request and value, certain types of services may surface. As you understand where future value will come from, define the patterns and architecture that will help you deliver that value.
For example, if users particularly value integrations between tools, make it easier and easier to integrate tools through identity and access management systems, message buses, and APIs. If users particularly value web-based content, make it easier to spin up web instances and web services. If users particularly value IT communication, build patterns you can use weekly, monthly, or in project plans to ensure users receive useful, quality communications.
I would close by saying that, when you’ve done all the above, you’re ready to start thinking about defining value: Deming talks about how customers buy what the market offers, and all innovation comes from producers. But for most IT departments, if we’re just able to deliver what users are currently asking for (and we are exceedingly lucky in that users still have constant demands for IT service) we will be doing a superior job.