“Thanks goodness for the last moment or nothing would get done.” A colleague of mine likes to say this, usually when something arrives on her desk about two minutes ahead of deadline.
It’s interesting that we have built the human failing of leaving everything to the last moment into our systems and processes. Not only do we extol its advantages, we even changed its name to “just in time…” Fill in the blank with delivery, training, manufacturing or any other word of your choice.
Just in time sounds better than last moment; it has a nice, optimistic ring to it. But call it what you want, the difference between success and failure under the last moment/just in time approach is the deliverable. If it’s completed so that the next part of the process can occur, it’s okay. Nobody notices. There may even be a short tolerance for being late.
Interestingly enough, being early can wreak havoc. In manufacturing, early means parts have to be stored or the assembly line speeded up. If it’s training, the argument is that people forget what they’ve been trained to do if it occurs too early.
Using all the time available to complete a given task is human and it underlies just in time thinking. IT projects often illustrate this. If the project plan allows three weeks to code something, it will take three weeks and probably an extra day or so. If you allow two weeks in the project plan for the same thing with the same person doing the coding, it will be done in two weeks – and an additional day.
For young project managers, the danger is that you can’t show a project plan with three weeks task time to the client and two weeks to the project team. This is what makes estimating a project so difficult. There’s a just in time best case, and there’s the latest possible time before disaster case, and there’s the best guess of real life. Unfortunately, marketing folks have difficulty selling the latter.
Also, have you noticed that software vendors have a maximum of five days in their estimates of doing things? How long will it take to get this project started? Five days. How long will it take to build this piece of code? Five days. This is predicated on squeaking more time out of the overall project by allowing five days for everything and trying to use the slack to make it up.
There seems to be a passion in some circles for just in time training to go with the just in time projects. I suppose just in time could mean the day before the system goes live, but I don’t think so. The most successful projects I’ve seen started training early with some form of mock-up of the system. Training wasn’t about the elegance of the system; it was about doing transactions and using the system as a tool to do a job. Having people train on the system after it’s installed is just plain late.
There isn’t enough room here to list the ways in which just in time training has failed miserably. That’s why I’m a firm believer in the right time approach. The right time is when it will be most effective and in sufficient time for people to become familiar and comfortable with it. Come to think of it, that probably holds true of just in time manufacturing, delivery and inventory too.
Horner is an IS professional living in Vancouver. He can be reached at alhorner@sierrasystems.com.
