Blogs

I was reminded last week while presenting several sessions at SPTechCon Boston how easy it is for those of us "experts" who work with SharePoint and similar platforms day after day that not everyone moves at our same pace. There are always one or two people who approach me after a session, asking me to expand on one of the concepts I sped through within my presentation, thinking it was common knowledge for the vast majority. Even a 60 or 70-minute session seems to rush by with all of the content that I think people want and need to know about, mixed with questions from the audience. And yet people inevitably come back and ask questions about the things that I label "Project Management 101" or 'Fundamental SharePoint knowledge."

No matter how much you prepare for your session at a conference, or for an internal training class, people simply move at different speeds. We do out best to set expectations, to identify who is in the audience and what they want to get out of the content. I even have a running joke, where at the beginning of my slides I invite people to leave -- explaining exactly what I plan to cover, what topics or examples I will NOT be covering, and then giving them ample opportunity to get up and leave if its not what they wanted. Kind of like the flight attendant reminding passengers a few times, before the outside door is closed, of the intended destination -- just in case someone boarded the wrong airplane.

I think we all inherently "get it" that audience and content are two critical steps in planning out your training strategy, but I thought it would be useful to share a few more ideas, or "best practices," around training.

1. Know your audience.
   Are they end users, IT pros, developers, or executives? Do they have years of experience on a similar platform, or an earlier version of your system? For example, I would train a new SharePoint 2013 user differently than I would someone with extensive experience on, say, the 2007 version. Understand commonalities in how they will use the platform, their critical scenarios, and the business processes that they own and are measured against.

2. Be clear on what content you will share.
   Will the content be based on case studies, working demos, or will it be purely future-looking and visionary? What topics will you cover -- and which topics will you exclude? If you plan to cover content that spans different user personas (your end user roles), make sure you let your audience know when the content moves from one persona to the next, so that people can put what you teach into content for their own role.
   
   

3. Make sure your content is up to date.
   On which version did you develop your demos, and what has changed since then? What new content is out there, what new partner solutions, what competitive platforms? In this age of online-first, agile development methodologies, your training material must include the latest and greatest details about your platform. Hopefully the examples you use in your training are, to some degree, relevant across multiple versions -- but there's nothing wrong with providing addendums and relevant links to additional reading and research.
   
   
4. Consider your delivery options.
   Will the content be delivered by lecture, through hands-on labs, individual study, or group projects? Research shows that most people tend to retain more when learning content through multiple delivery mechanisms -- for example, a combination of lecture and group project work. Different people learn in different ways. Whenever possible, provide different paths for your end users toward a common end point.
   
   
5. Don't forget to entertain.
   Did people fall asleep in your session, or was the response slightly more enthusiastic? Even the most compelling content can come off as dry and uninteresting if not delivered with passion and creativity. Most of us have experienced a classroom setting where the instructor simply read through the material already in front of each student. You don't need to hire a standup comedian to deliver your technical training -- but the best trainers are often those who can keep people interested no matter what the topic.
   
   

Some of the best executed, and most memorable training courses I ever took were because the instructor took each of these areas into consideration. I remember sitting in a Unix class for a week in downtown San Francisco that was fantastic. Now, almost 20 years later, I can't say that I've retained much from that class (haven't touched Unix since the 90's), nor do I remember the instructor's name, but I do remember how prepared he was, that his content was well-prepared and included relevant links and supporting materials, it was delivered through a mix of presentation, problem solving, and both individual and group activities -- and most of all, I remember that he was engaging and funny. I made friends in that class, and in turn, recommended the class to several of my teammates.

Training is, in my mind, an extension of your platform's user experience. You may have the most wonderfully designed and intuitive interface, but a poor user experience by sub-par training (or, in most cases, no training at all) and you could limit the potential of your deployment by squashing enthusiasm in your end users before they even officially start.

Take the time to develop a training strategy that sets your systems up for success.