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 system
• a change to any inputs or outputs of the application,
• 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 change request.

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 negative consequences.

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 the Change 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 team member.

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 discussed:

• 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 your ability.
• Shield the team members from pressure.