Archive of Technical

CRM Functionality Lists

16885470_mIn 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.

Human Resources Systems: Data Conversion Preparation

Some in one group, others in another..

Some in one group, others in another..

Data conversion preparation is a key step in making sure you have a successful transition to your new system. Preparing for a conversion of benefits data from different HR systems, such as converting from ADP to Workday, will introduce some entity layer keying challenges. Entity layer keying is the way in which individuals are identified as unique in a particular system. Often, especially when you have multiple data sources, individuals can be keyed differently. For instance John H. Doe in one system could be J.H. Doe in another, and Doe, John, H., in a third, with three different unique IDs.

With HR data, its all centered around an individual human. Create a way to identify everyone as a first order of business. This will save time for the data team, and for design and test folks too.

So the first step is to create an entity layer key.

Typically there are 4 types of “humans” in the system:

  • Employees (current, former, part time, etc)
  • Dependents
  • Beneficiaries
  • Trusts and other entity-proxy records

Keying this will allow for unique identification of the entities for later data juggling – and – will also force (early in the process) clear definition of variance from this list of 4 profiles – allowing for more complete target environment configuration on plans and eligibility.

The second step is to clean some of the source data

Dust stuff off a bit in the source database. Take these basic steps and a lot of the new SaaS based HR systems will like you better:

  • Complete all addresses; incomplete addressed, DOB, SSN.
  • Identify where zip code based coverage will be tripped up by decentralized pool addresses.
  • Identify election and effective date data hooks for all 4 type of humans.
  • Surface any “relationship” data hooks and any required variance therin.
  • Audit all free form text fields where a name is/can be entered and assess impacts.
  • Newer systems understand “Domestic Partner” better than older systems, look at the relationship data footprint in your system and surface it as you will hit conversion issues specific to that “relationship” type.

Adopt a 1% rule and bind to an escalation plan

Make sure you’re not spending too much time on too few records. Spending 3+ days on 12 entity records must be done only after its decided that the downstream effect of manually handling those 12 records is a higher cost.

Hire or assign a notes minion

HR conversions are complex and involve many steps, including often many separate stakeholder groups. This poses a challenge for data teams during test because problems to one group are often invisible to another. If you take notes, and actively manage root cause analysis methods, you can save everyone a lot of headaches as the following three key issues spin in the universe concurrently: 

  • Ongoing business (changes, adds, terminates, etc)
  • Plan and carrier conversions
  • Approaching open election dates

I think Abe Lincoln is famous for saying “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.”. Nowhere in our experience could that planning benefit a conversion team more than with HR data.

How To Choose a Cloud System: Test Your Top 10

40549475_mThe goal of talking with a vendor about a technology solution is to gather information to help you make the right decision. How do these products meet, or differ from, your requirements; What will they cost to both implement and sustain; What will not be available and may need custom development; and so on.

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?

Our Acronym List


If you want to communicate effectively, it’s important to be aware of your habits. My engineering team and I often speak and write in acronyms (you know…TLAs) and it’s not good practice, at least not outside of a conversation between propeller heads. While they convey specific meaning to us, when used outside of our team, acronyms without definition can negate their potential to make our communication easier to understand.

With that in mind, we set up an official team TLA list and wanted to share it here. Some of these acronyms are truly inspired, others are obscure, to say the least. Send us an email with any comments or additions to this list and we will fold them into our secret language.