In our previous post, we introduced the idea of the organizational capacity model and the graph of decision variability over time that helps illustrate the idea. In this post, we take the same graph but break it down differently, to reflect a project’s lifecycle.
The first takeaway in this series is that knowing your current organizational capacity can help you align the type of Salesforce projects you pursue for optimal success. You can read about that in more detail here.
Takeaway Two: Your technology enforces your organization’s business processes, which puts a burden on your organization at the same time it offers efficiency gains.
Everybody wants technology that fits them perfectly—technology that helps them do their work faster and better while alleviating pain points. When you adopt an enterprise system such as Salesforce, you have access to a powerful platform that can be made to automate just about any business process you can think of. In our ebook on the Data Maturity Model, we explain why that should be approached with some understanding of what your organization can support. In this post, we want to further explore the lifecycle of a Salesforce customization, and illustrate both the types of skills you may want to look for outside of your organization, and the tasks your organization should be prepared to take on for a healthy, well-maintained custom project.
When you first implement Salesforce, you will start by implementing some pre-built systems like the NPSP, RollCall, or 501CaseManager before moving into maintenance. If you decide to customize – whether it’s a simple process builder or something more complex with Flows or even Apex – you will take on a project that moves from invention through implementation and finally into maintenance. Each of these phases requires a different mindset and time commitment from your team, and you will have more success if you understand where you are entering the project and what it requires from your organization.
During Invention, a problem is identified that the organization wants to solve. There can be many approaches, but typically some kind of discovery is undertaken to answer questions about exactly what the problem definition is, exactly what resources and constraints apply to solving the problem, and– as clearly as possible – what the solution should accomplish. Salesforce allows you to rapidly prototype solutions and try them out, and as you discover ways in which parts of the system interact unexpectedly with other parts, you may have to dismantle and rebuild the whole thing more than once.
This rapid prototyping and rebuilding is represented in the graph as a high degree of volatility. That is because there are dozens of ways to perform any given business process, and often several ways to approach the solution in Salesforce, so a learning process must occur to find exactly the right fit between all of those variables. Prototyping allows the technology experts to learn from you what does and doesn’t work, and it lets you learn which Salesforce solutions suit your organization best.
If your expectation is that Salesforce has a ready-made solution for your unique business process, you might find this invention stage frustrating. There are times when purpose-built software does exist to extend Salesforce in a more structured way (for example, the NPSP for fundraising, 501CaseManager for human services) and a solutions architect should explore these options with you. However, anything built on top of Salesforce can be customized to some extent, so full customization to your unique needs will require a significant investment of time and knowledge from your team, in addition to the resources needed to hire experts who will build solutions from scratch.
If you decide to pursue a high degree of customization, you should expect to spend about as much of your staff’s time testing and guiding the process as the consultants spend on creating the changes; this is, after all, being invented for your organization, so you should expect to play a starring role. Once the invention and implementation are done, you also must be prepared to provide ongoing support and maintenance for the use of your customizations.
Once the project’s decision volatility has settled down and you can guide large numbers of people through the new process without having missed something important and without encountering bugs, your new project is ready for implementation. Most organizations do not invent new software – they purchase pre-built software, install it, and train their staff in how to use it. This also counts as implementation.
Getting Salesforce with the NPSP and learning how to use it through a training or Trailhead is an example of implementation. You are learning how the software operates, and you make your processes conform to that software. Using the tools exactly the way they are delivered is sometimes called “baseline” use.
We strongly recommend that organizations begin with implementing purpose-built solutions on top of Salesforce before attempting to invent or highly customize. Learn how the system was designed. Learn the rules that it comes with. When you first implement software, you are experiencing a major learning curve, so you don’t yet know what feels wrong because it’s simply new, and what feels wrong because it really doesn’t support your day-to-day operations. The other major benefit of focusing on learning the software before customizing it is that you have a better chance to get help on your questions from a helpdesk or community like the Power of Us Hub.
After you have used the baseline for a while, you will start to find that some things you thought were confusing or wrong in the beginning make a lot of sense and are fine the way they are. Only after you have gotten comfortable with the system should you begin to consider customization. This requires a real commitment to the learning process from everyone in the organization. You may find that your new software is somewhat ill-fitting, and you will have a temptation to rush to make a lot of adjustments. If you don’t wait through the learning curve, you will spend a lot of money on adjustments that are unnecessary, hard to maintain, and expensive to undo later.
When you implement software, you will likely need the help of an outside consultant to assist with setup, data migration, and training. There will be decisions that you will have to make about your data during implementation, and you will likely make some minor adjustments as you learn how your business processes work in that software. You will need to designate an internal data champion or system owner who will be the go-to for questions after implementation. Your data champion will need to spend at least as much time during implementation as the outside consultant, and often more when data cleanup is required. Your broader staff will need to commit time for training, and your data champion will need to be available during the initial launch to make sure things go smoothly.
”Humans still make the meaning, and the technology is still a relatively dumb repository for data. This has significant consequences for your maintenance and support planning.
Whether you’ve implemented the NPSP and made no changes at all, or stuck your toes into Invention waters, by the time you get to maintenance all of the important decisions have been made. You have decided how the technology will express your unique business processes and operations rules, and maintenance means that you’re not adding or changing anything major. Because the majority of your time with Salesforce should be spent in maintenance mode, it is important to understand what an enterprise system is and does so that you can plan for success in this phase.
Every organization has internal rules and cultural norms about data and the day-to-day operations that produce and consume that data. Leadership and management set and enforce these rules and norms, and they exist whether the technology that supports your organization is Post-It Notes or Salesforce. Humans still make the meaning, and the technology is still a relatively dumb repository for data. This has significant consequences for your maintenance and support planning.
Many purpose-built systems, like Raiser’s Edge or Neon, have encoded business rules in their systems that you cannot modify, so your organization has to adapt its practices and norms to their rules. As we discuss in our ebook, in many cases this is the best path for organizations at certain stages of operational capacity because it offers access to helpdesk and external support that the organization isn’t ready to bring in-house yet. Salesforce offers you a green-field platform to encode your own business rules relatively easily, so its technology adapts to you. The NPSP, 501CaseManager, RollCall and other software built for Salesforce is a mid-point between something that doesn’t allow any customization to the underlying logic and something that demands you create everything from scratch.
When you implement Salesforce (whether you’ve made extensive customizations or not), you are adopting a powerful platform that can reflect your internal practices and processes. An outside person, no matter how expert in the technology that Salesforce provides, is not an expert in the business processes, norms, and expectations inside of your organization; nor are they expert in what is normal use for you. Once you’ve begun to use the system, your business processes, norms, and expectations create the context and meaning for your data. This puts a relatively high maintenance and support burden on your organization and makes it difficult for an outside person to help.
Maintaining a healthy Salesforce instance requires more of a managerial than technical skillset. It is important that you have good documentation for any process that is supported by Salesforce, so that you can remind users when they forget and provide consistent training to new users. It is important that the data champion identified during implementation have the knowledge to create new reports, add new users, and perform very basic field maintenance such as adding new picklist values. During maintenance, the data system owner should meet regularly with business process owners to continuously assess how changes to the technology (upgrades and user requests) might impact business practices, and vice versa. This is a process called governance, that we will detail in our next blog post, and it requires ongoing commitment from many stakeholders in the organization.
Jenn is a business process designer and operations technologist with nearly 20 years of experience launching and maintaining projects with nonprofits, local government, higher education, and startups. Prior to joining 501Partners, Jenn founded a consultancy specializing in operational effectiveness for nonprofits and higher education. She brings that experience and passion for helping organizations execute in a smart and sustainable way into her role at 501Partners. Jenn holds an MBA in Nonprofit Management from Brandeis University’s Heller School for Social Policy and Management.