Monday October 04, 2004

Change Acceptance Lessons Learned

As my JDS CAP (Java Desktop System Change Acceptance Process) team takes Sun through the change to Everyone Running JDS Everywhere I am trying to keep a list of lessons learned. Sun has a lot of expertise in Change Acceptance and I would like to be able to help our customers who are changing to JDS by apply what I am learning in our JDS CAP effort. I am still struggling some with how to effectively do this but the lessons learned is a first step. If people have other ideas I would love to hear them.

1. " It is Hard work ". On the surface it seems easy. But building real acceptance requires a lot of the hard work of change acceptance i.e. talking to people., listening, addressing areas of resistance, and continually going back over what you have already done. You can't just send out an email and then check off that you have built a shared understanding of the vision or the roadmap for getting there. And you have to address the issues that people bring up you can't just make a list of them.

2. It is about the conversation Change acceptance is about two way conversations it is about listening to what people are concerned about. It is about asking for input. Change acceptance work can't be done by sending out emails. You have to talk to people and a lot of people are very hesitant to talk to people they don't know.

3. Don't assume that people understand the product and the details of the change. Our JDS CAP team spent a lot of time asking questions and going over what exactly was changing. I'm still learning and people's questions have helped a lot. The team members were very unwilling to go out and seek input until they had a concrete understanding of what is happening and in fact they required a presentation they could use in the discussions. (With their help I created one.)

4. Segment the user base When your goal is build acceptance of a change that impacts several thousand people you have to be able to figure out a place to start. We decided to focus on groups that are key influencers within the company. (System administrators, Sales engineers, Resolution Center staff, IT and Executives and their Administrators.) the change acceptance work for each of these groups is different.
5. Regular Change Acceptance Reviews are imperative. Not only do they allow us to keep our sponsors informed but they also help the team to experience the focused leadership. One other advantage of Change Acceptance reviews is that they impose discipline. When we know that our progress in moving our key stakeholder groups to active acceptance will be reviewed it helps build a sense of urgency.

   I have several more but that is enough for now

   (2004-10-04 13:17:22.0) Permalink Comments [2]
   Comments:

   
   

   Leaving aside the unfortunate Bush quote(!), I've always felt that we use the wrong "A" word in CAP. Rather than "Change Acceptance Process", it should be "Change Acceleration Process" (which is, I think, the way GE interprets CAP). It shifts the dialog from "How can I get you to accept this?" to "How can you help me to accelerate this?" Instead of "How can I change you?", it's "How can we change Sun?" I've always preferred "we" conversations.
   
   Anyway, good luck with the JDS move. I wonder how it will affect my PowerBook.....

   Posted by Geoff Arnold on October 04, 2004 at 03:32 PM PDT #

   Thanks Geoff, You make a good point about the difference between acceleration and acceptance. Of course if it was Change Acceleration Process people would say yes, but you can't accelerate change unless it is accepted. But I guess that is your point.
   I agree completely that it needs to be a we conversation. I think that by asking what can we do to make this better whether it be the roll out or the vision or whatever it will be better. You've made me think. Thanks :-)

   Posted by Marion on October 05, 2004 at 10:11 AM PDT #

   Post a Comment:

   
   Comments are closed for this entry.

   ---