Good planning = happy clients, happy team, happy you
Whether you develop training or manage those who do, you need to be able to come up with reasonably accurate estimates of how long it will take to complete a project. In this and the next few articles, I will discuss three methods you can use to make these estimates.
When I talk about estimating the time to develop a training project, I am referring to the “ADD” phases of the ADDIE model — Analysis, Design and Development. This starts with vetting a request for training and concludes with delivery of the final version, whether through deployment on an LMS, hosting on a file server, or shipment of printed material.
Method 1: Use data from past projects
What it is
Using past project plans to generate future estimates can springboard your estimating. The key to successful use of past plans is to find similar projects, draw applicable inferences, and make necessary adjustments.
How it works
Imagine that last year you developed the course: “An Introduction to Product X version 1” and now you are being asked to develop “An Introduction to Product X version 2”. Using your version 1 project plan along with a list of the new features in version 2, you can create a fairly accurate development estimate.
But, what if the request is for:
- “An Introduction to Product Y” or
- “Advanced Troubleshooting of Product X” or
- “Selling Product X against the competition” or
In this case, look for similarity in projects. Here are four things to consider when using past plans to make future estimates:
The biggest bearing on a development project is whether the content is more task-based (how-to) or topic-based (conceptual understanding and application). Task vs topic writing influences everything from the likely challenges you’ll face during the project, to the skills needed by your IDs, to how much buffer to build in for outside contributors.
Task-based writing is based on defined steps, with the primary challenge for the instructional designer being to place the steps in logical sequence and meaningful context. Technical documentation is a primary resource for the ID.
Topic-based writing is more dependent on scenarios, individual interpretation and exploration, and requires interactivity and feedback. The ID will need a better understanding of real-world applications, and will need to rely upon outside experts.
In our example above, the project “An Introduction to Product X version 1” is more similar to “An Introduction to Product Y” than to “Selling Product X against the competition”. The latter will have fewer procedures, more “what if” scenarios, and as a result will require more front-end analysis, more input from subject matter experts (SMEs), and different types of assessments than those in a task-based course.
The prior skill and knowledge of your target audience has a significant impact on instructional design. Previously we described the “Selling Product X” course as a topic-based course, with scenario-based practice and lots of interaction. Now, imagine that it is being written specifically for new salespeople.
The novice course might rely more on scripted scenarios that illustrate common situations. There may be more recommended best practices rather than open-ended exploration. The content would likely also include more tasks, such as how to find competitive information or write a proposal. Overall, the content might become less topic-based and more task-based.
As another example, consider the “Advanced Troubleshooting of Product X” course. While troubleshooting tasks may be presented, emphasis shifts from how to perform the task to when to apply certain techniques. More of the training may involve exploration and discussion. Given the complexity of the material, the ID will be more reliant on SMEs to create and review the content. Overall, the development will be more similar to topic-based projects.
When you look at past plans consider the experience of your team. They may be more skilled, better equipped, and should be able to show performance improvements. Challenge them!
Or, you may have new people, with less experience. Or, the project might involve tools or topics that are completely new. In this case, you might need to add some buffer.
Also, when looking at a schedule, be sure you understand the unit of time in person-hours. I once had a manager ask why a project was taking so long, only to learn that he was comparing work I was doing by myself to a similar project that had a team of 4 developers assigned. Making a note of the number of resources assigned or listing team members individually in the plan can help you avoid this confusion.
We have probably all had at least one project where the client threw a wrench in our best laid plans. Or when there was a high priority, fast turnaround needed, so you pulled out the throttle and got it done. It’s when ADDIE became just DIE. Or worse yet IE (“ay-ee!”).
Whether a project went slower / quicker, had reduced quality or increased costs, use caution when using it as the basis of future projections.
But what if I don’t have any past project plans?
You can try to construct a plan from emails, file dates, and other artifacts. But, that’s a time consuming process. Instead, I’d recommend using one of the other methods that I’ll be presenting in the next couple posts.
Until then, it’s never too late to start keeping track of current projects so that they become data points for the future.