Magento 1.3 Sales Tactics is Published

My new book, Magento 1.3 Sales Tactics, has just been published by Packt Publishing. My goal for this book is to help you solve real-world Magento sales problems with some simple, effective recipes. You can read a sample chapter on the publisher's website. It's too new for any reviews yet, but the CEO of Magento recently received a copy, and I'm eager to know what he thinks of it.

Review of Magento Beginner's Guide

MilkYourMoney.com is "a daily blog dedicated to helping its readers reach their financial goals." They just reviewed the Magento Beginner's Guide. I thought the review is thorough and fair. Check out the review and my comments here.

Magento Beginner's Guide versus Magento User's Guide

The company behind Magento, Varien, recently published their own Magento User Guide. This is a few months after Packt Publishing released my Magento Beginner's Guide. If you're looking for a book to help you use Magento, you might want to know how Varien's book and mine compare. I'll try to answer that question for you in a way that enables you to decide which book is better for your needs.

Is there really a difference between a Beginner's Guide and a User Guide?

After 20 years as a technical writer and trainer, I have come to the conclusion that yes, you will notice a difference between a Beginner's Guide and a User Guide. The differences are in the scope and flow of the book. And I think you will see those differences between Magento User Guide and Magento Beginner's Guide.

Scope: Reference Librarian versus Coach

If you read the User Guide table of contents, and the Beginner's Guide table of contents, you can see that the User Guide covers more of Magento's functions. Yet, it has fewer pages. It covers more features than the Beginner's Guide, but usually with less detail.

In the Beginner's Guide, the step-by-step directions are usually more detailed than those in the User Guide. And, the Beginner's Guide includes some business intelligence. That is, not just how to use a feature, but also when and why.

If the books were people, the User Guide would be a reference librarian and the Beginner's Guide would be a coach.

Flow: Jump In and Out, or Go For a Ride

Both books work as reference material. The User Guide usually gives you just enough information to make a function or feature work. It answers the question, "How do I do this?" and then returns you to your work.

The Beginner's Guide tells you how to use Magento's basic functions while building an example store. The example runs through the book. So you will see not only how each function is used, but also when and why it is used, and what effect it has on your customer's experience. You can work through the book from front to back if you want to follow the example. Or, you can use it as a reference guide.

So which do I recommend?

Neither. I recommend that you consider your own situation. Do you prefer a reference guide, like the one supplied by the official Magento Online User Guide or Knowledge Base? Or do you prefer a step-by-step Beginner's Guide to coach you through building your store? You might find them both useful: the Beginner's Guide to show you how to create and run the store, and the User Guide to provide a quick reference for many of Magento's features.

You can read sample chapters for the books at magentocommerce.com and packtpub.com.

You can read reviews of the Beginner's Guide at Andi J's blog and the Milk Your Money site. It's available for sale at Amazon.

Do your research, dive in, and let me know how it goes!

Sample Chapter and Extract from Magento Beginner's Guide

Packt has published my latest book, Magento Beginner's Guide. They offer a sample chapter on their website, "Categories and Attributes." They also took a section out of a chapter and published it as an article on their website, "Creating Tax Rules in Magento."

The sample chapter, article, and chapter descriptions on their website should give you an accurate and thorough impression of the book's style and content. If you're a Magento user, check it out. And if you've bought the book, as always, I like to hear from my readers. Send me compliments and complaints by clicking on the email link in my profile.

Developing an Online Course in Moodle as Quickly as Possible

I had a reader send me a question about how to estimate the time it will take to develop a course in Moodle. I'd like to share her question and my answer with you. As always, your comments and experiences are welcome.

Her Question:

I am just about to embark on my masters dissertation project, and am looking a web-based tutorials for teaching. At the moment I’m considering putting together a tutorial as part of the project using moodle (I have copies of your books in front of me now).

One question I cannot seem to find an answer to, is realistically how long would it take for me to construct something like this? I have seen reports stating that construction of online courses can take up to 18 months, but I think these were from scratch as opposed to using a software programme such as moodle. I am fairly Internet literate, and have created basic webpages before, but have never done anything like construct my own online course.

I am studying via distance learning and also have a full-time job. I have between now and June/July to work on my project (including analysis and user-testing, etc) – do you think this is something which I can realistically achieve in this kind of time frame?

My Answer:

In my experience, the old methods of determining how long it takes to develop courseware were never very accurate. With the variety of tools available to us today, the many different situations, and the many different expectations from learners and stakeholders, those old recommendations are even more inaccurate.

I no longer ask, "How long will this take me to develop?" Instead I ask, "How long before the client needs it?" And then I determine what I can do between now and then. It sounds to me like you have a few hours a week to spend on developing an online course, between now and June. That's not much time. So instead of dwelling upon how long it will take, let's talk about how to maximize your output in the time that you do have.

First, try to get out of installing Moodle yourself. If you can use an outside hosting service, find one that has a one-click install for Moodle. If you must use your organization's web server, try to get the web admin to install it for you. When Moodle installs without trouble, the installation goes quickly. When it gives trouble, you can spend hours tracking down the problem. If you pay a few dollars a month for a hosting service that will install Moodle for you, I advise it.

Second, resolve to stay within Moodle's built-in capabilities. Some of the add-on modules add great functionality. But for a project working against time constaints, I advise you stick with Moodle's built-in functionality and not get bogged down in trying to get add-ons to work.

Third, make as much use of existing material as possible. As a librarian, I'm sure you can locate web pages that you can use as course material. I think there's nothing wrong with a course whose learning material consists entirely of links to external web pages, video, and audio. For example, if I was teaching a course on public speaking, I might link to a funny Youtube video of public speaking bloopers, tips from Toastmasters, and famous speeches. Creating your own multimedia takes especially long, so I would search Creative Commons for media I could use in my course.

Fourth, I would try to use Moodle's built-in Web page editor (Web page Resource) to write a short description of each resource that I link to, and what I want the students to pay attention to while viewing it, and what I'd like them to get out of it. To ensure that they read this before going to the resource, I would put the link to the resource on this web page instead of on the course's home page. Then, the students would need to go through the web page that I write before clicking through to the external web page/video/audio.

Fifth, I would follow up each reading/viewing/listening resource with an activity created in Moodle. For example, I might ask the students to:

1. contribute to an online discussion, and to rate other students' postings in that forum. (Forum activity)


2. take a short quiz on the material (Quiz module)


3. write a summary of the material and upload it (Assignment activity)


4. record a snippet of speech and upload it (Assignment or Workshop activities).

Sixth, I would use outside services for things that Moodle doesn't handle, or that it handles only with plug-ins. For example, after the students have completed viewing the resources and doing the follow-up activities, just before an exam, I might schedule a summary lecture with WebEx or GoToMeeting. The lecture could include a slide show of the material that will be on the final exam, whiteboarding, and chat. If possible, I would record the session and offer it to the students as a download.

Seventh, I would offer an online exam open only at a given time, to ensure that students don't take the exam and pass along the answers.

That would be my model for rapid development of an online course. And if I could, I would choose a topic for that course based upon the amount of good material freely available online.

Estimating the time to create a training course

The Question

I received this email asking how to estimate the time it takes to create a software training course:

Hello,

I have a strong background in software development and training development and delivery. My training has always been around soft skills, business processes, and employee orientations.

I recently joined a software company as the Training Manager and I’ve been tasked with “figure out how we should do user training for our product”. I’ve purchased and read your book, User Training for Busy Programmers and it’s been very helpful already in translating my current knowledge of software development and non-software training into what I need to do for software user training.

I was wondering if you have any thoughts or resources around estimating the time it takes to develop user training following the process you outline in the book?

Thank you,

Jennifer

The (somewhat disappointing) Answer

Here's my reply:

Jennifer,

Years ago I asked this question on several of the most popular training and technical writing mailing lists. I also tried equating the time it took to develop training and documentation to things like function point counting, number of screens, number of keystrokes and clicks. None of it worked.

Seriously. The conclusion I arrived at is that there is way to predict the time to develop training and documentation, that is more accurate than your own experience.

Since you have experience developing training in business processes, you're not far off from being able to accurately estimate time to develop training for software. Because at the end of the day, a software class is (or should be) nothing more than a business process class that features a new tool. So when you're trying to estimate development and delivery time for a software class, ask yourself how long it would take to develop and deliver the class if you approached it as teaching a new business process, which just happens to use a new tool.

Sorry I couldn't give a more concrete answer. This is a question the continually challenges me, and I'd be happy to hear of any resources you find that help with it.

Regards,

William Rice

A Plea for Help

I want to hear what you have to say about estimating the time it takes to develop a software training class. Do you have any objective, quantitative methods that work for you? Or like me, must you rely on intuition and experience? How accurate are your estimates?

This topic is ripe for conversation. Leave a comment, and keep the dialog moving!

Book Review: Training for Software Rollouts

When a book on software training begins with the political issues of selling the training program to management and users, it's a sign that the author has real-world experience. As a training professional who's read too many books that take an academic approach to training, I appreciated the practical approach in Training for Software Rollouts: The Definitive Guide to Developing and Implementing Software Training Programs.

Charles H. Trepper's 480-page book is a comprehensive and accessible guide for IT managers and training professionals. Following the methodology in this book probably won't save you time compare to the seat-of-the-pants, ad-hoc method I've seen at many companies. However, the discipline and thoroughness of Trepper's method ensures better results for the time you invest.

Trepper takes a conservative approach, and bases his method on Instructional Systems Design (IDS), which consists of five phases:

1. Analyze
2. Design
3. Develop
4. Implement
5. Evaluate.

Trepper adds his own experience in company-wide software rollouts to the IDS method. For example, he covers Political and Organizational Issues in Chapter 1, which is probably worth the price of the book alone. He then moves on to the Analyze phase of IDS, with Chapter 2, How to Conduct a Training Needs Analysis.

Chapters 3 and 4 cover the Design phase of IDS. Some topics that only an experienced trainer could add are 3.4 Getting funding--where does all the money come from? and 3.7 Avoiding training budget cuts.

Chapters 5 through 8 cover the Develop phase, when the actual training materials are constructed. These are some of my favorite chapters.

Chapter 5, Self-Directed Training versus Classroom Training, helps you decide between classroom, self-study, and live distance learning. It ends with a brief discussion on combining these methods, 5.5 Combining methods for maximum effectiveness and efficiency. In the training profession we call this blended learning. If you decide to go this route, you'll probably want to learn more strategies for mixing learning modes than this section provides.

Chapter 6, Make or Buy--Purchasing Training versus Developing and Delivering Training In House, helps you make this important decision. Trepper points out that

It is reasonable to assume that some training professionals, in an effort to perpetuate their usefulness, may present a barrier to the outsourcing option.

This resistance is not only futile, but also counterproductive. As Trepper briefly states, "the role of training professionals within corporate environments is changing." The profession is seeing a shift from training to performance consulting, and trainers who don't get with this program are going to be left behind.

Chapters 7 and 8, Purchasing Training and Customizing Packaged Training to Meet the Needs of Your Organization, finish the Develop phase. Chapter 8 is notable because I have not seen any other training books offer guidance on how to customize purchased material. Don't expect detailed step-by-step directions on how to deconstruct a Flash-based training module. The situations are too varied. The advice is useful, but necessarily broad.

Chapters 9 through 11 cover the Implement phase of IDS. Chapter 9, Implementing the Training Program, makes you aware of administrative needs such as Tracking attendance, Maintaining Courseware, and Monitoring and Logging Training. However, it doesn't offer detailed solutions. For a more thorough treatment, you might want to check out The Trainer's Support Handbook by Jean Barbazette (disclosure: I get credit from Amazon when you buy through that link).

Chapter 10, Communicating the Training Rollout to the Organization, discusses employee resistance to training and how to deal with the resistance. This is the only training book I've seen that deals with this crucial topic. I think this topic is worth more than 12 pages, and if I could ask Mr. Trepper to expand any one chapter this would be it. He talks briefly about determining the "real resistance reasons" to training, but doesn't tell us how to do that. Even a few examples of these reasons would be very helpful. For example, I've found that employees often resist training because:

• They're afraid that efficiencies created by the new system will result in their jobs being eliminated.

• They are the only ones who can do their jobs well, and the new system might make their jobs easy enough (or appear easy enough) for almost anyone to do.

• They believe that the new system will take just as long as the present system, but management will still require more productivity to justify the new system.

• Their managers will require them to do the same volume of work even while they're taking time out to attend training.

• Previous, unsuccessful software rollouts make them cynical about this rollout's chance of success.

Chapter 11, Tips for the Trainer, gives some valuable advice for first-time trainers. The tips are general enough that they apply to almost every training situation. For more information about software training techniques, a good beginner's book is The Accidental Trainer : You Know Computers, So They Want You to Teach Everyone Else (yep, another Amazon Affiliate link).

Trepper devotes a few paragraphs to dealing with difficult students. If you want a more tips on dealing with hostile audiences, take a look at my article Surviving a Difficult Presentation: Techniques for Handling a Hostile Audience.

The Evaluate phase is covered in Chapter 12, Measuring Training Success by Measuring On-the-Job Trainee Performance. Trepper explains Kirkpatrick's Four Levels of Evaluation, which is the most popular and widely-accepted model. The four levels of measurement are:

1. The students' reaction to the training. Did they like it? Did they think it was clear?
2. The learning that took place. Did the students learn the material?
3. The transfer of the learning to the job. Can the students apply the learning on the job?
4. The result of the training on the organization. We also call this the Return on Investment, or ROI.

The ultimate goal here is to determine if, and how much, training has supported organizational goals. It's a big topic, but this chapter is densely packed and gives you enough information to evaluate your training program's effectiveness and return on investment.

One of my favorite pieces of advice in this chapter could come only from someone who has learned the hard way. Trepper writes about the difficulty of measuring the effect that training has on an employee's performance. He defines "results" as things the employee produces and that can be quantified: a completed widget, a completed support call, a discharged patient, a resolved customer complaint. He then defines "behavior" as something the employee does, without producing something that can be quantified: clean a room, give a massage, serve a diner. Results are easy to measure. But what about behaviors?

...begin by measuring results and only measure behavior when you have to. Most people try to identify the results of a position by listing its responsibilities and asking what product each activity generates. This process can take several hours and usually ends up with a very long list of results. A faster and better method involves identifying your customers and what you provide to them. This produces a list of key performance indicators.

In other words, to evaluate the bottom-line effectiveness of your training program, determine what effect it had on your customers' experience.

Chapter 13 covers Training the I/T Staff. I know many techies will appreciate this chapter, because I/T staff are often left out of training plans. The assumption is that training is for users, and techies can get what they need to know from the manuals and hacking around with the software. This is far from the truth, as Trepper adequately demonstrates in this chapter.

I've been called in several times to develop and deliver training for software that has already been rolled out. In Chapter 14, Trepper acknowledges that

..."training is not always at the top of the corporate priority list. Often training is developed casually as the software is rolled out."

The title of this chapter, Training Issues After a Software Rollout, talks about training issues when no training has been done, and when training was done with the rollout and now needs to be updated. Like Chapters 8 and 10, I've not seen any other training books deal specifically with this topic. And once again, I'd like even more of Mr. Trepper's valuable advice on this topic.

Chapters 1 through 14 comprise part one of the book, Designing, Developing, and Implementing a Software Training Program for Your Organization. Chapters 15 through 19 comprise part two, Application-Specific Training Issues. The applications covered are:

• MS Office
• Windows
• Lotus Notes
• SAP
• Oracle.

Each chapter covers some key training points for the application, potential problems, how to customize training for that application, and buying advice for training services and materials. These chapters are short but the advice is very targeted. For example, Trepper advises

Organizations often think they "know" Oracle because they possess the database. However, they fail to realize that the applications will probably be customized as much as the database.

Appendix A is the shortest of the seven appendices at only four pages. Trepper covers Rapid Development for Small Projects. I've spent at least half of my fifteen-year career rapidly developing small training programs, and I found Trepper's advice to be solid. For example, he states that

Designing the [training] program and custom-developing training can be done almost simultaneously...

This is often the case; an experience training developer will design and prototype the training program at the same time. Trepper includes a table of small-project steps and deliverables. This chapter, plus the guidance given in part one of the book, will serve you well if you need to rapidly develop a small training project. For a more focused treatment of rapid training development, you might want to look at my book User Training for Busy Programmers. It doesn't deal with the broader issues of a rollout like Trepper's book, but does offer a plan for non-trainers called upon to quickly develop end-user training.

Appendix B consists of Training Team Job Descriptions. Even if your team has been selected and everyone has their assignments, I recommend reading this chapter. Looking at the Principal Accountabilities given for each position may result in an "Aha!" moment when you realize that you left a task or area of responsibility unassigned.

Appendices C through G are hardcopy of sample materials that can be downloaded from the McGraw-Hill website:

• Appendix C: Sample Training Sales Presentation
• Appendix D: Sample Training Program Plan Outline
• Appendix E: RFP Outline and Completed Sample
• Appendix F: Training Program Process Checklists
• Appendix G: Sample Forms

These forms are in Microsoft Word format. Original purchasers of the book are permitted to download and customize the forms for their use.

At first glance, it would seem to be this book's focus that makes it uniquely useful. There are few books about training for software rollouts. However, after reading it, I realized that it's not the topic but the author's insight that makes this book unique. About three-fourths of the information in this book is standard Instructional Systems Design, customized for a software rollout. The other one-fourth consists of advice and insight that only someone with experience can offer. This is where the book most differentiates itself. If you're an experienced trainer, Trepper's insight can save you hours of work. If you're a non-trainer tasked with managing a company-wide software training effort, consider supplementing this book with some of the others I recommended, or with books from the American Society for Training and Development. Either way, this book is an investment that will pay off in a smoother software rollout.