Comments (0)

By Krishna, 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 (0)

By Krishna, September 14, 2009

I understand what Glen Alleman is trying to do here when he insists that you can pick all three of time, budget and scope, but he totally misses the point:

Put these estimates into a schedule, sequence the work. See what you get. Don’t like the outcome? Adjust One, Two, or Three of the variables and repeat the process.

Repeat until all three variables balance – fit into the acceptable norms of acceptance.

The big problem is, as they say, when everything is a priority, nothing is a priority. When push comes to shove, as will in any project, what will you give up on? Are you ready to go past the previously agreed upon timelines? Are you willing to allocate more money? Are you going to scale down your requirements for the release?

For example, if it is an “Industry Conference” you need to release for, you cannot adjust time. If you are a startup, your money is probably fixed. If you are trying to overthrow an established software player, scope cannot be changed. The whole point about TBS is that something cannot be compromised (at least not readily) and you need to give up on the others.

Same goes for “time, cost and quality”. The biggest danger about compromising on all three parts of the equation is that you may end up with something that is of low quality at a price nobody is willing to pay released at a time when no one is interested in buying it.

Projects that do such compromises go on for way too long, have their most important features gutted (because they usually take more time) and cost more money anyway. It is like what Jack Welch used to say about budgets. There is a compromise between the person who asks for it and the person who grants it, but neither are happy at the end. The asker didn’t get enough to do the work and the granter feels that they paid more than they wanted.

Comments (0)

By Krishna, September 13, 2009

Stephan Schmidt explains how doing several projects in parallel is counter-productive because of the high overhead costs involved.

Projects must be tracked much longer, more documents are produced and must be tracked. All those status messages aggregate, flow upwards toward upper management, clog thinking and time. All those status messages flow to all stakeholders. Each increment per status update is small, much smaller than when working in serial mode.

Doing many projects in parallel creates a management problem, which is perhaps the most difficult one to solve. Every organization, in one form or other, has a pyramid structure with fewer managers compared to developers. When you have more projects going on, you are putting greater pressure on the managers who then become huge bottlenecks.

And that is the good news. Where things go completely off the rails is when the managers start making hasty decisions to ease the situation without putting enough effort. Most of those decisions come back to bite them in the most nasty way possible.

Practically, it may be difficult for a company to shun such parallel execution of projects. Opportunities have a habit of raining down on you instead of conveniently coming one after the other. And even if you are ready to reject and postpone some, there will be circumstances when you just have to take on work you hadn’t planned.

But there are ways to be prepared. One is to ensure that projects that are getting completed stay completed without your team being interrupted by customer service issues. This requires a greater focus on testing, user documentation and project hand-off to customers. Doing this for every project ensures that you will not have another parallel activity on your list.

Another step (as Schmidt showed) is to parallelize the tasks in your existing projects. Have milestones which are reasonably separated from each other and then ensure that you work hard to meet those milestones with proper quality. Also budget time for customers to do acceptance testing and provide feedback, which will introduce additional tasks in your projects.

A temptation with so many scheduled tasks is to get them finished sooner and get them off the list. But this can backfire if quality is compromised. Therefore, you must re-emphasize to the project teams that quality must be prioritized over deadlines at every step, because reduced quality will mean additional work.

Comments (0)

By Krishna, August 30, 2009

The most important person in your professional life is the person who your manager is beholden to. In a large organization, it is simple to identify this person: it is your manager’s manager. In a smaller company, it could be a C-level person or a customer.

You see, the thing is that your manager is driven by two things: intrinsic motivation and external pressures. If your manager was only driven by internal impulses, your product would be driven by priorities that make sense: greater product quality, better work-life balance, consistent processes, calm work environment, etc.

But internal priorities are not the only thing in real life. There are budgets and timelines that must not be exceeded, people that must not be displeased, reports that must not be forgotten, bugs that must never be visible and so on. These are things that have a direct relationship to the stability of your manager’s job.

Managers insulate you from those external pressures, sometimes knowingly, but sometimes unknowingly because they are just focused on getting things done that they don’t have the time to explain to you what is going on in their world. But just because you don’t know about it doesn’t mean that you are not affected by it.

It makes sense for managers to share some of these pressures with their team members and for the latter to try to gain an understanding of what the manager is up against. This helps them work towards not only the real goals of the project, but also the goals as defined by other stakeholders that cannot be quite put on some project mission statement.