Why are the project due dates set the way they are? Is there a reason? Is there something happening that the project must complete beforehand?
Why did the client set the due date on that specific day?
When you prepare a proposal, the client may have some set dates for specific deliverables or a specific date that the project must be completed by.
You need to know why.
Problem: Due dates set by the client are not understood
Your project client has set a due date for your project and some due dates for the staged deliverables.
You don’t know why these dates are important to the client. You never asked.
Maybe they are arbitrary. Or maybe they are very specific deadlines that will have huge consequences if they are not met.
Perhaps the client project manager goes on leave the week after the due date, or perhaps there is a political reason, or a festival that the project is required for. Or maybe a product has been advertised to be shipped by a certain date. Maybe the due date is set just before the wet season starts.
When you don’t know the reason for the due dates, you don’t understand your client and your project properly. You cannot plan properly and negotiate dates with the client if you don’t understand their reasons for setting specific project due dates.
Solution: Get to know why the client set the due dates
Project management is all about planning.
This includes knowing why the project is required, when it is required by, why it is required by that date, and what the consequences are.
Some of the links on this website may be affiliate links to products I use, have tested or am familiar with. I may receive a commission if you click on some of those links and make a purchase. This is at no additional cost to you.
Make sure you know and understand the answers to those questions. They are all related:
- Why is the project required? I.e. What is the purpose, the final goal?
- When is the final deliverable required? When are the staged deliverables required?
- Why are these deliverables required by these specific dates?
- What are the consequences for earlier or later completion?
If you know and understand the clients’ reasons for their project and their project due dates (and the reasons for the actual deliverables) you can then better understand how to deliver the project to their satisfaction.
For example, if the client wants the first concrete poured on a certain date, understand why.
Is it because they have other works for another project that will impact that area? Or perhaps they know that the wet season will impact work after that date. Or a water release will occur after that date and could wash away formwork if it is not completed.
In understanding the reasons for the due dates, you can better manage your project to deliver the final outcome they want. In the above example, you may find you could bring in a precast unit sooner (or later), which will still give the same outcome but allow more flexibility in the schedule (possibly saving you and the client money, or reducing the risk of the final delivery date being impacted).
What, When, Why:
What is required, when, and why? Are there different levels of importance, or priorities for the deliverables?
Your client or clients may include stakeholders with different importance levels on the things they require. Find out what these are. Deliverable, due date, priority and why.
A client (usually an external client) will probably have a contract with you specifying a set of deliverables and probably specific project due dates (or length of time to these from the award of the contract). Find out the priorities and why those dates are set.
An internal client may have an agreement with you to deliver certain deliverables by certain dates, possibly to meet a larger deliverable for an external client. So their due dates may also be deadlines. Find out what these linkages are, and why the dates are set that way.
Some levels of importance may be:
- “Must have”
- “Should have”
- “Could have”
- “Won’t have”.
The “Must Have” scope deliverables will usually be specified in the scope of work contract. The others may also be but may not be as clear.
This MoSCoW method is often more applicable to agile methodologies (such as for software development) but can be used in the development of the scope with the client for other types of projects as well, such as infrastructure (especially if you can be involved in the development of the “how” and “what” to deliver the ultimate requirement).
Some or all of these should be negotiated and agreed before the final contract is signed. Sometimes your client will have an ultimate goal (e.g. delivering a certain amount of treated water per hour). They may specify all the types of equipment required to be installed to achieve this. This is where you may be able to negotiate, especially if your company has a better way of delivering their required water. You may be able to offer the same outcome but with different equipment at a lower price and by an earlier date.
Avoid micromanaging subtask due dates:
I believe that not all tasks need to have due dates.
Some tasks may be on the critical path to deliver client deadlines, but others may just need to have prioritisation applied. Or could just be in a list within the main task.
This can save you having to constantly reshuffle due dates (those red angry looking warning notifications you have once too many of your minor tasks become overdue).
I think critical path tasks should have due dates, and many or most of the rest could have prioritisation applied only, with a due date for that whole set.
If your PM software allows, you could have a larger task (or deliverable) as the task with the due date on it. You could then list all the sub tasks you need to achieve this main task and only have dates on the critical path sub tasks. The rest would be prioritised only.
That way your overall project can still show a waterfall of due dates, but you don’t have to spend too much time on micromanaging the due dates of sub tasks.
Doug Lester wrote a nice blog post on this. “How to Use Dates Effectively for Project and Task Management”. The point is to avoid the continuous cycle of rescheduling tasks that have due dates. You only set due dates on tasks that actually must be completed by a specific date.
Be realistic, and communicate that:
Be realistic with the due dates leading up to a deadline.
Learn to communicate with your client regularly and also discuss the project due dates and what is impacting them. For example, if the client changes or increases the scope, you may not be able to meet the original set deadline. So they need to understand that, or separate the new scope (or cancel it) if the original deadline is critical.
Set some float in your schedule to accommodate client scope changes or review delays.
Allow enough time for internal and client reviews. I prefer to put in the contract a defined length of time we allow for the client to review drafts. That way we can hold them accountable, and they will know that they are the ones delaying completion of the deliverable by the deadline, not us.
Lesson: Understand the what, when and why
Completing a project on time and to budget is complicated and often hard work.
Make it more achievable by ensuring you and your team have a good understanding of the purpose of the project and why it is required.
As part of this, you need to get to know why the client has set the completion due date and the stages or deliverable due dates the way they have.
Make sure you know the reason, and check whether it is something you can control or mitigate. Are there underlying factors at play that may carry significant consequences if a delivery date is missed?
Understand the what, when and why of the project and its due dates. This involves clear communication, and results in a realistic schedule that should satisfy the requirements of the client and your team’s ability to deliver it.
