Marion's Weblog
My name is Marion Vermazen. I worked at Sun Microsystems up until June 3, 2005. I worked on the IT aspects of Sun's work from anywhere program, iWork. I was also the team lead for the Java Desktop and Solaris 10 at Sun Change Acceptance team.

20041004 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.

CAP Lessons Learned
  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]


archives
links
referers