You’re a business owner, head of Sales, the leader of a Systems Engineering (SE) division, or maybe a Systems Engineer yourself, and no matter what you do the team always seems to be too busy with billable work to deliver great documentation to your customers. The first part of the sentence, that you’re all too busy, is a great problem to have – keep rolling in that revenue! The last part, however, is a death sentence. Whether it’s a scoping document, Statement of Work, design guide, implementation plan, or even a Bill of Materials I’ve seen too many SEs and too many SE teams burned out by, and several value added resellers (VARs) get crushed because of, poor customer documentation or worse – none at all.
Whether we’re talking about a rough scope for a bid, technical bits of a Sales proposal or just part of the final implementation sign-off, delivering documentation to your customer is a big differentiator. Give them low-quality documents ,or no docs at all, and you risk spending hours or more of non-billable time – because if they have any wits about them they’ll argue it’s your problem for never documenting your work – on a reassessment of their environment\systems\configurations in the future. Not to mention the impact this tends to have on customer relationships. Providing your customers with high-quality deliverables, on the other hand, might at first sound like you’re giving away the keys to the kingdom. What you’re really doing is showing that you’re in this together, you’re working from a place of mutual trust, and they can count on you to provide absolute top-notch effort.
Generating high-quality documentation can seem like a daunting task at first but the value is almost immeasurable. The real “1 easy trick” is to change your frame of mind about it. Instead of viewing documentation as an afterthought at best, or a “crap waste of time” at worst, you need to truly believe in the power of documentation. Understand that documentation can and should be created first in any project. And then act that way.
The “1 easy trick” really is that easy, so I’ll say it another way: stop trying to jam documentation work in at the end of your projects and start launching your projects from documentation. I’ll share a real example from my past that highlights the power of documentation as a proactive tool. Names have been changed to maintain customer confidentiality.
The power of documentation
A customer opportunity came up at ACME Corporation to provide both a physical office migration and an email server migration from an on-premises solution to Microsoft Office 365. Several area IT solution provider Sales teams had approached ACME with very simple proposals, none more than a few pages long. Just enough to “show up and throw up” at the 2nd or 3rd meeting and talk about “how standard and easy these types of jobs are, no sweat, when do you want to get started?” Whether any of those Sales teams did everything else right or not, none had won the trust of Bob, ACME’s VP of IT, because, and I quote, “nobody has taken the time to actually show me how the project will be executed. So forgive me, I appreciate the meal, but I hope you guys aren’t just going to show me a stock proposal and a quote as soon as we’ve finished eating.”
It was at a Friday lunch meeting with Bob that he said this. I looked over to my sales counterpart Jim and I shot him my “I’ve got this” look. He changed whatever he was going to say to, “Sean, you ran IT for a similar-size shop a few years back. What would make you comfortable if you had the same project fall in your lap?”
“Bob, like Jim said I’ve been in your seat in a past life. Maybe I’m reading into things too much, but I’ve made the mistake of trusting a solution provider too much, too, and so I think I understand where your concern comes from. If I come back to you Monday morning with a detailed plan for each of these moves, and – assuming you remember our rates – can Jim follow-up with you in the afternoon to talk about sign-off and a start date?”
Long story short, I worked with my manager to shift my last meeting for the day off to another engineer not so I could head home early on a Friday, but so I could document exactly how I intended to execute both the physical migration and the email system migration, from the high-level all the way down to the individual device and user. I showed up at the ACME offices on Monday morning, asked Bob for 15 minutes of his time to review the plans with me, and called Jim on my way back to the office to let him know Bob was ready to deal.
How did we scale to that point?
The answer is a simple one and has two parts. First, a predecessor had shifted the company’s approach to project management the point that every time Sales went to close a deal they started the close with a documentation plan. All of the engineers, myself included, were trained to understand that if a rep said they were planning to close a deal tomorrow it meant “get started on the ‘detailed design document’ and don’t sleep until it’s finished because we need it for tomorrow’s meeting”. Second, we didn’t believe in “light” or “high-level” templates, even for proposals, and the business invested the time in creating extraordinarily detailed templates. Every proposal started as a 20+ page form in Microsoft Word with an executive summary, space for several diagrams of the current state and the future state, and then a plethora of numbered lists, bullet lists, form fields, and tables where we would fill in the specific plan, in exacting detail, of how we would go from “current” to “future”. In this case I’d used our “data center move” template and our “email migration” template. I had to make many assumptions while filling out both documents, but assumptions can be changed as simply as “Find and Replace” in Word and other tools.
Not having a plan at all, however, would have lumped us in with everybody else.
The best part? Doing all of this work up front not only meant much greater chance of success in our Sales team, but also that much less work for me! Why? Because I had laid out all of the steps ahead of time, all I had to do on the day of the migrations was show up and go through my checklist! Many times, the person drawing up the design wouldn’t be the person executing the work, and we used this as a constant test of our planning capabilities. The company believed in the power of documentation so much that we all bet our reputations on it. This level of documentation was also useful when navigating those challenging situations where something wasn’t working right and we had an irate customer on our hands. Any Support Analyst would start by stepping through the docs to validate whether the configuration had changed since the last time any of us did any work, and then either get the OK from the customer to revert the change or to adjust other parts, of whatever system they were dealing with, in order to get things running. And talk about continuity in our approach: if they did make a change, they would first document a rollback plan, again using a template, make the change, and then update the design with the new configuration before closing the ticket. If anything bad happened in the future, we were again covered, as any other Engineer or Analyst could step through the docs and see step-by-step what the correct configuration was supposed to be.
For more information on scaling your documentation capabilities from “average” to “amazing”, start with the references below. You’ll need to get comfortable with creating templates, forms, macros, and other tools available in Microsoft Office and other productivity suites. Whatever tools and techniques you ultimately land on, if you’re looking to scale your capabilities as an individual contributor or drive scale across your team, creating solid documentation up front and believing in the power of documentation is critical to your success.
http://www.makeuseof.com/tag/integrate-excel-data-word-document/
Sean M Masters 