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
Management will be adamant that the deadline is fixed and must be met at all costs. Some management groups are more dysfunctional than others.
The most dysfunctional management will expect all existing project not to be impacted by the addition of a high priority project. They will say 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 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.
If an organization is well run and a management declared project occurs rarely then the extra stress due to working long hours can be handled. However there are senior management teams that will declare deadline driven projects on a regular 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.
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?
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.
If the resources exist in the organization then they need to be dedicated to the high priority project and all other work that they were doing needs to be put on hold.
If the resources required exceeds available resources, then the project scope needs to be 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).
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.
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.
i didn’t even see something like this before because of the scarcity of this type of information.