Closing the Back Door to Project Changes
A problem that plagues many project managers, particularly
in the software development industry, is those changes that mysteriously appear
in the work that you are unaware of until something brings it to your
attention. The change is usually brought to your attention when something breaks
without a logical explanation. For example, developer testing passes and yet
when the QA tester attempts a test, the software under test experiences a
fundamental failure. The explanation is usually that there has been a change to
the software design that has not propagated to the test cases the QA tester is
using. The reason: a stakeholder has approached your software analyst or programmer
to ask for a "minor change" that won't take "any time at
all" to implement and your P/A has gone ahead and implemented it.
Now you are left with 2 choices: either you can back the
change out of the code or you can propagate the change across all the areas
that the code touches. The 2nd option is not very attractive as it will signal
open season on changes to your project and annoy those stakeholders who were
following your Change Management process. Regardless of which option you
choose, this "back door" change will add to the cost of the work and
quite possibly put you behind schedule. This situation calls for
"preventative maintenance" so that the back door change doesn't
happen in the first place.
The preceding is not the only scenario that will alert you
to the existence of back door changes. When you are alerted to the change by
your QA tester, UAT tester, or some other team member who has been impacted,
you may find that the source is not a stakeholder but the team member. This
scenario usually springs from a programmer finding an error in the detail
design document, functional specification, or software specification. Instead
of making a big fuss over the mistake, the programmer quietly fixes it without
causing anyone any embarrassment. Unfortunately, this often shifts the
embarrassment further down the line to the testers who were not made aware of
the change. The source may not be a fix to a bad design, it may be a better,
more efficient way to deliver the same functionality. For example, where a
design dictates an inefficient way of querying the database, or a calculation
that uses an exorbitant amount of computing resources. The consequences of this
change are every bit as costly as the back door change requested by the
stakeholder and you will want to avoid these.
QA and UAT testing are not the only downstream areas
affected by these changes. User manuals may become out of sync because of the
change. Training may also be affected. The cost of a change to the
functionality of the application not caught before manuals are published or
training delivered, can dwarf the cost of changing software and tests. Changes
may also affect deliverables upstream from the software. For example, a change
to software design may put the supporting functional specification out of sync.
The obvious first step in avoiding these back door changes
is a good Change Management process. Actually you will probably want to have
more than one process for the typical software development project. Good Change
Management calls for the process to be agile and for decisions to be made by
the right decision makers. This means that decisions on one of the project's
key deliverables, schedule, or budget should be made by the CCB (Change Control
Board), or CAB (Change Approval Board). Changes of a technical nature which
alter the work of the project without any change to the schedule, budget, or a key
deliverable should be made by someone with an understanding of the requested
change. This understanding should enable the decision maker to analyze the
change and determine the extent of the impact. This person will usually be you,
but could be someone else on the team who has the required technical knowledge
and is also knowledgeable about the project.
Your second step is the communication of the
process/processes to the team and the stakeholders. Stakeholders will include anyone
who would have the authority to ask for a change to the project. Communication
should include training on the process so that stakeholders and team members
are not only aware of the process/processes, but are also familiar with their
responsibilities to the process. The key responsibility for stakeholders is the
use of the Change Request form to capture all the information about the change
they are requesting, and the communication of that completed form to you (or
the Change Manager). You need to ensure that all stakeholders have easy access
to the form. Training should be tailored to each group identified in the Roles
and Responsibilities section of your Change Management process/processes so
that they focus on their responsibility. Try using a 1/2 hour meeting to do the
training. You might even do it with a "lunch and learn" session.
Informing the stakeholders and team members of the change
management process/processes and then training them to fulfill their
responsibilities is no guarantee that they will follow the process. Ultimately
you must rely on your team members to refuse to make back door changes
suggested to them by the stakeholders, and avoid making back door changes themselves.
Let's deal with the easiest case first. It will be much
easier to prevent your team members from making their own back door changes than
to prevent them making those changes on behalf of stakeholders, because there
is no external pressure on them to compete with the pressure you apply to not
make the changes. To exert that influence, be clear with the team that no
change to the software, functional specs, software specs, test cases, etc. will
be tolerated without going through the proper process. Walk the talk here. That
is, make sure that you follow your own process whenever you make changes to the
project work. Don't just update the MS Project plan and communicate that
change, fill out the change request and follow your own process. Walking the
talk is an excellent way to show leadership to the team.
The other side of the coin is holding team members
responsible for their actions, including the damage caused by back door
changes. Take the offending team member aside the first time this happens and
explain the consequences of the action to them, then let them know the consequences
of a second offense. Consequences may be a negative performance evaluation, a
reduction or elimination of a performance bonus, a demotion, or even termination,
but should be on a personal level. You should be able to translate the negative
impact of the action on the project into a negative impact on the offender.
Use common sense when determining what constitutes a
"back door" change. Any change that has no impact on another team
member should not be included in the changes you are trying to prevent. If the
change would improve the product and has no down side, don't discourage it.
Changes that are made by team members acting in concert should also not be
included. Again, the team members involved should include everyone impacted by
the change. There are some indicators that will allow you to predict the extent
of the change's impact:
- a change to the way a user interfaces with the
- a change to any inputs or outputs of the
- any change to an underlying requirement
- any changes that would impact test cases, user
manuals, or training
Changes to any of these should always be supported by a
Team members can be placed under considerable pressure by
stakeholders who want a change but are not willing to follow the process you
have provided. The minimum reward is a pat on the back and an "atta
boy/girl"; the stakeholder makes the team member feel good about
themselves because they have given the stakeholder something they wanted. Some
stakeholders may be in a position to provide the team member with a reward:
they may have input to performance evaluations, have influence over deciding on
bonuses, or may be someone the team member wants to work for in the future.
These sources of influence all put pressure on the team member to accommodate
the stakeholder and make the change.
Stakeholders may be tempted to exert negative pressure on a
team member. "If you aren't prepared to grant me this small favour, don't
expect me to praise you in your evaluation!" Hopefully, your project won't
have any stakeholders who are prepared to use threats, direct or implied, to
get their way but if it does you must shield your team members from any
Having key stakeholders sign off on the Change Management
Plan (containing the process/processes) is one way of ensuring that key
stakeholders are aware of their obligations to the project, but you can't have
everyone sign off on that document. You will need to create an environment for
your project where team members come to you first with a problem. The best way
to create this atmosphere is to take action whenever a team member comes to you
to report pressure to do a back door change. Talk to the stakeholder and
explain why the team member can't make the change without following the
process, explain the process to them and ensure they have ready access to theChange Request form. If the stakeholder indulges in threatening behaviour, make
sure the team member understands that you will shield them from any negative
consequences. You may choose to talk to the stakeholder first and have the conversation just described, or you may choose to go to your sponsor with the
situation. In either case, steps must be taken to eliminate the threat to the
There is one exception to the advice in the preceding
paragraph: when the work is being done for an external customer. External
customers may go directly to your team members but they are usually not in a
position to pressure the team member either positively or negatively. External
customers will usually attempt to influence the project through you. Having a
Change Management plan signed off by the customer as part of the contract
covering the work will be very helpful here. The customer may attempt to
introduce the change through your project sponsor. If your sponsor directs you
to make the change (there could be valid financial reasons for doing this),
complete the change request yourself indicating the impact the change will have
on the project. Changes that will impact on the project schedule, budget and
deliverables should be decided on by the CCB, even when the decision is a
foregone conclusion. A change in the schedule may or may not be approved by the
customer. Your project sponsor should understand that the change agreed to will extend the schedule (or cost more money to compress it). A change to the budget may or may not mean a change to the price the
customer will pay for the software. The additional cost should come from your
corporation's margin on the contract when it doesn't come from the customer. In
either case, your project's budget should change and your project be
re-baselined upon approval of the change.
I've attempted to provide some useful examples of actions
that will prevent back door changes from happening, but of course every project
and situation is unique, so you will have to identify the actions that are
appropriate for your specific situation. Just remember the key points we've
- Your project must have a change management
process, or processes, described in a change management plan.
- The plan and process/processes must be agile and
identify the right decision makers.
- The plan should identify the roles and
responsibilities of everyone on the team and all the stakeholders.
- The team and stakeholders should be educated in
their responsibilities to the process/processes.
- Walk the talk.
- Don't unnecessarily restrict team members
ability to do their work in the most efficient way.
- Hold team members accountable.
- Hold stakeholders accountable to the best of
- Shield the team members from pressure.