Rob Buecker Consulting

I have been participating in a coaching group on learning The Collaborative Way.

A long standing gripe I have had is surrounding a lack of system documentation written for the intended audience. I.e. end users, support, engineers, developers, administrators, etc.

An example could be scheduling a training event. It can’t be THAT hard can it? I mean, everyone knows that you just need to know what it is and when it is, right? Oh, and where it is can be important too. And, how many employees are going. It might also be helpful to know how much it costs and how long it is.
Before I dive into allowing managers access to reports for showing employee availability for project planning, attendance for performance reviews, costs for budget planning, etc. I am just going to cover What, When, and Where…

What: Training! Does the customer have a text box that they can type whatever they want into it? How many characters are allowed to be entered? How about copy/paste from email or a web browser? Is it expected to keep formatting? Should it allow emojis? Does it need to be a dropdown list that is maintained by an admin? Are there multiple fields that need to be completed, like type and name? Is this data mandatory? Is there any validation on the input?

When: Date and Time! Simple! How does the user enter the data? Is it a calendar widget? Dials? Free text? What format is used to display the date and time? Local system, Year Month Day, Month Day Year, Day Month Year? Is month digits or names? Are years displayed with two or four-digits? Are dashes or slashes used as delimiters? Does it use 12- (AM/PM) or 24-hour times?

Where: well, this one isn’t getting any easier if you need to know physical locations like the galaxy, solar system, planet number, latitude-longitude-altitude, country, state, city, street address, building number, floor number, room number, etc…

We haven’t even started talking about module licensing, users permissions, database table structures, column data types, customer customizations, branding, security, authorized support callers, support levels, hosting status, versions, application performance…

Wow, this is starting to sound extremely complicated, we don’t want that… That sounds too expensive! We’ll just let the code be the documentation and the customers smart and will just intuitively know how to use it…

Sound like your company?
How many helpdesk calls do you receive on a regular basis?
What are the most common calls about?
How much time is devoted to testing application code before release?
How much time is spent troubleshooting issues?
Is there an issue with customer retention?
What about employee retention?
Do you include this feature in your sales brochure?
Is this a default module or an add-on subscription?

You can see the questions can appear to be endless.
Being clear and concise about what the feature is, what it does, who has access to it, if additional setup or administration of values is required does not necessarily mean sunk costs. Actually, it is quite the opposite in my view. It sets the expectations of what is available and how it is designed to work. That said, the greater the complexity the greater the cost, of course…

I am seeing this fall under the principle of Speaking Straight with The Collaborative Way. It is attempting to resolve issues at the lowest levels. It is giving reference and/or guidance to those that need it.
Keeping tight lipped and expecting those that need to know will figure it out is perfectly fine if that is how you choose to run your business. Just know, there is still a price to pay either upfront in documentation, design, and testing or later on in customer satisfaction and time employees spend troubleshooting.

Slow down to go faster. Slow is smooth, smooth is fast.
Step back and see the bigger picture.