Why Management Declared Deadlines Lead to Disaster
Why Management Declared Deadlines Lead to Disaster
Join the DZone community and get the full member experience.Join For Free
Get the Edge with a Professional Java IDE. 30-day free trial.
Management will do this when they feel market pressures to create a new software product or version because of some impending business event in the market.
These market driven deadlines occur for a variety of reasons:
- Competitor is releasing a new product/version that will eat your market share
- Laws have changed that require compliance by your software system
- Merger with another organization requires software systems to be integrated
- You are a start-up and need to build version 1.0 to obtain financing
- Sales has sold vapor-ware and engineering now needs to produce it
Counting function points will increase productivity by 17.5% and code quality by 25.8%.
Automated sizing tools will increase productivity by 16.5% and code quality by 23.7%.
However, on a regular basis automated sizing tools do not produce estimates that management likes. So management will be adamant that the deadline is fixed and must be met at all costs. Some management groups are more dysfunctional than others about insisting that deadlines because of business reasons and not by estimates .
Rejection of estimates for business reasons will decrease productivity by 15.7% and code quality by 21.7%.
Little's Law or Why Multitasking does not Work
Anyone who has worked in a multitasking mode is familiar with Little’s law or that productivity drop-off that comes from trying to do multiple things at the same time.Less dysfunctional management will realize that the high priority project will cause other projects to be late, but they will continue to expect that everything progresses even though resources will be committed to multiple projects. Project deadlines typically get set in the short term, which means that the resource for the project will be fixed.
The Law of Feasible ProjectsEven if the funding is available to hire resources, the new resources will not be familiar enough with the corporate context to be of much use. The scope and quality of the project will be dictated by the market pressure that generated the project.
This project will have fixed scope, quality, time, and resources which will lead to a feasible project only once in a million projects.
Those familiar with project management know that you can only set 2 parameters of time, resources, and scope and then the 3 rd parameter must be allowed to vary, if you want a feasible solution.
If you specify the resources and scope then the time must be allowed to vary; if you specify resources and time, then the scope must be allowed to vary. When management sets up a project like this the only practical variable that can stretch is time through resources working overtime. Overtime = excessive schedule pressure.
Excessive schedule pressure will decrease productivity by 16.0% and code quality by 22.5%.
Poor Deadlines = Pressure Cooker
However there are senior management teams that will declare deadline driven projects on a virtually every project. Unless the senior IT manager has the courage to point out the problems that such a project will cause, the IT department is doomed to become a pressure cooker. Even if the IT manager has the courage he needs to have the disciple to refuse the pressure from the other senior managers until a feasible project is defined.
Unfortunately, most senior IT managers have neither the courage of their convictions nor the discipline to weather the storm.
The end result will lead to a pressure cooker in engineering, where the engineers are being asked to perform super human efforts for which they will get very little in return.
Pressure leads to Two Week NoticesThis kind of environment if prolonged will lead to your better engineers quitting which will cause all the rest of your projects to get even later. With the loss of productivity that comes from trying to multi-task, the code that is produced is guaranteed to have more bugs than normal, which will then cause the problem to flow into QA. Even more insanity will follow when QA time is reduced or eliminated, after all, who needs QA?
Dealing with Market PressuresWhen faced with market pressure senior management must be absolutely certain that the pressure is real. There are many situations where managers have declared that a project needs to be finished by a given time, puts too much pressure on the project, and then the project is late or canceled.
Some managers make everything an emergency in order to get their way, they often say ' We have no choice'.
In these situations the manager will push for a ridiculous date that will be missed. They will then turn around and accept a much later date for the the project; if this is the case then the project was not real and management was not responding to a real pressure. This happens regularly in environments where politics is more important than getting things done.
If the project must be done (i.e. compliance project) then it will be critical to assess complete and consistent requirements for the project. Those requirements need to be estimated by the project managers for the deadline and allow the resources to vary. The best projects use formal requirements analysis so that they start with complete and consistent requirements; think about it, would you ever build a house without a solid blueprint?
Formal requirements analysis will increase productivity by 16.3% and code quality by 23.2%.
Only Option is to Trim ScopeIf the resources exist in the organization then they need to be dedicated to the high priority project and project scope trimmed if possible and the quality of the features need to be weakened until a feasible project is defined. If trimming the scope and bringing quality to a minimum will still not result in a feasible project then you need to consider what it means for the project to be late (because it WILL be late). Your best chance of trimming scope correctly depends on formal scope management.
Formal scope management will increase productivity by 13.5% and code quality by 18.5%.
Reward the TeamAny project which increases the overtime by the IT department must be done on a sustainable basis. The more time you demand from the IT department the less sustainable it is, i.e. don’t expect your IT department resources to do 80 hour weeks for 6 months. Heavy overtime will lead to friction among team members.
Friction among team members will decrease productivity by 10.0% and code quality by 15.0%.
With high priority projects make sure that the engineers get some kind of bonus on a regular basis (free lunches, dinners) as well as a financial bonus on completion of the project. If no bonuses are available don't be surprised to see IT resources jump ship at or before the project completion date.
Published at DZone with permission of Dalip Mahal , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.