Why Outsourced Learning Projects Fail

For 15 years, I ran a learning solutions company. During that time, I saw projects struggle for all kinds of reasons. Do any of these feel familiar?

The executive script review: A senior stakeholder sees the first script and asks, “What exactly are we trying to accomplish with this?” The project is already in development, but the business purpose was never truly aligned.

The course becomes the content repository: Stakeholders keep adding material because “employees need to know this.” Without a clearly defined desired performance, there's no principled way to say no. A focused intervention gradually becomes a 90-minute information dump.

The vendor keeps asking for content the client thought they were creating: The client expects the vendor to “develop the content.” The vendor expects the client and SMEs to provide it. Weeks are lost waiting for materials, interviews, examples, and approvals that both sides thought the other would do.

Scope keeps growing and change orders keep coming: Each new discovery uncovers another missing component. The vendor appears to be nickel-and-diming the client with change orders; the client appears to be expanding scope. In reality, neither party understood the scope because the architecture hadn't been developed before the project was priced.

From my experience, there’s a root cause to all of these scenario: 

The client thought they were buying one thing. The vendor thought they were selling another.

And often, neither side recognized the disconnect until the project was well underway.

A client would come to us and say:

“We need a course.”

They might have a PowerPoint deck, some existing materials, and a promise that a subject matter expert would be available later.

From the client's perspective, they had provided the content. Now they needed a learning company to turn it into training.

From the vendor's perspective, they had been hired to produce a course.

The problem was that there was an enormous amount of work missing between those two points.

“We Need a Course” Isn't a Requirement

When an organization says it needs a course, it's usually describing a deliverable, not the problem it needs to solve.

Before anyone starts writing scripts or designing screens, there are much more fundamental questions to answer.

• What business outcome are we trying to influence?

• What do people need to do differently?

• What are they doing today?

• Why aren't they already doing what we want them to do?

• Do they need knowledge? Skills? Practice? Motivation? Feedback? Performance support?

• And is a course even the right answer?

Those are performance consulting and solution architecture questions.

Yet companies frequently hire a production-oriented vendor (or only contract that service) and expect those questions to somehow get answered along the way.

If you wanted to build a house, you probably wouldn't hire the construction crew first, hand them a few pictures of houses you like, introduce them to someone who knows a lot about your family, and tell them to start building.

You'd develop the architecture first.

Learning should work the same way.

If your organization has strong internal performance consulting and solution architecture capabilities, do that work before bringing in a production vendor.

If you don't, hire a partner specifically to perform that work—and make sure the people assigned to it have the competencies required.

Then hire the right specialists to bring the architecture to life.

After 15 years on the vendor side, I've come to believe that some of the biggest disappointments in outsourced learning aren't really vendor failures or client failures. They're alignment failures.