The Latest Estimate

My favorite phrase - something breaks, there is a bug, system is not working, and the one thing most managers ask in the IT world is "when". Not what, can you fix it, do you need help, spare parts but "what is your latest estimate to fix this".

The same event out on the sea is equipment failure - not unexpected, as all equipment will fail, which is why we carry spare parts for everything, and life rafts. Undesired, and the timing is always a surprise, but not unexpected.

Here's an example - this boat's battery and electric system is shot. Small thing, and the skipper (your's truly, sad to say) is furious for breaking it. And would like to go back sailing, and would like to know when - but does not know that until the spare part is there, properly installed and the next problem (blew also an alternator) is identified and fixed.

The latest estimate is also a key question for IT projects and shipping schedules. In shipping, say a container ship route between Rotterdam and Baltimore is pretty well defined, has been traversed thousands of times and in general the ships have been tested and the crews have done the same trip in different conditions in the past. All this means cumulative, collective experience which makes it possible for shipping companies to post schedules and have a pretty accurate view on the expected arrival of a ship in any port.

IT projects, in comparison, rarely repeat the same task and deliverable. Be it an upgrade, new system deployment, new system development, replacement system setup, there is always something new in the project.

New implies "uncharted waters" in nautical speak, which brings us to the point. The phrase "Latest Estimate" turns mushy and meaningless, to wishful thinking, when one applies that to a new voyage. If the ship and it's capabilities are unknown, if the  destination is not charted, if the weather patterns are not known, if the crew does not know the ship or the seas, then the expected arrival date is pretty much just speculation.

Latest estimate (LE) for a workaround or fix is understandable as business does depend on technology and outages cause direct and indirect costs. In many cases the LE question in fairly sensible. Equipment failures for example and in general are straightforward to address.


The difficulty arises if and when the change, new feature or repair is more complex one. The main question is still too often the same, and most IT organizations try to answer that, giving educated guesses. Reliable information may be available, but not in the form of time but content.

On this regard maritime best practices beat IT easily. Fixing things at sea is often unpredictable, and the focus is on the task at hand, ways to address that and their pros and cons. Usually the entire crew is aware of the implications, and there are processes for all possible outcomes, including the dreaded "abandon ship".

A captain of a ship understands most systems, structures and processes on the vessel. The same does not seem to apply to business managers. This may have an impact  - if there is no or limited understanding about how the business (ship) works and how the technology relates and interacts with its progress, how can one ask but "when".

It would be much more productive and would make a much better working environment to deal with the likes of sea captains who keep their cool heads even in the face of a disaster than your average board member. If you happen to know about such a place in need of professional geeks, please let me know.

Until then - LE on that new network segment is "once we get the parts and they work", and for making features A, B and C to work is "once we figure it out and the pilot customer says OK".