Roy Tang

Without a doubt, the number one problem in software development projects is **schedule pressure, **that is, the pressure to meet unreasonable deadlines and targets

Almost all other problems can be overcome if there were no schedule pressure:

• weaker developers could be mentored to become better, more productive, and commit less faults
• less faults overall will be committed anyway if there were no schedule pressure
• poor requirements could be threshed out in more detail
• difficult clients can be argued, worn-down, and eventually reasoned with
• problematic team members can be counseled, or replaced with new blood
• and so on

But of course, the reality is that we live in a world with deadlines and targets, many of them set by people who have no idea about the complexities of software development. So schedule pressure is an inconvenient truth we must live with, and 99% of software development processes are there to help us manage that pressure

There are two particularly common mistakes arising from schedule pressure that I would like to point out:

1. Refusing to accept estimates because they put our schedule/deadline in peril. Software estimation is already difficult, there is no need to make it harder by pressuring developers to reduce their estimates just to be able to fit your project into a gantt chart. Such practices will only increase the risks the project faces AND make it less likely for the developers to give you good estimates in the future
2. Adding more people to a software project in order to catch up to a rapidly approaching schedule, popularly known as “The Mythical Man-Month” after the Brooks book of the same name. Every person you add to a team will increase communication and management overhead such that it is almost certainly not worth it. In order to catch up when falling behind, you have to reduce overhead, not increase it

Managing schedule pressure means understanding the limitations of what is and isn’t possible. We try to estimate better to better inform our planning. We add buffers where we can to absorb some of the pressure. We manage client expectations so they don’t pressure us too much. We try to learn from our mistakes so that future projects have less mistakes and therefore less pressure. And we have to be willing to say “this is impossible to do in the timeframe you want” to the stakeholders pressuring us