Skip to content

Duration vs. Effort – Why “When” and “How Much Work” Are Not the Same

Info

In project planning, duration (when something will be delivered) and effort (how much active work it takes) are not the same thing. Understanding the difference is critical for setting realistic deadlines and avoiding painful surprises.

Duration is the total time between starting a task and delivering it. It is measured on the calendar — days, weeks, or months — and it includes everything: active work, waiting for approvals, fixing blockers, and even delays outside your control (sick-leaves, holidays, etc.). A task might have a duration of ten days even if the team only actively worked on it for two.

Effort, on the other hand, is the actual hands-on work required to complete the task. In software teams, we often measure this in person-hours (PH), person-days (PD), or person-months (PM). In this course:

  • 1 PD = 8 PH (one full workday for one person)
  • 1 PM = 21 PD (about a month of full-time work for one person)

Example

If a feature takes 42 PH (5.25 PD) of effort, one developer working full-time could finish it in about a week. Two developers working in parallel might finish in roughly half the time — but only if the work can truly be split without extra coordination.

Deadlines are fixed points in time when something must be ready, often driven by external events like client sign-off, legal compliance, or product launches. A deadline limits the duration but does not magically reduce the effort required. If the effort is too large for the available time, your only options are to add resources, cut scope, or negotiate a later delivery.

Tip

This is where Frederick P. Brooks’s famous observation from The Mythical Man-Month comes in: “Adding manpower to a late software project makes it later.” His point was that throwing more people at a task doesn’t always speed it up — and can even slow it down.

Some tasks are inherently serial. Just like you can’t speed up a pregnancy by having nine women work on it at the same time, certain software activities — like designing the system architecture, debugging a deeply hidden bug, or integrating complex modules — simply have to happen in sequence.

Even when work can be parallelized, adding people increases communication overhead. A two-person team only has one direct communication line. A five-person team has ten such lines, and each one needs time and effort to keep information flowing. The more people involved, the more time is spent coordinating, not coding.

Finally, every new team member needs time to get up to speed. Learning a project’s code, tools, and past decisions cannot be divided in half — two people can’t each “learn half” and expect to work effectively. Everyone needs the full context, and the people teaching them temporarily slow down their own work to provide that knowledge.

Danger

When managers confuse effort with duration, they risk making impossible promises. The temptation to “just add more people” often ignores the limits of parallel work, the cost of communication, and the onboarding time for new team members. If those factors are not accounted for, projects can actually take longer instead of shorter.

By keeping duration and effort separate in your thinking — and by being honest about dependencies, communication needs, and learning time — you can set schedules that are both achievable and respectful of the team’s capacity.