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

Estimate and report by tasks rather than work types

Bottom of Page

1 to 5 of 5


    Sample project: Design a learning program.

    Module 1: Analysis
    Task 1.1 Gather data
    Task 1.2 Analyze data
    Task 1.3 Write report

    In this sample project, task 1.1 involves several work types. I account time to Meetings, Admin (logistics), Design (creating a survey tool), etc.

    However, I estimate the project based on task - task 1.1 should take about 20 hours to complete. Something like Meetings flows through every one of the tasks, as does Admin.

    So now creating an estimate is very tough - I have to create a spreadsheet with tasks x work types, and figure out how much of each task will be meetings v. writing v. admin, then total the meeting time across tasks - because Intervals asks me to estimate the total time spent in meetings, NOT the total time spent in each task.

    Worse, much of the reporting is work type oriented rather than task oriented. I want to know my estimated v. actual by task - because that's what the customer wants to know - not work type.

    I'm not quite sure what type of projects the software architects had in mind that promoted the importance of work type to the degree it has - and I'm LOVING the tool overall so please take this as constructive suggestion - but it would be very very helpful to have estimates and reporting by task as well as (or in my case instead of) by work type.

    Or am I thinking uncldearly and there are better ways to skin my particular cat?


    Yes, I agree, in anylising projets, task is much more useful that work type.
    I have a set of spreadsheets where I manually extract the Intervals data and reformat in Excel.


    To add a similar twist: I would like to be able to estimate by module.

    Modules could be stages like

    * Discovery
    * Planning
    * Content
    * Design
    * Build
    * Test/QA
    * Launch

    It would be nice to not only estimate, but invoice, with those summaries rather than worktype summaries.


    A few things that may be helpful on this front:

    1. Have you given the Project Activity report 'by task" a look by chance? It includes the task estimates in an estimate versus actual fashion. Since task estimates do not include estimates by work type it might be useful.
    2. If you go to the task listing and filter based on a module or milestone there are task estimates versus actuals totaled. Say for example you wanted to see all of the estimates for tasks for a given module. You can go to the task listing, select the project and module and view the estimated versus actual on the task listing.
    3. If you drill into a project via the project section there is an "estimated vs. actual" link on the left. Estimates can be viewed via the project estimates or the task estimates. The back story on the project estimates may be helpful. Those are there if you estimate projects up front. For our web development work we create estimates that include total estimated hours. We use the project estimates to enter this information and set an overall budget for the project. Then we use the task estimates as a reality check through the course of the project to make sure we have enough time. The task estimates can serve as an alarm if you are seeing task estimates that are way higher than the project estimates. It is a sort of check and balance

    Regarding the emphasis on work types, Intervals comes from a web development and web design background where different rates are charged for different disciplines. One task could potentially have multiple work types (and rates) associated with it. For example a task titled "beta launch web application x" would have project management time, quality assurance time, system administration time, and engineering time. Sorry for the lengthy answer, but hopefully it adds some value.

    Michael - thank you for your remarks. I knew about 1 and 2 (and use #2 a lot) but hadn't seen #3. For those of our projects where modules are a meaningful construct, that gives me a good 10k view - thanks1

    Our projects are wider in range, but also have multiple work types and rates. I'll put this here not in the spirit of arguing with you, but in making a business case for expanding the feature set so that Intervals is useful to a wider community.

    We in fact are managing our next release's rollout via Intervals. However, we don't see this as a task, but rather as a project - a series of discrete tasks with deliverables, some of which have dependencies on them. So our patch rollout process had the following tasks:

    Code Complete
    Run regression tests
    Create release notes
    Update manual & help system
    Update training programs
    Create sysadmin training
    Update tutorials
    Initial customer communication
    Final client communication
    Roll out release

    Note that several of these tasks have the type "Communication", several have "Documentation", and for many of our projects, "System Administration" is the type for several tasks. When we budget for this project, we estimate how long it will take to update the training program, to update the help system, and to update the tutorials - because each one takes a different amount of time for any given release. We don't think of estimating "documentation" time - it's too broad. So to get estimates into Intervals I have to create a spreadsheet (for larger projets) that sum up the documentation time associated with several tasks.

    Why not do it the other way? Because seeing how much "sysadmin time" has been spent doesn't really help me manage a project where until Charles provisions the site, Mary can't QA it. Just thinking of Charles as having done 50% of the sysadmin work doesn't help. We need to manage by task, not by pay category. Does that make sense?

    Hence, while I understand why Intervals' architecture is as it is, I think the publishers can do themselves a service by incorporating more "management by task" features, so the product will be more easily used by a wider audience.

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