Explaining the Proposal: Communicating With Bossmen

In The Proposal, we first provided a high-level summary of the capital and labor costs which would be involved in building out the infrastructure Bob asked for. Some geeks call this the TL;DR clause, and over the years I have found it hugely important in communicating with the people who sign the checks. They are not technical (if they were, why would they hire us?) and their eyes tend to glaze over when we subject them to the info-dumps we find necessary, informative, and highly interesting. The TL;DR clause is presented first, but it's actually the last item you'll write. It's only four sentences long, but it immediately gives Bob a sense of what he’s agreeing to in terms he’s familiar with:

• How much is this gonna cost,
• how long is it gonna take,
• and what we need from him in order to get started.

Pay close attention to that short bullet list - especially the last few (bolded) words! Have you ever participated in a long back-and-forth email thread with your management, where nothing ever really seemed to get resolved, but the thread never seemed to die? I’ll bet you have – I know I have! One of the prime causes of such things is that one party or the other is failing to clearly say what they want. I’ve known many people who expected the boss to know what came next, whether it was clearly stated or not. But bosses are humans too, and like you, they have many demands on their time. Tell them what you want, and don’t mince words about it. You’re not ordering the boss around – you’re giving him a clearly worded course of action to decide on. Bosses love that, so give it to them as often as you can!

If he’s unhappy with the summary (a/k/a TL;DR clause), he can pick through the following details and let us know what changes he wants. If he’s happy with it and he trusts us, reading the rest of the document isn’t necessary. He can just tell us how he’d like us to order all his new hardware/software, and when he wants everything done – and we will be off and running.

We then parroted Bob’s requirements back to him in our own words. This is a hugely important part of professional communications, I feel. It tells Bob: ‘this is what I heard you say’, and it gives him a chance to amplify, clarify, or outright change his directives to us. It also provides written documentation of the conversation in case there is later confusion about what was agreed to. If Bob replies to this written communication without providing any corrections, he is implicitly (and in writing!) agreeing that yes, this is what he said he wanted. Business workers everywhere call this CYA (cover your ass). Professional sysadmins every know that because of the incredible sillyputty plasticity of technical systems (they can be whatever you want them to be – if you work at it hard enough!) CYA is an important part of the job. We don’t have to call it CYA – I knew one person who called it “clear, crisp communications” – but it’s a valuable skill to bring to your job, every day.

Finally we move to what will be (for us technical guys) the real meat of the document, in three sections:

• The hardware/software we'll need
• the labor plan
• and the ongoing maintenance plan.

All three are fairly straightforward for the reader - but as the writer of such a plan, you'll probably agonize for hours about the details.

The hardware/software buy section can be especially troublesome. Here you're building what is essentially an entire IT ecosystem. All of the parts depend on one another. If you leave something out, your ecosystem will die for lack of a critical player. But it all has to meet the budgetary and other constraints imposed by the circumstances at hand. Lists like this become easier to make the more experienced you are; but they are never easy. Give yourself plenty of time to build them. And when you think your list is complete, take a break - then come back and read it again. You'll probably notice a few items you missed. Or better yet, discuss with an IT colleague, and have him point out the holes.

In later articles I will be explaining how and why I made the choices found in this particular proposal, so within this article I'll confine myself to notes on how it is formatted. 

I like bullet lists! I think they convey a sense of how things relate to one another. They're concise but convey a lot of information rapidly, in an way that's easy to navigate. So here I've listed all of the things we'll need to buy or acquire (FictionalBiz is providing some of the software, so that's noted in the list), along with their prices in bold font, because we know that Bob is especially interested in costs. Additionally I've created hyperlinks to all of the places I've priced software at, because I know I'm going back to those sites once Bob gives me the go-ahead to actually order the products. No sense in my having to find all that stuff over again! Or, Bob might take it upon himself to order these things - and by explicitly linking them, I can be sure he'll order the exact items I have specified.

Occasionally the bullet points give some hint about the expected functionality of the items, but mainly this is a shopping list. So, as a shopping list, its job is mainly to name, link, and price the products.

The labor plan section is another one that looks simple once written, but is actually a bear to produce. The tricky parts of this are the order of work, and the time estimates.

In IT work, you will often hear yourself or others saying things like "Oh! I forgot to set the whatsit value to foo!" Again, we're building an ecosystem here, and the interdependencies are not always apparent in the planning phases. So you rough out a list based on your knowledge and experience, and you proceed on the understanding that this is only mostly the way it's going to work on install day.

But ordered lists are important. I try to break down the task list in such a way that there is no task more than 6 hours long. This is important because the more granular your task list is, the more accurate your time estimates will be. And time estimates are important to get right (or at least mostly right) for a variety of reasons. I will list a few off the top of my head:

• Credibility. The people paying for the work want to know how long it will take, because they need to understand costs, and they need to know when things will be done, so they can hit their own deadlines. Your knowing how long a task will take will do a lot for your credibility before they've seen you deliver (because it shows you know what you're doing) - and your working feverishly all night to deliver something you said would be 'a piece of cake!' will demolish your credibility (because it shows you were winging it at best when you said you know what you were doing!).
• Sanity. We've all done those all-nighters, of course. But they leave us tired and crabby the next day, and prone to mistakes which generate more all-nighters. It's a vicious cycle!
• Predictability. Knowing you'll be all done with tasks 1-4 on the list by Thursday means you can make the other promises important to your life - that date with your main squeeze, that ball game with your nephew, that important interview with the bank loan officer.

I'm sure there are more. Accurate time estimates are important. Don't blow them off!

In your time estimates, leave in enough time to document your work. You'll thank yourself later!

There's a lot more I could write about time estimates, but I'm not going to. Instead I will refer you to the trade reference on the matter: Tom Limoncelli's Time Management For System Administrators.

Finally we come to an often forgotten segment in the proposal: ongoing costs. Here, I've simply laid out some basic costs and time estimates for the ongoing maintenance and operations of the network we are building. First I lay out the time and money costs of new user additions, because I know that as a small businessman, Bob needs to understand this. How embarrassing for him if he hires a new employee and can't find money in the budget to give him a computer to use on day one!

I also provide basic time estimates for replacing an employee, which is a similar task for the system administrator but requires no new computer.

And finally I give some estimates for ongoing regular/preventative maintenance of the network. This little tidbit is missing from a lot of network build and change proposals, and it's the reason a lot of things break when strictly speaking, they don't have to. I'm giving Bob an upfront heads-up that one doesn't just build networks, run them till they break, fix them till they work, and repeat endlessly. Dependable networks require regular maintenance!