Best Practices for Software Projects -
Change Control
This year's newsletters will focus on best practices for Software
Development Projects. Each month will cover a different best practice
technique. This month focuses on improving project management by managing
feature creep with solid Change Control practices.
|
Newsletter
Sponsored by Software Planner |
|
http://www.SoftwarePlanner.com
Sign up for a free 2 week trial and you are entered to
win a
FREE HP Pocket PC |
|
Software Planner (http://www.SoftwarePlanner.com)
helps improve the quality of software releases and decrease software
maintenance costs by providing you with tools for managing all phases of the
software lifecycle. Software Planner tracks customer requirements, test
cases, defects, support tickets, appointments and to-do lists, and allows
you to share documents and hold threaded discussions. Fully web-based
and integrated with email.
|
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 manage 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.
|