Google Glass, two Pebbles, a new Mac PowerBook, Surface Pro 2, Roku, PlayStation, three iPads (retina display, mini and old school), a new iPhone, Samsung Galaxy S5 — all of these things are in my home office. I love technology. I even married a software DevOps guy.

So I was thrilled when I walked into a new client's office as their interim head of HR and they told me IT reported to me. A treat for me, but perhaps not so much for the IT guy who had previously been left alone and trusted to do his own thing by the mostly professional, nontechnical staff.

He told me he had just submitted his assessment and budget. With a copy on its way to my inbox and a follow-up meeting scheduled, I was ready to dive in. What followed was something that happens too frequently when experts communicate with nonexperts.

Stop assuming anyone cares or understands

The document included the major problems he saw and the money he needed to fix them. Without judging grammar or sentence construction or anything related, the content of the document was lacking because it made too many assumptions — the first of which was that the reader cared about the topic.

It was basically a set of statements and a conclusion. Nothing in the document got me as the reader interested in why I should even care about the problems he was trying to solve. In fact, I could immediately think of more important things on which I could spend the money he was requesting.

Secondly, it was too technical. This is a major problem from accountants to scientists and everyone in between. Nothing in the document helped explain the complexity of the situation into a succinct, easy-to-understand collection of problems and solutions.

In both cases, just a few examples would have gone a long way to help the reader connect with and comprehend the issues. In this situation, IT guy could have easily included some common pain scenarios to which he knew for a fact his audience would relate:

"Remember the last time you were trying to access the network from home and it kept kicking you off? And then when you got on, how slow it was? Well, I have figured out a couple of ways we can approach fixing that."

I could practically see the CFO writing the check.

Start assuming they want to be interested, but have limited attention

The next problem with the document was that it was too long. No one has time to read a long document; and if they do, you have to wonder why. Often though, experts lack the ability to acknowledge the difference between what is important to them and what may be less important for other people.

Does the CFO need the names of the servers, the firewall address or the technical diagram? Likely not. So before blessing them with details and erasing all doubt of how much you know, ask yourself what they actually want and need to know, then start editing.

If that does not help, remember this: The more information you give them, the more opportunity you are providing for them to question what you are doing. If your goal is support for your request, a clear presentation that results in few questions increases your chance for success.

Remember your mom

Finally, realize that no question is stupid. If you want to argue the two servers are malfunctioning and out of date and why we should replace them with three blades, realize that someone might ask you what a blade is. To avoid looking exasperated or making anyone in your audience feel stupid, pretend you are presenting to your mom — or if not yours, the mom from some 1950s TV show.

It is not insulting to lay the groundwork for your discussion to ensure everyone is on the same page before you launch into your examples. Include a glossary or an FAQ attachment. Do something so that anyone who picked up the document could immediately understand the topic and the problem.

Doing so puts you in a much better position to earn support for your request.