Estimating time to develop training – Part 3

This is the final post of my 3-part series on how to estimate the time to complete training development projects. (See Part 1 and Part 2)


Early in my career, I worked as a software quality assurance engineer. This was back in the days of manual testing, before Agile and Lean, when department managers gathered with their costing summaries and hammered out development schedules that could last months or more.

The costing summaries were based on individual team members’ timing estimates. As a new QA engineer, I had no idea how to estimate how long my testing would take. I wondered if there was a process I had to follow.

So, I asked my manager for some guidance, and I remember being very surprised by her answer:

Time yourself.

I hadn’t expected it to be that simple.  And indeed, I found it to be a very accurate means of generating cost estimates.

Count the days…or not

One approach you can take is simply to count the number of days a project takes. Starting at the kick-off and ending with delivery, a rough count of person-days has the advantage of taking into account typical workdays, including time spent off project.  We are talking about estimates after all, and it’s good practice to include a buffer for email, meetings, lunch and all the other sorts of activity that also need to be done.

But counting days has its drawbacks. If your team is working on multiple projects at once, you’ll need to figure out if and how to split days. Another disadvantage of counting days is that you lose insight into how long different phases of a project take and how individual team members are performing.  This can result in inefficient scheduling or an imbalance of work assignments.

For example, I worked in a department where job responsibilities were strictly divided. Designers were responsible for storyboards, writers for scripts and assessments, and developers for slides decks, videos, and QA. But the staffing levels didn’t match the time needed to complete each phase. The designers kept pushing through the storyboards, the writers couldn’t keep up, and the developers were left under utilized.

So, I asked each team member to time how long it took to complete a unit of work. We learned that the ratio of design:writing:development was approximately 1:3:2 for slide decks and 2:5:3 for eLearning.  Adding a writer to the team and reassigning QA testing to the designers balanced the workload and made the phases take about an equal amount of time. As a result, the team could keep three projects in production at all times.

As a consultant, I time all my billable and non-billable tasks. For example, right now I’m timing how long it takes for me to write and publish this blog post.  Tracking everything I do gives me a better understanding what goes into my workday (week, month…) which in turn helps me plan my schedule.

Timing your team

When introducing timing to your team, work as a group to see how accurate estimates are against actual times. When the estimates are off, try to determine possible causes. And then, try to make your next schedule more accurate.  Be careful about using timing estimates to compare individual performance.  Your team will be tempted to play with the numbers if they are tied too closely to rewards and disincentives.

You can use timing as an occasional exercise to tune up project planning or adapt to new work flows.  Or, your team can use timing on an ongoing basis.  Ongoing tracking can help with project management, team management, and take the drudgery out of creating status reports.

The time tracker I use

Please note, I receive no compensation or other benefit by providing the following information. This is simply my experience and opinion.

When I first started consulting, I tried a handful of time tracker tools and ultimately chose TrackingTime (  I’ve been using their basic version for almost 18 months. The product stability, ease of use, and functionality have kept me very happy.

I particularly like the project structure.

Within a project, I create an outline of the milestones (using Task Lists).  Then, under each task list I enter the associated tasks. Every task can be assigned an estimated time, due date, and owner. As I work through a project, I can easily add, reorder, edit or delete tasks.

Most of the projects I’m currently working on don’t fit a single model.  I like being to sketch out a project in the early phases and then add to it as the path becomes clearer, all while keeping track of time spent, goals, and due dates.

With the Pro version of TrackingTime, you can duplicate a project. In essence, you can create a reusable project template. I imagine that would be very helpful for teams who deliver more predictable products.

Parting thoughts

  • If possible, give your initial delivery date as a range:  optimal, average, and challenging.
  • After your client signs off on the design and you’ve confirmed all necessary resources are in place, you can offer a firmer date.
  • Keep room in the schedule for surprises, non-project related tasks, and time off.
  • Include a post-project buffer for close-out activities such as cleaning up your directories and getting feedback from your client and team.




Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.