Start Dates, Due Dates, and Time Estimates

A task can carry three planning fields, and each one answers a different question. The start date is when the work may begin. The due date is when it should be finished. The time estimate is how many minutes you think it will take. None of them is a milestone, and the estimate is not time you have already logged.

If you only set a due date, you can still see the task on the calendar. If you set both dates, the Gantt can show a span. If you set an estimate, you have a plan for effort. Mixing the three into one number is how a "two-day task" becomes a due date, a duration, and a timesheet at once.

The due date

The due date is the day the task is meant to be done. The calendar places the task on that day. A task with no due date stays off the grid, in the undated list. Priority does not move the day. Urgent work can be due next month. Low-priority work can be due tomorrow.

The due date does not send an email when it passes. It does not include the company holiday calendar. If the office is closed, pick another day yourself. Workload counts tasks that have a due date in the current month. It does not read the estimate.

The start date

The start date is the beginning of the span. Use it when the task should not be treated as starting the moment it was created. "Design starts after the outline is signed" is a start date plus, usually, a Blocks link from the outline. The link says what holds it. The start date says which day you are planning. Both are described from the chart's side in how to plan on a Gantt chart. Dependencies themselves are Blocks or Related to, nothing else.

A start date with no due date is an incomplete span. The calendar still keys off the due date, so that task will not sit on a day until a due date exists. Do not use the start date as a substitute due date.

There is no milestone type to mark "start" or "finish." If you need a moment on the schedule, use a short task with a due date.

The time estimate

The estimate is stored in minutes. "Half a day" should be entered as the minutes you mean, not as a slogan in the title. The estimate is a plan. It is not a timer, not a manual time entry, and not attendance.

Logged time is what someone actually recorded on the task, either with the timer or by typing minutes. That record stays separate from attendance and from payroll. Project time versus attendance is that split. An estimate of 180 minutes does not create a 180-minute time entry, and a time entry does not overwrite the estimate.

The estimate also does not change the workload view. Workload counts due tasks. It does not add the minutes up into capacity, cost, or a billable day. A currency field is unrelated. It is not a fee calculated from the estimate.

A three-field example

"Write the case study."

• Start: next Monday, because the interview is Friday and writing before it is waste.
• Due: the following Thursday, because the newsletter goes out Friday.
• Estimate: 240 minutes. The writer knows the draft takes about four hours, not three days of full attention.

The span on the chart is Monday to Thursday. The effort is four hours. Those are compatible. A three-day bar does not mean three days of uninterrupted work. If you put the due date on Monday and the estimate at 240 minutes, you are saying it takes four hours and it is due the day it starts. That may be true. If it is not, fix the due date rather than inflating the estimate to "three days" so the bar looks long.

What not to store in these fields

Do not put a person's name in the date because you want it on their row. Use the assignee. The timeline shows assigned tasks for the current month with the due day on the chip. It does not draw the estimate, and it does not draw a bar from start to due. That bar is the Gantt.

Do not put "blocked" in the due date by clearing it. Clearing the date removes it from the calendar. The block belongs in a Blocks link.

Do not use the estimate as a status. "We are halfway" is either logged time compared with the estimate, which you compare yourself, or a status of In progress. The product will not mark the task Done at 100 percent of the estimate.

A weekly habit

Once a week, look at tasks due in the next ten days that have no estimate only if your team uses estimates for planning. An empty estimate is honest when you do not know. A fake round number is worse. Look at tasks with a start date after the due date, which is a data error. Look at In progress tasks whose start date is still in the future. Either the work started early and the start date should move, or the status is wrong.

Leave the estimate alone when the due date slips unless the work itself grew. A later Thursday does not automatically mean more minutes.

Putting the fields on an existing task list

You will not fill all three on every old task in one sitting. Do it in this order, and stop when the next field is a guess.

First, due dates on anything someone will ask about this month. The calendar and the workload view are useless without them. Second, start dates only where the span changes a decision, usually because another task blocks this one or because the work must not start early. Third, estimates on tasks an individual will actually plan their week around. A queue of tiny chores does not need a minute count on each.

When two people disagree on the estimate, write the minutes the person doing the work believes, and note the disagreement in a comment if it matters. Do not average it into a false precision. When they disagree on the due date, the date is a commitment, so the owner of the commitment decides, and the task shows that day. The estimate does not vote.

Recheck tasks whose estimate is larger than the span allows. Four hundred minutes between a start and a due date on the same afternoon is a warning, not a fact the chart will correct. Shorten the estimate or move the due date. The product stores both and does not reconcile them.

Conclusion

Set a due date for the day it must be finished, a start date when the span matters, and a time estimate in minutes for the effort you expect. The calendar reads the due date. The Gantt reads the span and any Blocks links. Logged time, attendance, and fees are different records. There is no milestone to attach these fields to. They live on the task in /pms.