My staff have heard me use the expression all too often. “Tail wags dog! Film at 11.” As though it were a breaking news headline on CNN. I use the expression though to talk about organizations that approach our company with an interest in deploying our enterprise timesheet system or an enterprise project management system but have somehow gotten the cart ahead of the horse (Yes, I know. It’s another expression).
The conversation usually starts off quite normally.
“Hi, I’m calling because we’re looking for an enterprise project management system.”
“Great,” I reply. “How can I help?”
From there it’s all downhill.
“Let me send you our list of required features,” the caller announces and I wince in reply.
“Awesome,” I’ll say. “I look forward to it.”
The list that arrives is, sure enough, a list of features the organization has determined that it desires in its soon to be acquired enterprise projects system. The list can be short but it’s usually not. It’s a multi-page Excel workbook and it’s obvious from reading it that it has been assembled by a committee. Each interested party has had an opportunity to put what they want on the list.
Sometimes the list is weighted. The most popular weighting is 1) Must have, 2) Should have and; 3) Nice to have. Needless to say, 90% of the required features are Must-have’s.
Like all the vendors who have received this list, we respond of course. We can almost always tick off a “Yes” next to all but one or two required features and now the tail starts to wag the dog.
The organization receives similar responses from all the possible vendors and has a hard time trying to figure out who is the most likely winner of the selection. “How can this be?” You ask.
Most enterprise level project management systems are capable of delivering most of the more commonly requested features. Oh, they look different and they act different but based on the 10 or 20 word description of the feature, most vendors can either answer “Yes” or “Yes, with some effort” to all the requests. So picking the right software based on this plan has hit something of a challenge.
There’s a big missing so far in the analysis for those who have been around for awhile. Almost never in these documents do we find the business problems which the requested features need to resolve. If someone were to say “We need missing timesheet email notification to help mitigate the 30% of timesheets that can only be located now by manually and laboriously sifting through all the delivered timesheets, determining which ones are missing and then emailing or calling those people directly.” I’d be so excited, I’d write about it in these pages that very week. But this is decidedly rare.
Instead the organisation will now struggle to fit the list of possible features of each of their shortlisted products into problems they can find. It’s a solution, looking for a problem. Sound familiar? The tail is wagging the dog.
“How can this happen?” You ask.
It’s a fine question. Almost always, this is the result of good intentions run amok. The person given the analyst role in this requirements exercise gets lots of input. Everyone is trying to be helpful. But, the requests and even his or her own thinking is based in what will the solution look like. This is not at all helped by big enterprise project management software vendors showing brochures, talking to colleagues at trade shows and pumping out lots of literature about how many features we have. And, before anyone points out the obvious. Yes, HMS does this too. All enterprise software publishers do.
So the list of requirements becomes longer and more detailed and eventually goes into a purchasing evaluation process. There may be some part of the organisation that would be just as happy to have to write the system internally. This is particularly true if there are offshore developers on the team. A request for an IT system that could be written over time by a contractor is like candy for such people.
At some point the evaluation may require demonstration of the software. My least favourite demonstrations involve a pre-defined script written by the organization who as yet knows nothing about the software they’re purchasing and the script bears no resemblance to any employee’s actual work day. We try to talk prospective clients out of such scripts and focus instead on working through the kinds of problems that can be solved with TimeControl.
In my experience, if there are demonstrations involved, the organization will move forward with the vendor it “feels” most comfortable with. I say feels in quotes because organizations don’t feel anything of course. But those who are evaluating may feel that one vendor understood their issues more than the next.
So how do you get the dog to wag the tail; to get the horse to get in front of the cart? One things we do is to deploy in phases. We will do a pre-sales phase where we are identifying as many of the business challenges as possible. Then our technical staff will do a pre-deployment meeting in which assumptions we made get tested and validated by the client. When a business requirement seems fuzzy or less than certainly defined, we’ll recommend to deploy that in a subsequent phase. One thing we’ve learned for sure. No matter how well we define the requirements now, they will evolve with the client’s knowledge of the system they’re buying.
Organizations can insulate themselves from this problem by putting emphasis on the business problems they want to solve. In all likelihood, vendors will have different ways of solving those challenges and evaluating possible solutions from a perspective of “How did they solve my problem?” Is going to be much clearer than “How many features did they have?”
If a vendor and prospective client collaborate from the outset, then the dog will always wag the tail.
