You are putting together a proposal for a new client. Your lead developer sends you the estimate for the backend work: “400 hours.”

You look at the number. It feels accurate. But then you hesitate. Should you put “400 hours” on the client-facing proposal? Or should you convert it to days?

If you convert it, what math do you use? Is it 400 divided by 8? Or divided by 6?

This dilemma—hours vs. man-days—is one of the oldest and most confusing debates in software project management. It seems like a simple semantic choice, but getting it wrong is a leading cause of blown budgets, missed deadlines, and frustrated clients.

Choosing the wrong unit is not just a formatting error; it is a strategic error.

This guide will cut through the confusion. We will define the units precisely, expose the mathematical trap that most agencies fall into, and provide a clear framework for when to use hours and when to use man-days.

Table of Contents

  1. The expensive misunderstanding
  2. Defining the units: Effort vs. Capacity
  3. The case for Hours (Precision)
  4. The case for Man-days (Abstraction)
  5. The Mathematical Trap: Why 1 Man-day ≠ 8 Hours
  6. Strategic Framework: When to use which unit?
  7. The psychology of units in sales
  8. How devtimate handles unit conversion automatically
  9. Checklist
  10. FAQ

The expensive misunderstanding

Why does this matter so much? Because “Hours” and “Man-days” measure two fundamentally different things, yet people use them interchangeably.

When a developer estimates in hours, they are thinking about effort. “How long will it take me to write this specific function if I am undisturbed?”

When a client or Project Manager hears man-days, they are thinking about calendar time and capacity. “How many days will this person be unavailable for other work?”

The disaster happens in the translation. If a developer estimates 8 hours of effort, and the PM schedules it as 1 calendar day of work, the project is immediately behind schedule. Why? Because no one provides 8 hours of effort in one calendar day.

Mixing these up is why so many project timelines are always wrong.

Defining the units: Effort vs. Capacity

Before we compare them, let’s define them accurately in the context of software development.

The “Hour” (Ideal Hour / Effort Hour)

An “Hour” in estimation does not mean “60 minutes on a clock.” It means one hour of focused, uninterrupted, productive coding effort. It is a unit of pure work. It does not include coffee breaks, checking Slack, or sitting in the daily stand-up meeting.

The “Man-day” (Person-day)

A “Man-day” (increasingly referred to as a Person-day) is a unit of capacity or duration. It represents one developer being allocated to a project for one standard working day. It acknowledges that within that day, there will be a mix of coding, communication, and administrative tasks.

The case for Hours (Precision)

Developers almost always prefer to estimate in hours. For technical minds, it is the most logical unit.

Pros of using Hours:

  1. Granularity: You can estimate small tasks accurately. A “2-hour task” makes sense. A “0.25 man-day task” is confusing.
  2. Aggregatable: It is easy to add up hundreds of small tasks into a total project effort.
  3. Tracking: Modern tools like Jira or Harvest track time in hours. Estimating in hours makes comparing “Estimated vs. Actual” very easy.

Cons of using Hours:

  1. Micromanagement: Seeing a proposal with “842 hours” invites clients to scrutinize every single hour and ask, “Can we shave 2 hours off this login task?”
  2. The Big Numbers Scary: Large numbers can scare non-technical clients. “1,000 hours” sounds enormous, whereas “4 months for a team of two” sounds reasonable.

The case for Man-days (Abstraction)

Project managers and sales teams often prefer man-days when dealing with stakeholders outside the development team.

Pros of using Man-days:

  1. Big Picture Focus: It abstracts away the technical details and focuses on the scale of investment. It helps clients think strategically rather than tactically.
  2. Easier Budgeting: Clients often think in terms of daily rates or monthly salaries. Man-days align better with their financial mental models.
  3. Hides the Sausage Making: It accounts for the necessary “non-coding” time (meetings, emails) without having to explicitly line-item it, which clients sometimes resent paying for.

Cons of using Man-days:

  1. Loss of Precision: Rounding complex features up or down to the nearest “day” introduces inaccuracy.
  2. The Conversion Trap: The risk that the client (or the PM) assumes a man-day equals 8 productive hours.

The Mathematical Trap: Why 1 Man-day ≠ 8 Hours

This is the single most important section of this guide. If you take only one thing away, let it be this.

In software estimation, 1 Man-day does NOT equal 8 Hours.

If your employment contract says you work 8 hours a day, you probably only spend about 6 hours doing the actual core work you were hired for (coding, designing).

The other 2 hours are consumed by the “overhead of being employed”:

As we discussed in detail in our article on poor capacity planning, assuming 100% utilization (8 hours/day) is a guaranteed recipe for burnout and late projects.

The Golden Rule of Conversion: When converting estimated Effort Hours into billable Man-days, you should divide by a realistic productive factor, usually 6.

That difference of 17 days is your safety buffer against reality.

Strategic Framework: When to use which unit?

You don’t have to choose one unit forever. The smart approach is to use the right unit for the right audience and the right stage of the project.

Project Stage / AudienceRecommended UnitWhy?
Internal Team Estimation (Developers estimating tasks)HoursNeeds maximum precision. Developers think in effort.
Sprint Planning (Jira tickets)Hours or Story PointsNeeds granularity for tracking daily progress.
Early “Ballpark” Sales CallsMan-days (or Weeks/Months)Keep the discussion high-level. Avoids premature micromanagement.
Formal Client ProposalsMan-daysEasier for clients to budget. Abstracts the messy details.
Resource / Capacity PlanningMan-daysYou book people on a calendar by the day, not by the hour.

The Hybrid Approach: The best agencies estimate internally in hours to get a precise total, apply the correct conversion factor (divide by 6), and then present the final quote to the client in man-days.

The psychology of units in sales

The unit you choose changes how the client perceives the value.

When you present a quote in Hours, you are framing yourself as a laborer or a freelancer. The client immediately starts doing mental math about your hourly rate and wonders if you are working fast enough. It becomes a transaction about time.

When you present a quote in Man-days, you are framing yourself as a consultant or a partner. You are selling a block of capacity and capability to solve a business problem. It becomes an investment in a solution.

If you want fast client approval, avoid overwhelming them with thousands of hours. Use man-days to tell a clearer story about the project’s scale.

How devtimate handles unit conversion automatically

Doing this conversion manually in Excel is risky. If one formula is wrong (e.g., dividing by 8 instead of 6), your entire project budget is flawed.

devtimate solves this by handling both units simultaneously.

  1. Estimate in Hours: Your technical team builds the detailed estimate using hours for maximum precision on individual tasks.
  2. Set Your Factor: In the project settings, you define your “Productive Hours per Day” (e.g., 6 hours).
  3. Present in Days: When you generate the client proposal, devtimate automatically converts the totals into Man-days using your predefined safety factor.

You get the precision of hours for your internal planning and the clarity of man-days for your client presentation, without ever touching a calculator.

Start estimating with precision and clarity using devtimate.

Checklist

✅ Define clearly within your agency what a “Man-day” means (e.g., 6 productive hours).
✅ Never assume 1 Man-day equals 8 billable hours in your estimates.
✅ Use Hours for internal estimation, technical breakdowns, and sprint tasks.
✅ Use Man-days for high-level proposals, roadmaps, and client communication.
✅ When converting hours to days, divide by a realistic utilization factor (we recommend 6).
✅ Be consistent. Do not mix hours and days in the same column of a proposal.

FAQ

1. Why is the industry moving towards the term “Person-day”?
”Man-day” is the traditional term, but “Person-day” is increasingly used as a more inclusive, gender-neutral alternative. The mathematical definition remains exactly the same.

2. What about Story Points? Where do they fit in?
Story Points are a measure of relative complexity, not time. They are excellent for Agile teams tracking velocity from sprint to sprint, but they are terrible for financial budgeting or fixed-price contracts because they have no direct relation to money or calendar days. Do not use Story Points for client proposals.

3. If I bill by the hour (T&M), does this matter?
Yes. Even in Time & Materials, you need to give the client an estimate of the total cost. If you tell them “400 hours,” they will likely mentally divide by 8 and expect it done in 50 days. You need to manage that expectation by explaining that 400 hours of effort will take longer than 400 hours on the clock.

4. Can I just use a standard 8-hour day and add a 30% buffer instead?
Mathematically, that gets you to a similar result. (400h / 8 = 50 days. 50 days + 30% buffer = 65 days). However, using the “6-hour productive day” method is often cleaner and easier to justify to a client than tacking on a generic “buffer” at the end.

5. Does devtimate allow me to change the conversion factor per project?
Yes. You might have a highly efficient senior team where you feel comfortable using a 7-hour factor, or a junior team where a 5-hour factor is safer. devtimate allows you to adjust this setting to match the reality of the team doing the work.

The choice between hours vs. man-days is not just vocabulary. It is about setting realistic expectations.

By understanding the difference between effort and capacity, and by using the correct conversion math, you protect your team from burnout and your projects from going over budget.

Use the right unit for the right job, and let a tool like devtimate handle the math for you.