The phone call was from an old friend of mine who runs the IT department of a small but growing company. I was glad to hear from him and after we exchanged pleasantries I promised to help him however I could.
His company is approaching Spreadsheet Suffocation and needs a custom solution built or perhaps guidance on buying one that they can configure to deliver information to a growing customer base.
Red Flag #1 – An IT driven software project.
Small companies tend to do this — they assume that anything of a technical nature should be routed through IT. But IT people tend to look at things as puzzles first – problems to be solved. Business people, on the other hand, will first ask if the problem is worth solving. And they will quantify what the solution is worth. Once you know what something is worth to you, you have a budget. This kind of clarity rarely comes from IT.
I asked, as I usually do for a catalog of the Inputs and Outputs of the current system. This is a technique for quickly gauging the complexity of an information system. A week went by. Once I got the spreadsheets, I had a few quick questions. Another week went by before I got answers.
Red Flag #2 – Communication is a Low Priority.
If you need something and want progress made, it only makes sense that you will make time to provide materials, answer questions and accelerate the conversation toward a solution. If, on the other hand, the solution isn’t really that important, then by all means, take your time. I get it. You already had a full-time job being an IT person before this allegedly ‘urgent’ need popped up.
Peppered in among my other questions was this innocuous but significant query: Who will I talk to about the business process – the person who actually does the work and needs the new solution? Answer: “That will be me for now.”
Red Flag #3 – Insulation from the Real User.
Have you ever heard of a plumber trusting the homeowner’s measurements for laying pipe? How about an electrician using the office manager’s estimate for how many amps a circuit should carry? Of course you haven’t. But somehow, in the world of software, people who are not trained to gather software requirements presume to do just that.
Oh, they always have a reason. This time it was, “That would just cause more confusion.” (I didn’t say it was a good reason.) No software professional will ever be comfortable drawing up a blueprint based on secondhand information. It’s just dumb. Be the sponsor, be the cheerleader, be the approver, but don’t be a conduit for something the quality of you are not trained to judge.
The No-Win Project
I could spin up an effort to make my friend happy, write a document that collects bits and snatches of second-hand requirements, written over a month of catch-as-can phone calls and emails with my busy friend and finally submit a swag proposal loaded with caveats. The truth is, however, that this project needs two things to even get out of the gate:
- A business sponsor
- A customer liaison (not from IT)
Without these, the project won’t have a budget, won’t have priority and won’t have requirements that are on-the-nose accurate to the customer need. Without those things in place, what’s the point?