Why Management Declared Deadlines Lead to Disaster

Senior management, in the face of market pressure, will sometimes initiate a project to address a business need that has a management declared deadline.

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

Some organizations (not many) are enlightened enough that they determine project size in function points and use automated sizing tools to estimate time and cost.  Large organizations have measured automated tools against actual results and determined that automated sizing tools estimate projects to within 5% of time and cost.

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%.

The most dysfunctional management will expect all existing project not to be impacted by the addition of a high priority project. They will say silly things like 'You will just have to multi-task' or something equally ridiculous.

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.

Even 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%.

If an organization is well run and a management declared project occurs rarely then the extra stress due toregular basis. Such senior management teams are unaware that they are increasing risk by an order of magnitude and are always mystified when they are unable to achieve the results that they want.

working long hours can be handled.

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.

This 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?

Loss of key personnel will decrease productivity by 15.7% and code quality by 21.7%.

Needless to say, when faced with such time sensitive projects the work done on the requirements is minimal and so the end product (even if delivered) will generally not satisfy the market pressure the project was designed to alleviate. In short, when senior management responds to market pressures by declaring a project and its deadline it is virtually guaranteed to fail.

How should senior managers deal with market pressures?

When 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%.

If 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%.

Any 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.

References

• Capers Jones, " Scoring Good and Bad Practices ", 2010
• T. Wayt Gibbs, "Software's Chronic Crisis", Scientific American, September 1994

---

Articles in the "Loser" series

Moo?

Want to see sacred cows get tipped? Check out:

• Comments are for Losers
• Efficiency is for Losers
• Defects are for Losers
• Debuggers are for Losers
• Testing departments are for Losers

Make no mistake, I am the biggest "Loser" of them all.  I believe that I have made every mistake in the book at least once :-)