Avoiding Software Car Wrecks

by Krishna on September 15, 2009

I.M. Wright’s post on risk management is worth reading:

Software engineers do this all the time. They come up with a development schedule, unexpected issues come up, and they end up being late. Instead of informing their managers of the delay, they avoid facing conflict, rush the work, sacrifice quality, and slip the schedule, all with little control or visibility. It’s the opposite of what managers should want, yet those same managers insist on following the schedule precisely. Why? Because most managers and engineers don’t distinguish between the two types of scheduling—meeting a commitment and managing risk.

I did find the conclusions of the post a bit unsatisfactory because Wright wants to eat his cake and have it too. He wants developers to inform him about slips in schedule so that he can maintain his high-level commitments. The problem is that developers continue to be reminded about those commitments that they are afraid to reveal small slippages. It doesn’t matter whether the slippage is with low-level tasks only.

As I wrote about in a post about quality and deadlines, project timelines loom larger than quality problems. Time overruns are more visible and they are in the present. They are given great importance and most managers base productivity judgments on who meets their deadlines. If you insist on a deadline, you will frequently find developers working like crazy to meet them, regardless of whether they can actually meet it. Many feel that they are letting you down or that they are somehow incapable if they admit that they cannot meet the deadline.

So just insisting on getting updates is not going to do the trick. The project mentality has to change and for that, first, you have to trust and have to be able to trust your team and vice versa. When you trust your team, you know that schedule slippages are not the fault of the developer, but because of a genuine mistake in understanding the requirements or estimating them. When they trust you to be understanding, they will not fear you in bringing things to your notice, because they know that you will be working with them to resolve the slippage.

In this scenario, you will get to know of any minor slippages before they even happen. The developer knows when a task is getting more difficult for comfort. If you get jumpy each time you hear of schedule problems, the developer is going to keep mum and dig harder, sometimes to no avail. On the other hand, if they find you genuinely cooperative, they will tell you immediately and that gives you time to resolve your commitments sooner.

You have to make this explicit at the beginning. Explain to the developers that commitments can be negotiated if new information comes sooner than later. The farther the deadline, the easier it is to change them. Remember that estimates are, by definition, educated guesses only and there is no shame in changing them if facts determine otherwise.

And then, walk the talk. Your behavior (words and action) will determine whether the developers trust you enough to trust you with the truth.

Comments on this entry are closed.

Previous post:

Next post: