Just-in-Time is a Toyota manufacturing term that has its roots in Henry Ford’s inventory control philosophy. This term has bled over into many other industries, grown beyond just inventory control, and evolved further, in the 90’s, into a cornerstone of LEAN manufacturing.
Over the years, I’ve seen this term start to wriggle it’s way into the world of technical documentation. It may not always be referred to as JIT. It may, instead, come garbed in terms such as On Demand Documentation or Knowledge Centered Service (KCS).
While I understand on-demand documentation – and have put out a LOT of it over my 25 year history as a technical writer and senior IT support desk staff. I get nervous when I see buzzwords like this thrown around in terms of information quality. I think it sets a bad mindset.
It often lends itself to the thinking that support desk staff can just filter through an endless history of past support tickets to find a solution for something in front of them.
Mind you, this is what I glean from many management types who, themselves, aren’t really in the foxhole. They scan over complex systems, such as KCS, and pick up the knowledge reuse and incremental improvement pieces of this system, but completely gloss over the very necessary suggestions the framework has to give, such as a KCS Council, a formalized system of Coaches/Mentors, and regular, standardized training to support desk staff.
KCS will also say, very clearly, that it’s an entry point, not a replacement, for more complex levels of technical/instructional writing.
One thing that is often missed by people who don’t do process-based writing regularly, is the fact that a lot of processes have prerequisites. This could be in the form of skills that are required ahead of time, or pre-process events, varying cases…
I’ve seen a lot of focus on “getting it done quickly”…but “quickly” doesn’t necessarily mean “efficiently”. If instructions are incorrect, at best it will cause a person time to try to figure the right way to do something. At worst, it can result in expensive rework or scrap – this is the opposite of efficient.
I can perform a process really fast, I can jot down a note or two, rely on my own personal knowledge to fill in the blanks, and assume that whomever follows me knows as much as I do, but failing to really consider inputs, outputs, how things fit together, and how downstream processes are affected beyond what’s in my immediate vision will ultimately snap the value chain.
Efficiency is when something is done quickly, without error.
Understanding and clearly communicating required inputs, process steps, and expected outputs is critical and this is what JIT documentation needs to transform into.