Showing posts with label documentation. Show all posts
Showing posts with label documentation. Show all posts
Friday, September 15, 2017
Old Joke Contains A Serious Business Lesson
There is the old joke about the plumber who gets called to fix a water heater:
He listens to the heater for a few seconds, taps it with his hammer, and it starts working!
The plumber then gives an $80 bill to the homeowner, who then complains that the plumber didn't do anything.
The plumber then writes up an invoice and gives it to the homeowner:
$1 to hammer the heater
$79 for knowing where to hit
Interestingly, this joke actually contains an important business lesson. Business should be about generating results for customers, not in methodology or outputs.
In other words, the value to the homeowner is to get the heater working. The value doesn't depend on what the plumber actually did or how hard he worked. In fact, getting it fixed quickly is more valuable for the homeowner.
Yet, in our society, we value hard work. Even worse, we (the service provider) feel that, unless we generate enough work, we haven't given value to the client—even if they are happy with the results. We are our own worst enemy!
In the joke, the plumber was pressured to generate a simple invoice. But, in the real world, many companies would go further, and, under self-pressure, add even more unnecessary deliverables such as power points, documents, etc.
If your company wants to be productive, agile, and innovative—in other words, strategic simplicity℠ —then it should focus on generating results, and resist the urge to justify value through busy work.
Thursday, July 13, 2017
Quick and Dirty Expert Systems Get Used
When I was a vice president at a large bank, I had a team that was responsible for production support for an online corporate banking application. We had 1 or 2 people on the team who were experts (with years of experience supporting the application), while the other members were inexperienced.
We found that the inexperienced people kept asking the 2 experienced people for help, and they were tremendously overworked.
As a solution, we created a very simple, informal wiki that was only accessible to the group. Then, after every incident where a junior member needed assistance, they created a quick note with key words on how it was solved. Also, whenever the senior people solved a problem on their own that they thought might be hard for the junior members, they took a few minutes after solving the problem to write up a quick note with key words.
The key was that we didn't mandate a format or make it complex. The support people were busy and did not have the bandwidth to either write a document, or read through one. It had to be a quick and dirty note, or else it wouldn't get done and/or wouldn't be used.
The result was that, in about a month, we had an expert reference system that reduced the junior's need for senior support by 80%.
My advice is that I've seen many internal documentation systems at companies that are not updated and aren't used, because they are too complex. Teams need the ability to share quick and dirty notes that can be quickly created and quickly accessed.
Subscribe to:
Posts (Atom)