Archive of Process

Measure Twice, Cut Once: How To Standardize a Salesforce NPSP Account Model

ID: 22073 by tgroden November 05, 2016 Process 0 Comments

A Case Study: Who Did We Help?

We were asked to help a Canadian nonprofit group (approx 80 employees) with their Account Model standardization. One important part of any Salesforce CRM implementation is the Account Model – which defines the way that people (contacts) link to companies (accounts) in the system. This relating of objects has its source in the “Business to Business” focus of the Salesforce product story. This Account Model can vary system to system (there are 3 primary models), and sometimes within the same system. Often an organization running their business on Salesforce will want (or need) to standardize this model across all their data/records. Optimally, the organization does this standardization pre-emptively, enabling better data quality and system usability, however, this effort is more typically a reaction to problems with applications and or integrations and sometimes simply required by new vendor products. This client had purchased an engagement platform app called StepUp which they were told required the newest account model; this requirement was the trigger event towards account model standardization, and thus begins our story. The client had also been warned (for some time) that the old model caused reporting to be slow and sometimes time out; more evidence that a standardization was a good idea.

This client’s Salesforce ORG (approx. 5 years old) had 800k+ contacts, 5 integrations, 27 packages, 58 triggers and many workflows. The ORG was a production instance sending a very large number of weekly emails via one of their integrations, so business continuity impact was a key concern.

Before We Get Going, A Bit More About NPSP

The Salesforce Nonprofit Success Pack (NPSP) is an open source set of managed packages for Salesforce, specifically oriented to help non-profit organizations track donors, clients, volunteers and others.  It has been developed over many years and has a strong developer community dedicated to it. The NPSP has 3 account models that it supports: 1:1 accounts (each individual has one account: themselves,) the “bucket” account model, in which individuals are connected to a bucket, like “individuals.” The third, and optimum account model is the household model, where individuals are related to households.

How to Make This Model Standardization Successful

There are two ways to accomplish this account model shift. One option is an automated tool which will go through the data (just the data..) and make the account model change for you. Please review the web content for this tool very carefully, and heed the warning “The changes you make with the conversion utility are irreversible changes.”. The other option is to do the shift “manually,” by working through the necessary changes object by object. Open-Issue looked carefully at the risks involved in this process, and opted to do the manual process.

A Quick Note On Risks
Risks for this client meant that inbound lead generation and email acquisition, or outbound emails could stop. Additionally, more than 20 of their development and program folks would have had significant interruptions to their day-today work, not to mention the related potential for anxiety and panic! Given the number of integrations, users, packages and custom APEX, we opted for the manual route… its not just because we like difficult stuff you know…

First, the team needs to have a project manager who can not only keep the project on track, but also is able to communicate with many different stakeholders and vendors before the project even really starts (see more about risks below). Also, having both a data analyst and systems analyst on the team is critical – both sets of expertise is necessary for a project of this sort to succeed. When integrations are present, the interplay between Salesforce, NPSP package automation, the data model(s) and the integrated systems is much more complex and requires staged testing to completely mitigate potential for outages.

There are three places where an account model shift of this sort will have important implications. First, there are packages that the organization has installed. Some of those packages may, or may not be affected by the account model shift. Second, there are workflows and triggers, and again, some of these may or may not be affected. Last, but not at all least, are integrations that the Salesforce ORG has with other applications. In this case, the org was integrated with Marketo, WordPress, and Drupal, not to mention the new integration with the Percolator product waiting at the door..

  • Detailed Workflow, Package and Integration Audit – Measurement of Complexity

The first thing Open-Issue took on was to measure the complexity of the project. We combine a set of assessment best-practices to obtain a “MOC” – or – Measure of Complexity, which considers all aspects of the effort including human factors, technology, roll-back plans, external events and constraints, and a combination of internal and ecosystem precedent. This project (on our scale of 1-5, 5=most complex) hit right around 3.2. Anything over 3 forces a higher level of prep/test. This initial assessment let us properly resource and manage timeline expectations for all parties involved.

The bulk of the project fell into two key areas of effort; first, the audits (packages, workflow, triggers, integrations) and second, coordination with Marketo technical staff on T5 cut-over sequence of events and integration sync planning. We always create a technical workbook ( We love Google Apps!) for our projects and have linked a redacted version of this project’s workbook here. A significant part of our consulting work over the years has met with an all-too-frequent dead end called “we don’t know”. This project, and this type of transition in general, will deliver you those responses – from vendors and from your own team; be ready, be brave!

  • Detailed Sequence – What is Our Step By Step Process for this Org?

Any successful CRM (or really, technology project) will have a planned sequence of events. There are always some things you need to make sure you do before or after others. And documenting and reviewing closely two levels of sequences (Seq 1 = High level, Seq 2 = low level) is a critical step for this type of multi-variable, multi-vendor transition project. The link above to our Project Workbook will get you access to our Seq 1, let us know if you’d like the Seq 2 document… its a lot more detailed! You can dive into the timeline here.

  • Sandbox Testing – More Risk Analysis

We had to enable the Percolator people to test their app against the large-row-count ORG of this client, while also proceeding along our audit steps, so we decided on 2 sandbox environments for the project (one Dev, one Full – which is a paid service of Salesforce). By having 2 sandbox environments, one engineer could proceed to test the sequence of data changes at the same time as the vendor could test app performance (this done in the Full sandbox), while the second engineer could do package, trigger, workflow and integration testing in the other (this in the Dev sandbox). Setup of these environments was key to coordinating the 5 groups involved in this transition.

Summary – Front-Loaded Process

This project took almost 125 hours – and much of that work was in analyzing risk, and communication with vendors. It is the sort of project where if you know everything, you can do it quite quickly (less than 20 hours) – but you never know everything! Because of the complexity of how objects, packages, triggers, workflows and integrations intersect and interact, understanding the effect of such a fundamental change as an account model shift is necessary before the shift is actually done. And that takes time, and attention to detail. Measure that thing twice before you cut!

How To Carry All Those Nuts

ID: 2016-08-25.1 by tgroden August 25, 2016 Philosophy, Process 0 Comments
My work in data system consolidation is very rewarding; I greatly enjoy the challenges that our clients bring us, and love working with my team at OpenIssue to solve problems for those clients.

A few years back we established a pro bono practice and a series of low cost “kick start” conversion services (using a fixed fee model) and have treated those projects as some of our most important work because they are most constrained, and often the clients are most in need. The ones we love are referral, and fast. The ones we fear start with an RFP. We understand an RFP when its policy driven, but that is not often the case in the small nonprofit world.

We recently reviewed an 18 page detailed specification which described a very complex tool set and information system likely to cost at least $40k to implement and another $10k/year to maintain (at least!). The 2 hours I spent with the prospective client went into the document, and helping them understand their document’s content and its translation into real-world software options.

What they really needed instead was a $5k, two week “quick start”.

We understand (and see quite often) the incentive for a small nonprofit to write a big spec to allow for catching as much as possible (from funders, from software, etc). Low or no-cost systems like Salesforce™ allow groups to move quickly into new systems without the former complexities of server and installation. With the ease of communication with other users and ecosystems of advisors and consultants, why are these groups not simply taking the free stuff? Vendors (like us) will quote (and build) the world for a client – if that is what the client asks for! So is the RFP helping then?

Its tough to get folks to:

  • See the value in simplicity and speed of transition with SaaS tools
  • Realize data conversion is complex and should be done by experts

In search of council, I turned to a friend (we’ll call her “S”) and client who was familiar with the RFP process and the prospect’s situation, and I asked “How can we help these folks go after more realistic, and sensible goals?” The reply we got was:

Watching her the and struggle with figuring out systems, reminds me how much time is wasted, and stress is caused for people trying to do awesome work. And how regularly non-profit leaders have to make game changing decisions about stuff they don’t have capacity to understand.

Keep doing what you are doing – providing authentic, nonpartisan (ha!), trustworthy leadership in this space. I’ll chew on how to help the little orgs better, but I think you are already well down the path.

This is officially a “favorite” email ever. Thank you again “S”, and to all our great clients and ecosystem partners and allies.

Here is the prescription I wish I could write for all nonprofits and higher ed groups:

  • Consider an advisor who has made this type of transition a few times. If we can’t help you – we can find you a few folks who can.
  • Lean on incumbent tools if they can be improved – as an alternative to switching.
  • Be honest about your operational needs from a software system (rolodex, lists, email, donations).
  • Consider the Agile/Iterative model – some of these people have good advice on that:
    • Guy Kawasaki  -Iterations and fast/frequent work product to garner feedback is more valuable than the “perfect product” (which never appears…)
    • Eric Ries  – The idea of the “Lean Startup” and “Validated Learning” further supports iterations, and small steps in the right direction – not plans that map the whole journey.
    • David Kelley, IDEO – Kelley believes that how quickly you create an initial prototype is directly proportional to how successful a product will be. Essentially, given a set project deadline, the earlier you invite feedback, the more chances you have to revise and improve. He calls this “enlightened trial and error.” (citation source: http://ecorner.stanford.edu/videos/686/Design-as-an-Iterative-Process)

Buy or Build? NetSuite Customization

ID: 2015-02-08.1 by tgroden February 10, 2016 Process 0 Comments
These days, figuring out how to implement a system that you need for your business can be a challenging process. Do you buy something “off the shelf” which has most of what you need, or do you build it on top of a SaaS system such as Salesforce or Netsuite, which allows you to build a lot of custom functionality while leveraging a best-in-class CRM or ERP system?

We approach the decision by breaking things into two important groups, the “knowns” and the “unknowns.” The “knowns” are things to expect, including: a prioritized functionality list, an assessment of “canned” products already out there, an assessment of how much config a “canned” solution would need, the need to set time & money budgets (don’t forget consulting costs), and finally, allocation of internal resources for the effort.

The “unknowns” are  examples of the unexpected, including the fact that custom software build projects are a “new thing” for most teams. Finding the right consultants can be time consuming, and un-planned impacts can slow timelines and increase internal team resource load. Change management, adoption and training are always more difficult than expected, and it can be challenging to align business stakeholders during the project (again, whether built or bought).

Building a formal process document, or several, (typically at a very high level) with all key users can allow internal and external project team to align around a single vision which is an essential factor when designing software.

We recently designed and built a custom part number configurator for the East Coast manufacturing firm Equilibar, LLC, working with the operations team under David Reed. We started with getting an idea of what they wanted and quickly moved into the design/build discussion based on our review of their ERP system (NetSuite) strengths and weaknesses. We looked at one viable “buy” option, and assessed the gaps if we followed that path. The end result was to build instead of buy.

I recently spoke with David Reed about their decision making  process.

The native functionality of Netsuite would not allow us to efficiently build specific elements we needed for our pressure regulator manufacturing business. For years we had used work-arounds that included databases written externally in Microsoft Excel. This added complexity required us to use multiple pieces of software for any given task rather than using Netsuite as a true full function ERP package. To find a solution that would allow us to build part numbers, for example, within Netsuite, we looked at both market ready packages and custom written software. The ultimate deciding factor was the realization that off-the-shelf products were not going to eliminate the need for custom development. The great likelihood was that we would still need to locate and engage a custom software company to modify the off-the-shelf solution. That approach did not mitigate any of the risks usually associated with custom software development, and in fact may have created additional risks given the greater number of parties involved. If we were going to need to write custom software anyway, why not just write the software from scratch to meet our goals exactly? That is what led us to engage with OpenIssue to develop our tool within NetSuite.

In working with David and his team at Equilibar, our first step was to create a meta-sales process allowing the team to “see” where a customization could be needed. We established a rough baseline specification to start the process, and moved into it designing both functionality and day to day business process, keeping in mind that the new software functionality will need to work for the team, and may change as we build it. We implemented an Agile design/build approach, working around a base spec and the needs of the team, and within 5 weeks had a working prototype.

We believe the time spent on process design/adjusting then clear documentation is a great way to align tech, vendor and internal stakeholders around any project, buy or build. The process becomes a go-to document to help with scope creep, prioritization and escalations.

SaaS Services (rental software) afford businesses lower cost system with everywhere-and-always access (mobile, etc), and scalability. While these benefits are clear, they come at a cost: one size fits all. Most SaaS systems offer customizability as the fix for this cookie-cutter approach. Customization is a cost.

This paradigm shift to SaaS has been so profound, and yet there are still gaps for specific business needs. How then does one make a decision on Buy or Build?  A few questions to ask yourself:

  • Is building this customization a part of a long term vision?
  • Have you looked closely at where your current systems are inefficient?
  • Do you have recommendations for consulting teams from trusted advisors?
  • Can customizations benefit the majority of current system users?
  • Could customizations replace manual process or duplicate effort?
  • Are you having a hard time finding “baked goods” available in the market?

These questions will help you not only make a decision of whether to buildor buy, but will also guide you in the process of building a custom system, or configuring an out-of-the-box product.

We love helping clients identify options, and make smart system design/implementation decisions. Let us know if we can help you with a technical project. 

CRM Functionality Lists

ID: 2015-08-03.1 by tgroden August 03, 2015 Process, Technical 0 Comments
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.

How To Choose a Cloud System: Test Your Top 10

ID: 2014-09-17.1 by tgroden September 17, 2014 Process, Technical 0 Comments
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?