So - how do I pick a winner? What to look for when buying SaaS software. (Part 1)

saas_software_

I said in my previous article that this is a subject worthy of some time of its own. So here goes with a really broad topic. There are lots of factors to consider when looking at any software purchase. I will cover two here, and others in a future article (or articles as the muse takes me).

1) What does the business need (and in some cases what are the competing needs of the business)? Of the different needs, which are more time sensitive and or critical?

2) Do we already have a way to achieve the needs? And have we thought them all through?

Others will include :

3) What is the matrix within which we want to solve this problem?

4) Can we afford to do it, can we do it right, and can we afford not to do it?

1) What does the business need?

Worthy times have been devoted to finding this out, with metrics and references aplenty. If you ignore the books and just ask twenty people what they want, you will get thirty conflicting answers. Thankfully there are tools and approaches to gather up enough information to get on with.

The MoSCoW method (has nothing to do with the city but it’s a pretty picture, isn't it?) would be one approach.

It involves gathering all the varied requirements and working with the project stakeholders to analyse them on the basis of what they “Must have,” “Should have,” “Could have” and “Won't get.” With that understood, it’s possible to then wrap timelines around them and go to market with a pretty good idea of what you want.

But what if you don't understand what is possible at all? Then some initial market analysis should provide some idea of the art of the possible, into which this thinking will slot. Struggling to determine whose needs win out? That's what executive sponsors and senior management are for.

If it’s hard to cut through the list of "Must haves" that emerge with interest in solving a problem, perhaps you can try the Five Why's approach. You keep asking why (typically up to 5 times) until a need or needs emerges. So for example:

Question: “Why do you need a new appointment system?”
Answer: “Because the current calendar causes problems.”

Question: “Why does the current calendar cause problems?”
Answer: “Because it’s part of our email solution. Security and sense tells us not to share that with the world.”

Question: “Why is the appointment calendar part of the email?”
Answer: “Because staff need to juggle internal meetings and let customers book in with them as well.”

And as if by magic - the need emerges. In the example above, there’s a need for an appointment calendar that can be exposed externally, one that integrates to staff calendars, that secures some information but also offers available times to the end user. It’s just one approach - but it might prove useful.

2) Do we already have a way to achieve the needs? And have we thought those needs through?

[Photo here by Anders Jildén on Unsplash]

If the needs are simple and within bounds of tools you already have, it is very important to consider that first. Buying a second CRM to add a single feature set is likely going to create more problems than it’s worth.

Equally though - the gap analysis between what a business has and what they really need can be incredibly useful when buying a solution. You know what you have, where problems have been in the past and what might be the start of a solution.

I have seen cases where a customer comes to me, wanting a better version of what they have (“I need this feature”) rather than taking a more complete view of what "good" looks like for them.

Sometimes, especially when the potential gains are larger, it makes sense to ask an expert how they solve the business problem and be willing to try something a little different. If there is one thing 25 years in professional IT has taught me is that most solutions evolve over time, not just because of what is needed, but because of other factors.

A developer likes a coding language so he/she uses that. Later on, someone adopts a module in that language to implement an extra feature that is close enough to what a customer wants. Then its customized later by someone else because of a feature which was a nice to have. And on and on. Eventually, the organic system has a long list of "we do it like this" attached which doesn't really reflect what the business needs to do now. Subject matter experts can usually work with the business to help unpick their requirements.

Up next ... So - how do I pick a winner? What to look for when buying SaaS software. (Part 2)