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%.
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 3rd 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.
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.
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?
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%.
Formal scope management will increase productivity by 13.5% and code quality by 18.5%.
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.
- Capers Jones, " Scoring Good and Bad Practices ", 2010
- T. Wayt Gibbs, "Software's Chronic Crisis", Scientific American, September 1994