Keep It Short & Simple

There is no need to over complicate best practice.

Openly, continually and actively engaging with the IT end-users, other IT teams, other business partners and suppliers, relaying status, especially any delays, seeking and recording continual feedback as a matter of routine within your service delivery processes to ensure everyone is aligned on expectations is a winner, every time.

Talking (or texting, emailing etc.) with people is simple and most people will use it.

Technology may have a unexpected part to play in making life complex, but the KISS principle should suffice within most IT functions. Having a messaging system embedded in to a helpdesk system can sometimes be as must a burden as it is a central easy to use system.

There are some notable exceptions; where trust is questioned or auditability is key to an activity the communication, data requirements and processing may be exhaustive however, for most IT activities a "Bottom Line Up Front" (BLUF) approach to communications and continual feedback may be more efficient generally.

BLUF prefers to specifying the main context of the message at the beginning and then explain why or give context afterwards. This does generally improve responses but can sometimes be seen as a little abrupt. It's purpose is simply to enforce speed and clarity in status reporting and requests. In the modern age with texting, messaging and emails becoming a normal business tool some communications are cut short of the context and so often keeping questions and feedback short loses definition through lack of context.

However, IT staff (and all end-users) should be encouraged to deploy BLUF and ask first, and then always ensure context follows, for example:

Bad questions:

• Dave, I was looking at the issue and going through the data. There is a lot of it going back months and I cannot find the record that is in error. Please can you give me the reference number of the order so I can trace it further.

Good BLUF:

• Dave, What is the order reference number of the record in error? I was looking at the issue and going through months' of data but I cannot find the record that is in error.

The recipient of the second request can respond immediately after the first part, before concluding to read the second part of the message.

There is, as always a caveat to BLUF, you should generally only ask one question at a time or at the front indicate that there are multiple requests.

• Dave, answer these three questions for me? 1) Do you get the same error when off-site? 2) Are you on cable or WIFI when this happens? 3) Does it happen every time? I am trying to ascertain if this is a performance issue or a timeout of some disguise and just need a little more clarification before I try to hunt down a bug deep in the code that might not actually be in this module and may sit in the communications stack.

Keep it Short & Simple and put the bottom line up front, and context afterwards.