- Dimensions and Components of Change
- Human and Social Factors of Change
- Managing Change and Its Effects
- Making Things Real
- References
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Managing Change and Its Effects
During projects, change can happen along any dimension and factor. The most visible changes are related to new or changed requirements. Common changes are related to optimization of a product under development. Some of the changes are needed, but others are self-inflicted opportunities to increase Cost or reduce Quality while achieving marginal gains in Features. A key goal is to manage change in an orderly manner so that closure of project development is achieved (see Figure 7).
){kind=link}
Early in a project, business sponsors and development management must come to an understanding of the impacts of change during software development, especially after requirements are "approved." Change is defined as new or modified
Infrastructure or architectural features
Use cases and consequent functions, data, user interface, etc.
Cost or quality factors
Rule of Thumb
A project must decide how much change is absorbable over time.
UCD, user participation, and visualization of requirements facilitate approval and closure of requirements and design, and minimize the risk of major rework in later project phases. UCD is useful as a tool to evaluate and manage the impacts of change.
Figure 7 Managing change over time.
Change has impacts during all phases of a project, including planning. It is difficult to develop a plan if a project is impacted by massive changes in fundamental direction, goals, features, or strategy. Depending upon the change proposed during a given phase of development, a project may need to revert to an earlier phase of the development cycle. For example, a conceptual or fundamental change in the requirements in one functional area may require that a project revert to planning, conceptual design, high-level design, prototyping, and user evaluation prior to proceeding.
Once understood, sponsors and management can set limits on how much change is manageable over time; for example, "no more than 1% change after entry into Low Level Design" and "no change once construction is complete." Change can be measured in terms of new functions, data elements, user interface (for example, appearance, behavior, interaction), information, and integration features. Change can also be measured in terms of impacts to cost (person hours) and quality factors (calendar time), as well as project deliverables (specifications and test results).
Rule of Thumb
The more things change, the more things are the same except for schedule, cost, and quality of software projects with uncontrolled change.
Regardless of the source and timing, any change must be evaluated carefully. Early in a project, there may be lots of flexibility in adjusting Features, Cost, or Quality factors in order to accommodate new requirements or product optimizations. Late in a project, flexibility in adjusting anything except Schedule is more limited. The goal of sponsors, users, project managers, and technical leaders should be to complete development and defer any changes not deemed essential to success.
Rule of Thumb
The more things change, the more a project falls behind, the higher the costs, the longer the schedule, the more compromises are made, and the more frustrating it becomes.
Regardless of the magnitude, any change must be evaluated carefully. Early in a project, there may be lots of flexibility in doing "neat things" or nice features. Late in a project, flexibility in adjusting and polishing may be quite limited. Time spent in polishing could be deferred until critical aspects of a project are completed. Of course, use of participatory methods for evaluating change is important.
Rule of Thumb
Late, uncontrolled, and unmanaged change in a vacuum is a project killer, and is upsetting to sponsors, management, and developers.