Thoughts on "change"

---

I ran into a blog item on change the other day, at a blog site called Rule of Thumb.

The posting entitled "The Change Curve", depicts a project management adaption of the change model proposed by Elisabeth Kubler-Ross in her book "On Death and Dying" when she described the "Five Stages of Grief"

Rule of Thumb proposes this adaptation for project management of the Five Stages into these six ideas:

•Satisfaction: Example – “I'm happy as I am.”
•Denial: Example – “This isn’t relevant to my work.”
•Resistance: Example – “I’m not having this.”
•Exploration: Example – “Could this work for me?”
•Hope: Example – “I can see how I make this work for me.”
•Commitment: Example – “This works for me and my colleagues.”

Of course there are many other models of both change and change resistance. One useful model of change (not change resistance) is by Kurt Lewin; I like it because it's similar to Deming's PDCA (plan, do, check, act). Lewin's model is three steps:

1. Unfreeze previous ideas, attitudes, or legacy
2. Act to make the change
3. Freeze the new way in order to institutionalize the change.

And, A.J. Schuler, a psychologist, has his 10 reasons about why change is resisted in a paper entitled "Overcoming Resistance to Change: Top Ten Reasons for Change Resistance". His lead-off idea is "doing nothing" is often perceived as less risky than "do something"--in other words, Plan A (do nothing) trumps Plan B (do something). 

But the one I like is that people fear the hidden agenda behind the reformers ideas! Amen to that one.

---

Buy them at any online book retailer!

Just changed, or transformative?

---

Change: things are different, or will be. Often a matter of process and function
Transformation: Change + values or philosophy that are changed as well


Some say that we still don't get it, some 12 years after notable John Kotter wrote his seminal article "Leading Change: Why Transformation Efforts Fail." Some say 30% or more fail. Of course, this begs the question: what is failure, or perhaps harder: what is success?

A piece I read by Ron Ashkenas says:

"Unlike change management, it [transformation] doesn’t focus on a few discrete, well-defined shifts, but rather on a portfolio of initiatives, which are interdependent or intersecting.

More importantly, the overall goal of transformation is not just to execute a defined change — but to reinvent the organization and discover a new or revised business model based on a vision for the future.

It’s much more unpredictable, iterative, and experimental. It entails much higher risk. And even if successful change management leads to the execution of certain initiatives within the transformation portfolio, the overall transformation could still fail."

Of course transformation is unpredictable! Who can say where a change in beliefs and values is going to lead? Who can say if such is really a good thing?

We can put parameters around objective change management stuff, but it's hard to measure, much less predict, non-objective phenomenon. About the best you can do is look at the A/B situation: A: the way it was; B: the way it is now.

A/B testing is a big thing in many projects these days.
How else to actually evaluate things?
So, is it change or is it transformation? Usually the former shows itself right away; the latter may be generational (See: transformative politics)...
You'll just have to wait and see; or better yet, get promoted and have someone else wait and see.
 

---

Buy them at any online book retailer!

Managing the change to Agile

---

I once asked my Agile class what they would do vis a vis change management to prepare the organization to take on Agile methods, if only a pilot to start.

One student replied this way. I thought it was pretty decent list, so I present it unabridged:

"In order to gain acceptance I would use the following change management techniques:
- Vision–Clearly articulate the vision and needs
- Phased Implementation–Start out slow and progressively implement Agile practices in a prioritized order
- Create a Communications Plan–Ensure all affected parties understand your vision and realize the benefits of Agile. You need to explore how Agile practices will impact the customer, the organization, various departments and the employees who will be involved.
- Educate Stakeholders–Education of stakeholders is imperative. Everyone on your communication plan needs to understand why Agile is being implemented, and the benefits and practices involved.
- Prepare for Change Resistance–I would use my communication plant to communicate my vision to the sponsor and key stakeholders/customers, accept that there may be resistance to the change. I would need to continually stress the benefits for the nuclear utility and how Agile could be beneficial to them on future projects.

Once the customer agreed to use the Agile methodology to implement the Plant Computer System as a pilot project for Agile, I would transition to the Agile Project t Methodology as follows:

- Business Value–Specify how Agile will help resolve any current problems, and how it supports the business objectives.
- Create Implementation Plan–Create and execute a communications plan to share key messages and listen to sponsors , employees and other stakeholders. Continuously communicate progress, objectives and changes. Solicit feedback to ensure support for the transition.
- Create Communication Plan–Create and execute a communications plan to share key messages and listen to sponsors, employees and other stakeholders. Continuously communicate progress, objectives and changes. Solicit feedback to ensure support for the transition.
- Create Training Plan–Create and execute a training plan. Provide the team with sufficient training and continued support. Many Agile implementations have failed after team members were sent to training and afterwards told to implement new approaches without further support or guidance."

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Collingridge's dilemma

---

A simple but profound observation:

When change is easy, the need for it cannot be foreseen; when the need for change is apparent, change has become expensive, difficult and time consuming.

David Collingridge
"The Control of Technology"

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

The "new order"

---

Machiavelli had explained—that “the reformer has enemies in all those who profit by the old order, and only lukewarm defenders in all those who would profit by the new order … [those]who do not truly believe in anything new until they have had actual experience of it

Quoted by Doris Kearns Goodwin, Historian

I've described what Machiavelli has said -- in past posts -- as: "Any ankle biter can say no; it takes a committed leader to say yes, and make it stick!"

So, apart from the scourge of the ankle biters, what does Machiavelli portend for the project office? Or, for the team leader, or even a team member, who wants to "change the process"?

Answer: lots of resistance from the "old order"; few climbing out on the limb with you as the "new order"

Indeed, what if the "process change" is to do away with the need for the process?
Who's not heard this one (*)?

Instead of investing to make the trains run on time, why not do away with the trains?"

(*) I admit that this one itself may be dated as trains are making a comeback, sort of. So, let's bring it up to date:

Instead of investing to make vehicle drivers better at driving, why not do away with drivers?

So, now you're in the project office inventing the "computer science" of driving decisions, such as the sundry moral questions of who to save in an accident situation: you, or the person your car is going to injure?

Your office is now the "reformer" Machiavelli spoke about: lots of enemies, as in the hundreds of thousands of professional truck and taxi drivers (to say nothing of Uber and Lyft) you will put on the bread line ... talk about enemies!!

Good luck with that
Let me know how it works for you

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Leading change ... Kotter

---

John P. Kotter is a change guy. I've been going through his 1996 classic "Leading Change"

Here's my take: it's a good book, but a little long on the narrative since the essentials are right up front: 8 leadership steps towards change management.

Now, admittedly, this is more aimed at the business readiness swim lane, and the foreplay necessary to get the business and the customer ready, than it is aimed at some of the change management tactics for scope control. Nevertheless, here's my paraphrase of Kotter's 8:

---

1. Put a value on short term versus long term
2. Gather a coalition of the willing
3. Develop the vision, goals, and strategy
4. Communicate
5. Push action to the practitioners
6. Be incremental
7. Consolidate gains
8. Leverage culture

---

Now, in Kotter's actual formulation for point #1, he wrote more about creating a sense of urgency than simply putting a value on the short term. But, actually, I'm not a fan of crying wolf on urgency just to get the team moving. Frankly, I'm more about finding a legitimate reason to value a short term goal; with that in hand, you should be able to get some action going.

His point about #5 was the ole "empowerment" thing. It was probably less worn in 1996 that it is 15 years later. The issue is that the empowered may not know how to use their power. That hasn't changed since power and empowerment were invented:

Those with the power have no experience

Those with the experience have no power

General Sir John Dill

Placentia Bay Conference, August 1941

I really like the last one about culture. We've mused on culture a few times here.

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Leading Change -- Kotter

---

John P. Kotter is a change guy. I've been going through his 1996 classic "Leading Change"

Here's my take: it's a good book, but a little long on the narrative since the essentials are right up front: 8 leadership steps towards change management.

Now, admittedly, this is more aimed at the business readiness swim lane, and the foreplay necesssary to get the business and the customer ready, than it is aimed at some of the change management tactics for scope control. Nevertheless, here's my paraphrase of Kotter's 8:

1. Put a value on short term versus long term
2. Gather a coalition of the willing
3. Develop the vision, goals, and strategy
4. Communicate
5. Push action to the practitioners
6. Be incremental
7. Consolidate gains
8. Leverage culture

---

Now, in Kotter's actual formulation for point #1, he wrote more about creating a sense of urgency than simply putting a value on the short term. But, actually, I'm not a fan of crying wolf on urgency just to get the team moving. Frankly, I'm more about finding a legitimate reason to value a short term goal; with that in hand, you should be able to get some action going.

His point about #5 was the ole "empowerment" thing. It was probably less worn in 1996 that it is 15 years later. The issue is that the empowered may not know how to use their power. That hasn't changed since the tension and conflict between power and empowerment were invented, as observed by British General Dill when conferencing with his American counterparts early on in the WW II era:

Those with the power have no experience Those with the experience have no power

General Sir John Dill

Placentia Bay Conference, August 1941

I really like the last one about culture. We've mused on culture a few times here. Just click here to get a sense of where I'm coming from.

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Start-up in large enterprise

---

Brad Power says this in a blog posting that caught my eye:

"In this world, customers expect their suppliers to surround their products with data services and digitally enhanced experiences. This means that many organizations and their leaders are running as fast as they can to quickly build their software capabilities."

And, for the PMO, it more or less means answering this question posed by Power: "How can these companies overcome the inevitable leadership, organizational, and cultural challenges involved?"

Actually, that's a tall order. Change:

• Leadership biases, perhaps even biases against doing software at all ("we're hardware ... ", and so forth)
• Organizational biases, perhaps separating the hardware from the software (OMG! I can't let go of the product software!)
• Cultural biases, like run fast, when perhaps it's been years since we've done any running

Power claims that there are units within large corporations that have been successful. But Power tells us there were questions that were hard to answer:

• How to reorganize: project, functional, or some other?
• Who to run it?
• In-house or out-source?
• Where to locate in the world?
• How to connect and integrate it to existing product lines? (did you ask what "it" is? And, is the mother ship friendly or a foe?)
• How to change the business scorecard, and
• How to change compensation plans to go along with these changes (Oh, that's a biggie!)

Probably Power is right when he says address the first two, and then have the team address the remaining questions, though it will take C-level support when you get to the business scorecard and the comp plan.

Oh, did I mention hiring the kind of people you might not have even looked at before? And, by the way, they look different, dress differently, and demand an environment that is likely a lot different.
Should they have the same comp plan and career path, or something custom to their needs?

And, gasp! Agile... we have to put up with that as well. There goes the neighborhood.

This stuff is hard. The main message here: allow for lots of time, because it's going to take lots of time. Don't build any project schedules without some slack; you'll need all you can get.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Change v Transformation

---

Change: things are different, or will be. Often a matter of process and function
Transformation: Change + values or philosophy that are changed as well


Ron Ashkenas tells us in an essay that we still don't get it, some 10 years after notable John Kotter wrote his seminal article "Leading Change: Why Transformation Efforts Fail." Some say 30% or more fail. Of course, this begs the question: what is failure, or perhaps harder: what is success?

Ashkenas says:

"Unlike change management, it [transformation] doesn’t focus on a few discrete, well-defined shifts, but rather on a portfolio of initiatives, which are interdependent or intersecting.

More importantly, the overall goal of transformation is not just to execute a defined change — but to reinvent the organization and discover a new or revised business model based on a vision for the future.

It’s much more unpredictable, iterative, and experimental. It entails much higher risk. And even if successful change management leads to the execution of certain initiatives within the transformation portfolio, the overall transformation could still fail."

Of course transformation is unpredictable! Who can say where a change in beliefs and values is going to lead? Who can say if such is really a good thing.

We can put parameters around objective change management stuff, but it's hard to measure, much less predict, non-objective phenomenon. About the best you can do is look at the A/B situation: A: the way it was; B: the way it is now.

A/B testing is a big thing in many projects these days. How else to actually evaluate things? So, is it change or is it transformation? Usually the former shows itself right away; the latter may be generational (See: transformative politics)... You'll just have to wait and see; or better yet, get promoted and have someone else wait and see.
 

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Growth, maturity, and decline

---

A common sequence studied by change managers -- particularly business change managers -- is the so-called growth-maturity-decline triad.

PMs experience the effects of this sequence more in the business case than in the actual project. After all, it takes a good deal of time to go through the business cycle; and it's not inevitable that the entire sequence ever comes about since managers intervene to redirect the business.

And, the public sector is not immune: Agencies can go out of business, declining as constituent demands declines or gives up; and agencies can re-invent themselves for new constituent demands (it's not your grandfather's motor vehicle department, or bus line, etc).

And, of course, there can be new agencies born of necessity of a changing public demand -- who remembers that in the U.S. conservative Republicans invented the Environmental Protection Agency in the Nixon administration, or the liberal Democrats invented the CIA, in the Truman administration? Now, How the world turns, etc and so on....

So, how does growth-maturity-decline look when viewed through the lens of projects?

Business case: Low cost of ownership
The real test between maturity and decline is whether or not there is new investment going into the business. In the decline stage, the emphasis is on cost control, efficiency, and getting the most out of existing product with existing customers; there's little or no investment beyond required maintenance.

Over time, product will obsolesce and customers will move on.

Business case: New customers for existing product base
If there's investment going into finding new customers with existing product, that's probably a mature organization surviving. 

Business case: New product, but directed to new customers
Growth investment is going into both customers and product, keeping both fresh and competitive.

And, here's a challenge question: when is an expenditure a cost and when is it an investment? Sponsor attitudes are usually quite different depending on the view point.

My answer: It's an investment when it goes toward making the future different from the present; that is: it's aimed at strategic differentiation -- to wit start-up and growth. Else, it's a cost required to keep things moving along as in the present for maturity and decline.

People and things
And, you can extend the argument to people: the CFO carries people on the liability side of the balance sheet -- creditors (they provide time & talent) to whom we owe benefits, salary, etc.

But, what if you're out to hire the one best person to do a task and make a strategic difference toward growth? Investment (asset) or cost (liability).  If an investment, hopefully you've got their scorecard set up to reflect the ROI demand.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Security vs Liberty

---

In my change management classes we debate and discuss this issue:

How do you work with a team that has a low tolerance for high change or uncertainty?

Of course, you can imagine the answers that come back:

• Frame all actions with process and plans
• Provide detailed instructions
• Rollout change with a lot of lead time, and support it with clearly understandable justification

What's rarely -- almost never mentioned -- is lead through the uncertainty. Is it odd that PMs think first of plans and process before leadership would come to mind? My advice:

• For those in the high avoidance culture, they have certain expectations of their leaders, starting with the establishment and maintenance of order, safety, and fairness.
• Insofar as change is required, even radical change can be accepted and tolerated so long as it comes with firm and confident leadership.
• Lots of problems can be tolerated so long as there is transparency, low corruption, and a sense of fair play. In other words, the little guy gets a fair shake.

Now comes a provocative op-ed from a German journalist based in Berlin with essentially this message (disclosure: I lived and worked in Berlin so I have an unabated curiosity about my former home base):

"To create and grow an enterprise like Amazon or Uber takes a certain libertarian cowboy mind-set that ignores obstacles and rules.

Silicon Valley fears neither fines nor political reprimand. It invests millions in lobbying in Brussels and Berlin, but since it finds the democratic political process too slow, it keeps following its own rules in the meantime. .....

It is this anarchical spirit that makes Germans so neurotic [about American technology impacts on society]. On one hand, we’d love to be more like that: more daring, more aggressive. On the other hand, the force of anarchy makes Germans (and many other Europeans) shudder, and rightfully so. It’s a challenge to our deeply ingrained faith in the state.

Certainly, the German view of American business practices is the antithesis of following the central plan. To me, this is not all that unfamiliar since resistance to central planning, state oversight, and the admiration for the "cowboy spirit" of individualism is culturally mainstream in the U.S., less so in the social democracies.

In the U.S. if you ask what is the primary purpose of "the State" -- meaning: the central authority -- whether it's Washington or the PMO -- the answer will invariably be "protection of liberty" (See: the Liberty bell; "give me Liberty or give me death" motto; the inalienable right to pursue Liberty, et al)

Ask the same question of a social democrat and you get "protection and security". With two devastating world wars in the space of 30 years that wiped out the most part of all economies except the U.S. and imparted almost unspeakable population losses, except in the U.S., how could it be otherwise?

Security vs Liberty: a fundamental difference in the role of central authority. Of course, all central authority provides both, and the balance shifts with circumstances. In the U.S. during the mid-19th century civil war and during WW II, and then 9/11, security came to the front and liberty took a back seat.

Now, port all this philosophy to a project context, and in the software world, no surprise: Agile!

Certainly the most libertarian of all methodologies. And, agile comes with a sustained challenge to the traditional, top-down, centrally planned, monitored, and controlled methodologies that grew out of WWII.

And, agile even challenges the defined process control methods that grew out of the post WW II drive for sustainable, repeatable quality.

Did some say: high change or uncertainty?

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Agile cost of value

---

Everywhere I go I make it clear that agile in the enterprise begins with a business case. I make this point in my books* and blog postings over and over. The logic of this is obvious on its face: if you are going to spend other people's money (OPM) they'll hold you accountable. Accountable for what? That's what the business case is for... to answer that question. And, if your processes require a project charter, you can morph the business case in the charter.

But agile goes a step further: agile asks that the customer/user/product manager be embedded in the project and empowered to interpret the requirements in the backlog: sequence them, give them priorities, and recommend new ones, ones to change, and ones to delete.

So, given that empowerment, what then is the utility of the business case. What happens to accountability?

Actually, and in the spirit of keeping it simple, yet effective:

If the customer/user/product manager recommends changes in requirements, not anticipated in the business case, and these changes are material to the business proposition (cost of value), Agile provides two methodology opportunities:

• The retrospective evaluation leading to the next formulation of the next iteration's backlog, and
• The release planning session (or process), leading to production releases to the business.

Beyond these methodology opportunities, each business may have processes to handle business case changes that would overlay the project methodologies.

In each opportunity, the witting and accountable product manager goes back to the business case to evaluate impact to the cost of value, very likely consulting with affected stakeholders. It could be messy of course, and it could delay things, but following the agile principle of provoking change early on, it's really in the job jar of the agile product manager to be pro-active about attending to the business case.

---

* Maximizing Project Value, Chapter 3, discusses the agile business case
Project Management the Agile Way, Chapter 2, also describes how to build an agile business case

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Change bandwidth

---

Author Jason Bloomberg wrote: "It's human nature when faced with a chaotic environment ... to filter out most of the noise to focus on a single trend. The resulting illusion of stability gives us a context we can understand. But it's still an illusion."

Others have said that to permit innovative change, particularly destructive innovation, the filters must come off to permit rapid and "out of the box (filter) responses"... you can't work change (or see enough context) through a straw, as it were.

It's a matter of physics: if you put a sharp change through a somewhat narrow filter, then what you get out is somewhat smeared bell-shaped response with gradually changing shoulders, thus damping the effect of the change. And, you get a delay as the input energy has to move through the filtering effect.

Consequently, the output is a poor facsimile of the input, and it's late!

The problem we see in the organizational change business is that if there is a sudden big shift in the business environment (or public attitudes that could affect the public or non-profit sectors), the business sees the big shift after it's exited the filter. If the filter is narrow, the delay will be significant (inverse to the bandwidth) and, if the filter is really narrow, the information at the filter output will be distorted. The effect, as Jason describes, is to continue the status quo (an illusion due to filter delay) ...  [and] miss the outset of a big change.

Consequently, the business may be too late, and  may even bring a basketball to the football game: (distortion effects). See "Microsoft misses the mobile revolution" for an example. 

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Lean entrepreneur in the enterprise

---

Brandt Cooper added something to the body of knowledge at the Australia 2014 Agile conference in Melbourne. His topic is the lean entrepreneur, though there's not much in the presentation that is lean specific. Nonetheless it's a worthy read about the trials and tribulations of the experimenter - entrepreneur

He starts off by declaring that there are two upfront killers of entrepreneurial innovation:

• a demand for ROI and 
• a demand to know when innovation will arrive. 

Likely so.

What caught my eye was the use of these charts to develop his ideas that it's not all predictable, not all estimateable, not at all a sure thing worth of a ROI commitment, and certainly not easily put on a calendar.... Thus our Hero!

And, don't forget the change thing....

 

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Behavior Outcome Success Failure

---

You have to give Jurgen Appelo high marks for imaginative illustrations that catch the eye and convey the thought. He says this is one of his best illustrations ever; he may be right. He calls it his "celebration grid". I imagine Jurgen will be telling us a lot more about this if it catches on.

But what he says about these grid points is the more important take away:

• “Celebrate failure” is nonsense, because you shouldn’t celebrate failure that comes from mistakes (the red part). What you should celebrate is learning, and repeating good practices (the green parts).
• Pay-for-performance tends to drive people away from experiments, toward the safe practices on the right, with little learning as a result. 
• Hierarchies are good at exploiting opportunities, and endlessly repeating the same practices; but they learn very little. 
• Networks are good at exploring new opportunities, and failing half of the time, but they’re not good at efficiently repeating practices.

File this under leadership for learning and motivation, change management, managing team dynamics, and carrot and stick.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

The leverage of small teams

---

Author Norman Maclean challenges his readers to address: "What the structure of a small outfit should be when its business is to meet sudden danger and prevent disaster".

With the current flattening of organizations, the day-to-day emphasis on team work in small work units, and the demonstrated potential that a small group can make a decision wielding enormous business leverage (how big was the team that decided to attack the World Trade Center in 2001?), Maclean's challenge is particularly timely.

In thinking about how to answer, you might consider:

• Team structure (and protocols)
• Various models of behavior (tolerance or not for chaos and change, etc)
• Structured frameworks for change process, etc
• Empowerment of improvisation (Mann-gulch),
• Virtual small team loose coupling to collective culture (the work of Geert Hofstede on culture), and
• Norms of respect (talk truth to power, etc)

Sudden danger certainly brings trust into the frame: would you trust a stranger to get you out of trouble? Perhaps, if there's no one else around, but your instincts are certainly going to be to turn to someone you can trust. And, trust and safety are certainly constituents of successful teams. My experience: trust doesn't scale too far, so the smaller the better as regards a close knit.

Preventing disaster sounds like there could be advance planning and premeditation to put the right protocols in place -- fire, flood, nuclear breakdown, etc. But also practicing the escape mechanism -- some may be on-the-shelf and largely untested -- do they actually work as intended?

The Gulf oil spill of a few years ago comes to mind. Sometimes, the small team on duty in the middle of the night is all there is between disaster and just another day at the office.

And, how does a structured framework for decision making process and decision fulfillment really work when stressed to the limit? My experience is that they are often tossed overboard pretty rapidly to be replaced by some process that is stress resilient.

Indeed, I often asked: why don't we use the latter routinely? Why is it the extreme solution instead of the usual solution? Answers: too expensive for long term sustainability and lack of scalability. "It" works on a small scale among a trusted and dedicated group, but not likely as the team grows into a "group".

Improvisation saved a few in the Mann-Gulch fire disaster, and many such disasters since. For a good reading on this one, go the link in the first sentence of this posting.

Intellectually, we probably all know that culture either encourages or impedes quick reaction responses to extreme situations, including the cultural acceptance of talking truth to power (and, by the way, the power respecting the message and the messenger).

But, its hard to push culture through an Internet cable. So, sometimes a small team is more like a small group and does not really have the advantages of a close knit team. For example, the norms of small close knit teams are almost always sufficiently informal that the message is aired and the substance often gets heard.

So, one summary observation: as you empower small teams you are empowering leverage: the ability to have large influence with modest effort... Can you handle it?

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

The illusion of stability

---

It's human nature when faced with a chaotic environment ... to filter out most of the noise to focus on a single trend. The resulting illusion of stability gives us a context we can understand. But it's still an illusion.

The reality is that there are many different interrelated trends -- areas of change that impact us as well as the other trends. There are also discontinuities: sudden shifts that force us to rethink our assumptions.

Jason Bloomberg*
"The Agile Architecture Revolution"

Amen! to that sentiment. One often wonders if we're the engine of change, or the victim -- change leading us, rather than the other way 'round.

In the statistical world, it's much like finding the regression line amongst a lot of seemingly random or chaotic data points. The regression line is kinda the place we would like to be if we were the next thing to happen.
(Note: regression isn't filtering, but the line itself is a nearly noise-free representation of the "message of the data", so to speak)

Of course, a word of caution: it's not actually so swell to speak of filters narrow enough to smooth out the noise, and yet leave enough bandwidth to be disturbed by a discontinuity or sudden shift. Such phenomenon have very high frequency components which would likely be smoothed to the point of unrecognizability at the filter output.

Therein lies the hazard: big shift at the input... and little notice at the output. (See: Microsoft misses mobile and the tablet shift, or worse: Blackberry misses everything. ) One wonders if the Microsofties have been living on the wrong side of the filter.. perhaps a little exposure to the chaos of small business would be a tonic.

 

---

*Bloomberg is President of a consulting firm that takes the position, roughly, that a SOA (services oriented architecture) that is very loosely coupled to accommodate ambiguity and emergence of function and performance when the user is part of the system and in-the-loop is an "agile architecture". Bloomberg has coined the development of such architecture as "Complex System Engineering" (CSE); it is the heart of the "revolution". He contrasts CSE with traditional system engineering which he more or less equates with integrating a number of small objects into a large system.These views, and his company offerings in this regard, informs the content of his book.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Matrix messaging

---

We've all heard of matrix management; many of us have gotten involved in projects with matrix organizations. But recently I was led to the idea of matrix messaging in the context of change management.

How does it work?

Actually, the same as matrix management: YOU are at the intersection of multiple messages: one from one manager, perhaps the project sponsor, and the other from the business. Hopefully, they are the same, but often not.

Messages	Project
Business	YOU

And, so what's a change manager to do? Obviously: take action to coordinate and make coherent the messages... so as to make "music" and not "noise" from all the input.

And, how to do this?

• Form relationships with all the messengers
• Coach them on the message
• Validate the message delivery
• Take corrective action if necessary

This is a form of Messaging 101:

• Tell them what you are going to tell them
• Tell them
• Tell them what you told them

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog