« Just the Facts, Ma'am | Main | Executive Agenda for IT »

February 16, 2006

Does Different Software Make a Difference?

He who forgets the past is doomed to repeat it...

That's not an inviting scenario for companies that decided to get rid of old software in order to improve costs and productivity.

"Goodbye, and Good Riddance!" was the attitude, and why not? Typically, the understanding was that older software was keeping important work from being done because:
- it didn't have the right features, or...
- it had the right features but its method was too involved or complicated, or...
- it worked fine but it no longer was covered by a support agreement whereas newer stuff would be.

Those conditions eventually got discovered if only due to difficult events cropping up with ongoing usage. The decision to intentionally change was well founded by evidence.

But taking the pain first wasn't the only way to handle it. We could also have anticipated each of those three problems -- and actually scheduled them right out of the "future problem" zone.

So it seems, anyway... but there are complications in trying to do that. For example:

- Changes in the users themselves can make features suddenly seem more or less appropriate.

- Training and Standards streamline patterns of usage but are both more difficult to come by after the software is already in company circulation. Demand for the software to spread is typically much higher and faster than the acceptance of training or standards.

- Most software gets under-utilized; but the part of the feature set that gets the most use becomes more than familiar enough to continue on after support agreements have unnoticeably expired.

And the final twist is that the software lives on the hardware -- so hardware decisions very often wind up becoming defacto decisions about the location and type of software. For example, if the hardware walks out the door, so might some software! Or if the hardware gets upgraded, the old software might not be able to keep up. Finally, can the new software be used without having new hardware first?

This means that newer software, bought and implemented, may be trying to add benefits on top of unsolved ills.

If new software and/or upgrades are to be done in a way that can handle our intentions and the complications that get in their way, there must be a breadth of awareness that requires information pooled from a variety of sources.

Let's look at an example of how this awareness, or planning perspective, results from the information pooling. Our perspective will be built with the following:

- Purchase plans
- Vendor records
- Employee records
- Distribution records
- Support records
- Budget and expense records

First, a general overview: the sequence of this group of records allows us to trace the life of the software as it changed from being someone's property other than the company's, into property company owned or contracted. It also traces the availability of the software from a period when that was a supplier problem to when it was a company problem. As we watch the meaning of "owner" and "available" change over time, we can see why the change happens -- but we can also recognize that earlier meanings often get forgotten or demoted as later meanings take over. In other words, things that are still true about the software fall out of sight, out of mind. But if those forgotten conditions can still exert influence, chances are that they will.

Next, some specifics. In each of those different kinds of records, imagine (or confirm) how one particular piece of software is uniquely identified. Identification rules might exist for each different type of record, but do any of those rules intentionally support preserving the identity of the same unique piece of software across different kinds of records? Who within the company creates the rules that do that? What do they expect to get from using those rules?

Now, for the effort to handle our new intent and the complications that underlie them, we need to figure out how the old stuff might compete with the new stuff. We can look at that in three ways:
(1) Fiscal -- what kinds of dollar-related issues are still associated with the software?
(2) Physical -- what options and restrictions exist on where the software is and should be?
(3) Functional -- what certainty do we have about why the software is being used the way it currently is?

And in every case, the challenge is to be able to get reliable answers in a reliable way.

For most of those questions, getting the answers requires identifying certain decision-makers, finding out how they make decisions, and finding out how they prove that their decisions were executed and maintained. That will push us into the records.

This often turns up a lot of inefficiency at best, or chaos and contradiction at worst. Those problems have to be minimized, because they are at the root of why old software can come back to sabotage expectations about new software being helpful. And what everyone needs to remember is that new software becomes old software, too.

If a collection of reliable data from those sources can be consolidated, it can then be analyzed to find patterns that indicate where upgrades or new software can most likely have an impact. The probable degree of impact should also begin to surface as a matter of how hard it is to eliminate barriers represented by old software or, jujitsu-style, to exploit its current attributes (fiscal, physical or functional).

Finally, as the hub (if not the holding tank) of the consolidated information, the software inventory should be available as the primary thinking tool for planning change from the old to the new.

With that emphasis on analyses that improve planning, many organizations might want to revisit the reports that are currently published from the software inventory -- and assess whether those reports are really helping to manage things as opposed to merely tracking them.

Posted by Malcolm Ryder at February 16, 2006 7:58 AM

Trackback Pings

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

Comments

Post a comment