Milestones, Task Durations, and Resources
Not sure you’re ready?
Take the ~3-minute readiness diagnostic and see where you stand.
Consider the construction of a suspension bridge. The pouring of concrete foundations, the weaving of steel cables, and the installation of the roadway are the intense, daily actions that drive the structure across the water. Yet, when the final span connects the two shores, the crews pause for a ribbon-cutting ceremony. The pouring of concrete is the effort; the ribbon-cutting is the marker. In the rigorous discipline of project management, separating the work that consumes our resources from the markers that signify our success is foundational. Mastering this distinction allows us to accurately estimate what it takes to build the bridge and flawlessly communicate our progress to those waiting to cross it.
To build a realistic schedule, a project manager must mathematically and conceptually separate the passage of time from the measurement of progress. We do this by breaking the project down into tasks and milestones.
Project Tasks and Durations
A project task represents a distinct piece of work requiring effort to complete. If you are developing a new software application, writing a specific module of code is a task. Because work happens in the physical world, project tasks consume time during project execution, and equally importantly, project tasks consume project resources during project execution.
When we measure this passage of time, we look at the task duration, which represents the total elapsed time from the start of an activity to the completion of the same activity. If a coder starts writing a module on Monday morning and finishes on Thursday afternoon, the task duration is four days.
The Nature of Milestones
If tasks are the journey, milestones are the signposts. A project milestone represents a significant point in a project timeline, or equivalently, a significant event in a project timeline.
The Zero-Duration Rule: Because milestones represent a moment in time rather than an ongoing effort, project management scheduling tools universally assign a duration of zero to project milestones.
Consequently, a project milestone does not consume time, and similarly, a project milestone does not consume project resources. They are the finish line tape, not the act of running.
Project managers rely on these zero-duration markers for two critical reasons:
- Internal Tracking: Project managers use milestones to track major progress points in a project schedule, allowing them to verify if the project is progressing at the expected velocity.
- External Communication: Stakeholders rarely want to read a 1,000-line Gantt chart. Project managers use milestones to report high-level schedule status to stakeholders, providing a clean, comprehensible snapshot of project health.
Examples of these critical markers appear across all industries:
- Completing a major project phase serves as a common project milestone. (e.g., "Design Phase Complete")
- Obtaining a key stakeholder signature serves as a common project milestone. (e.g., "Building Permits Approved")
- Delivering a final project product serves as a common project milestone. (e.g., "Software Deployed to Production")
If the schedule is the map, resources are the vehicle that moves the project forward. In project management, resources are broadly categorized, and their governance is dictated by a core planning document.
The resource management plan is the operational playbook for your assets. This plan dictates how project resources are categorized, dictates how project resources are allocated to specific tasks, and ultimately, dictates how project resources are released back to the organization once their work is complete.
The Categories of Project Resources
A comprehensive project plan accounts for multiple resource dimensions:
- Human resources represent the team members providing the labor required to complete project activities.
- Physical resources include the tangible assets required to complete project activities. This broad category is subdivided into two distinct types:
- Material resources are consumable items used during the execution of a project. (e.g., lumber, wiring, chemical reagents).
- Equipment resources are non-consumable tools or machinery used to complete project activities. (e.g., bulldozers, servers, software licenses).
- Finally, Financial resources represent the funding required to execute project activities. Without capital, the other resources cannot be procured.
To maintain visibility over these assets, a Resource Breakdown Structure (RBS) categorizes project resources hierarchically. Much like a Work Breakdown Structure organizes scope, the RBS might break down "Personnel" into "Engineers" and "Designers," and further into specific grades or locations. Project managers use a Resource Breakdown Structure to organize project resource utilization during planning, and later, to report project resource utilization to leadership, ensuring budgets and capacities are respected.
Before we can schedule the work, we must know exactly what the work requires. The Estimate Activity Resources process is the mechanism we use. This process identifies the type of resources required for project activities, identifies the quantity of resources required, and identifies the characteristics of resources required (such as senior-level expertise versus junior-level).
The mechanics of this process require careful definition:
- Determining resource types involves identifying the specific skills required to complete a project task, as well as identifying the specific equipment required to complete a project task.
- Determining resource quantities involves calculating the exact amount of materials needed for a project task, and correspondingly, calculating the number of personnel needed for a project task.
Tools and Constraints of Estimation
We do not estimate in a vacuum. The environment around us shapes our math.
First, we must rely on historical context. Organizational Process Assets (OPAs) provide historical data to help determine project resource needs. If your company built a similar database last year, those archived files (OPAs) tell you exactly how many developers it actually took.
Conversely, the outside world restricts us. Enterprise Environmental Factors (EEFs) can constrain the availability of specific project resources. If a global supply chain shortage limits semiconductor availability, or a union contract restricts labor hours, those EEFs strictly limit your estimating reality.
Furthermore, we must consult the calendar. A resource calendar documents the working days and shifts available for specific project resources. Because humans take vacations and machines require maintenance downtime, project managers use resource calendars to determine when a specific resource is available to perform project tasks.
The Three Pillars of Estimation
When it comes time to calculate the numbers, project managers utilize three primary techniques, each offering a different balance of speed and accuracy:
| Technique | How it Works | Accuracy vs. Effort |
|---|---|---|
| Analogous Estimating | Uses historical data from a similar past project to estimate current project resource needs. | Fast to calculate, but less precise. Relies heavily on the similarity of the projects. |
| Parametric Estimating | Uses an algorithm based on historical data and project parameters to calculate resource quantities. (e.g., If 1 painter paints 100 sq ft an hour, 1,000 sq ft requires 10 hours). | Highly accurate, provided the underlying statistical relationship is robust and scalable. |
| Bottom-Up Estimating | Calculates resource needs for individual project tasks, and then aggregates individual task resource requirements to determine overall project resource needs. | Highly precise, but extremely time-consuming. Requires a fully decomposed Work Breakdown Structure. |
One of the most profound realizations in project management is that time and resources are inextricably linked, but not always in a linear fashion.
Task durations are directly influenced by the skill level of the resources assigned to the task. A senior software architect will invariably code a module faster than a junior developer. Likewise, task durations are directly influenced by the quantity of resources assigned to the task.
It seems intuitively obvious that adding more resources to a task may decrease the overall task duration. If one person can dig a trench in ten days, perhaps two people can dig it in five. However, we must confront the realities of human collaboration.
First, adding more resources to a task introduces coordination overhead. Ten developers working on the same code module must spend time communicating, merging code, and resolving conflicts—time they are not spending actively typing.
Because of this friction, we are bound by an economic principle: The Law of Diminishing Returns dictates that adding resources to a task will eventually yield lower marginal productivity increases. Eventually, adding a 50th painter to a small room does not make the painting go faster; they simply step on each other's toes and halt production entirely.
When we calculate our resource needs, we often find a mathematically impossible scenario: a critical team member is scheduled to work 16 hours in a single 8-hour day. To solve this overallocation, we apply resource optimization techniques.
Resource Leveling
Resource leveling is a resource optimization technique used when absolute resource constraints exist. If a specific crane is only available for 8 hours a day, the schedule must bend to reality.
Resource leveling resolves resource overallocation by adjusting activity start and finish dates. Because you are prioritizing the availability of the resource over the rigidity of the schedule, resource leveling can increase the original project duration. The project takes longer, but it becomes physically possible to execute.
Resource Smoothing
If a project's deadline is absolutely fixed (perhaps by a regulatory mandate), leveling the schedule to a later date is unacceptable. In this case, we use another approach.
Resource smoothing is a resource optimization technique that optimizes resource usage without breaking the schedule constraint. Resource smoothing adjusts project activities within the limits of available free float and within the limits of available total float.
Because smoothing only shifts tasks that have flexible buffer time (float), resource smoothing does not delay the overall project completion date. However, because its mathematical flexibility is limited, resource smoothing may not fully resolve all project resource overallocations. It makes the resource curve smoother, but you may still have to authorize overtime to meet the fixed deadline.
The predictive concepts discussed above rely on heavy upfront planning. In adaptive, iterative environments, our approach to resources fundamentally shifts to prioritize adaptability over precise initial calculations.
Agile project management methodologies emphasize the use of cross-functional teams. Instead of passing work from a design department to an engineering department to a testing department, agile pulls all required skills into a single, cohesive unit. A cross-functional team contains all the skills necessary to complete a working product increment from start to finish.
To maximize this efficiency, agile teams often utilize generalizing specialists to reduce bottlenecks in resource availability. A generalizing specialist (often referred to as a "T-shaped" professional) is someone who defies the traditional narrow job description. Generalizing specialists possess core expertise in one area alongside broad knowledge in other areas.
If the team's primary tester is overwhelmed, a generalizing specialist whose core expertise is coding can pivot to help write test scripts. By dynamically sharing the load, the team avoids the very overallocations that predictive project managers spend hours trying to resolve through leveling and smoothing.
