Mastering Imposed Project Deadlines: A Comprehensive Guide for Project Managers

How often has your boss or senior manager assigned you to manage a project with that exact mix of challenge, technology, team and customer that you can’t wait to start? Then you find the project has been given a crazy deadline that will require a time machine to deliver successfully.

Yeah, lots of time!

I could write a whole blog about why this situation is so bad and must be avoided by managers commissioning projects. But it won’t stop it from happening. Projects often get spun up to address critical business needs or issues with real and immovable dates, like an update to a finance system to support revised legal rules for the next financial year. Or the sales support system that requires enhancement to support a new seasonal product range.

I was once assigned to a project delivering a school support application that needed to be live by the start of the next school year in September. That date would not move for me or the project, so we worked within the constraint.

These projects are approached and mobilised with predefined deadlines with the best intent and for valid reasons. But, they can be tricky for project managers to navigate. With the duration defined by the deadline, the project scope and the resources need to be aligned.

So, in these situations, accept that the date cannot be moved, work within it and take steps to ensure you can deliver to the date.

What should those steps be?

1. Confirm the features to be delivered by the deadline.
2. High-level estimate the delivery of those features and draw a timeline.
3. If the timeline and deadline still need to be matched, identify options to deliver by the deadline.
4. Present the options with impacts to the project sponsor and senior stakeholders. Help them decide the best option.
5. In the worst-case scenario, if no option is viable and the deadline still exists, then manage it as a high-impact issue. Do not accept the deadline.

Let’s explore each one of these steps in more detail.

Confirm features

The first step is to confirm the features or scope to be delivered by the deadline. Ask the product owner to review the agreed scope with the customer. This could be at a feature or epic level. Even if this step was done before you started as project manager, re-confirm the scope. At the very least, you will better understand the project; at best, you might discover scope gaps or misunderstandings that help clarify the delivery.

At the end of this process, clearly document the results for the next step.

Estimates and timeline

Now, you and your team need to estimate the scope. Agile purists may get upset, saying only the current sprint should be estimated. This stance is very well when there is no deadline, but there is, and we need to manage that constraint.

At the start of the project, you will only have a list of features or epics to be delivered. My preferred approach is to estimate at this high level by asking the team or parts of the team to estimate t-shirt sizes, small, medium and large. Sometimes, we estimate extra-small and extra-large, but only occasionally. Associate a duration length with each t-shirt size, such as the number of weeks, days, or sprints. For example:

• Small: 1-2 days
• Medium: 3-5 days
• Large: 6-10 days

When the features or epics have been t-shirt-sized, a simple timeline can be drawn and tested to see if it fits the imposed completion date. Remember, if the deadline is for implementation in a production environment, include deployment and user testing activities.

Does the timeline meet the project deadline date? If yes, happy days! You don’t have a problem, and you can accept the deadline.

However, you cannot accept the date if the timeline forecasts project completion after the deadline. You will need to work with the team and project stakeholders to identify options to meet the date and select an approach.

Identify options

At this point, you know you have a problem. The project cannot be delivered in its current state with the imposed deadline. So, you need to identify options to meet the deadline date.

All the options are going to revolve around two areas:

1. Scope. Here, we are talking about fewer features or fewer functionality-rich features. These decisions are always hard. But, conversely, there is always scope that can be cut or delayed to a future release. Collaborate with the functional experts, usually the product owner, to identify possible scope reduction options. Then, review with the project customer to confirm feasibility. For each option, adjust the timeline based on the revised estimate to assess the impact and viability of meeting the deadline. Usually, one or two options emerge as clear favourites to be taken forward.
2. Resource. Adding additional resources to the project may be an option to meet the deadline. This could be adding some members to the team, spinning up another team, or even outsourcing a discrete project portion to external providers. Of course, this will be costly, and you may hit a budget constraint when trying to meet a date constraint. Also, remember that doubling the project team will not half the project duration time. At best, it will reduce the duration by a quarter or third. The extra team members may also necessitate additional support staff like another scrum master or product owner. If you are talking about adding 1 or 2 people, that will be doable in an original team of 5 or 6. Adding more will bend the team out of shape and cause more problems than it fixes. Finally, when trying to crash the timeline with additional resources, ensure it is possible to have more build and testing activities in parallel and that the dependencies between features don’t get in the way. If the project has many feature dependencies, successfully crashing the plan will create an increased risk if the feature build runs late, causing downstream delays.

Of course, a single option could combine scope and resources.

When you have two or three preferred options, document them. This documentation should be brief. It needs to include for each option:

• Description
• Impact (timeline, costs, risks)
• Recommendation

A slide per option will be fine.

Agree on an option

Now you have a few options agreed upon and documented, they need to be presented to the senior project stakeholders for decision and approval. Sometimes, this might only be the sponsor and project customer. Other times, a wider forum is needed. You might include in the following Project Status Review session (if there is one scheduled soon) or convene a short meeting with the required people to make the decision.

Do not include discussion of the options in the project kick-off meeting. The kick-off meeting needs to be focused on delivering the project; it needs to motivate and energise the team. Discussing these options in that meeting will have the opposite effect.

Once an option has been agreed upon, update the project timeline, budget, and risks. Keep the options documentation for reference and lessons learned.

Now, you can start the project and deliver to an achievable deadline. Well done!

Worst case, manage the deadline issue

The above sounds great. What can go wrong? Answer, no one agrees to an option, and you are left to deliver the project unchanged to an unachievable deadline. This does happen and is so frustrating.

Sometimes, you are left with half a resolution, like agreeing to fund overtime for weekend work for the team. These types of options rarely work. They usually delay the inevitable decision to change scope or resource or both.

The problem is that this decision will be made late in the project lifecycle, and as a result, there will be fewer options available. Some low priority scope will have been completed, so higher priority scope may need to be cut. Increasing resources may not positively impact the project because they have less time to influence it.

In these situations, document the issue of the deadline and forecast project finish not matching. Make it clear to the senior stakeholders that the project plans show it cannot be delivered. You can do this via the Project Status Review meetings and the progress reports.

What RAG status should you give the project? The RAG status should be red because there is no mitigation, and the deadline milestone cannot be achieved. If your senior project stakeholders are comfortable with the project reporting as red, especially how that looks to others in the organisation, that’s great. However, reporting the project as red from the start will likely play poorly on the broader organisation, and there may be pressure to report it as amber or green. Resist attempts to report as green; that’s just plain untrue. Reporting as amber to start and then moving to red as the deadline approaches and options to mitigate are reduced is a sensible compromise.

Wrapping up

In this post, we’ve explored having an imposed project deadline is not impossible to manage. Usually, plenty of options are available to adjust the project to meet the deadline. Importantly, realise that these situations of imposed project end dates are every day and are done for the right reasons, even if you might think those reasons are misguided. While managing this situation, remain positive and treat the experience as a learning and growth opportunity. With this mindset, you will take positives from the situation and be a better project manager.

I hope you have enjoyed this article. If you have any comments and feedback, I’d love to hear them; please get in touch or comment below. Thanks.