Freelance training! It was my ultimate goal. When I finally arrived in that dream world of consulting, I was in heaven. No politics, no boss, no limits. But, there is another side to this equation. This “other side” looks something like this: no support, no guidance, and no answers.

Many people do quite well in this environment. Others don’t. The case study below (which is a fictitious situation, compiled from real assignments) illustrates some of the potential pitfalls of going solo.

Overview: A case study in course development
As a course developer, you have been asked to create some technical modules to support the rollout of a new help desk department. The help desk will service both internal and external customers. When you arrive at the client’s site, you assess the situation and identify the following problems.

No baseline standards, processes, or procedures
The skill sets of those entering into training are as varied as the products they are going to support. There are no standards or protocols in place. One tech would tell customers that they didn’t support specific applications. The next tech would spend 30 minutes with a different customer troubleshooting the same software issue.

You learn that the reason for this is part of the company’s corporate culture. Management encourages techs to think outside of the box and to work with a customer in a manner that fits the tech’s personal comfort level. This, you are told, fosters a feeling of pride in work and allows each employee to seek out a professional development path best suited to his or her needs. That’s a great approach, but what about the little issue of consistency of message to the customer?

Multiple products with no documentation
OK, this may be overstating the obvious. You wouldn’t have been contracted to do the work if documentation existed. It is fair to expect a lack of documentation?

However, when I say no documentation, I mean no documentation. No blueprints or schematics of the product, no specs, no notes, no job descriptions. That is fine, because there needs to be a starting place. The best place to start is to learn about the product and the current level of support. In this case the product is fairly straightforward. But when the word “support” gets added to the composition, variations on the theme abound.

Conflicting agendas
To add the finishing touches to this case study, let’s just throw in some major organizational change for good measure. The company is at the tail end of a purchasing spree. You are hired by folks from the corporate office and asked to work with folks at one of the satellite sites. Of course, most of the employees from the satellite site were employed by another company before your Pac-Man friends at corporate decided to swallow them up. There is nothing like a strong dose of cultural clashes and mixed agendas to add to the fun of freelance training.

So, there you have it, just another day in the life of a freelance trainer. Is this a nightmare come true? No, it is business as usual. I am sure that nothing in this case study shocks or even surprises most of you. As freelance trainers, we have to be prepared for anything. After all, if the job were easy, they’d do it themselves.

Avoiding disaster
When you’re faced with a situation like this, there are several things you can do to prevent this kind of “business as usual” from becoming a disaster. Below are some tips that will help you meet your client’s expectations, and allow you to remain sane at the same time.

Establish clear expectations

  • Understand the client’s business objectives and how your training module will help to meet these objectives.
  • Agree upon timelines.
  • Determine a product format that will allow you to meet those timelines.
  • Learn to say “no.” Say it diplomatically, but say it.

Contract work in phases to ease tight timelines

  • Contract phase one to develop a beta product.
  • Contract phase two to develop a revised product, based on beta feedback.
  • Contract phase three to develop a train-the-trainer program.

Know the players

  • Identify not only your contacts, but also the people who make decisions, pay bills, and set strategies.
  • Learn the informal network and the informal leaders; get a feel for your real customers’ feelings toward the company and the training to be created.
  • When there are conflicts between corporate players and frontline players, be aware that the frontline players may be filling out your evaluation, but the corporate players are paying your bill.

Keep it simple

  • Avoid too much detail.
  • A good basic foundation that covers all material will satisfy most companies.
  • A simple product done well will lead to another contract for adding the bells and whistles.

Stay in touch

  • Send daily updates to your client.
  • Ask for ongoing feedback; correcting work before it is in final draft form is much less painful.
  • Let your client know immediately about any issues with the project.
  • Do not try to be a hero and solve problems by yourself; your solution will inevitably be the wrong one.

Pace yourself

  • Do not spend too much energy creating the perfect module, as you may need that energy for the six other modules to come.
  • Be prepared to scale back original plans as timelines draw near.

And finally…
Remember to have fun!

I know that in the end, I will hand my work over to someone else. I put long hard hours into creating my training programs, and I always feel a small sense of letdown when I give my product over to the client. I need to have something to take away to balance all the work I have just done.

Yes, there is the money, but for me there is something else. I get to meet really neat people, learn from their wisdom, and see multiple perspectives on everyday work. I try to capture all of those perspectives and bring them together into one concise set of instructions. The client gets the synthesis of all of that knowledge. I get the sum of the experiences.
Have you run screaming from a meeting room because you saw the nightmare coming down the pike looking for you? Or did it sneak up on you, quietly, three or four months into the project? Share your horror stories with us, and be sure to explain the escape route you took.