|
Best Practices for Software
Projects - Change Control
When developing and enhancing software, a well laid plan
has a documented set of features, detailed designs, and estimates that
allow the project manager to quickly determine if the project is on track
to completion. As development proceeds, it is not uncommon for
business or market conditions to change, thereby changing the needs of a
software project that is currently in development.
Change control is the process of managing changes as to
ensure that decisions are not made hastily and that the decision to add an
additional feature is in the best interest of the project. If
change control is missing from a project, new features will be introduced
at random, jeopardizing the delivery date and quality of the software
being developed.
To manage change, it is best to have a Change Control Board. The Change Control
Board normally consists of the project manager, client manager,
development (programming) manager, quality assurance manager, user
documentation manager, and support manager. As new changes are
requested, the Change Control Board analyzes the risks and rewards of the
proposed change. They analyze how the change affects the overall
schedule, costs, and feature set. Below are some guidelines for the
Change Control Board:
- OK to say "No" - If
the project team has done a good job of collecting requirements and
managing the software life cycle, many features have already been
reviewed and prioritized before coding begins. If the new
requirement is not worth the time of analyzing it, then it is not worth
the time to implement it, therefore, it should be rejected
immediately. Normally, a good Change Control Board will say "No"
more times that it says "Yes", as to ensure that only critical changes
are implemented.
- Changes should be Bundled
- A large number of small changes, when done independently,
can greatly affect the project timeline because each one affects many
areas of the system (analysis, coding, testing, user documentation,
support, etc). To gain economies of scale and effective use of
personnel, it is wise to document a set of changes at one time and
include them into a bundled release. By doing this, you eliminate
a lot of the convergence needed with implementing each feature
separately.
- Eliminate Bureaucracy
- Some Change Control Boards are tainted by individuals that
just like to say "No" for the sake being in charge. This can bring
ill-will to a project, when it seems as if the Change Control Board is
not making decisions that are in the best interest of the project.
To eliminate this problem, educate all members of the Change Control
Board before the project begins. Ensure they understand that there will
be frivolous changes that will be submitted as well as legitimate
changes necessary for the product to be marketable and to meet the needs
of the business. So as each new change is suggested, have a
risk/rewards discussion that documents the business reasons for the
change and the risk associated with the change. Documenting and
publishing your findings for each change request provides understanding
and buy-in from members that requested the change.
- Document Changes -
Document each change by first assigning the change request a unique
tracking number. Then have your team do an analysis of the
risk/rewards for the change and document that. It is wise to use
an on-line change management solution that allows you to track the
changes and manage the workflow of it (reviewing, approving and
rejecting changes). There are many solutions for aiding you in
this process. For example, Software Planner (http://www.softwareplanner.com) has a
functional specifications feature that tracks change requests and allow
you to manager the associated workflow.
As you have seen, changes can be easily managed with a
disciplined approach to project management. Below are some helpful
templates to aid you in managing the entire software life
cycle:
About the Author
Steve Miller is the President of Pragmatic Software
(http://www.PragmaticSW.com). With over 20 years of experience, Steve has extensive
knowledge in project management, software architecture and test design.
Steve publishes a monthly newsletter for companies that design and develop
software. You can read other newsletters at http://www.PragmaticSW.com/Newsletters.htm. Steve's email is steve.miller@PragmaticSW.com.
|