Dangers of underscoping

A typical negotiation between the development and the sales goes like this.

Sales: The client wants us to build awesome feature x, that is their key value proposition. However, they also need feature a,b,c since their competitors already support it.

Development: That is great, we have met and discussed the work. It seems like it will take about 9-12months to get it done.

Sales: That is not possible, the deadline is in 3months

Development: There is no way we can deliver anything reasonable in that time

Sales: Ok, 6 months maximum

Development: Seriously we did not pull our estimate out of thin air, it will take 9-12 months

Sales: Ok then we will just have to resolve this with the boss

The boss: Hey dev guys, get it done in 6 months

Development: That time is not enough

The boss: That was not a request

Development: Ok

If you have been in this position before, you know it is not a pretty place to be. The pressure is incredible and you are made out to be the enemy. Yet I will argue that through it all, you should stick to your estimates. Especially if the estimates incorporate everything you know about the project.

You see when you back down at this point, you have not saved yourself, you have only traded a less evil (angry boss) for a bigger evil (failed project).

I suppose you are wondering how a software project can fail from an overly optimistic schedule. Well in my experience, that happens through the following ways.

Tight deadlines are missed by huge margins

You would think that the tight deadline would reduce the actual time taken to write the software as compared to the original estimate. At worst it would be the original estimate.

It never works out that way. In my experience, once a tight project misses its deadline, all bets are off. The actual delivery day can be the next day or months from now.

Design is ignored but at great cost

I have said it before and I will say it again. Software development is not a clerical activity. Yes, I know it seems like all there is to it is typing code and that’s it. In reality, typing speed has little bearing on the speed of development.

Now when the schedule is unreasonably tight, the emphasis switches to coding. Developers are rated by lines of code or commits/day. Important activities such as design are tossed out. After all, how do you know if that guy is actually working or daydreaming?

Eventually, design missteps will come to bite you when you discover that development can not continue unless you rework great parts of the application. Then even world class typing will not save you.

Developers will lose morale

To get any creative accomplishment, you need time and energy. Time is easy to enforce, energy on the other hand is not. Thankfully developers tend to be naturally motivated.

This form of intrinsic motivation will get you a long way but only if you allow it to flourish.

In ancient wars, if you were captured, the enemy would at times subject you (and other prisoners) to a death march. The essence of it is that the enemy would make you do intense labor on a march until exhaustion and finally death.

While a late project will not kill you, it still gives rise to the same emotions of hopelessness to the developers who have to work on a project that they know will fail.

Important activities will fall by the way

Important activities tend to not be the most urgent ones. This applies to software projects more than anywhere else. Having a looming deadline means that the team will focus on the most visible parts of the application no matter their importance. Eg beautiful carousel on the home page instead of writing proper interface to the payment gateway.

As you can imagine, this mounting technical debt will one day come collecting.

An even more subtle effect is that the developers will stop putting any time to their own self-development. You will thus slowly but surely corrode your competitive advantage. Even worse your best developers will eventually leave the organization.

I hope this has convinced you of the importance of sticking to your guns.

How do you handle schedule pressure in your organization? Talk to me on my twitter @jchex or in the comment section below.



Published by


Software Project Manager