Excessive Schedule Pressure
Schedule pressure appears to be endemic to software development. Many managers and customers defend their pressure tactics by referring to Parkinson's Law, which states that work expands to fill the time available . “Give a developer 4 weeks to complete a task and he'll deliver in 4 weeks, but give him 3 and he'll deliver in 3.”
If Project Managers can force developers to deliver software 25% faster, shouldn't we always apply schedule pressure? Shouldn't this strategy be considered a best practice?
The following paragraphs explain 5 reasons why you should not put excessive schedule pressure on developers.
Risk Management
Project Management is a discipline that includes many practices, including risk management. Every time you increase schedule pressure, you increase the likelihood of not meeting your deadlines. Let's get real. If your developer tells you it'll take him 4 weeks to complete a task and you only book 3 weeks in your project plan, there's a strong likelihood that your schedule is going to slip.
Many developers will be able to deliver “something” in 3 weeks, which might give you a false impression that you're on track. In order to deliver 25% faster, the developer will most likely cut corners. For example, he might have delivered before he had the chance to write and execute unit tests. Or he might have skipped a few error-handling scenarios. Granted, the feature will be delivered in 3 weeks, but once your QA team starts seriously testing the code, they might send it back over the fence so the developer can finish the implementation. Result? Instead of accelerating the schedule by 1 week, the excessive pressure might actually slip the project by 1-2 weeks.
Quality Control
As explained in the previous section, when forced to accelerate their development schedule, developers tend to cut corners and deliver on time at the expense of quality. In some cases, the quality of their work might be so poor that the feature will simply have to go back to the developer where he will have to complete his work. Far too frequently, the management team will decide to live with the poor quality in an effort to meet the overly optimistic schedule. “It's just a severity 3 bug. The customer will never even notice it. Let's ignore it for now, or document it in the Release Notes.”
In and of itself, a severity 3 bug doesn't justify a slip to the schedule. For example, if a defect is purely esthetic or is more of an “annoyance”, accelerating the schedule might have been a good call after all. However, if such annoying bugs appear at every corner, than the customer might perceive the overall product as very poor in terms of quality and, well, annoying to use.
A customer will never reject a product simply because he's discovered a severity 3 or 4 bug. However, he might throw it out if he discovers such bugs every single time he clicks on a button. By themselves, low-severity bugs are inoffensive, but as a whole, they might just drive the final nail in the coffin.
Maintenance Costs
Imagine that the developer does meet the schedule, and that quality turns out to be as expected. Were you right to accelerate the schedule? Was the developer simply padding his estimate? Perhaps. Or perhaps, he ended up taking short cuts that are not apparent in the short term, but will end up costing you in the long term.
If you've ever had to work in someone else's code, you know how difficult it is to fix a bug when the feature is not designed properly. You know what I'm talking about. Instead of adding a Java method in a class and importing it from various other classes, the designer simply copied and pasted the same code 5 times in different classes. Now, this method contains defects that you have to fix, but instead of fixing it once, you need to fix it 5 times. Either that, or you need to refactor the feature. Either way, you're looking at days to fix a simple defect that should have been solved in hours had the code been properly designed.
Most Project Managers who estimate the cost of developing features don't factor in maintenance costs. Generally speaking, the project ends when the customer accepts the solution, so any cost associated with maintenance isn't their problem.
If all you care about is your pet project, then your strategy is effective. But if you're more mature and consider the company's bottom line and not just your own, then you need to be aware that applying schedule pressure generally increases overall software development costs.
Relationship Building
Schedule pressure widens the gap between managers and developers. Developers tend to think that managers don't respect them, or simply don't care about them. “I have to work yet another weekend because my Project Mangler, who clearly doesn't understand the first thing about software development, thinks that this feature can be done in 3 weeks even though I clearly stated that I would need 5”, is the type of comment often overheard from developers.
You might get lucky on a few features, but sooner or later, one of them will slip. And instead of working with you to catch up, the developer will start pointing the finger at you. Then you'll point the finger at him. Ultimately, people will start caring more about who gets blamed for what than saving the project.
This type of a relationship is not only counter-productive, but it's also not a pleasant one. After a while, both sides will try to avoid each other, which will only lead to other problematic issues.
Having a healthy, respectful relationship between the manager and developer is extremely important to the success of any project. I would go as far as saying that, in some cases, protecting the relationship is more important than protecting the schedule.
Employee Turnover
The number one reason why people quit their jobs is because of the relationship they have with their manager. The number two reason is because of overly optimistic schedules that force them to work evenings and weekends with little or nothing to show for it – except for the occasional pat on the back.
As a Project Manager, your biggest asset is your team. Not your tools, not your equipment, and certainly not your knowledge of the latest and greatest processes. Your greatest asset is people. And if you lose these people, you're doomed.
If you've ever had a technical leader quit midway through a project, you know what I'm talking about. When such an employee leaves, you're generally not talking about a 2-3 day slip. You're talking weeks, if not months, depending on whether or not another senior designer is readily available, and how big the learning curve is for him.
The delay is even more significant when schedules are overly optimistic. Why? Because in order to meet overly optimistic schedules, the technical person that just resigned most likely (a) didn't comment his code properly, (b) skipped code reviews, and (c) omitted any form of documentation. As a result, you end up with code that is not commented nor documented, and that hasn't been reviewed by anyone. As explained in the “Maintenance Costs” section above, the code is most likely poorly designed as well. All things considered, the learning curve will be gigantic – so gigantic that the next developer might prefer to start from scratch and rewrite most of the code, thinking that it might be more efficient than learning it.
Conclusion
Will applying excessive schedule pressure give you what you need faster? Possibly, but you won't get it for free.
Not only will the excessive pressure increase project risk, but it will also have a negative impact on the quality of the software. Consequently, the poor quality of the product will eventually force you to over-invest in software maintenance, which will directly increase the overall cost of the solution. Furthermore, it will damage your relationship with your team and might even lead to some of your top developers resigning midway through the project.
Should you apply excessive schedule pressure onto your development team? Absolutely not.
This article was originally published on www.gantthead.com.