May 25, 2019

Working With Software Companies

Bob Tuttle, MBA

Bob Tuttle, MBA
Owner/President/Bob Tuttle Associates

Share This Post

In the majority of cases, individuals and companies buy software and start using it. Typically there may be some initial training, or the company sends a person to class, and that is about the extent of communications - unless there is a problem. You also find cases where the initial product stakeholder goes off to a different position, either in or out of the company, and the connection to the software company is lost. As a consultant, to many companies have experienced this, amd I find that I have to do a great deal of investigative work to help companies effectively use the software they already have.

Have You Ever Lived Through This?

One day you come to work and your ERP application screen looks different. You start to mouse around, trying to find what you were used to looking at. You ask others what happened, and are told that they (whoever they are) did an Upgrade over the weekend, and now we are running on the new version. It seemed like the assumption was that the new version would look the same as the old version but just have more features or capabilities or be more secure. No real mention of screen, menu, navigation, terminology changes.

What Might Be A Better Approach?

  1. To start with, companies need to take their investment in software seriously. A primary and secondary stakeholder (owner) should be assigned to every product.
  2. The stakeholders should have ALL of the software company purchase information and contacts, both sales and tech support. If there are Admin User IDs and passwords, they keep this information.
  3. The stakeholder should know about any changes so that they can communicate with all the users, and if needed, provide training.
  4. If a stakeholder leaves the company, another person is assigned, and the Admin passwords must be changed and documented.
  5. There should always be at least one person who knows the product well, and can train others on it. If that person leaves, another person needs to be assigned.

I have found that, the closer a company keeps in touch with a software vendor, the more likely the software will be more fully used. I have also found that, if you volunteer to be a tester or on a review committee, the more likely changes that you need will happen (squeaky wheel gets attention). Another benefit of maintaining good communications is that, when you have a problem, you generally have someone higher in the tech support food chain to call.

What Does This Mean?

  1. Company management (sometimes HR) needs to know WHO is responsible for every piece of software in and out of house. If the responsible person changes jobs or leaves, the company MUST find a replacement person(s) ASAP. The most ideal case is where the outgoing person braindumps to the new person.
  2. Have a checklist for a new application owner to follow: A) contact the person in the company who their predecessor was working with, B) find out if there are any action items that are open, C) are there any financial issues existing or coming up (this could be a big one), and D) if the new owner has not been trained on the product, see that they are.

The Employees Perspective:

You start working in a company and are given a desk with a computer. Someone in HR or IT gives you an email address, User ID, and Password ( and at best tells you to change the password the first time you log in). You log in and find one of two things: 1) an almost empty screen, or 2) a screen with a bunch of icons - only some of which you recognize. In the first case you start clicking around to see if you can find something you recognize so that you can start working. In the second case, you click on something you recognize and start doing some work.

A new employee may be given the company handbook which ideally explains what software is available to use and what resources are available in case you have questions. Another approach is the Partner or Buddy system where another employee is assigned to you to show you the ropes. The result from both of these is typically not that good: 1) the manual is typically out of date, and 2) the Buddy only has time to show you some of the capabilities - after all - weren't you hired to do this job.

A Possible Solution:  What if the main software stakeholder started off with putting together fairly short videos that new employees would view, and they were required to watch. You could then use the Buddy system to ask the newbe if they had any questions, and to possibly demonstrate what they learned. After the employee has used the software for a week or so, the Buddy would then ask how they are doing and if they had questions. This proactive approach has proven to be very effective for both the new employee and the Buddy. In the most ideal case, the Buddy would refer the new employee to other videos and then go through the same review process.

Company Financial Benefits:

  1. Using training videos means that you are saying the same thing to both existing and new employees. This will reduce cost because it reduces errors caused by experimentation.
  2. If the software is modified, followed by updating the training video(s), then all of the users are asked to view the new video. This will reduce "time loss" due to the fumble effect (fumble around until you find out how it works).
  3. Find the one or more employees who are very good at using the software, and make them Buddies. Ideally you can provide some incentive for doing this.

Should Software Be Viewed As "Buy it and use it"

By now, you should have answered this question with a big NO. Companies who function this way are generally not taking full advantage of what they have purchased, and could be losing money. Software should be viewed as a longer-term investment that has operational cost associated with it, including: Upgrades, new versions, single point and group training, stakeholder management, and more.

Worst Case: I was called in as a consultant to a company who had upgraded their ERP software, and were having issues getting the software company to: 1) integrate the old data into the new system, and 2) train the staff on how to use the software - the way it used to be. There were a couple of reality checks here to start with: 1) the database structure and naming of the new product was different from the old, and this required re-mapping all of the old data so that it could be imported into the new, ad 2) the new software functioned enough differently from the old, that the entire accounting staff needed to be re-trained. This entire change process took almost a month, and the person responsible for the decision to change was fired. NOTE: That person said that the software salesperson had assured them that there were no issues, and had put this in an email. The sales person was fired, and the software company was sued. PS: I was still paid.

Best Case: I was called into a company that was going to a new manufacturing software platform and wanted an extra set of independent eyes to look at the project and product. The stakeholder had put together Requirements and Specification documentation, and had obviously done his homework, including using Gartner and Forrester reports. I did notice that there were a couple of holes: 1) only training for one person, 2) minimal user documents, 3) no online training available, and 4) a set number of support hours until the company had to start paying.

In this case I recommended revising the contract to include: 1) training 2 people initially, and 2 more within a 3 month period, 2) to provide much more user documentation, especially online and/or video, and 3) doubling the free minimum tech support hours. I worked with the software company to show them how putting video training could help them sell more product, and a fairly low cost. I also introduced them to Adobe RoboHelp which could help both clients and the inhouse support staff.


  • Software should always be viewed as a long term investment that requires operational support over time.
  • Software should always have a primary and secondary stakeholder who is responsible for maintaining ALL related documents.
  • There must be a training program in place for all of the software that employees are expected to use.
  • If the company is going to do a major upgrade or replacement of software, it would be a good idea to bring and independent consultant to look over the project and product to assist.

Share This Post