Intervals is online time, task and project management software built by and for web designers, developers and creatives. Learn more…
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 reportIn 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* LaunchIt 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:
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 - thanks1Our 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 CompleteRun regression testsCreate release notesUpdate manual & help systemUpdate training programsCreate sysadmin trainingUpdate tutorialsInitial customer communicationFinal client communicationRoll out releaseNote 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 help.myintervals.com