Managing Software Projects – Dealing With Change

Managing Software Projects – A Software Engineers Perspective.
Contrary to popular belief, many aspects of a software project could be proactively controlled and managed by an ordinary software engineer to make his/her life easier. Instead of whining about frequent requirement changes, looming deadlines ..etc, there are many things you can do to help yourself retire with enough hair left. The “Managing Software Projects” series is an attempt at exploring these aspects.

Be In A Position Of Strength When Changes Occur (By Maintaining Code In A Ready-To-Ship State).
Rarely does anything in life work according to plan and software projects are no exception. Simply put, changes are bound to happen and how you deal with them will determine how successful the project is. Most of these changes will be involuntary and unexpected and the programmers and testers are usually at the receiving end. With deadlines whizzing past you the pressure mounts and the vicious cycle continues. This is where a solid foundation is useful as explained here. If you have a solid foundation, then it becomes less of a burden to maintain code in a ready-to-ship state at all times. Without that you may not have the ability to respond to changes in a timely manner. Lets look at a few scenarios.

Sudden requests for demos or alpha/beta builds by influential customers. If you have a continuous build system and you keep your builds reasonably green, then you could literally provide the last successful build. If not you would need to drop everything you are doing and try to figure out a way to get a stable build. If you have many test failures, you will probably need to fix them first as well.

A team member resigns, or falls ill. Unless the project culture had insisted in tested, reviewed and documented code right from the get go, the person who have to take over will need to spend a significant amount of time in getting it going.

And our favourite, the customer and/or marketing folks change their mind for the umpteenth time. Again if you have ready-to-ship code backed by an armada of tests (unit, integration, performance, interoprability ..etc) then you are in much better position to make the required changes with confidence. The tests will provide you instant feedback about the impact. The most important thing is to be able to give an accurate picture of the impact of such a change. If you have evidence to backup your claims then managers, marketing folks and the customer are more likely to listen to you

Have A Well Defined Process To Manage Change (No, I am not talking about the process that your organization already has)
Most organizations have a formal process for handling RFE’s and bug fixes etc. (There are also organizations that are completely at sea when it comes to this). Irrespective of whether there is such a process or not at the organizational level, the engineering team should have it’s own. Some points to consider from an engineering perspective (as alluded to in my previous post).

If your organization doesn’t have a proper process already in place or does not follow the process, then the first thing to do is to work on getting that done. It’s sad to see that some organizations doesn’t have such a process, while others did have a process but was frequently ignored for short term convenience. The consequences were disastrous, especially for the poor engineering team, and not to mention that the ability to respond effectively decreases dramatically over time. How such a process should look like and what’s involved is a separate discussion that I hope to tackle later on.

Branching policies for handling releases, hotfixes (these are notorious for making your life dreadful). In my humble experience, having this discussion right at the beginning (and on an ongoing basis) vs later in the project cycle (especially when everybody is under the gun) is whole lot more productive.

Handling RFE’s/critical bug fixes for existing releases. – same as above. Do it when your head is relatively free.

Figuring out how to evaluate change requests & who is responsible for what area to make that call While the team leader/manager is ultimately responsible for making a call, they are always not in a good position to make a good decision without input from others. Therefore it want hurt to have folks informally appointed (known within and outside the team) as subject experts in certain areas. Radical changes to the code base, taking on new functionality that directly/indirectly affects a particular area should not be decided without the input from these area experts. All though Apache Qpid is an open source project, most committers will discuss with the area expert (on the dev-list/JIRA) if the commit falls outside the committers core area of expertise. Not only it’s courteous and reduces friction/disagreements it also ensures things are done correct the first time which minimizes the impact it has on schedule etc..

Deal With RFE’s/Requirement Changes Methodically (instead of being emotional and kicking up a storm).
No matter how swamped your team is and/or how ridiculous the request/requirement is, emotional outbursts or rejecting them with “not enough time” ..etc is not going to help.
It’s in your best interest (and the interest of the customer) to listen, understand, analyse the impact and then compile your response backed with evidence.

If you make an effort to listen & understand the change request,

You may find the real underlying requirement is something else. Which maybe easier to implement after all.

Provide an acceptable alternative

Provide an acceptable workaround until you fix it properly in the next release.

If you provide a proper response backed by evidence

First of all people are likely to listen to you as you are presenting facts backed by evidence and not mere conjeture .

It helps people to understand the impact and the consequences (Ex half the functionality will not work and would need n extra days).

Even if your opinion is ignored and the change is forced upon, atleast for your own/teams benefit you know how much of an impact you have to deal with.

Your Credibility Is Important.
This could go a long way in ensuring your opinion is heard, hence being able to negotiate changes successfully!

If you have provided sound judgement in the past, the managers are likely to listen to your opinion.

If you have built credibility with the customers, then they are likely to listen to your opinion, accept your workaround or alternative solution.

Ability To Improvise
Sometimes it takes a bit of improvisation to deal with the changes and still beat the clock. Instead of complaining and whining about the changes, use them as an opportunity to show your worth.
And here are some stories..

Once we had to deal with a customer who asked for frequent GUI changes on an application that ran in an embedded device. Suffice to say it was a real pain. At the time one of my colleagues was toying with the idea of expressing the screens in XML. We promptly adopted it and taught the customer how to customize the screens to their hearts content. My colleague eventually went on to lead the team.

We needed an automated build system to run our test suites in different OS’s and aggregate results. As the project progressed the permutations grew. We looked around and didn’t find anything that fit our needs. Then a colleague of ours used our own product to create a distributed automated-build-system.

While working on an application that ran on an embedded device (same as item 1), the QA team had a tough time testing due to the restricted nature of the embedded device. The long test cycle ate into our dev cycle and impacted our turnaround time. I finally wrote a simulation program during my free time that simplified a lot of the testing. I scored some brownie points there, which came handy during the next performance review

In summary, a software engineering team can do a lot to mitigate the risks posed by changes that happen throughout the project. How well you negotiate those changes will have a huge impact on the final outcome.