Using the right tool
[date-stamp]A friend of mine works at a small company. This friend was complaining to me that the organization was a little lost concerning the computer programs they were using. I took the conversation forward and asked what exactly the problem was. He said that the organization was using all these different applications that didn’t seem to really fit together. What’s more is that this software was costing them a lot of money. My friend said that they were having an IT meeting the next week to help solve the problem. I told my friend that I would be happy to help if I could. He was excited that I would provide free software advice, and I was happy to help a friend with a problem that is semi-relevant to what I do. So he got me an invite to the IT meeting the following week.
This company has fewer than ten full-time employees. The organization has been around for about five years. To maintain anonymity, I will avoid saying exactly what the company does. Parts of their situation is generic enough that it is applicable to many different organizations and companies. I will say that their business is a little technical but not very.
I joined the meeting a bit after it started, and we were presented with a long list of items. There were twenty-odd items on the list, and they were all software programs that this organization was using. Some were cloud-based, some even SaaS, some were locally installed. I was surprised that an organization this small would need this many pieces of software to help them with their operations. They went through the list and explained what they were all for. Knowing very little about how their operations worked, their justification for each software program seemed reasonable. For every task they needed to complete, a software program could handle the job. But then I heard a lot of complaining from the staff members about how this wasn’t really true: “The program couldn’t do this…this program really needs to be like this…” No one seemed to like the software they were using.
The cost for each piece of software was then revealed. Some were free, some were very cheap, one was quite expensive; and one was mind-bogglingly, outrageously overpriced. Their accounting software was the quite expensive one and was somewhat justifiable. The overpriced one cost the same per year as several full time staff members with benefits.
After seeing what they spent on software per year, my jaw dropped…literally. My mouth was gaping open as I tried to comprehend how a company that is in the beginning of their development as an organization could justify spending that much money on software. The company was being taken advantage of by one particular software company - this company (the customer) was funding the product development of the other company (the software company). How could the company my friend works for not see this? Hiding my shock, the meeting moved forward, and they outlined how exactly these programs supported their operations. This is where the real problem surfaced.
Contrary to what they believed, there was no workflow supported by software. They used software to develop their workflow. The company did not understand that the programs they were using were tools. A carpenter does not decide what to build based on the different tools that are at his/her disposal. The organization must understand what needs to be done (i.e. their workflow) and find tools that can help them-not the other way around. There is no perfect software tool that will do the mission for an organization. Software helps, and even helps achieve things that would otherwise not be possible because it frees up manpower for other more creative tasks. But software is still a tool.
So instead of giving them software advice, in the end, I wound up giving them project management advice. I told them to write down from A to B to C what their projects needed to accomplish - without thinking of the software that was available to support the task. Create a flowchart based on the needs of the organization, not what the software wants you to do.
They agreed that this was the best way to move forward, and they would talk to me again after they did this. Unfortunately, the next time I heard from them was about helping them learn how to use a new software program. I really did not want to help them learn how to use yet another program – I am also not an IT consultant - and I felt like asking them to pay me was the best way to get them to leave me alone. And this is what happened.
My friend told me that they did, in fact, create a flowchart of sorts - more of a script - but that it did not seem to change their software problem. They were so far into the pocket of that organization that they did not want to abandon their investment. The company did cut off some of the fat - they stopped using at least one software program-but they never really changed the way they thought about software. To find the right tool, you must first understand your task.