software
Programming code abstract technology background of software deve

By Al Strauss

(The software discussed in this article is created or purchased by the company for its own use. I am not referring to products that are licensed by or sold to another company.)

As you know, your company uses all kinds of software. Within the company, who owns it? The answer may surprise because it should not be IT. The software should be owned by the business entities that use it, like Accounting, Marketing, Inventory, etc. IT gets to access the software but should not own it.

Ultimately, it comes down to Pay Me Now or Pay Me Later. Your company will always be better served by Pay Me Now. What does this mean? It means the business entity that owns the software is actively involved in its maintenance and modifications.

Here is an example of why that is important. I once did software testing on a project for a subsidiary of a very large, well-known and respected company. The portion of the project I was testing was being demonstrated for the internal customer in my cube; we worked in a large building and I was centrally located between the developers and the business entity. When people showed up at my cube, I took a backseat and let one of the developers sit at my chair and go through the demonstration.

As the meeting progressed, the leader of the business entity was quite nice and offered a lot of suggestions. “That looks really good. But can we switch A with B?” and “I really like that. But how about if we move C to D and E to F?” Other developers were taking detailed notes of every comment.

When the demo ended, everyone left my cube with smiles on their faces. The internal customer liked what she saw and the developers had direction for their continued work. I was the only one not smiling. Why?

Because I was the only one that realized this conversation should have occurred at least eight months earlier. Every new requirement was really re-work.

The developers were never given the chance to talk to the too-busy business entity. They took their best guess as to what should be done. Although the IT staff would never use the word, “guess,” it is what they were doing and they weren’t always wrong, either. They had enough rough knowledge to create something semi-viable. But they needed direction from the people that were going to use the new system.

While the business entity truly was busy, making the time to provide IT with direction should have been a priority given the nature and expense of the project. If the business entity was not going to give IT the proper time and attention, the project should not have been funded.

With up-front and continued involvement – Pay Me Now – IT have saved thousands of work hours and avoided going (unknowingly) down a rabbit hole. But the company chose Pay Me Later and the whole project got cancelled – wisely – after millions of dollars were spent with no results. The demo in my cube was a microcosm of how this project unraveled; this scenario played out multiple times on multiple parts of the project over a period of time.

Here is another Pay Me Later example. While working at small company, IT built and delivered a system on-time. Like the first example, IT didn’t get much input from the internal customers. The IT manager received a large bonus for his on-time delivery and chose to leave the company immediately after getting his money. He knew he delivered a porous system. In addition to paying him a bonus, the company had to hire and pay three full-time employees to help stabilize the system. I was one of those three employees so I suppose I should thank him for my employment, salary and benefits.

Here are three tips for good software ownership:

  • When budgeting for a project, the business entity should also budget for its time. There should be regularly scheduled status updates and subject matter experts should know they will be asked for input along the way, especially at the project’s beginning.
  • IT should adhere to those regularly scheduled status updates and respect the subject matter experts’ time. These people are busy with other work and should not be contacted by IT every time there is a question. Unless IT runs into a showstopper, wait until the appropriate time and method to communicate with the subject matter experts.
  • As one of my internal customers taught me, “I’d rather have you late and right than on-time and wrong.” The cost of fixing a system after implementation is far greater than delaying it until it is right.

Your choices are Pay Me Now or Pay Me Later. What will you choose?

Al Strauss, M.A. is the author of The Newman Adjustment: A Fable About Bridging The Gap Between Business And Software. It is available through Amazon and other fine booksellers. For more information about the author, go to www.alstrauss.com.