Change Management

How do you manage changes in your project?

The change is one of the most difficult things to deal with during a project. There are many reasons for this, you don’t have extra resources, the project timeline can not change, the budget is short, etc.

Small changes are easy to do with a few or no impact in project delivery. But when the requested change applies to a behaviour already developed or being developed, the problem becomes serious.

Project managers have three things they can change during a project life cycle. When they got a request to change the scope there are only two ways to go: add Resources or delay delivery date.

How can they avoid having to take such decisions?

As an example, imagine you are working in a project to develop a web application to manage a Quality System. After planning the project manager should be able to give a Ready To Market date to the stakeholders. The first step is to Plan! Yes, this involves a lot of steps and it is not my point to discuss it now. But Change Management starts right here.

Suppose your project has six iterations (or sprints), the last two spent in stabilization (meaning no more code only bug fixing).  You probably start by defining the scope of the project,  the requirements, architecture and design before you start coding and testing. The more advanced in iterations you are the more difficult is to manage the change.

But we all know that changes can’t be avoided, unless you prefer to delivery a product that is no longer what the client wants.

Now suppose your team is already coding and you find out that an important feature was not planned. The reason could be a missed point in design. Suppose this feature will affect the code already written. Panic? No need.

In this scenario two things might happen. If you spent a good time in design iteration, considering all conditions, then the probability to occur the scenario described is very low. Otherwise, the probability rises. To be prepared to this you should consider some time in your planning to use in case of a scenario like this occurs.

There should be a balance between the time consumed in design and requirements definition and the time reserved for design failures. This depends on the complexity of the application, the expertise of designers and developers, the experience in similar projects, the available resources, and the project budget, among others.

By my experience some of these change requests will happen during testing phase. When testers start working they have a product to test, or part of it, and it’s easier to see things when you have a product in your hands. Developers didn’t look at it the same way. Another reason is the ability a tester has to see things as a developer and as a user, at the same time. This is why it is so important to involve testers in all phases of developing process. They are good allies to analysts and developers.

Now consider another scenario. During a presentation of the application the client decided to include a new feature, or change an existent one, but he needs to keep the RTM date. Will you work during night? How can you add this new feature if you don’t have more available resources?

It is important to give this to the client, otherwise he will get a product that isn’t exactly what he would like to have.

You may use the same strategy of the first scenario or you may improve it.

Before you start planning try to negotiate with your client a Box that he might use to add or change features, during the project development. The Box can be an amount of time, number of resources, number of features, extra iterations, number of code lines, anything that you both can measure. The client must be able to pay for this and you have to include this in your planning.

My advice is that you should expect changes because they will happen for sure.