Not signed in (Sign In)
The Intervals Forum is read-only
Please head to for help articles and guides. If you have any questions, please contact our support team.

Feature Requests [Closed]

Estimated vs. Actuals report for each task

Bottom of Page

1 to 13 of 13

    • Michael
    • Nov 28th 2007 edited @ 01/11/2008 10:50 am

    Today we received this feature request:

    Is there any report which provides an 'estimates vs actuals' where we can track actual head hours against the estimated hours for each task in a project? We are already entering the 'estimated hours' for a task and developers are clocking up time against the tasks so it would seem the data is there to do this. Ideas?

    Here was my follow-up response:
    The estimated hours on tasks presently do not total up anywhere. That is a very interesting idea. The project level estimate is meant to help control total scope for the project and the task estimate is meant to help the person know how many hours to work on something while also letting the owner of the task change course if the task starts tallying up too many hours. We will ponder this one some more...thanks for the suggestion.

    Would you use it? A new report maybe? Does it add additional complexity or a lot of value?
    I would DEFINATELY use this. So much of Project Management is keeping track of what was estimated versus what has been used, and having that in a one click as opposed to having to view each task would be extremely helpful.

    This would be so useful. It would allow us to quickly pinpoint where exactly the budget is going. The worktypes and modules are to general. As a workaround we define worktypes to be able to track with more detail. This makes setting up a new project quite timeconsuming.

    This would add a lot more value for us!


    We are going to retrofit the Project Activity Report by Task to include the task level estimated hours. This one report will allow you to see each task estimate and the exact hours that have gone into each task.

    We are also kicking around the idea of adding an additional view to the Estimated vs. Actual page at the project level. It currently shows the estimated hours that have been entered for the project against all of the actual hours that have been logged. This new view would be similar, but would show the estimated hours summarized from all of the tasks that have been created for the project. For example:

    Estimated Hours from tasks: 80
    Budgeted estimated: 110
    Difference: 30

    Good idea? Would you use it?


    ## Update ##

    Last night we launched a new batch of updates including an update to the Project Activity Report. Now the Project Activity Report displays the estimated hours for each task (note: only if the "by Task" filter is selected when running the report). The top half of the report includes the summarized hours and the bottom half includes each time entry for each task and the estimate:

    project activity report by task

    • David R
    • Feb 1st 2009 edited @ 02/01/2009 6:40 pm

    Hi. I'm in my trial period for Intervals. Here's the deal-maker for me: My end is to be able to let staff know how they are doing on estimate vs actuals for a month, a quarter or a year.

    In the time management software I'm using now, I can pull a report that has that info, but with a problem: that I'm hoping you've solved: Say a project has 40 hours. If I'm looking for a report for December, and the project has 20 hours spent in December, and 20 in January, the current software shows that we've done 20 out of the 40 hours, and therefore looks like we're well under budget. This is a huge problem because no matter what time span I select, the report always contains partial projects.

    Is there a way to show this information per employee?

    I think Michael's comment on May 14th 2008 would may do the trick - being able to see an aggregate view of all projects.




    This is a terrific product, but I'm still having trouble understanding the use of project-level and task-level work estimates that are not connected.

    In your example above there is a project budget estimate of 110 hours and a task estimate of 80 hours. The first question that pops into my head is -- how else would somebody estimate the total project hours except by summing the estimated work by tasks?? I guess a client with a specific budget could give you a figure to work backward from, but you would still have to align the task estimates with that figure. Either way, the task-level and project-level estimates should match.

    The most irksome aspect of having the disconnected work estimates is that I have to enter the figures twice...once at the task level, and then again at the project level.

    Please reconsider the current set up and link the two figures together.

    The two different forms of estimating are ideal for tackling the project from two different perspectives. The project estimate is often used as a high level estimate for approving overall time and financial budgets. The task estimates are used during development to work backwards toward the original estimate. We do have plans on integrating the task estimates into Intervals more so they are more present. This should help unite the two types of estimates in a more intuitive way.

    I just have to throw my vote in here too. By my thinking, and in our processes, total time estmiated for any project is the sum of time estimates for all tasks in the project. The seemingly strange disconnect between estimated task time and estimated project time might prevent our adoption of Intervals.

    I hope that you will soon reconcile those two perspectives of time estimates. Otherwise, Intervals seems like a winner.


    Thanks for your input. We do agree that task estimates are still in their infancy and we have plans to integrate them more thoroughly throughout the application. Stay tuned for new feature launches that incorporate more task and time estimates into Intervals.
    • Michael
    • Jun 29th 2010 edited @ 06/29/2010 8:58 am

    It might be useful to give some additional back story on the intent of estimates within Intervals since there are project estimates and task estimates. The most common way is to use the project estimates to set the high level budget for the project and then use the task estimates as a control/reality check for the project. It is a top down vs. bottom up view. On the Pelago web development side of our business we sell contacts that have the total number of hours included for the project then use the task estimates as an early indicator if the project is going to go over what was contracted. We typically do not update the project estimates after the project starts.

    If you are interested in seeing hours only based on task estimates there are a variety of ways to get at that data.

    1. On the task listing if you filter for an individual project the estimates will total up on the listing. Selecting “include closed tasks” at the top of the listing will include all tasks for the project.
    2. If you navigate into a project and then click on estimated vs. actual there is a link to toggle task estimates.
    3. In the reporting section if you run a project activity report and select “by task” in the summary drop down the bottom half of the report will include all tasks and their estimated time.
    4. In the reporting section if you run the project landscape report and click on the time tab after the report is generated the total task estimates are included.

    Depending on your workflow and the data you need one of those options might help.
    The project landscape report might be worth a look as well. It is probably the most comprehensive report. In the reporting section if you run the project landscape report and click on the time tab after the report is generated the total task estimates, project estimates, and remaining hours are included. Also, this report has financial information available in the budget & invoices tab.

Comments are closed.
For more Intervals help documentation, please visit