Estimate and report by tasks rather than work types

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?

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.

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.