« The Sources of Software ROI | Main | Does Different Software Make a Difference? »

February 15, 2006

Just the Facts, Ma'am

Ever play "Telephone"? You know, the game where someone whispers a message into another person's ear, and that person has to whisper the message to the next person, and the chain of whispers goes on person after person until the last person is asked, "What's the message?" This is usually where everyone's funnybone gets whacked, when the answer turns out to be entirely goofy as a transmission of the original message.

Looking at the data in your software inventory can have all the same fun and excitement -- of knowing the validity of the info you're getting is... laughable!

All you have to do is (1) keep no track of how many times the information was transferred, and (2) not care where it started out. Easy!

Sure enough, for thousands of organizations, it is really amazing how "entertaining" the inventory is to business users.

But on the other hand, if you are the person who is held responsible for the data, you probably have a lot less interest in this game. It's almost criminal how hard it is to fix the business mistakes and misunderstandings that can grow from the unreliability of the information.

The problem is, as the game demonstrates, that when garbage out goes on to become garbage in somewhere else, the mistakes get magnified.

Where are the likely "garbage in" points in your company?

IT industry research organizations like Forrester, Gartner, and the Standish Group routinely bring up three major points where business leans on IT for information inputs: architecture, projects and support. Not only is each of these subject to being spoiled by bad information, but the relationship of the three to each other can magnify their individual damages.

Why are they so vulnerable? Because each one has a major design component that is what makes it of any further beneficial use – and the design is based on the information inputs. Bad info leads to incorrect design, which leads to incompatibilities with the ultimate business purpose. These incompatibilities include mistakes like:
- making something incorrectly, which because it doesn't work leads to re-work just to get it finished;
- making something with poor quality, which leads to breakdowns; and,
- making the wrong thing, which leads to disposal;

Add the time, money and potential aggravation involved, and it's easy to see where impatience and anger make the difficulties bigger than just the difficulty per se.

Popularly, it is believed to cost 90% less to prevent a problem than it does to fix it. Ben Franklin probably made the idea popular (a stitch in time saves nine) but it keeps getting proved again in things like software programming and medicine.

As it turns out, software inventory information can likely be the key culprit of those major corporate mishaps, but is also a likely candidate to be the prevention hero for such problems.

Three areas where the corporate "entertainment" value of bad inventories becomes criminally difficult to reverse are in penalties -- from failure to meet contracts, failure to meet the law, and failure to maintain security of corporate data. These can be very substantial risks.

(1) Contracts assume certain capabilities to deliver, which depend on processes with high levels of reliability. But that reliability depends on technology configurations that must execute functions properly on demand.

(2) Laws state that companies have only certain rights to use technologies in certain ways, but in the heat of competition, corporate user behaviors may be unconcerned or unaware of the restrictions.

(3) Confidentiality underlies much of what turns a company's knowledge and difference into an advantage. It's just too hard to run the plays when the opponent already knows what you're going to do, and what you're going to do it with. Software is how you get to your information; it's how they get to it, too. Ideally, they don't get their hands on your software...

These are three different issues, having particular software management solutions but solutions that are enabled by inventory information.
- Version control and delivery puts a foundation under contracts.
- Delivery and authorization keeps users within the safety zone of usage rules.
- Authorization and tracking keeps tabs on where those software stepping stones are that lay down paths between information and info users.

The overlap in the solution approaches is not an accident. Furthermore, it doesn't stop there. Tracking confirms what versions are actually under control or not -- immediately implying certain things about the effectiveness of planning, changes and acquisitions as currently practiced.

Overall, the point is to have the right software in the right place at the right time for the right reason.

When those four qualifications are met simultaneously, risk has been minimized. But this is a point that may never be reached or long-lasting for all situations. Since the business is by nature a dynamic affair, requirements and circumstances keep changing and present the need for adjustments in how software is involved. Managing risk has a goal of minimizing it in total, but the process is about being continuously proactive to keep it from growing where it wasn't already and doesn't have to. For that effort to be efficient, the relevant information must be accurate.

The pressure on the IT organization is to ensure that the data in the software inventory is always capable of expressing when certainty about risk has been lost, and expressing with certainty the facts about whatever is wherever it is and how it got there when it did.

Posted by Malcolm Ryder at February 15, 2006 3:39 PM

Trackback Pings

TrackBack URL for this entry:
http://www.malcolmryder.com/cgi-bin/mt-tb.cgi/214

Comments

Post a comment