In our consulting work, we are often pinned between a world of software functionality (and limits) and client functionality requirements (which are sometimes known ahead of the project start, and sometimes bumped into a project  mid-stream).

Over the years we have built a sort of “master list” of functionality, and have decided to setup a maintained page on this site to keep it available for reference. We will often go down this list in a client discussion to see how we rank their requirements. Sometimes potential clients and clients come to us with this list – and very often when they do it is specified at the level of the end user, not at a level that is helpful for building out a system.

We’d welcome your feedback on this list and its usefulness. We specifically use this list in our XRM Assessment reports and use our survey and data scan process to “guess” at the client’s prioritization sequence, typically igniting spirited discussions which ultimately lead clients to a more informed decision on systems, partners and approaches.

We especially like this post from Ian McAllister, on how to approach prioritization. It favors going higher up to themes (which could also be characterized as specific outcome goals, like donor retention,) then coming down to more granular levels of functionality within those themes.

So what is the best way to choose a cloud system? Why is it that people don’t test systems before buying them? Why would customers not take a few sample records from their existing environment and systems, and just walk through the simple steps (we hope) of entering them into the new system and having the whole crew say “Cool – lets buy it”.

Clients just don’t do this. We are sort of amazed at this. We have a methodology we’d like to introduce, called “Tiny Test Conversion” aka TTC. We have not seen the following published ever – so we are doing it, and welcome like minded folks to reach out to us to spread the news…

How to buy a technology system:

• Form a decision group around the vision of the project. This should include people from all your primary information system areas (accounting, development, operations, program, hr).
• Decision group creates a short list of the technology vendors seen as possible partners and contacts the companies, asking for the following:
  • We are a <# of employees> user group in <insert industry>, located in <city, state>.
  • You may want to give them your EIN, too, as that is how they rank/route you as a lead.
  • We have an annual operating budget of <$>.
  • We are considering a move from <incumbent tech>.
  • We would like a demo of your products and want to have an interactive experience where, in our first meeting, we can enter some actual data into the system during the demo.
  • Send them some version of this Functionality List — not too specific.
  • Giving them all this info gets you to the right sales rep right away. It also gives them all the information they need to know you are not messing around and need results — not just conversation.
  • Be prepared for them to ignore or avoid the “enter data live in the demo” – this is key.
• Have the decision group compile a list of 10 constituents in your current systems who represent both complex examples of data needs, but also well-known information so you can walk into a demo knowing the source data/system – and enabling you to test the target system.
• On demo day have a non-stakeholder record the following in a spreadsheet:
  • Vendor name – Sales Rep Name – Product Name
  • Action taken – Result
  • After the call – have a round table discussion with the decision group and review the Action/Result notes – and vote on if this system is perceived as capable of doing the trick.
  • Get into the demo and enter the data, and run the reports. See if the software actually work.
• Make no commitments, ask for no next meeting – explain you have to have an internal discussion with your decision group then “we will reach back out to you in a few weeks”.

The key to this exercise is to get you into the product right away and not in power point or talking. Its software – so use it. This is seriously unpopular in the sales process – but it will save you a lot of time and money.

This early-in approach also will surface gaps in both product – but also your team’s understanding of what you need – and perhaps how to talk about it in an eventual requirement document.

Going through this will help you form a team, and will begin the creation of a prioritized functionality list. Moreover, it will educate you, and allow you to move faster in the decision-making process. There are a lot of moving parts out there and cloud computing is making the playing field a very crowded place.

If this sounds difficult to do, or understand, call us and we will help you get through it no charge. But be ready to bump into readiness issues on your part!

A little backstory on why we promote this approach:

We believe that the TTC will be well worth your time and effort investment. If a ultra-tiny version of this conversion does not go well, how well do you think a big expensive one will?

We believe clients are being sold systems, instead of buying solutions. I am not sure “sell” and “solution” can be in the same sentence. This, from the desk of the guy hired to put the systems into action for the clients…

Most stakeholder groups are neither tech selection experts nor conversion specialists. We see that projects in stage 3 (initial test conversion – requirements refinement) of our 5 stage methodology framework have surfaced gaps in their requirements and goals, both human and technical, and anxiety is a little high. At least 50% of the time somebody on the client project team says: “Hey, lets just take the top 10 <fill in the blank> records from the old system/s and have just those converted to the new system and see if we can do end to end testing on those?”.

The suggestion from the client allows them to take a known set of data (in the legacy system) and see it through the lens of the new system.

Our response — Why don’t they test the software that way before they buy it?

We’d also suggest reading our post on Technology Myths when you are comfortable with these as myths, as we are, you have a new confidence and realism around making a change to your tech.

Visualization Exercise:

Imagine you are blindfolded, you are walked by the hand into car dealership, and you are told “yes, the new car is beautiful, your significant other loves it, and it will fit all your passengers without a problem”. You sign the check, then later back at the ranch you try to fit the 6 kids into your two seater which your significant other loves. Nobody lied did they?