Avoiding Revision Hell: Mo' Versions Mo' Problems

Thank you for allowing me a modified Notorious B.I.G. quote. I've been wanting to do that for quite some time. Also, today's the first day of a new font! Let's hope it makes my blog a little less stodgy, and a little more readable!

Let's talk about changes in documentation. The process of handling change documentation is a pretty wide and multi-headed beast. And with these kinds of hydras, it's really best to tackle one head at a time. I'll address some basics today, in the hope that it will spur inspiration on how to handle change for your own organization!

Version Control

I worked with a small e-learning shop that liked to store all the resources for all its projects in one place. Subdivided by client and project directories, it was a great way to organize. I was tasked with an update to an existing e-learning solution, changing some content to reflect changes in goverment regulations. I pulled the resources, sat down with a developer and made the changes. Go-live went smoothly and without issue.

The client called, six hours later, utterly mystified. The module didn't look the same, feel the same, have the same branding or language. How did small changes make such a difference?

After some investigation, the question was refined to: "Karim, how did you make changes to a six-year-old version of the module that no longer exists?!"

The short answer: Version Control

In its most basic form, version control is simply a way to identify changes to a project-critical document, track them, and stay updated. Think of a grocery list stuck on your fridge. Always updated, you know where it is, and it's easy reference for anyone who is taking on the task. 

If you're going to use version controls on your documents, here are some things you should know:

Use the Track Changes Function

If you haven’t already used it, the Track Changes function in Microsoft Word, as well as the Comments function, is a great way to see changes made in a document by different people, as well as insert comments for what needs to be done. Turn this on before every document you send to a client so you can more easily understand what changes have been made, and use comments to ask for clarification in areas. This will also allow you to accept/remove old changes from a document, and keep a loose track of when changes were made

 

 Keep a Change Log

Avoiding Revision Hell is all about keeping organized and staying that way. Using an Excel spreadsheet for every document, list substantive changes you’ve made (i.e. changes in branding, images, and content). This will help you see at-a-glance any issues as they arise, and will allow you to proactively address projects that may be slipping into excessive revisions before you have to play catch up! 

 

Version Naming

Changes should always be reflected in the document naming convention. If you've made global changes (Anything that affects page numbering scheme of the document, document style templates, images, or branding), you should create a new version. Old versions should be stored, and entries in the change log should have a distinct reference to the version number.

How you name your files is up to you, but you can't go wrong with a classic:

Descriptive Name - Date revised + Initials of last revisor  - Version Number.


I hope I have helped at least some of you to implement some changes to your practice that will save you a lot of time and aggravation in the future!

Has this raised any questions for you? Are there any tips or experience you'd like to share in avoiding endless revisions?  

As always, feedback and comments are welcome, and you can find me on twitter @LnDGuru. Let's start a conversation!

Avoiding Revision Hell: The Importance of Communication!

 Communication.


Definitely a word that can jitter even the most steadfast of souls. 28% of Americans rank Public Speaking as their number one fear, according to the Chapman University Survey on American Fears (Now THAT'S a title to stick with you!)

Communication with your clients doesn't have to be as fear-inducing. E-mails, phone calls, and even how you carry yourself in meetings - If you're reading this, chances are that you're not sure how to start communicating with clients or stakeholders: There's no single best way to do it, there's just the one that fits best with you!

As an Instructional Designer, the biggest part of communication in my work is about establishing relationships and respecting boundaries. 

How much leeway are you willing to give clients, stakeholders, and SMEs in your process of instructional design? No matter how much you decide, make sure the client knows. And make sure they know in no uncertain terms: Contracts, documentation, e-mails, and repeated messaging in meetings. Whatever works, or however you feel comfortable, establish boundaries now so that you won't regret it later!

I worked with a company whose SMEs were serially unable to understand the difference between nice-to-have and need-to-know. 

“Some of this technology is STILL in the field!” they’d cry, “What happens if someone doesn’t know about it!?”

 “They have e-mail, don’t they? Google’s also a big thing, from what I hear. I think that with the number of experienced guys in the field, it won’t be too hard”.

  Along with asking them a few other basic prioritizing questions, the truth was teased out, and I was able to provide a firm timeline with a two-week content block window – Two weeks before delivery, no new content could be introduced. That meant no revised images, text, or content. It forced a wholesale rethink of what could be done in the time they had, and what needed to be thrown out.

As we can see, more communication will inevitably help you. Don't be afraid to ask the questions that get you odd looks around the table, as long as you know what you need!

 Earlier I talked about changes to the alpha, beta, and final revisions of a project. Communication here is key, because you need to decide what constitutes “enough” change as opposed to “too much”. If you send a beta version of a document or project to a client and find that 50% of the version needs changes, is that too many? What about 25%?

 What do you do if that’s the case? From the outset, you want to point these things out to the client.

If you’re freelance, you can charge for what’s called a “Change Order” that lists the scope and number of alterations, because the scope of the project has significantly changed. The client needs to sign off on this change order, and will likely change their minds once they know this.
 If you’re within an organization, point out at the beginning that changes past a certain percentage of the project will require revised timelines that may push back completion significantly, incur extra costs, and require signoff.

Many of the people I've worked with as IDs are uncomfortable with "hard" communication with clients. Whether that's saying 'no', or requesting extra time or informing them of higher costs. "I don't like confrontation" is something I hear too often as a result: I can't tell you how to start communicating better, but it's amazing how quickly that phrase disappears from their vocabulary once they start losing money!

If you can't bring yourself to make the hard communications, try practicing first. Put a script down on paper, or look in the mirror and start running through the key points of what you need to say to your client. Even if you're uncomfortable, getting into autopilot when you're in that meeting or that phone call will definitely help you to represent yourself better!

No matter whether it's e-mail, over the phone, via webchat or face-to-face, communication is critical not only for your bottom line, but for your sanity as well as that of your clients! 


As always, feedback and comments are welcome, and you can find me on twitter @LnDGuru. Let's start a conversation!

Endless Revisions: The Bane of an Instructional Designer

Today’s blog is directed more towards those who are freelance designers, and everyone who has to work in client- or stakeholder-facing positions, but it’s fair to say everyone’s experienced it, and it’s called Revision Hell. You know the phenomenon: Storyboards, templates, modules, and all kinds of deliverables go through a revision process allowing stakeholders to make edits and changes.

 This spirals quickly out of control, ballooning from one or two people making content edits to senior vice presidents making tweaks to words like ‘or’, and ‘the’, because “it needs to fit the corporate vision”. Pretty soon, you’re at “Revision 13b3”, with no end in sight, and not enough coffee in the world to fix things.

Let’s take a look at some strategies to stop your projects spinning off into Revision Hell.

Setting Expectations 
This one is tough to do from the outset unless you’ve done it before. First, you need to know who will have touch with the document at what stage? Are Senior VPs going to be involved from the start, or is it just one or two people? What kind of changes will they be able to/allowed to make? Once you know, make sure to stay in contact with your stakeholders to explain what changes need to be made, and what changes they should avoid making – Try attaching a checklist of things to look for with every revision.

You need to let your clients know from the start of the project how your revision plan is going to work. I find that three revisions (In ascending order of magnitude) is the most effective method:

 1) Alpha - In this first revision, the course is between 20-50% complete. In a storyboard, various sections have been outlined, some have been filled in, and there are notes about what will come next, and what content still needs to be provided. In any application, the alpha should show the bare-bones of the finished product, including what information will be covered and how, and what information is missing. The client should provide feedback within a specified timeframe that will allow you to proceed

2) Beta - The project is 80% done, and the client can make changes to wording, images, and content. With facilitation guides and job aids, split the work into categories – Audio, video, images, content, text. Aim for an 80% completion rate for each so that you can get critical feedback to implement. Remember to always document feedback, deliverables, and delivery dates

3) Final - In the final stage, the client is only allowed to touch final wording and narration, correct any spelling, or provide final updated information. This stage immediately precedes sign-off.
This cycle tends to work pretty well for me, and as long as the client sticks to it, we’re both generally happy with the work that gets done.

Just remember that at every stage of the process, ping the client with reminders at the end of every week and a few days before any milestones to make sure they’re on track

Next time, I'll discuss how to set boundaries - Or, how you can say no to endless changes!

As always, feedback and comments are welcome. You can find me on twitter @LnDGuru, or check out my LinkedIn profile at https://ca.linkedin.com/in/thelearningguru

Let's start a conversation!