Skip to content
PM Certification
Generic filters
Exact matches only

Product Milestones Scheduling Approach

When it comes to timing in projects, customers want to get fast results. This is something natural. If they pay for a project they expect to start getting results sooner rather than later.

Traditional waterfall project management has been focused on sequencing the activities required to complete the project. In this scheduling approach, milestones represent when a set of activities have been completed based on the project phases. In the following example, you can find the lifecycle phases required for building a bicycle following the traditional activities milestones approach:


On the other hand, there is the product milestones scheduling approach. In this approach, the final product is decomposed in a set of component products (not activities or lifecycle phases), and these again in more sub-products. The whole approach is a “product” approach and therefore delivers valuable partial end-product results for the customer. Only the integration phase includes the lifecycle phases because this also delivers the final full product.


In fact these “shippable-products” milestones approach is the foundation in Agile project management methods for project scheduling.

Agile methods go one step further and define fixed time slots for building each milestone that are called sprints.

No matter if you use fixed-time or variable-time product building steps, in this approach the most important idea is that a project must have a sub-products structure approach in order to deliver value in each milestone.

Once we have a product high level structure, maybe we will be required to go further into activities to get a better accountability. If there aren’t enough milestones, our project may not be under control due to a lack of accountability. In that case, we will be required to control also some intermediate activities critical for building a sub-product.

Timing is also important. Customers can’t go much time without seeing valuable sub-products. In case in your project it is not possible to deliver sub-products in a short period of time, you will be required to involve your customer in some activities in order to provide them the required visibility of the status of the project. The more smarter you involve the customer the better final satisfaction of your Product.

For the above reason, publication of milestones it is very important. Everyone needs to know your project milestone scheduling and the next steps. Today there are many social media opportunities, project blogs, Whatsapp groups, etc. You can take the one that may fit better for your client, but make sure that everyone knows about your project and what are the main delivery dates.

Milestones are a commitment that we have agreed upon with our customer. The more milestones, the more control. Of course this may also have its limits, and if we exceed common sense we can go into a management overhead. In any case, a good accountability is based on enough meaningful milestones that they provide both customer-value and project management control.

Continuing with this SMART (Simple,  Measurable, Achievable, Realistic, and Timely) approach for setting project milestones, we need to focus on the achievable and realistic part. Milestones are required to be challenging for getting the most of your team’s productivity, but at the same time we can’t exceed their work capacity for a lengthy time because we can get into trouble).

As always I recommend, as a Project Manager (PM) don’t build your project schedule alone. You must work with the experts and team leaders in order to get a good product-oriented project structure and accurate estimates.

Finally, a product-oriented project structure will provide a powerful decision making tool for senior management in case the project becomes delayed or on cost overruns. Easily, it will provide visualization of what sub-products have been already built and what products will not be delivered in case we run out of time or cost.

Images: Practice Standard for Work Breakdown Structures (Second Edition)

error: Content is protected !!