Showing posts with label communication. Show all posts
Showing posts with label communication. Show all posts

Monday, April 27, 2009

10 Principles of Change Management

Bookmark and Share

Strategy and Business magazine recently posted a "Resilience Report" titled "10 Principles of Change Management". As we've discussed (What is A Software Architect?, Most Important Competencies of the Software Architect, Governance Without Goodwill Is Dead, Service Design Principles and Governance), communication and leadership are critical skills for the Architect. These skills are really put to the test as part of initiatives with a large Change Management component - the sort of transformation programs the Architect is often asked to lead.

Strategy and Business identifies the following 10 principles of Change Management. These principles articulate what you might consider to be fundamental truths and to varying degrees should inform nearly every change initiative. I'll follow up with a post about the process of managing change. A solid understanding of these principles and processes pays great dividends.

1. Address the “human side” systematically. Any significant transformation creates “people issues.” New leaders will be asked to step up, jobs will be changed, new skills and capabilities must be developed, and employees will be uncertain and resistant. Dealing with these issues on a reactive, case-by-case basis puts speed, morale, and results at risk. A formal approach for managing change — beginning with the leadership team and then engaging key stakeholders and leaders — should be developed early, and adapted often as change moves through the organization. This demands as much data collection and analysis, planning, and implementation discipline as does a redesign of strategy, systems, or processes. The change-management approach should be fully integrated into program design and decision making, both informing and enabling strategic direction. It should be based on a realistic assessment of the organization’s history, readiness, and capacity to change.

2. Start at the top. Because change is inherently unsettling for people at all levels of an organization, when it is on the horizon, all eyes will turn to the CEO and the leadership team for strength, support, and direction. The leaders themselves must embrace the new approaches first, both to challenge and to motivate the rest of the institution. They must speak with one voice and model the desired behaviors. The executive team also needs to understand that, although its public face may be one of unity, it, too, is composed of individuals who are going through stressful times and need to be supported.

Executive teams that work well together are best positioned for success. They are aligned and committed to the direction of change, understand the culture and behaviors the changes intend to introduce, and can model those changes themselves. At one large transportation company, the senior team rolled out an initiative to improve the efficiency and performance of its corporate and field staff before addressing change issues at the officer level. The initiative realized initial cost savings but stalled as employees began to question the leadership team’s vision and commitment. Only after the leadership team went through the process of aligning and committing to the change initiative was the work force able to deliver downstream results.

3. Involve every layer. As transformation programs progress from defining strategy and setting targets to design and implementation, they affect different levels of the organization. Change efforts must include plans for identifying leaders throughout the company and pushing responsibility for design and implementation down, so that change “cascades” through the organization. At each layer of the organization, the leaders who are identified and trained must be aligned to the company’s vision, equipped to execute their specific mission, and motivated to make change happen.

A major multiline insurer with consistently flat earnings decided to change performance and behavior in preparation for going public. The company followed this “cascading leadership” methodology, training and supporting teams at each stage. First, 10 officers set the strategy, vision, and targets. Next, more than 60 senior executives and managers designed the core of the change initiative. Then 500 leaders from the field drove implementation. The structure remained in place throughout the change program, which doubled the company’s earnings far ahead of schedule. This approach is also a superb way for a company to identify its next generation of leadership.

4. Make the formal case. Individuals are inherently rational and will question to what extent change is needed, whether the company is headed in the right direction, and whether they want to commit personally to making change happen. They will look to the leadership for answers. The articulation of a formal case for change and the creation of a written vision statement are invaluable opportunities to create or compel leadership-team alignment.

Three steps should be followed in developing the case: First, confront reality and articulate a convincing need for change. Second, demonstrate faith that the company has a viable future and the leadership to get there. Finally, provide a road map to guide behavior and decision making. Leaders must then customize this message for various internal audiences, describing the pending change in terms that matter to the individuals.

A consumer packaged-goods company experiencing years of steadily declining earnings determined that it needed to significantly restructure its operations — instituting, among other things, a 30 percent work force reduction — to remain competitive. In a series of offsite meetings, the executive team built a brutally honest business case that downsizing was the only way to keep the business viable, and drew on the company’s proud heritage to craft a compelling vision to lead the company forward. By confronting reality and helping employees understand the necessity for change, leaders were able to motivate the organization to follow the new direction in the midst of the largest downsizing in the company’s history. Instead of being shell-shocked and demoralized, those who stayed felt a renewed resolve to help the enterprise advance.

5. Create ownership. Leaders of large change programs must overperform during the transformation and be the zealots who create a critical mass among the work force in favor of change. This requires more than mere buy-in or passive agreement that the direction of change is acceptable. It demands ownership by leaders willing to accept responsibility for making change happen in all of the areas they influence or control. Ownership is often best created by involving people in identifying problems and crafting solutions. It is reinforced by incentives and rewards. These can be tangible (for example, financial compensation) or psychological (for example, camaraderie and a sense of shared destiny).

At a large health-care organization that was moving to a shared-services model for administrative support, the first department to create detailed designs for the new organization was human resources. Its personnel worked with advisors in cross-functional teams for more than six months. But as the designs were being finalized, top departmental executives began to resist the move to implementation. While agreeing that the work was top-notch, the executives realized they hadn’t invested enough individual time in the design process to feel the ownership required to begin implementation. On the basis of their feedback, the process was modified to include a “deep dive.” The departmental executives worked with the design teams to learn more, and get further exposure to changes that would occur. This was the turning point; the transition then happened quickly. It also created a forum for top executives to work as a team, creating a sense of alignment and unity that the group hadn’t felt before.

6. Communicate the message. Too often, change leaders make the mistake of believing that others understand the issues, feel the need to change, and see the new direction as clearly as they do. The best change programs reinforce core messages through regular, timely advice that is both inspirational and practicable. Communications flow in from the bottom and out from the top, and are targeted to provide employees the right information at the right time and to solicit their input and feedback. Often this will require overcommunication through multiple, redundant channels.

In the late 1990s, the commissioner of the Internal Revenue Service, Charles O. Rossotti, had a vision: The IRS could treat taxpayers as customers and turn a feared bureaucracy into a world-class service organization. Getting more than 100,000 employees to think and act differently required more than just systems redesign and process change. IRS leadership designed and executed an ambitious communications program including daily voice mails from the commissioner and his top staff, training sessions, videotapes, newsletters, and town hall meetings that continued through the transformation. Timely, constant, practical communication was at the heart of the program, which brought the IRS’s customer ratings from the lowest in various surveys to its current ranking above the likes of McDonald’s and most airlines.

7. Assess the cultural landscape. Successful change programs pick up speed and intensity as they cascade down, making it critically important that leaders understand and account for culture and behaviors at each level of the organization. Companies often make the mistake of assessing culture either too late or not at all. Thorough cultural diagnostics can assess organizational readiness to change, bring major problems to the surface, identify conflicts, and define factors that can recognize and influence sources of leadership and resistance. These diagnostics identify the core values, beliefs, behaviors, and perceptions that must be taken into account for successful change to occur. They serve as the common baseline for designing essential change elements, such as the new corporate vision, and building the infrastructure and programs needed to drive change.

8. Address culture explicitly. Once the culture is understood, it should be addressed as thoroughly as any other area in a change program. Leaders should be explicit about the culture and underlying behaviors that will best support the new way of doing business, and find opportunities to model and reward those behaviors. This requires developing a baseline, defining an explicit end-state or desired culture, and devising detailed plans to make the transition.

Company culture is an amalgam of shared history, explicit values and beliefs, and common attitudes and behaviors. Change programs can involve creating a culture (in new companies or those built through multiple acquisitions), combining cultures (in mergers or acquisitions of large companies), or reinforcing cultures (in, say, long-established consumer goods or manufacturing companies). Understanding that all companies have a cultural center — the locus of thought, activity, influence, or personal identification — is often an effective way to jump-start culture change.

A consumer goods company with a suite of premium brands determined that business realities demanded a greater focus on profitability and bottom-line accountability. In addition to redesigning metrics and incentives, it developed a plan to systematically change the company’s culture, beginning with marketing, the company’s historical center. It brought the marketing staff into the process early to create enthusiasts for the new philosophy who adapted marketing campaigns, spending plans, and incentive programs to be more accountable. Seeing these culture leaders grab onto the new program, the rest of the company quickly fell in line.

9. Prepare for the unexpected. No change program goes completely according to plan. People react in unexpected ways; areas of anticipated resistance fall away; and the external environment shifts. Effectively managing change requires continual reassessment of its impact and the organization’s willingness and ability to adopt the next wave of transformation. Fed by real data from the field and supported by information and solid decision-making processes, change leaders can then make the adjustments necessary to maintain momentum and drive results.

A leading U.S. health-care company was facing competitive and financial pressures from its inability to react to changes in the marketplace. A diagnosis revealed shortcomings in its organizational structure and governance, and the company decided to implement a new operating model. In the midst of detailed design, a new CEO and leadership team took over. The new team was initially skeptical, but was ultimately convinced that a solid case for change, grounded in facts and supported by the organization at large, existed. Some adjustments were made to the speed and sequence of implementation, but the fundamentals of the new operating model remained unchanged.

10. Speak to the individual. Change is both an institutional journey and a very personal one. People spend many hours each week at work; many think of their colleagues as a second family. Individuals (or teams of individuals) need to know how their work will change, what is expected of them during and after the change program, how they will be measured, and what success or failure will mean for them and those around them. Team leaders should be as honest and explicit as possible. People will react to what they see and hear around them, and need to be involved in the change process. Highly visible rewards, such as promotion, recognition, and bonuses, should be provided as dramatic reinforcement for embracing change. Sanction or removal of people standing in the way of change will reinforce the institution’s commitment.

Most leaders contemplating change know that people matter. It is all too tempting, however, to dwell on the plans and processes, which don’t talk back and don’t respond emotionally, rather than face up to the more difficult and more critical human issues. But mastering the “soft” side of change management needn’t be a mystery."


Watch for the follow up on the process of change and look for every opportunity to learn more about Change Management principles. Great Architects are distinguished by practical skills in this area.

Sunday, February 24, 2008

Right Ways of Working with the Left Brain

Bookmark and Share

"The Heart of Innovation" is the blog for Idea Champions, the highly-respected consulting and training company specializing in creativity, innovation, team building, and leadership. A recent post titled "Right Ways of Working with the Left Brain" offered some valuable suggestions for helping to lead left-brained people (like most of us) through creative activities. The article opens with:

"If your job requires you to lead meetings, brainstorming sessions, or problem solving gatherings of any kind, chances are good that most of the people you come in contact with are left-brain dominant: analytical, logical, linear folks with a passion for results and a gnawing fear that the meeting you are about to lead will end with a rousing chorus of kumbaya."
I can relate.

The 10 practices are listed here, but check out the article for details - and fine-tune your ability to provide leadership throughout the creative process. As discussed in Architect as Advocate of the Business and The Proactive Architect, these sorts of leadership skills help distinguish world-class architects.

Ten Tips for Leading Creative Activities:

1. Diffuse the fear of ambiguity by continually clarifying the process
2. Get people talking about AHAS! they've had in their own lives
3. Identify (and transform) limiting assumptions
4. Encourage idea fluency
5. Invite humor
6. Do the right brain/ left brain two-step
7. Periodically mention that chaos precedes creative breakthroughs
8. Establish criteria for evaluation
9. Be a referee when you have to
10. Consult with the tough people on the breaks

Check out the full article here: Right Ways of Working with the Left Brain

Thursday, November 29, 2007

IASA/ITARC Communication Talk

Bookmark and Share

Uploaded my talk on Communications from the IASA/ITARC Conference.

http://softwarearchitecture.s3.amazonaws.com/C4_Communications_IASA_.pdf

This talk elaborated on the 4C's of a good Software Architecture description:

Correct - Accurate content describing the right architecture
Clear - Easily understood and meaningful to the stakeholders
Concise - Includes only the architecturally significant content
Comprehensive - Addresses the true breadth of architectural concerns

Tuesday, July 3, 2007

Good Architecture Descriptions are Explosive

Bookmark and Share

Good architecture descriptions are explosive! Like C4, the architecture description can shake things up, remove roadblocks, and create opportunities where none existed before. In order to have this impact, the architecture description - the Software Architecture Document (SAD) - must be Correct, Clear, Concise, and Comprehensive. It must be C4!

As we touched on in "What is Software Architecture?," it's essential that the architecture of a software-intensive system be appropriately documented and communicated. In "The Most Important Competencies of the Software Architect," we discovered that communication is one of the most important skill groups for the Software Architect and identified the following communications competencies:

  • Understand stakeholder needs
  • Ensure the stakeholders understand the capabilities and limitations of the architecture
  • Gain consensus on approach through diplomacy, compromise, and mediation
A quick look at the communication competencies immediately suggests the pivotal role of the Software Architecture Document (SAD). An effective SAD is essential in gathering consensus and ensuring universal understanding among the community of stakeholders.

Of course, at its core, the SAD is an assembly of models, each representing key dimensions of the architecture. These models are necessarily abstractions of the actual software system, and serve to encourage breadth of understanding, establishing context and meaningfulness to the many stakeholders. As abstractions, though, the models are somewhat removed from reality. In his book on Analysis Patterns, Martin Fowler addresses this concept in a claim that "Models are not right or wrong, they are more or less useful." The authors of Software Systems Architecture expound on the idea and argue convincingly that "Every architectural model is an approximation of reality. In other words, it is only partially accurate and partially complete."

Given the nature of the SAD as a series of abstractions, it can sometimes be a challenge to decide what content is appropriately included in the Software Architecture Document and what is better left for other (important but separate) artifacts. To help encourage good decisions in this area, it can be helpful to pursue an "Explosive" architecture description that maximizes the four C's:
  • Correct - Accurate content describing the right architecture
  • Clear - Easily understood and meaningful to the stakeholders
  • Concise - Includes only the architecturally significant content
  • Comprehensive - Addresses the true breadth of architectural concerns
Correct

Arguably "Correctness" is the foremost quality of a Software Architecture Document. The SAD is one of the most critical tools for ensuring consensus among the stakeholders. By accurately representing the needs and concerns of the stakeholders and mapping those concerns into the solution space, the Software Architect is able to validate consistent understanding of the needs and ensure they're accurately satisfied by the architecture.

To gain full benefit of the architecture description, the SAD must be kept up to date. This ensures that the right inputs are being considered and encourages good decision making. Keeping the SAD up to date requires the integration of effective processes into development, operational, and support plans.

Clear

In order to be effective as a communication vehicle, the SAD must be written in clear and straightforward language and organized/structured in a manner that promotes the ability of each stakeholder to understand the relevant parts. To accomplish this goal, the Software Architect must demonstrate two things to each stakeholder (or stakeholder group): 1) The needs of that stakeholder are accurately understood, and 2) The needs are met by the architecture. As different stakeholders have different interests, it's essential to structure the SAD in a way that accommodates the various perspectives. A common approach to dealing with this factor is the use of multiple views such as described in "The 4+1 View Model of Software Architecture" promoted by the Rational Unified Process and Phillipe Krutchen (http://www.win.tue.nl/~mchaudro/sa2004/Kruchten4+1.pdf).

In addition to multiple views and perspectives, a SAD is typically more clear when you go out of your way to establish business and technical context and to tailor the content, language, and detail to the audience's skills and experience.

Concise

Of all the SAD quality attributes, "conciseness" is one of the most difficult to achieve. But it's also one of the most important. In fact, a SAD that comes up short in conciseness is likely to come up short in other dimensions such as correctness and clarity. By carefully calibrating the level of detail represented in the SAD, the Software Architect fine-tunes the clarity of the document and makes it more meaningful to the stakeholders. Essentially, this is an exercise in maximizing the purity of the architecture description, aggressively fending off the fluff and maximizing the signal-to-noise ratio.

When the SAD is effectively concise, it represents only those characteristics of the system that are truly architecturally significant. This means, as we progress more deeply into a software project, the SAD becomes more and more stable (as the architecture becomes stable) and the document is easier to keep current. This reduces the effort associated with the maintaining the document and maximizes its value, both during the project and throughout the life of the product.

Comprehensive

Comprehensiveness can be the opposite of conciseness, so we see here one of the many balancing acts played by the Software Architect. To be effective, the SAD must include the full scope of business and technical concerns and establish a clear context for their understanding and evaluation. These concerns must then be analyzed and addressed with sufficient precision and detail to encourage strong stakeholder review and support the ongoing implementation of the system.

In "What is a Software Architect," we identified the role of the Software Architect as:
  • The software architect has overall responsibility for driving the major technical decisions, expressed as the software architecture. This typically includes identifying and documenting the architecturally significant aspects of the system, including requirements, design, implementation, and deployment "views" of the system.

  • The architect is also responsible for providing rationale for these decisions, balancing the concerns of the various stakeholders, driving down technical risks, and ensuring that decisions are effectively communicated, validated, and adhered to.
Successful Software Architects recognize the need for an explosive Software Architecture Document that maximizes the four C's.

Wednesday, June 6, 2007

Secrets of Collaboration

Bookmark and Share

It's increasingly important for Architect's to exhibit effective collaboration skills. For example, innovative ideas, trust, and teamwork thrive in a collaborative environment (and we know that trust and communication are precursors to results). Also, many of us find ourselves working with teams that are geographically and culturally disparate, a situation that demands even greater collaboration - more creatively.

In this light, Alistair Cockburn recently gave a sneak preview of an article he's working on about improved collaboration. He highlights the following practical techniques:

  • Lift others
    • Be courteous
    • Add energy to the room
    • Listen intently
    • Inquire (don't argue)
    • Recognize others
    • Challenge but adopt other suggestions
  • Increase safety
    • Be yourself
    • Say something honest and true, but on the edge
    • Support someone else who is at the edge of their comfort level
    • Challenge but adopt other suggestions
  • Get results
    • Make sure there is a known goal
    • Get one result (then get more)
    • Focus, get back from diversions
These suggestions are provided in the context of a specific engagement or meeting, but many can be applied in general. Reading through the list, I'm reminded of principles such as "Seek first to Understand" from The 7 Habits of Highly Effective People and "Vigourous Debate" from Good to Great: Why Some Companies Make the Leap... and Others Don't. These are not only essential characteristics of a healthy and productive culture, they're essential skills of the Software Architect.