Tuesday, December 02, 2014

We Have Met The Enemy....And He Is Us

- from Pogo, Walt Kelly 1971

------------------------
I've been doing a lot of thinking about cultural readiness in the past couple of months.
Pretty much since the day one of my colleagues took all the air out of the room with a simple comment.

"We are not ready for this solution."

He meant that the organization wasn't ready for the solution.
But I wasn't so sure.

Struck me that it was really our team that wasn't ready for the solution.
----------------------------
It's easy to point to the end user and say "well - they are just not ready."
And for a few very vocal people, it was absolutely true.
It's easy to focus on the noisy negative.  Human nature. Looking for "danger".

But I was getting many comments from our end users that led me to believe that the general environment WAS ready.  I knew they were already using many of these features in other formats and tools. They just wanted a better way to work.

The group that wasn't ready was our team.

So many of them spent decades working with a particular technology.
Mastering the one thing they do really really well.
And all of that is being thrown out the window.

So the finger gets pointed at the end user when it is really us.
So we retreat back to the closest thing to the thing we know and try to ignore the rest.
---------------------------------
I'm still trying to shake off the lingering sense of failure.

I spent so much time getting the pilot group "culturally ready" when most of them didn't need it.

I expected my teammates to have enough of a sense of self-preservation to internalize the change for themselves.

They are technology folks.  I assumed they would be able to figure stuff out without a ton of hand-holding.

But I ignored the fear factor that accompanies any huge change.
- Fear of loss of identity
- Fear of loss of mastery
- Fear of looking stupid
- Fear of not knowing 
- Fear of loss of status
- Fear of how others will react
- Fear of the unknown

I now wonder what I should have done differently.
---------------------------------
How do we develop "cultural readiness?"
What needs to happen?
What timeframe is needed?
What environmental supports?
How much repetition of message?

How do we nurture and encourage those early adopters of the new culture?

And most importantly - how do we reduce the fear?

Monday, November 24, 2014

A Case Study in Environmental Influence



"What I started discovering is that the music from these places, the roots of it goes so deep that it's historic — there's history and there's culture, and all of these different elements influence the musical outcome of that place. Not just the studios, but the cities themselves." - Dave Grohl during an interview at UK's Absolute Radio

----------------
Dave Grohl's current documentary series, Sonic Highways, is one of the best case studies I've seen showing how one's environment can influence what you create.

Watch the Nashville episode (Episode 3).  Beginning to end.
Carefully read the lyrics for the song at the end of the episode.
You can see exactly where the lines came from.

He does this throughout the series, but what made this one particularly powerful was the impression that this was a city he spent very little time in.  He didn't have as rich of a catalog of prior knowledge vs DC (home) or Chicago (a place where he has spent a lot of time). As a result, it struck me that he didn't already come in with ideas in his head or any real idea of what he was going to do once he got there. The influences were "fresher".

He took those impressions and made something with it.



------------------
This has made me wonder....

How is my environment shaping my work?
The history, the culture, the physical place, the interactions between people, the tools at hand, the underlying assumptions?

Each time I step out of my day-to-day environment, how does THAT influence me?
How permanent is that influence?
How does it vary based on length of time spent in a particular place?
The emotional intensity of the experience?

No answers....just a lot of questions.


Tuesday, September 23, 2014

Unified Communications Pilot Training - Findings

Digging out from this really huge project and a bit of burnout.  I still don't think I have a wide enough perspective on this thing.  Anyway, figured it was time to share what I learned....

Subscription-Based Learning Iteration 2
Guerrilla Change Management in Action
---------------
Tools we used to implement:
- A ListServ
- A Wordpress blog (SharePoint wasn't ready at the time of implementation)
- Articulate Storyline (for movies etc)
- Microsoft Word

Findings:
- The 4 weeks spent introducing the pilot and the interfaces made a huge difference when we got to the training event.  For the trainers, this required a lot of working around non-working equipment, cribbing screenshots from vendor documentation, and a lot of creative writing.

- The pilot users liked that they had a resource and lots of information.  Sometimes too much information.   The sheer amount of information wound up making the solution seem more complicated than it really was.  I would rather err on the side of too much than too little, but the feedback tells me I need to be more mindful about how to deliver this material and how I present the options. Production training and support will require more careful information architecture to make it all less overwhelming.

- 2 hours of classroom training is 1 hour too long.  Production training will be split up into 4 or 5 separate classes + asynchronous materials.  This will allow people to choose what they wish in the time they wish to use it.  Yes - there is pressure to get everyone to switch to a new way of doing things all at once.  I learned (again) that we need to respect the change process.  For some - it's just getting comfortable with a phone. For others - it's solving a problem they have. Mileage will vary.

- The whole project team and the pilot participants ran out of steam after a month from Go Live.  Because certain things still weren't working, I ran out of material.  The pilot participants got tired of hearing from me.  And things kinda settled into a groove.  I was too tired to shake that groove up.

- The Subscription-Based Learning model is still very human-resource intensive.  As in, you need at least one person who can solely concentrate on creating material for that model. This person also winds up serving as the community wrangler - despite attempts to direct people to appropriate resources.  That person becomes the name and the face of the project whether the team wants that or not.  People prefer to talk to individuals, not anonymous "Support Centers."

- The Subscription-Based learning model is really nice for introducing new features as the engineers and architects get stuff working.  Having that in my back pocket reduced pressure for the entire project team to get certain features operational on Day 1.  As long as we had the core working (chat, phone calls, 1-1 video, desktop share and the path between these features), the other stuff could be introduced later.

- We wound up abandoning IdeaScale.  I had a hard enough time with my email and no one else on the team had the bandwidth to step forward and be the community curator. I was still impressed with the level of engagement from the pilot participants - even if most of it seemed like complaints.

- The Business Analyst assigned to our project introduced me to Qualtrics.  We used this for regular surveys instead of Google Forms.  I'll admit - for my purposes, I much preferred Google Forms.  But Qualtrics makes it easier to create pretty pictures. 

Having the 1 month survey and results from the previous surveys let me know that the solution we have is a good one - we just need to get it working better.  Very useful when all it felt like I was hearing was complaints.  Actually - I was very impressed we had a 33% answer rate to the survey (vs. the 10% after chasing people down that I was expecting).
------------------
Things we need to figure out moving forward:

- Our mucky muck's executive assistant commented "I've been using this thing and it's fine.  But I am not sure how to go about using the newer stuff. Maybe I need more hand-holding."

What she really identified is that people figured out a way to get comfortable. There is nothing pushing her to try something else or do something differently because she doesn't have a pressing problem that needs to be solved.  I'm not terribly interested in creating problems that aren't there.  But there are also better ways to do things housed in this solution.  Time for another round of talking to people.

- Information Architecture - how can people find what they need when they need it?  This is a HUGE solution.  How do we make it less overwhelming?

- Accommodating UI changes - What we used in the pilot is going to look very different when we start rolling it out to the University.  So all of the materials I developed are being trashed and I am starting over.  We are in an age where vendors are changing UIs at whim anyway.  Our development processes need to figure out how to accommodate this reality quickly, and not just for this project.

I have a lot more work to do between now and December 1 when our first group goes live with this solution.

Friday, September 19, 2014

Key Questions

We are at the tail end of our Unified Communications pilot.

I'll share the experience a little later, once I finish digging out and getting a little distance from the thing.

--------------
This morning, I was listening to Nick Shackleton-Jones, BP's Director of Online and Informal Learning.

His entire strategy is based on the question "What can we do to help you do your job better?"

In the talk, he breaks this question down a bit further:
- What top 10 things do you worry about?
- What are your top 10 tasks?
- What do you struggle with?
- What do you find useful?
- What is unhelpful?

It really has nothing to do with budget, technology, resources, courses, or how fancy your solution is.

It has everything to do with those answers.

Friday, June 20, 2014

Using ListServs in Subscription-Based Learning

Janet Clary asked me the following question in the comments:
"For your subscription-based learning how are you using your ListServ and what are you using?"

Figured I would answer her in the blog vs. the comments.

-------------
What we are using : CataList powered by LISTSERV.

I don't know the financial or technical details of how our ListServs are set up.  
We've had this in our environment for ages.  

How we are using it: I am embarrassed to say this - but I am essentially using this as a one-way mailing list.  It's the best thing we currently have in our environment for bulk-mailing without the multiple approvals.

On governance: We do have an approvals process in place for these emails and posts. A team review, then the Communications review.  I am sending stuff for team review the morning 2 days in advance. They are expected to turn around comments by COB. The Communications review is the morning of the day before.  

All parties are well aware of my concerns around how easily this process gets bogged down.

We have been told that we don't communicate enough.

This is going to be a test..... 
Especially the first time one or the other group gets upset that I send stuff without their "approval."

The Telecommuting subscription-based learning program did not have these governance layers and was well-received by the audience and by senior management.

Let's see how quickly I get yelled at....


Thursday, June 19, 2014

Do We Sound Like This?



My dad is slowly getting his eyesight back.  Still not where he wants it - but it is good enough that he sent me this gem.

Sometimes, our training sounds like this to our audience.
Does yours?
-------
Go to the YouTube posting for the full story behind this video.



Tuesday, June 17, 2014

A Message from the Universe?

This is where I planted my sunflowers.




This is where the birds decided they should go



I see a lot of parallels between the birds' "help" relocating my plants and my life right now.
Still pretty....still growing...just not where I thought.