As someone who works on teams, I often think about the characteristics and attributes that would make up the perfect team—an eLearning dream team. No matter the group that I come up with though, there is always a potential problem or two. Sometimes these problems have less to do with specific team members and more to do with the team make-up. This issue makes creating a perfect team a difficult endeavor.

In this article, I offer my thoughts on various combinations of background and experience that team members typically present. I also offer an analysis of the strengths and challenges inherent in these individual combinations, and the kind of development projects where each will do best. I believe that if the project manager has the opportunity to match team members to project characteristics, this will help to create “the perfect team.”

Over-schooled team members

When building a team there is a natural tendency to want the brightest and most up-to-date players for each role. Luckily, this is easy to do as we work in a field that is heavy on the credentialing side; that is, there is a lot of formal education available for our typical eLearning project roles. A project manager, for example, might possess a project management professional (PMP) certification. An instructional designer (ID) might have a formal degree in instructional design. And, for programmers, holding a computer science degree indicates a person who should be able to build anything. Using these credentials as a guide should help you build a team that is versed in the latest and greatest methodologies for each position.

However, this can create a false sense of security; there is a significant danger when a team consists of these certified, credentialed individuals. Each of these specialists will tend to default to specific defined methods and processes. Such mechanisms make sense as they reduce risk, but in doing so, they may discourage innovation and personalization.

I experienced this situation on a previous team. For each project, I used a 20-point rubric, a 10-point design checklist, and a style guide to direct my activities. Before I started my work, a project manager (PM) would have already established other design parameters by using scheduling templates and estimation sheets to scope each project. We based these schedules and estimates on existing course engines and completed modules.

Following this system, the team was able to produce quality content; however, it was generally the same package repeatedly. In other words, every project started out as a unique training need but slowly stopped being unique as these tools and templates came into play. Our processes and tools, rather than the true needs of the training, drove our solutions.


Fortunately, not all of our formally schooled colleagues follow the strict science of their respective fields. They may be aware of the latest and greatest methodologies, but they will pick and choose the parts that make sense to them and their projects. These team members will approach each project as unique, and work to ensure that they highlight actual skill or knowledge or performance need throughout the development cycle. You may think that these self-schooled folks would make up the ideal team, but they have blind spots as well.

A recent experience highlights a particular danger that can appear when a team is heavy with self-schooled members. In this case, I was working on a course and needed to come up with an exercise on burn estimation. My initial thought was to develop an interaction that created random images of burn patients—users would then perform their estimations on these images. This activity would be appropriate, engaging, and provide endless opportunities for practice; however, getting it to work would require advanced programming time.

Unfortunately, time wasn’t something that we had on this project—we needed to move quickly, so we went with an alternate solution. A team composed entirely of self-schooled folks might not have seen this need and would have proceeded with the original interaction. Doing so would have blown up the project schedule and increased the final cost of the product. These outcomes would be detrimental to the success of any project.


A reality about our teams is that we rarely get to pick them—often we inherit existing teams. When this happens we have to manage as best as we can. This can be tough, as these teams probably have people on them who lack knowledge about the latest and greatest methodologies. These team members generally fall into one of two schools.

Different schools

Many of the people on our teams have simply “fallen into” our field; that is, years back someone assigned them to an eLearning initiative—and they never left. Common examples of this are the stand-up trainers and subject matter experts who helped out on an eLearning activity. Those that did a good job slowly became part of our teams as IDs and PMs on our projects. Additionally, many of our programmers came in from different roles. So a graphic artist or a technical writer who showed some programming skills or demonstrated proficiency in a course-building tool may have become our programmer over time.

This lack of formal training, in itself, isn’t bad, as there are benefits associated with these previous roles. For instance, having subject expertise can be valuable in scoping and content development activities. In addition, skills such as graphic design can come in handy as projects move forward. The danger with these types of teams is that they have the potential to become outdated and stay tied to old technologies and strategies.

I saw a recent case of this when a business problem was mistakenly identified as a training need instead of a performance issue. What followed was the development of an online training course rather than implementation of a performance support application. In this case, the online course turned out great, but the ID on the project—a former SME—didn’t have the formal background in needs analysis and problem identification to see the performance support opportunity. This opportunity and solution would have cut the cost of the training, reduced errors associated to that on-the-job activity, and increased productivity for that task.

”Old School”

It’s unfortunate, but some people on our teams choose to check out. They finish their degree, certifications, or other training, and then stop updating their knowledge within the field. Having a team like this is dangerous, as our field is always changing. To ensure the identification and execution of appropriate solutions, a team needs to continually update its knowledge of technologies, strategies, and methods.

This concern is especially relevant today as we are in a rapidly evolving environment containing games, mobile, informal learning, alternate reality, and other technologies that were only theoretical options several years ago. Today, not only are they becoming practical options, they are increasingly expected.

Perfect projects

Often, under-schooled members may seem like weak links in need of replacement. I disagree with this assessment. Many of our projects require widget building and rapid response. These types of projects are a good fit for under-schooled members, as they call for some of the strengths of these persons (efficiencies gained from their previous roles and an appreciation of a standard technology and/or approach), while minimizing the effects of their weakness (lack of a broad knowledge in the field). In addition, most of our team members are trainable, and as new needs and solutions come up their range of work will expand as well.

This concept applies to all team members; that is, there are projects that match their strengths, and it’s these types of projects that you should direct their way. By following this philosophy you no longer need to build a perfect team—the eLearning dream team. Instead, you have team members that you can assign to projects that will be perfect for them.

Table 1 may help you get started in this pursuit.

Table 1. Matching team members to their perfect projects
Description Strengths Weaknesses Types of Project


These people have formal training.

Know latest and greatest methodologies.

Reliance on process and templates can interfere with innovation. They may miss the true training needs of your projects.

Projects that have some existing foundation and projects where you need to limit risk.


These people have formal training but choose to follow their own set of rules and guides.

Know latest and greatest methodologies.

Disdain of process and templates can cause them to skip steps. Also, they may miss efficiencies by trying to reproduce the wheel with every project.

Projects that require innovation or personalization, and ones that don’t have extensive foundations.

Under-schooled: Old school

These people have formal training, but haven’t kept up with recent advances.

Knowledge on a set of technologies, strategies, and solutions.

Lack of recent field knowledge can cause them to stick to old and dated strategies, technologies, and solutions.

Cookie-cutter projects composed of widgets and other rapid-response solutions.

Under-schooled: Different school

These people lack formal training in this field, but often come from a related area (SME, editor, graphic artist, etc.).

Fresh perspective and added efficiencies in your projects.

Lack of knowledge can cause them to force inappropriate and dated strategies, technologies, and solutions.

Cookie-cutter projects composed of widgets and other rapid-response solutions.