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 improvement1:
•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 tra