Monday, March 31, 2014

This post was originally published on the Daily Mindflash blog. Included here is the lead and a link to full post.

In any business that creates physical products, prototypes are used to show an early example of a product so people can visualize it. Inventors live by the prototype, producing early examples of inventions to test and to gather feedback. In product development, prototypes are critical so people can see what is being created. Why should eLearning be any different?

Tuesday, March 25, 2014

This post was originally published on the ServiceRocket blog. Included here is the lead and a link to full post.

In my last post, I kicked off this blog series by posing a question, “How do you know if you need to build a training function in your enterprise software business?” The question begs so many others, particularly since every company is at a different level of maturity when it comes to training (more about the levels of training maturity in a future post). Some companies have no enterprise software training at all. Others have no training, but think they do. While others are humming along offering training that customers say helps greatly with adoption.

This post was originally published on the Daily Mindflash blog. Included here is the lead and a link to full post.

For anyone who wants to be as great as they can be in a chosen field, reading books on the subject is critical to one’s development. Whenever I see a blog or article listing important books, I read the article. And more often than not, I read one or more of the books from the list. It is a key part of how I stay current in my field.

Below is a short list of books I think every eLearning designer should read. Each brings a slightly different angle to the subject, and each book can be used differently to build your eLearning and online training skills.

Thursday, March 20, 2014

I recently finished a client project writing a certification examination for an open source software development platform. It was an exciting project with an exciting and emerging start up in the San Francisco bay area. The problem was that I did not know the programming language, and I had to write test questions on it.

Good test questions.

Photo Source: http://www.sxc.hu/profile/kakaopor

Not all of the test questions were conceptual. In fact, most of the test questions, tested on the proper use of code. There was no way I could learn fast enough to write all of the test questions. So I asked for help.

At ServiceRocket, we use Confluence Questions from Atlassian. So, I posted a question (several questions) and asked our development team if they knew this technology and if they could help me write some of the questions. They did. They were happy to. It was incredible.

In no time, I had an entire exam written and the result of the project was that the client was very happy.
In a leadership meeting, our CEO shared with the team how happy he was with the project adding, "...and Bill basically outsourced his work using Confluence Questions."

I didn't know whether to be proud of this praise or worried that the CEO thought I just hang around the office all day, drinking Code 33s from Philz Coffee, while other people did my work. Either way, the work got done, and the customer was happy. This was all done because of the collaborative working environment we have....and because of the tool we used; Confluence Questions.

Side Note: I may not have known that programming language, but I do not how to write exam questions. I had a process that was guided by Bloom's Taxonomy. If you'd like to learn how I did it, comment below and we can connect in real life.

This post was originally published on the HumanCapitalist blog. Included here is the lead and a link to full post.

Recently, I wrote about how I believe the future of enterprise learning should include internal blogging The idea is that by openly sharing one’s work, much can be learned from the sharing itself and from others who see the blogs and contribute to them. In other words, people can learn through internal blogging because it is about communicating and collaborating with people anywhere in your organization.

Because I have derived direct benefits in my work through internal blogging, I have continued the practice and have begun to take it one step further. That one step further is working out loud.

Working Out Loud

The idea of working out loud was first introduced in 2010 by Bryce Williams, who describes it as the sum of observable work and narration of work. Internal blogging is the narration of work. I have begun to add the observable work to the equation by actually creating work products on documents that any one of the 140 employees at ServiceRocket can view, edit, and comment on.

Believe me, it is not easy putting a first draft of a document out there for all to see. First drafts are awful. But that is a topic for another day.

The first real observable work I worked on was a blog post for our web site.

Working in Public

In addition to my training role at ServiceRocket, I also write many of the blog posts that are published on the web site. Before my working out loud initiative, I wrote drafts of blog posts on a Google Doc, which I could then share with our marketing team after I finished. Every once in a while, I shared the “in-progress" draft with people around the company for feedback. The problem was two-fold. First, I need to have both the presence-of-mind to share my "in-progress" draft, exposing my early, awful drafts to ridicule. Second, I must know with whom to share it.

Two weeks ago, I decided to work out loud. I posted an outline (and some rough notes) as an internal blog with a lead that read, “This is a working draft for a blog post on…..” I didn’t expect much, but when I woke up the next morning, the first three paragraphs had been written by one of our consultants in our Sydney office. Wow! My post was off and running. I finished the draft and later discovered that someone else from our Palo Alto office had edited it and fixed several errors.

Working out loud works if you have the collaboration tools and are willing to stick your neck out there. You might even get better work done more quickly. I did.

My Next Project

I benefited from working out loud so much that I am continuing the practice. Currently, I am working on a speaking proposal for a conference in May. Instead of drafting my proposal in private in Evernote or Google Docs, I have written an internal blog post for everyone in my organization to see. Within one hour of posting the notes for my proposal, I have received five comments and one person has edited some of my proposed titles.

How could my proposal not be accepted now?

What examples do you have of working out loud? How has it worked for you? What reasons do you have for not working out loud?

Wednesday, March 19, 2014

This post was originally published on the ServiceRocket blog. Included here is the lead and a link to full post.

In my work, I run across this question all the time. Early to mid-stage enterprise software companies start to believe they need training, but they are not sure how to know for sure or what it looks like to get started building a software training department. In fact, I just had this conversation with a potential customer discussing how to know when to get started and whether they need a learning management system (LMS). Of course, I directed them to this series.

Although each enterprise software company is in a different stage of training maturity with unique customer needs, there will be different reasons for developing enterprise software training. This series is designed to address all of those reasons and to answer the following, you know you need to build an enterprise software training function if:

Tuesday, March 18, 2014

This post was originally published on the Daily Mindflash blog. Included here is the lead and a link to full post.
The online training industry is flooded with articles and blog posts about future trends that focus on far fetched fantasies attainable only to those with discretionary budgets and/or niche needs. These trends generally include topics like gamification, the xAPI, and wearables to name a few. But for most of us, these are not practical trends we will implement any time soon.

These trends may one day be as ubiquitous as claimed, but if you are a one or a two-person training department creating and delivering training for an audience of 2,000 employees, you unlikely have the time or budget to implement a gamification strategy or figure out how Google Glass will help your field operations team.

Monday, March 17, 2014

This post was originally published on the ServiceRocket blog. Included here is the lead and a link to full post.
Most startups fail. In fact, 90% of new businesses fail. In his Monktoberfest 2013 talk, Zack Urlocker cites research that shows 74% of the startups that fail, fail because they attempt to scale too soon. In other words, these startups believed they were gaining traction and began to invest heavily to capitalize on that traction.

The problem is that the startups that fail are either too soon or were wrong about the traction. Either way, the result is that these startups spent more money than they had, did not earn the revenues necessary to support the spending, and they failed. It turns out, the process of scaling a business takes longer than most people think.

Friday, March 7, 2014

This post was originally published on the HumanCapitalist blog. Included here is the lead and a link to full post.

When it comes to discussing the role of social media in large enterprises, many HR managers today remain oddly fixated on creating and enforcing social media policies and determining the right sorts of internal penal codes for violations. I don’t know about you, but I’m not a fan of punitive policies that seem to be designed specifically to catch people doing something that people who created the policy do not approve of. The irony, of course, is that the vast majority of people who work in these organizations will never do anything on social media that will reflect poorly on the company.