"Poor management can increase software costs more rapidly than any other factor." (Barry Boehm)

I attended an Organizational Change BoF last evening at the AYE conference. Among other things, we talked about why it is that some managers fail to act when there are many signs of big problems.


I see three conditions that are prequisites for change (at any level):

People have to recognize the situation. One person at the group told a compnay that was losing billions, but kept cancelling projects that produced revenue, and funded projects that failed. The problem was obvious to anyone who *could* see. But the senior managers had a mental model of operating as a monopoly, and updated neither their mental models nor their corporate accounting systems. So they didn't see it.

People have to believe it is possible to change the situation in some way. If people don't believe it's possible to change, they are paralyzed. THere are some things can't be changed, that are out of the sphere of influence or control. People often forget that even when they can't change external circumstances, they can change their response.

People need to have some idea of how to shift the situation. WHen people have no earthly idea how to shift the situation, they become paralyzed. So paralyzed that they don't seek help in the form of new ideas or expertise. Or they grasp at the first silver bullet that's offered (which often makes the situation worse). Or they do nothing.

So how do you create the conditions for change in your organization? Stay tuned. I'll be blogging about that in the next weeks.

Labels: change, management

posted by Esther Derby at 7:17:00 AM

|

I got a call from an acquaintance, Gloria, who is trying to convince her organization to adopt agile methods.

"I've given them every logical argument I can think of," she said. "They just don't get it. All I get is blank looks. How stupid can they be?"

"They" probably aren't stupid at all.

But they may have a different frame of reference, or a different mental model.

They may value something that isn't considered in Gloria's logical arguments.

They may agree completely with Gloria's argument, but don't see how to get to where she wants them to go.

They may be afraid that if they do what Gloria suggests, their managers will be angry.

What Gloria doesn't get is this: while logic is appealing, it isn't always the most effective tool for persuasion.

Rather than try to win through logical argumentation, Gloria might try understanding:

what other people value
what other people fear
what obstacles other people face
what problems they want to solve.

Labels: change

posted by Esther Derby at 10:13:00 AM

|

Back in February, I wrote a post on helping people change and pointed to George Dinwiddie's post on Overcoming Resistance. His post has grown up to be an article, and it's posted on the AYE Conference website.

Labels: change

posted by Esther Derby at 7:14:00 PM

|

Last week, I wrote a post about decisions that look only at easy-to-count costs and ignore hard-to-count benefits.

Here’s one method for estimating hard-to-count benefits, subjective impact analysis:

1. Identify the proposed course of action.
2. Determine what’s important to the person who makes the decision.
3. Ask that person who they consider credible sources related to the issue.
4. Create a short interview protocol.
5. Interview the people the decision maker identified as credible.
6. Summarize and present the results.

Here’s part of a subjective impact analysis I did for a client a billion years ago (suitably scrubbed).

The client was a VP in an IT operation. The business was livid about the production problems and outages that followed when the IT group installed new functionality.

When I looked at the data about outages, it was pretty clear that the worst problems came from the hand-off between the development folks and operations folks. I poked around, and found that the two groups weren’t working together.

So I suggested a little experiment: a “readiness review” prior to installing a change where the development people and the operations people would sit down together and walk through the installation. And I created a half-page checklist for the development people to actually write down critical information for the ops folks.

Then we tried the experiment. We held a "readiness review" for a smallish update to the production systems. The meeting took about 45 minutes.

After the “readiness review,” the IT managers told the VP they were concerned about adding another meeting that took away from development time. The developers complained about the burdensome documentation (half a page).

The costs were obvious.

The benefits were not so obvious.

So I did a subjective impact analysis to show the benefits (if there were any).

Here’s what the VP valued:
• Avoiding production problems
• Improving the application
• Taking a proactive stance

I asked a cross-section of the people who participated in the review these questions:

1. What gaps and issues came up in the review that could have caused problems had they been discovered in production?

• What was the biggest problem discovered in the review?
• On a scale of 1 – 10 (1 = negligible impact, 10 = disaster), how big would that problem have been?

2. What was the team able to do to improve the application because of the review?

3. What problems did the team fix before they hit in production?


Then I summarize the data and presented it to the sponsor. Here’s the data from the first question.

Problems Discovered in the Readiness Review
(1 = negligible impact, 10 = disaster)

10 ****
9 *
8 ***
7 **
6 *
5 *
4 **
3
2 **
1

(This represents each person's assessment of only the biggest problem, so it’s a subset of the problems. For the most part, the development folks identified lower impact problems, the ops folks higher impact problems. Very interesting...)

This little data table helped people see the benefits of the readiness review, as well as the costs.

(Obviously, there were lots of other issues with this organization. This was a starting point to bring the level of conflict down enough for people to look at underlying problems.)

I did this subjective impact analysis after the fact, but you could easily adapt it to estimate benefits before making a decision.

Labels: change, leadership, methods

posted by Esther Derby at 8:32:00 AM

|

I’ve been noticing a problem in my office lately. My dog, Pudge, spends a lot of time in the office with me. She has a blanket in the corner where she hangs out and naps or chews her nyla bone. The only problem is that the blanket tends to spread out and cover a large expanse of the hardwood floor right across the entrance into my office. Then I come in and step on it and go flying. Plus when it’s spread out, it’s not very cushy for Pudge.

So I had the bright idea to improve things and make things better for both of us.

I sent away for a fine, cushion-y, and washable dog bed. I measured Pudge, and I measured her other favorite spot (a chair in the living room) to get the right size.

I was sure she’d love it. Why wouldn’t she? The new bed would be much better than the ratty old yarn blanket, much cushier and more comfortable. And her nyla bone wouldn’t get snagged in the yarn and all tangled when she pawed the blanket around.

When the new dog bed arrived, Pudge was curious about the box. She was even curious about what was in it.

But when I took her ratty yarn blanket away, her curiousity vanished. I put the cushy new dog bed down and urged her to try it. She sniffed at it, then took her nyla bone into the kitchen for a good chew. Over the course of the day she moved all her chews and toys to a new location, far away from the new bed.

The next day, instead of hanging out in the office on her fine new dog bed, she sat in the kitchen on the hard floor. After a while, I enticed her onto the new bed with a biscuit. She stepped gingerly onto the bed, picked up the biscuit and left. Later, I picked her up and put her on the bed. She stayed as long as I was scratching her belly, then headed back to the kitchen.

Eventually, she accepted that her ratty yarn blanket wasn’t coming back and started lying on the cushy new dog bed. We’re in a new status quo. She’s content in the corner of the office, all her nyla bones have migrated back, and I’m not tripping on the blanket.

So what can a story about my dog tell us about change?

Our wonderful ideas of how to make things better for other people may not be greeted with enthusiasm.

Other people may value things about the old way that we don’t see or don’t appreciate.

Things that we don’t like about the old way may be valued by other people.

It takes time for most sentient beings to adjust to a new way.

People accept the new way to retain something they value.

Even when the new way is accepted, people may look back fondly on the old way.

So don’t take someone else’s lack of enthusiasm as an indictment of you or your ideas--but look at how you introduce your ideas.

Labels: change

posted by Esther Derby at 8:56:00 AM

|

George Dinwiddie posted a story of how he over came "resistance" to a change he was proposing.

I wrote up a description of the types of changes I was proposing and made my pitch to the team. As I talked about making these changes (and making them incrementally, as we added newly requested features), I could tell that they weren’t really enthused by the idea. I poured on the heat of persuasion, describing the benefits in the short term of the immediate features we were developing. The less progress I made, the more enthusiastic I became, scribbling UML diagrams on the whiteboard and building castles in the air as I pointed out the advantages in the long term of making some significant changes we knew were coming down the pike.

I got nowhere but exhausted. I stopped, wondering how I could get these procedural programmers to understand the benefits of object-orientation. I was trying to figure out what to say next when a senior member of the team said, “I don’t think there’s anyone in this room who doesn’t believe you when you say this is a good thing to do. We just don’t know how to get from where we are to what you describe.”

Oh.

I guess I should have asked more questions.

How did I get over this “resistance” to my suggestions? I can think of three distinct ways, demonstration, discussion, and retrospection. The demonstration is focused around what I did, as I provided examples of what I intended and described how I got from the current code to the new code.

This is a great example blasting the notion that people who aren't following our ideas are "resisting." What "resistance" really comes down to is that other people aren't doing what we want or expect them to do when we ask them to change.

This may be because...

they don't know how (as in George's story)

they don't feel they have time

they think their way is better

they don't think the new way will work

they don't like/repespect the person requesting the change

the new suggestion is counter intuitive given people existing mental models (or what they've been taught)

the new suggestion runs counter to existing reward structures or other organizational systems

the new suggestion doesn't make sense to them

they have no experience that tells them the new way will work, or how it will work.

Listening for what's behind the "resistance" gives valuable clues on how to move forward.

Unfortunately, I hear many people--even those who hope to influence others to change--label people who are "resisting" as clueless, stupid, or selfish. Some would-be change agents attack the motives of the people who aren't following their ideas, accusing them of wanting to bring the company down.

This may make the so-called change agent feel superior, as he/she belittles people who don't get his/her wonderful ideas. But it doesn't help him/her bring about change.

Change artists listen and adjust their approach based on what they learn. They try to make it safe for people to try new ideas. And change artist never ascribe maliciousness to what can be explained by simple ignorance (which is lack of knowlege, not lack of ability or intellect).

Labels: change

posted by Esther Derby at 7:14:00 AM

|