Don’t Get Stuck in the Middle Seat

…When buying software for your company

It's hard to imagine -- since more people have flown on an airplane than have ridden on a bus -- but I actually knew somebody in his 20s that had never been on an airplane.

“All airline seats are the same, so why bother” he explained to me, “at least in Economy, which is what I intend to fly.”

Ask the question "are all airplane seats the same?" to anyone who has flown even once and you'll hear a different answer; but in the strictest sense, he was right.

• Each seat in Economy was 49 inches tall and 17 inches across,
• they could all recline by 3.5 inches,
• they all had a tray table that pulled down from the chair in front,
• they all had the identical seatbelts,
• and they all a flotation device underneath the seat.

Conclusion: all the seats in Economy are the same.

Except you know they’re not.

The middle seat is the worst. You get crammed between two other passengers. The window seat is okay but you have to climb over people to use the lavatory. The aisle seat enables you to move freely and even stretch your legs out if nobody’s in the aisle.

Sitting toward the front of the plane enables you to make a quicker exit. The worst is having to sit right next to the lavatory when fellow passengers line up to use it after a meal and before landing.

No, not all airline seats are the same. There’s a parallel here with buying software for your company.

If you can't articulate the differences in the software vendors you're looking at, you’re likely to wind up in the middle seat “because they’re all the same.”

Having started (and sold) a software company in the enterprise performance management (EPM space) and having supported hundreds of clients as a consultant with Deloitte and KPMG as they went through the section process, I cringe when I hear “they’re all the same”. I know a mistake, one that may even be career limiting, is likely on the horizon.

For example:

• A company discovered the software they bought had limits on dimensions and had to rely on something called “concatenated keys” as an extremely costly, complex and fragile workaround.
• A company discovered after it was too late that although they need to plan by Day, the planning software they bought could budget only by Week.
• A company discovered that the planning and analysis software they bought required coding just to create a drill down path of Category > Product Family > Product > SKU… and that each separate drill down required its own script.

I can hear some readers say “I would never make those mistakes” and they could be right. But if they can’t articulate differences in the software vendor offerings they’re looking at, then there’s something else that's being missed.

Here’s how to avoid the middle seat

DO: Think through the capabilities you're going to need on a Daily or frequent basis. Even consider creating a pie chart of how you spend your time, so you can assess a vendor's capabilities to make you more effective in those areas.

For example, with Financial Planning & Analysis (FP&A) a core part of doing the job is variance analysis – understanding why actual results differ from what was planned or forecasted. So understand if the software being evaluated can enable Drill Down and also Drill Anywhere to enable the interrogation of the results and “what changed”

Or, keeping with FP&A, making 11th hour changes to the plan or budget is quite common. And those Senior Management directed changes can be complex, “Take Revenue up by another 3% except for this Region which should go up 5% and this Product Line that should go down 2% -- but this specific Product we’ve decided to discontinue later in the year so take it down by 40%.” So understand what it will take in the software you’re evaluating to make those changes.

DO: Ask the vendors to demonstrate how key everyday tasks are performed.

For example, “Self Service Reporting” is a good marketing hook, but you want to see how a vendor enables that. So ask the vendor to take a report, change the view on it (using filters, selectors, changing columns and rows, etc.) and then save it somehow so that user could come back any time to view it.

DO: Document the scope of your project (what's in and what's out of scope) and what the priorities are. This helps focus the evaluation and can save the team from distractions.

DON’T: Let the vendor’s marketing drive the bus.

You shouldn’t dismiss what a vendor says just because it’s the vendor saying it, but you need to evaluate it from the perspective of “Is this important to our team, how exactly will we use this feature or capability, and how frequently?”

DON’T: Get distracted by shiny objects.

For example, AI can be incredibly powerful and useful. But you need to think through your own use case for AI and where it fits in your documented priorities. Then, yes, you want to see how a vendor can deliver that.

DON'T: Rely on references.

Very few vendors will make the mistake of putting you in touch with a bad reference. And those that hand you a book of references and tell you to call any one already know that unhappy customers won't call you back.

Reference calls are a common step in an evaluation, just don't rely on them to make a final decision or to shed light on what's different about a vendor.

DON’T: Mix up "one time" versus frequently used features or capabilities.

For example, taking data from a source system and putting into a new system (e.g., Data Integration) is inherently one of the more complex tasks a vendor will have to perform, but it’s usually done once at the start of an implementation by the vendor or their partner, and then the data flow is automated. Understand and evaluate it, but don’t let it be a distraction from how you’ll be using the solution on a daily basis.

Buying software for your company means taking on a lot of responsibility. You own the outcome, good or bad. If you're at the end of your evaluation process and have reached the conclusion "they're all the same" you've missed something. Either take the time to dig deeper, or run the risk that what you don't know will be the point of failure for your project.