why forcing unrealistic project dates is often counter productive

It is not rare that project dates, in particular the end date, are forced on the project manager and his team. Are they realistic? How were they estimated and approved? What is their foundation? Here are some ideas to better handle this somewhat frequent problem.

The arbitrary...

Let's keep in mind the 3 parameters of projects: any project can be represented as a triangle which summits are time, costs and contents. To freeze or force one of the summits often implies sacrifices on one of the other two. Thus, fixing a completion date in an arbitrary manner can lead the project team to try to reduce the contents (the scope) to fit the timeframe. It can also drive costs up with the use of more resources to reach by all means the time target either with more resources, or superior skills or more expensive ones due to time pressure (reduced negotiation position) or all three. Naturally, these changes should generate the necessary discussions with sponsors and stakeholders to reach an agreement. If the compulsory date is absolutely unrealistic, it is of the duty of the project manager to pull the alarm bell and even consider refusing the project (must read: « Code of Ethics and Professional Conduct » of  PMI).

 
On the sponsors' side, it is necessary to be capable (I would even say that it is a duty) to explain the reasons behind the forced dates. These reasons can very well be valid and the project team, once it will have integrated them, will be motivated all the more to reach them. A real life example was the implementation of a new accounting system at a big multinational firm. The sponsor of the team dedicated the necessary time to explain to all the stakeholders, project teams, future users, and management, the necessity of a launch of the new processes and application software on January 1st. Any delay would have caused big difficulties in data conversion and reconciliation at any other time during the year, i.e. additional pain for each person... The whole company was mobilized from then on; the deployment took place in time and was a success.

Rough estimates

There are many more or less scientific estimation techniques. The most wide-spread are the analog, parametric, intuitive methods or the experts' advice, and « Bottom-Up ». Without going into too much details in this article, by analogy is about comparing a future project to similar already realized projects and extrapolating the estimates from this base. For example, if I have already implemented a software package in country X and I have to deploy the same product in country Y which of comparable size and complexity. I consider by analogy that the cost and the timeline for country Y will be sensibly the same as country X. The parametric method focuses at a high level at defining parameters that will allow estimating duration, efforts and costs. This is often used in Information Technology with parameters such as the number of screens, lines of code, interfaces between systems, and the other « Function Points » ... The intuitive method is - as its name indicates - based on the personal appreciation of the estimator and it is mainly used to get quickly an order of magnitude. It is particularly useful upstream to prioritize approaches and downstream to identify potential incoherencies in the results produced by more detailed methods. The experts' advices are often used to rationalize intuitive results. The experts draw from their experience and skills to provide their best estimates. Finally, the  "Bottom-Up" method, more analytical requires much more detailed work at the level the deliverables of the project to estimate efforts, duration and costs. Generally, it is implemented via the Work Breakdown Structure of the project (WBS), and we try to estimate at the lowest level possible. The best is to apply to several methods and compare the results.

Involvement of the team and the project manager

For the project to be successful, we will need that the team understands and signs off for the dates, even if imposed, as well as the effort estimates... If we take the example of Scrum in the software industry, at the beginning of each code development iteration (the Sprint), the members of the team often have the possibility of choosing themselves in the list prioritized by the customer (« product backlog ») which they take the commitment to realize over the period. They are completely engaged from then on with the task and the duration.
At minimum, the project manager must be able to be confident that he dates can be held in order to motivate his team on the duration, contents and quality.

Realistic and reachable plans

Realists for whom? First of all for the project team. As mentioned above, the project manager and his team are going to have to answer in a positive way the following questions:

• Will we succeed in delivering a product or a service that we we will be proud of in the allotted time?
• What sacrifices will it require and are we ready for these?
• Will we get the necessary support from our sponsors?

Maintaining a completion date in spite of the delays to start

This case is regrettably very frequent. The supplied estimates are correct and the end of September was reachable with January 1st start of the project. But, here we are, on March 9, and over the past three months sponsors and stakeholders hesitated, asked additional questions, did not manage to find time slots to meet...  Finally, they saw each other this morning and agreed: we have the green light, this is great news! And (not as good) we are asked to respect the end of September completion and the budget!!! It will sound familiar to you, I am quite sure. However, unless we had inflated extravagantly our estimates (by 30 %) or are able to cut into the deliverables/contents, it will be mission impossible. Increasing the number of resources in such a drastic way at short notice does not seem plausible. One of the practices to be used to avoid as much as possible this type of situation is to include a milestone in the project's critical path for the approval of the project (Project Approval Milestone - PAM).  Then, express the next dates only as a matter of delays from this milestone date. For example, the analysis will be ended 2 months after the PAM, the design 4 months, the construction 8 months and the phase of test 9 months (PAM + 9 Months). I know, not easy in practice, but it is worth trying it.

Involvement of the customer

Is the date really convenient for the end customer? For example, to deliver a new booking system for a hotel just before peak season is probably not an excellent idea. Maybe would it be better to wait for the following quiet season and to enrich the features, or on the contrary, to minimize functionality to the bare minimum and deliver the system much faster? Also, in accounting some periods are to be avoided to deploy novelties: balance sheets, month end closure, invoicing runs, the tax declarations ... It is thus advisable to make sure upfront of the relevance of forced dates coming from sponsors and stakeholders and not to assume that they are fully aware of the customers' impact.

Resources

For a reason and another, totally independent from your will, it was not possible to you to recruit the resources in time: order forms blocked in purchases, slow controls by the recruiters, delays by certain managers to give the required skills to the project... Nevertheless the sponsors and the stakeholders are not willing to accept any delay!
In fact, they are probably right. It is our job as PM to anticipate, avoid or surmount this type of obstacles and to call upon sponsors to help remove any roadblocks before the project is negatively impacted.