Monthly Archives: July 2008

Another Look at Change

Change means doing new things, but it also means letting go of old ones:

“We all cling to our projects, our directives, especially if they are the bulk of what defines our position, or a whole department’s identity. But what if that directive, like Mr. Smith’s, was outdated, was in the way of progress, or harmful? Would you continue on course or would you question it?” — Nikki Massaro Kauffman

——–

John Gruber on Jamis Buck on Estimating

Imaginary work is always easier to do than real work. It is much more attractive (being more quickly done) and once you see the imaginary work, it can be very difficult to identify the real work it masks. People estimating imaginary work often assume they have all the facts in hand when making their estimates, which assumption leads them to believe that there is no “big technical hurdle” preventing its implementation. — Jamis Buck

These users are inevitable, and they never cease to annoy. But no product team will ever be successful without the confidence to know when to ignore them. What these users want is everything, and if you try to do everything, you will fail. — John Gruber

——–

Change, Flexibility, Recognition

I just listened to a news story on the radio about General Motors. They have established brands and methods for producing those brands. Unfortunately for them, their marketplace is in a period of change. Their customers have changed their needs and GM has to adapt to the new conditions. This is not the first time this has happened. In the past, when companies have successfully adapted to a changing marketplace, it was because of flexibility. I hear many people saying that we need to be more flexible, too.

The news has a funny way of focusing on the bad. My memory of this type of story is that they follow this line: a series of plant closings; followed by business closure; followed by persecution of management in the media and the courtroom; followed by second-guessing on what could have been done from people peripherally involved who could have done something but didn’t. Rather than repeat that cycle, let us jump to the end and try to learn from it.

After the fact, everyone recognizes that the cause of the failure was a lack of flexibility. The company should have made smaller (bigger) cars. The company should have made more fuel-efficient (powerful) cars. The company should have made more family-oriented (sporty) cars. The company should have made what the market wanted when the market wanted it.

To their credit, most companies are in business today because, through serendipity or generally good business acumen, they made what the market wanted when the market wanted it. The trick to longevity is recognizing when the market has changed its mind and being flexible enough to change to producing what the market wants.

As an organization, we have talked about change. We have talked about how we need to be flexible. We need to let go of what our customers no longer need so we can target our energies on what they will need next. Letting go is hard, but we can all work together to accept it (denial, anger, depression, bargaining, acceptance). Wait a moment, though. Look back at the last sentence in the last paragraph. We are working backwards through it. There were three concepts that made up the “trick” in that sentence (in reverse order): change, flexibility, and recognition. We already talked about change and flexibility. They are hard things because we live with habits and like to have others tell us what to do. But, what about recognition? That is the key to the trick, but we have not talked about it.

Recognition for an organization starts when the individuals who make up the organization are in touch with and aware of the needs and wants of their customers and then they communicate those customer needs and wants freely, openly, and honestly to the largest possible audience. Share what you know, learn what you don’t.

How does all that happen? That is the easy part. All you have to do is ask.

Are you interested in weight lifting? There was just another successful Lift for Life. Go introduce yourself to one of the people involved and ask them about it. Learn about what they do and ask yourself if what we do helps or hurts their efforts, or is completely irrelevant. Communicate what you learn.

Interested in fine art? Go find one of the people involved in research on digital systems for detecting forgeries. Ask them about their research and ask yourself how we might make a positive contribution. Communicate what you learn.

Interested in earthquakes? There is a group of people studying the recent earthquake in China. Go talk to them about what they do. Ask yourself how they could benefit from what we can do. Communicate what you learn.

Find a faculty member, researcher, or administrator. Find a student organization that might be of interest. Introduce yourself and ask them about what they do. You do not have to sell them anything. You are trying to get in touch with our customers and become aware of what they do. That is the mission of the University. When we say we support the University that is what we mean. It is not support as in “Hello, this is Microsoft Technical Support.” It is “With the support of all of us, we can do what each of us cannot do alone.”

Get out of your office. Bump into someone you do not know and say, “Do you have a moment? Can you tell me what you do at the University?” Recognition, flexibility, and change all start with you.

——–

You’ll Never Believe This

I have this crazy idea. I want to form a committee. I know… but I really do. I have this idea for a service that the University should have. (Notice I didn’t say who should provide it or even what “it” is.) I’m thinking this service has a transport component, so TNS should be involved, but I don’t want to make it a TNS committee. I’m also thinking that there will be an authentication component, so AIT should be involved, and of course there is a security component, so SOS should be involved, and yet I don’t want to make it an ITS committee. I’m thinking this will have a distributed IT component — you know that IT at Penn State is bigger than ITS, don’t you? But I don’t want to make it a Penn State IT committee, either. This service has a huge end user component. After all, what is the mission of IT at Penn State if not to support the University’s teaching, research, and service missions? And, what are those if not the embodiment of our faculty, staff, students, researchers, and so on — the users of our services.

You begin to see why I don’t want to narrow the focus of the committee too much. I have this crazy idea that a service should be formed with input from all of the stakeholders. It should address real users’ needs and wants, rather than the imagined ones of a middle manager on the IT staff (wherever he or she may be ;-)). Certainly, they are stakeholders, as well, as I’ve already mentioned, but not the primary ones.

I’d go into the particular service, but it is not pertinent. You can see that this is a general problem. How do you get input from 107,000 people in any kind of useful, constructive way?

There are some things I’d like to accomplish in this committee:

  • Convince the stakeholders that they have a stake in its success
  • Identify how the group can work together
  • Do an affinity analysis to help define the user needs
  • Identify and define use cases
  • Establish a desired future state
  • Determine functional and non-functional requirements
  • Identify and prioritize essential, desirable, and optional features
  • Do a gap analysis

Out of this would come enough information for the appropriate people to go off and decide whether the service is feasible, and how to provide it. Of course, given a sufficient mandate, appropriate people would then go on to develop it in an agile way, providing early access to core functionality and features. Adding more features based on the original specification and feedback from users, administrators, and the committee.

So… Does anybody have any idea how to go about this? What has worked for you?

——–

Retreat

I spent (most of) the morning at Mountain Acres Lodge. Actually, I spent the first hour and a half driving around George’s Valley, which is directly across the ridge from Decker Valley, which is where Mountain Acres Lodge is, but let’s ignore that. As a result, I managed to miss Kevin’s talk in which he apparently answered a question I asked him in the last IT Leader’s Brown Bag lunch. :-[ If nothing else, at least I can provide fodder for further conversation. :-/

Anyway, this was session 19 in the Brown Bag series and it was graciously hosted by AIS. Thank you very much! :-D

As always, the event was wonderful. The conversation insightful and stimulating, and I already have ideas about how I can use what we talked about. Many light bulb moments today.

I think there is a core of people who really get it, who have integrated these themes not just into their daily lives, but into the way they think. Like learning a foreign language, it is the difference between being able to translate into the language you know and being able to think in the foreign language so that no translation is necessary. We are beginning to speak the language. Half a dozen people sat in a circle with me in our discussion group and had a single conversation. Ideas starting in one voice and flowing to the next. Being picked up by another and carried on by the rest. Without hesitation. Not rote repetition, but new answers to new questions — pertinent questions.

On a side note, I saw something in some meetings yesterday, as well. For a long time, I’ve been wondering how to influence the glacial pace of change in our organization. It has been extremely frustrating for me. I guess I was in a bit of a mood and I had a moment like Howard Beale (Peter Finch) in Network, where he says, “I’m mad as hell, and I’m not going to take this anymore!” That wasn’t what I said, but it was how I felt. The funny thing is, like in Network, the reaction was to hear the same thing from just about everyone around the table. It wasn’t just me any more. The people that I thought were the glacier had changed my mind. I was looking at it wrong. Not a glacier, but an iceberg. And the iceberg was breaking up before my eyes.

Things are changing. Now in visible ways.

Labels:

——–

Shorter “Why Transformation Efforts Fail”

  1. Not Establishing a Great Enough Sense of Urgency
  2. Not Creating a Powerful Enough Guiding Coalition
  3. Lacking a Vision
  4. Undercommunicating the Vision by a Factor of Ten
  5. Not Removing Obstacles to the New Vision
  6. Not Systematically Planning for, and Creating, Short-Term Wins
  7. Declaring Victory Too Soon
  8. Not Anchoring Changes in the Corporation’s Culture

Leading Change: Why Transformation Efforts Fail

——–