Running IT is hard enough when all the CIO has to contend with are changing business demands. But these are far from the only “condition fluxes” IT has to deal with.

Take an example: Imagine some aspects of the business you support depend on a reliable, predictable, and immutable definition of the second.

No, not the second what, as in what comes immediately after the first.

The second. The unit of time representing 1/60th of a minute. The unit of time defined by the frequency of cesium atoms oscillating between their two stable quantum states.

The unit of measure on which, the meter, lumen, gram, ampere, degree (Kelvin), and mole depend.

The unit of time that’s in the process of being redefined by the world’s metrologists, a job title I just know most KJR community members aspire to. And before I mosey on to the next point, a thank you to my now-retired business partner, Steve Nazian, for pointing out the coming temporal redefinition to me.

Okay, maybe I’m overstating its potential impact, given that the change in a second’s length will be, at most, about one part in nine billion. Or maybe not, depending on the future of quantum computing.

Anyway, the question to be answered this week isn’t about the second itself. It’s about the coming challenge of tracking down all of the change’s ripple effects. Physicists and engineers around the world might, that is, have a whole new Y2K-like challenge in front of them.

Which (at last!) almost brings us to the point of this week’s rhetorical random walk: How well-documented is your technical architecture?

One more step and we’re there. The point isn’t about your architecture. It’s about you technical architecture management practices, not about how complete and up to date the documentation of your technical infrastructure, platforms, information repositories, applications, interfaces and integration, is not to mention the many-to-many mappings connecting your applications and business capabilities.

Here’s the point

Technical architecture management includes the concept of what’s usually but erroneously called technical debt, to correct which error I’ve suggested the term “chronodebt.”

I’ve defined chronodebt as the accumulated cost of remediating all IT assets that aren’t what engineering standards say they should be. chronodebt is what your IT organization owes the god of time.

Which leads to the question of what we should call the accumulated cost of remediating incomplete and inaccurate documentation of your technical architecture.

It’s chronodebt applied to IT management. It’s a debt that doesn’t come due until it suddenly approaches knee-capping-level urgency.

It matters because there will come a time … there always comes a time … when you need this information Right Now, because you need to track down the ripple effects of a redefined second, a modified business process, the integration requirements of new or updated software, integration of a newly acquired business, the need to provide documentation for a divestiture … really any change imposed on IT by changing circumstances beyond its control or ability to influence.

It’s management chronodebt – the entirely predictable result of striking the wrong balance between those management practices that are most urgent and which are most important.

Bob’s last word: The first law of preventive maintenance is that while you always have a choice between paying now And paying later, paying later almost always costs more.

But in order to implement any program of preventive maintenance, whether it’s managing IT architecture’s chronodebt or a factory’s mechanical and electrical systems, company leadership first has to recognize the existence of what we might call “management chronodebt” – the cost of having failed to invest in the management practices needed to manage technical chronodebt.

New on CIO.com’s CIO Survival Guide: The Edison Ratio: What business and IT leaders get wrong about innovation. Because when it comes to innovation, great ideas matter, But in the end, understanding the need to act on fewer great ideas matters more.

Completely inappropriate for KJR, but who can resist? I hereby nominate the distinguished judge J. Michael Luttig for membership in Bob and Ray’s “Slow Talkers of America.”

We haven’t talked about common sense recently. Especially, you might have wondered why, when devoting two full columns to gun control (don’t worry – this isn’t a third), I didn’t propose measures about which the popular, adjectival form … “commonsense” … apply.

I didn’t because I couldn’t – not after having published this way back in November of 1998:

Management Speak: You have to apply common sense to this problem.

Translation: You have to think like me.

“Common sense” is a popular way to affirm a person’s commitment to an idea. It’s a seductive alternative to presenting a coherent analysis of a situation, and far from the only one.

Here’s another: “It’s only logical.” Thank you, Mr. Spock. But even when a proposition is logical (or “only logical”) that doesn’t mean it’s the only proper conclusion that can be drawn about the subject at hand. If it were, we’d have to choose between Euclid and János Bolyai when evaluating the correctness of geometrical formulations.

Different premises, including but not limited to different priorities, lead to different conclusions for even the most rigorous thinkers. So no matter how certain you are that you’re on the right side of an argument, take the time to wonder if a person who disagrees with you might be just as right as you are, only their “right” is the result of having started with different premises, postulates, assumptions, or axioms.

Getting the hang of it? Here’s another one for your repertoire: “Everyone knows that …” In addition to helping you make your point without resorting to the hard work of thinking, it also plunges your debating adversary into the utter despair of deep loneliness. After all, if everyone knows something but your adversary disagrees, they’re the only person in the world who doesn’t belong to the set of “everyone.”

One more: “In reality.” If you’re theologically inclined, you at least might claim divine support for your perception of what’s real and what isn’t. Or, if you’re properly prepared with actual evidence … and even better, if your perception of reality resulted from evidence rather than vice versa, then okay. “The evidence says,” would still be better.

Then there’s the popular “And don’t tell me that …” followed by a point that, had it not been pre-empted and prevented, would have been a perfectly reasonable point to make. But after someone tells you they won’t allow you to even make the point in question, making it anyway just wouldn’t be polite now, would it? Maybe negotiation would work: “Okay, I won’t make that point if you promise not to make this one.”

Finally, no rogue’s gallery of improper discourse would be complete without including the the inverted form – empty arguments against someone else’s position.

“That’s B.S.” is a popular version. It’s okay when it’s attached to a statement that’s utterly preposterous and immediately followed by reasons the statement is utterly preposterous.

Sadly, it’s more often used instead of listing reasons the statement is utterly preposterous. “It’s B.S.” Q.E.D. Case closed.

Bob’s last word: What all of these annoying rhetorical tricks have in common is, as you’ve undoubtedly figured out already, that they’re examples of argument by assertion. If you find yourself at odds with a perpetrator of this argumentative sin, don’t even bother to call your opponent on resorting to it.

You’ll be better off just walking away.

Bob’s sales pitch: Bare Bones Project Management is arguably the most practical, pragmatic, and succinct guide to project success you can buy. You can also buy it in in-person form: Bob will come on site to provide a one-day look at what project managers and teams need to do differently to achieve project success, either as a seminar, workshop, or clinic, depending on your specific situation.

Contact him here to get your planning started.

Now on CIO.com: 7 tools for mastering organizational listening – leadership’s most poorly understood and undervalued responsibility.