This is the third in a series of articles aimed primarily at those who are beginning or thinking about beginning a process improvement journey. These articles address five questions, which have proven useful in thinking about and structuring process improvement programs. Further, they are based on the premise that any process improvement program should be driven by and related to some set of business or overarching organizational needs. Process improvement for its own sake will soon die. It must address strategic organizational imperatives if it is to be successful.
The five questions are:
I. Motive – What are the critical business issues driving process improvement?
II. Model – Which reference model best maps to the organization practices?
III. Method – How can you quickly and effectively identify improvement opportunities?
IV. Managing Change – What factors impact the effectiveness of introduced changes?
V. Measures – What are critical factors in setting up a measurement program?
This article addresses question IV – Managing Change.
IV. Managing Change - What factors impact the effectiveness of introduced changes?
Human beings are typically resistant to change. I've observed that in my own life in little things like having to move my office. This resistance often comes from uncertainty, which can generate fear, anxiety, a sense of loss, and skepticism ("here we go again"). If an organization has had previous change initiatives, which were unsuccessful, this creates a climate of doubt and resistance. Management needs to be aware of the change climate in an organization prior to beginning a major change initiative such as a process improvement program.
Success and Failure Factors
Watts Humphrey describes a number of factors, which are critical to the success of process improvement: 1
•Major changes to the software process must start at the top.
•Ultimately, everyone must be involved.
•Effective change requires a goal and knowledge of the current process.
•Change is continuous.
•Software process changes will not be retained without conscious effort and periodic reinforcement.
•Software process improvement requires investment.
Conversely, Hefner2 identifies the top ten reasons process improvement programs fail:
Failures in strategy:
•Failing to define reasonable goals and plans.
•Failing to tie the improvement goals to business objectives.
•Having inadequate resources and unrealistic expectations.
Failures in planning:
•Starting improvement efforts without an assessment (and/or without CMM knowledge).
•Running improvement efforts like another Level 1 project, with no requirements, no plan, no tracking against plan, no configuration management, no quality assurance, etc.
•Over-focusing on a common solution – "Let's write a new standard development process."
Failures in execution:
•Ignoring middle management - Middle managers stand to lose the most, and are the most effective in resisting change.
•Confusing institutionalization with standardization - A strong culture does not imply everybody does it the same way.
•Defining process changes too early - Improvement is not simply about doing things differently; it requires a change in the culture to sustain the improvements.
•Trying a do-it-yourself approach - SEPG (Software Engineering Process Group) skills are different than software development and management skills.
A Software Process Improvement (SPI) effort will be most successful if it is treated as an on-going project to improve your overall business viability, not a specific point solution to a temporal or transient business demand.3
To implement specific changes an organization should use the concepts embodied in the Process Change Management Key Process area of the Software Capability Maturity Model: (1) continuous process improvement is planned; (2) participation in the organization’s software process improvement activities is organization wide; and (3) the organization’s processes are improved continuously.
These basic principles can be applied no matter what the level of the organization.4
Cultural Issues
Humphrey5 suggests that many current software problems stem from the pervasive culture of software organizations. This culture has developed over many years and has been largely responsible for the poor performance of these organizations. This “hacker” culture glorifies rapid coding, is schedule driven, and objects to planning. Commitments are generally missed, while quality is unmeasured and unmanaged.
What is culture? It is a pattern of shared basic assumptions:6,7
- that a group learned as it solved problems;
- that has worked well enough to be considered valid; and
- is reinforced as the correct way to perceive, think, and feel in relation to resolving problems.
Caputo posits three layers of organization culture:
- Communications – the visible aspects;
- Expectations – the desired results; and
- Assumptions – the subconscious aspects.
The assumptions are the part which is often missed
d or neglected in implementing changes. Cultural change involves rethinking those basic assumptions, deciding some assumptions are no longer valid, and learning a new pattern of shared basic assumptions. For example, the change in moving individuals checking their own code to peer reviews involves a change in the basic assumption about how errors in code can be most reliably detected.
Changing the Culture
To achieve successful change, the existing culture must be recognized and dealt with. Existing culture must be recognized and dealt with. Existing culture tends to reinforce itself. For a change to stick, expectations must be:
- Expressed – “Here’s what we expect.”
- Demonstrated – “Here’s what we do.”
- Reinforced – “Here’s what we reward.”
- Believed – “Here’s why this works for us.”
To change the culture, one must focus attention on the visible aspects of process improvement. But it is also necessary to pay attention to the invisible aspects of culture change. Start with understanding the assumptions, and improve by changing expectations and communication. Keep yourself and others motivated to change.
Using CMMI terms as a reference, we see:
- the Key Practices as the communicated visible aspects;
- the Maturity Level Goals as the expectations/desirable results; and
- the assumptions as the “not discussed” subconscious aspects.
Cultural change, supported by a transformed leadership and appropriate tools and enablers, will enhance the formal process change process. Absent that foundation portrayed in Figure 1, the formal process change is likely to flounder.
There is a range of approaches to managing change (see Figure 2) from which one is consciously or unconsciously chosen. The primary differences between the three basic approaches are in the assumptions about human nature in relation to achieving change. At one extreme is the mandated approach in which the focus is almost totally on logistical or project management issues—“get the job done”—with no focus on human and organizational issues.
At the other extreme, the managed approach to change is where there is at total commitment to planning for the human and organizational factors. At some midpoint on the continuum is the mediated approach.
Mandated Change
In this approach, shown in Figure 3, leadership mandates the change and focuses on managing time and resources established in the project plan. The approach is based on the assumption that human and organizational factors do not play an important factor in achieving desired results. When such issues surface, as they surely will in implementing a complex change, this approach adopts strategies to enforce behavior changes.
Mandated change has these characteristics:
- Top leadership sets direction.
- A project plan is constructed and followed.
- Compliance mechanisms are used to enforce the needed change in behavior to achieve the objective.
Mediated Change
This process, shown in Figure 4, is top down, involves a small number of “smart” people, and results in a very slow implementation. It is task and event oriented and usually reactionary. If the desired results aren’t achieved, if the behavior doesn’t change, a level of bureaucracy is installed to enforce the results and behavior needed.
This process may work all right in a smaller, top-down driven organization. It is less effective in larger organizations. It has these characteristics:
- Small team determines what to change.
- Team aligns and sets strategies.
- Organization members develop new mindsets and behaviors.
Managed Change
This new approach, illustrated in Figure 5, is based on the belief that to change the behavior of an organization you need to change the behavior of individuals, but in instead of selling the new view at the end of the process, you build it in advance. Instead of a few people defining solutions or strategies, people together discover the answers.
Things you discover for yourself are felt more deeply than those thrust upon you. This process requires more people to get involved so that the change is owned so that a sense of urgency results. This approach requires more time spent early in the planning. Planning is a learning tool which is used to create a shared view. This process taps into the wisdom and good ideas of those in senior leadership roles and also those within the ranks.
The approach cultivates trust, teamwork, and greater resilience. Managing change is a process of discovery. A far greater probability of successful implementation exists when this approach is used. The investment time is paid in advance, instead of later in solving problems.
It has these characteristics:
- Stakeholders create a shared vision of the change.
- Stakeholders set the strategies.
- Stakeholders align the organization to the change.
Organization Readiness
Assessing the readiness of an organization to undergo change is a critical step. The Software Engineering Institute (SEI) has an Assessment Readiness Survey as part of its Assessment Kit available to lead assessors. It is used to explore such issues as sponsorship, culture, resistance, synergy, and organizational issues. There are also courses offered by business trainers.
Transition Strategies
Transition strategies are used to facilitate the introduction of process changes by addressing key organizational issues and possible points of resistance. The strategies address eight key issues to be dealt with throughout the entire change process.
Team structure – Establish the team and its structure to plan, implement and sustain the change: sponsor, leadership team, change team, change coach, and transition team.
Leadership – Establish the sponsorship development activity and learning organization environment for achieving and sustaining the desired change.
Education and training – Establish the education and training to provide stakeholders the knowledge and skills of methods, tools and processes integral to the change initiative.
Measures – Establish the business value, process and readiness measures that should be tracked and monitored to enable learning and measuring progress, as well as results. (These issues will be discussed in the next article in the series.)
Business and technology integration – Determine the desired change in business performance and integrate the technology-driven changes that will support it, such as systems lifecycle, project management, or new tools.
Performance measurement – Identify the desired behaviors and performance results for the change; establish the reinforcement mechanisms for each behavior (positive and negative) to institutionalize the change.
Relationship management – Determine how the change will impact your customer or supplier and establish a win-win business relationship for working together.
Communications – Establish communications for the change within all levels of the organization.
Implementing Change Methodology (ICM)
Electronic Data Systems (EDS) uses a guiding framework for organizational teams to use in planning and implementing fundamental changes that impact the people, culture and structure of the target organizations.8
The ICM framework (see Figure 6), developed by Implementation Management Associates, incorporates the eight transition strategies in three phases:
Develop a shared understanding – Describe the change, build the team structure, assess the organization’s readiness and complete project startup.
Develop key strategies – Determine scope, develop transition management structure and process, and prepare a phased implementation with the enabling strategies, processes and associated training.
Align the organization – Apply the transition plan, evaluate progress and results, align the organization components, sustain continued improvement, and create added organizational capacity for future changes.
Critical Elements for Cultural Change and Process Improvement
Sponsorship is, of course, one of the most critical elements in successful process improvement. Without serious top management involvement and support long-term successful process improvement is doomed. Davis suggests that senior management understanding is the first critical element in a series of steps toward successful process improvement9, including senior management commitment, organization assessment, process documentation, improvement implementation, and a focus on project management discipline.
Change agents are those individuals who serve as catalysts to bring about organization change. They should be respected opinion leaders who can influence others to implement change. Ferguson10 suggests some basic principles for change agents: get a sponsor with appropriate budget and spending authority; do real work; be a missionary; rather than tackle an entire process area, do one thing better, faster, cheaper that people did it before; advertise, advertise, advertise—make certain that every victory makes the evening news.
The Software Engineering Process Group is the focal point for process improvement.11, 12 It provides guidance and leadership to the organization. Composed of line practitioners who have varied skills the group is at the center of the collaborative effort of everyone in the organization who is involved with software engineering process improvement.
Group size is usually equal to one to three percent of the development staff. Because the process group is generally small, it relies upon support of a management steering committee and various technical working groups to address specific process issues.
Process Action Teams (PATs) are a good choice for actually defining and implementing specific process improvements.13
Getting PATs up to speed is easier with a defined process. One such process is documented in ETVX (Entry, Task, Verification, eXit) format, which is also used by the team to document the model of the process they are working on. In addition to assorted templates and guidelines for both project output as and project planning, and status reporting, each step in the process has entry and exit criteria, roles, measures, standards, and tools.14
Summary and Conclusion
Managing change is a difficult and time-consuming task. However, without sufficient top management sponsorship and leadership (which means much more than just mandating “get it done”) , process improvement will at best flounder, and more likely fail and engender a climate which will make future improvement initiatives more difficult.
The foundation for process improvement is solid project management. Management must insist that product development work be planned and properly managed. Senior leadership must then continue to insist that all the projects be planned, even in a crisis. They must respect the plans and ensure that the engineers own and defend them.
Management must review and critique these plans to look for holes and oversights. Once the engineers have defended their plans, management must respect these plans and not override them with schedule edits. This kind of management support can establish a culture which empowers organization members and encourages process improvement.
References
1. Humphrey, Watts. Managing The Software Process, Addison-Wesley, 1989.
2. Hefner, Rick. The Top Ten Reasons Improvement Efforts Fail, 1999, SEI SEPG Conference.
3. Rabideau, Mark F. Providing the Context for Successful Software Process Improvement, 1999, SEI SEPG Conference.
4. Kolkhorst, Barbara and Kitty Olson. Jump-Start Your Software Process Improvement Program, 1999 SEPG Conference.
5. Humphrey, Watts. Changing the Software Culture, 1999 SEPG Conference.
6. Caputo, Kim. Level 3 Culture is More Than Just the Artifacts, 1997 SEPG Conference.
8. Waina, Richard B. and Wiliam Phifer. Purpose-Driven Process Improvement, 2000 SEI SEPG Conference.
9. Davis, Darryl. On the Cart and Horse: Putting Process Improvement Activities in the Right Order, 2000 SEI SEPG Conference.
10. Ferguson, Robert W. The Guerilla Warfare Approach to Process Improvement, 1998 SEPG Conference.
11. Wigle, Gary B. The SEPG From Level 1 to Level 5, 1999 SEI SEPG Conference.
12. Rifkin, Stan and Priscilla Fowler. Software Engineering Process Group Guide, SEI, September 1990.
13. Eagen, Bob. Where the Rubber Meets the Road: Getting It Done with Process Action Teams, 1999 SEI SEPG Conference.
14. Waina, Richard B. A Process Action Team Process That Works, Software Technology Conference, May 2000.
Richard B. Waina, P.E., Ph.D., Principal of Multi-Dimensional Maturity, has over 35 years of experience in information technology. He worked for five years at White Sands Missile Range, measuring, analyzing and predicting missile range workload. He was with the Rand Corp. Air Force think tank where he developed computerized logistics, simulations and cost models. He has worked on a number of missile programs, including Maverick for the Air Force, Phoenix for the Navy and TOW for the Army. At EDS he was responsible for deploying process maturity assessment methodologies globally. He holds engineering degrees from Carnegie-Mellon University, New Mexico State University, and Arizona State University.
The views expressed here are solely those of the author, and do not necessarily reflect those of the Department of the Navy, Department of Defense or the United States government.