When EQ Editor Nancy Hays gave me the opportunity to contribute the Alternative IT Sourcing column for 2011, I was sure I'd have a chance to tell some good stories about things we'd successfully sourced in a new way. A couple of projects were moving forward nicely. In hindsight, I was counting on these chickens before they hatched.
While the eggs of those two projects continue to incubate, I find myself thinking about how tough it is to talk about the challenges we all face with our colleagues when determining the best way to deliver IT services. Not just the how, but also the what. My organization delivers services today that might be better sourced externally or even retired entirely from the catalog of services. Should we provide on-premises e-mail and collaboration tools, or rely on the commercially available external services? Should we change processes and procedures to fit more neatly into a vended software solution for an application, or continue to develop customized solutions? Some institutions rely on "IT change managers" to help with the preparations necessary for implementing new systems and new ways of doing business. An important question runs through this topic of sourcing IT differently: "What story do we want to tell?"
Change, Fear, and Football
At Princeton, we changed how we delivered our main emergency web presence about a year ago by working with colleagues at Duke University and swapping some virtual machines. Today, our emergency web presence is operated from Duke — while a commercial company checks the heartbeat of our main web page and redirects visitors to the virtual machine located at Duke should the need arise. As it turned out, we have ended up with a great story of collaboration, new relationships, and a success story in alternative IT sourcing.
For many IT staff (and others in the academy), the prospect of sourcing our services rouses great anxiety. The prospect of change creates palpable tension. Let's take the example of Princeton's emergency web presence as an example: Even though we had complete confidence in our architecture and enjoyed our new connections with colleagues at Duke, there was still trepidation about going with a commercial firm that would negotiate swinging web browsers between Princeton and Duke.
This actually was not an unreasonable response.
The most challenging aspect of the project was the tension involved in making the best decision and communicating the "story" to all involved. Each of the players and stakeholders experienced this tension differently. For some, it was a source of inspiration, with grand visions of virtual machines everywhere. This project meant a new beginning, a new model for delivering services. For others, the change invoked a bit of the flight/fight response. There was uncertainty about delegating the control of our main web address to an outside company.
In his book How We Decide, Jonah Lehrer combs recent neuroscience research to explain what is happening in our brains when we make decisions. One of the many fascinating tidbits scientists have now confirmed using brain imaging is that our decision-making abilities are significantly influenced by fear.
We might gain insights about the way we view business model changes by looking to the world of football. The sport's terminology illustrates wonderfully how the word "change" can introduce the notion of "losing control" and of all the attendant difficulties it implies. Unless our team has scored points, we are not happy about a "change of possession." No points for our team can only mean a punt, an interception, a fumble, or a safety for the opponent. These are all bad. Now consider the language broadcasters use: they talk about teams advancing the ball toward the goal line. They talk about successful drives and the offense holding on to the football to maximize time of possession. They always avoid language describing the loss of "control of the ball" or a "change of possession."
So, the language we use when discussing the topic of sourcing IT services may well be important. How do we evaluate and decide whether a change is necessary now or later or at all? Many factors decide the particulars of how we advance the ball to the goal line, depending on our institution. How we determine the next steps and how we communicate them can mean the difference between moving ahead with fear or moving ahead with the confidence of having a good story to tell in the end.
An Invitation to Experiment
I'd like to suggest a working hypothesis:
There is a language that communicates persuasively a successful way to source and deliver IT services.
To test this hypothesis, I'll need your help.
At institutions where IT service sourcing has changed or is well underway, how was the initiative broached with your staff? How did you communicate with your stakeholders? Did you use the word "change" or some other language? What steps did you take that worked well? What did not? For others of us, what language do we use to introduce the idea of new IT service delivery models and change? As homework, we can try to develop a new set of terms. Perhaps borrowing some ideas from the football broadcasters can help. There may be even better ways to talk about transforming the services we provide. In the end, the story we should tell will be about helping the institution progress toward its goals.
This idea about the language of change links to the two projects I have in progress. The decision to change the delivery of an IT service is really an opportunity to develop relationships — new and old — and to figure out a best path forward. The process itself can lead to unexpected outcomes if we do not carefully prepare our message. Based on conversations with colleagues, many of us have learned the importance of the language we use — verbal and nonverbal — and often in hindsight, rather than in real time. A number of years ago, I experienced this law of unexpected outcomes firsthand. I mentioned an idea to an enthusiastic programmer. By the end of the day new code was running — in production! I recall vividly how I tried to reconstruct the hallway conversation to pinpoint when and how we went from a half-baked idea to code in production.
Everyone has a certain temperament when it comes to change. An institution also has a temperament — or culture — around change. The pace of my two projects slowed as we talked about going ahead with a "not quite perfect" approach to delivering a service, or holding off and working to effect improvements in the future service. We chose the latter and extended our original project timeline. I realized taking the additional time is not a failure; it's a reasonable response to a complex reality. This chapter of the story is not quite complete.
Join the Conversation
How we decide to make changes is a complicated topic. A sometimes long and winding path, it can be influenced by a laundry list of factors. In the next few columns I would like to explore with you how the language, the conversations, and ultimately the relationships we build shape our approaches to new IT service delivery models. I'd enjoy hearing your thoughts about the IT service delivery models you are exploring at your institution and how you are advancing the ball down the field.
I hope you'll join the conversation. Contact me at email@example.com.
© 2011 Donna Tatro. The text of this EQ article is licensed under the Creative Commons Attribution-Noncommercial 3.0 license.