How to Win at Consulting (7/8): Paper Trails and Version Control

7) Paper Trails and Version Control

Another request comes in- it's 11PM and you've added more things to your to-do list than you've taken off. It's Tuesday night and there's a big client presentation coming up the next morning. Everyone's rushing in with their final changes from their different sections and you're holding the master document.

You do about half of the changes on the fly and the others you write on your phone's to-do app. There's a wording change here, a footnote there, changing the order of two slides. Your goal is to make sure everyone's changes get in without losing anyone else's in the process.

Approach A: To save everyone time, you try to make all the changes as quickly as you can so that you can stand by for new ones and proofread in the meantime. You go through your changes as you hear them, updating the deck on the fly. When you're done with the changes you remember, you look at your list.

You open the latest attachment from a colleague, hit F12 and "save as" to your desktop so you don't lose any data by closing it by accident (you learned that one the hard way), and you start copying and pasting changes from the file to your master document.

Your phone rings and it's your boss with more edits which he tells to you as he's boarding his flight. He wants you to change the sequence of a few slides. After you hang up, you look back at your computer screen.

"Wait - did I just change the order on my colleague's version or my version?" you think. Your boss was in a hurry, so you never took notes on that.

Now you have to go back and see which document you were working on, and the changes keep piling in.

Approach B: Before you make changes, you print out the master document. Secondly, you make a quick XLS with a list of all your colleagues' names and several columns named something like "received edits?" "changes made?" "proofread?" "footnote check?" and "done?". After you do this, you make handwritten changes through your version of the document.

If anyone - offsite or not - wants to make sequence changes, you write down the original page number and the new page number. Having physical copies of the slides helps you keep track as well.

When colleagues send you their versions, you put "yes" or "y" in the corresponding cell of your XLS. For colleagues in the same room as you, you leave the stack on your desk, and anyone who wants to make changes can handwrite them on the deck.

For each page with edits, you make a mark that indicates there are changes to be made. You use black marker/highlighter to indicate where each change is. After you incorporate each change, you make a checkmark right next to it on the page.

This way, you know who has made the edits and you know when you can sign off on them. Much easier. You now have a record of each change made along with a record of whose edits are still outstanding.

Conclusion: When it comes to document consolidation, you have to be very organized. Everyone will think his/her change is the most important change and you have to drop everything and do it. The presentation won't be until the next morning, so you're best off going with consistent quality throughout the document rather than a hastily-assembled version that'll be ripped apart by your boss and reflect poorly on you and your team.

The guy in Approach A thought he was saving everyone time, but if a single distraction popped up, it'd take him a while to get his bearings again. The guy in Approach B understood the implicitly unpredictable nature of compiling documents and made sure he had a system to a) make sure he had everyone's feedback and b) keep track of whose changes he had made where.

You never want to have a team member say they sent something to you but they don't see their edits in the final version of the document. Avoid that.

That's all for this week, good luck out there.

PS - PM me if there's a topic you'd like to see covered next week.