Selecting and implementing a Grants Management System (GMS) is often a resource-intensive process. Understanding your options is a huge undertaking on its own, but you also need to understand how your foundation’s processes will translate into these systems. Add in a hefty dose of change management to bring your team along and get them excited about the new system, and preparing resources for testing and maintenance post-implementation, and it can be a daunting task.
Across more than 200 digital transformation projects, many of them focused on GMS selection, implementation, and optimization, we’ve helped many foundations realize the full potential of their tech investments. This post outlines the factors that may contribute to the complexity of your GMS build, to help you navigate demos, statement of work conversations with vendors, and to prepare your team for the implementation and adoption of your system.
All funders exhibit complexity in different ways, and therefore are difficult to compare in broad strokes—you may have a great deal of complexity in some areas, with more straightforward and simple needs in others. Understanding where you really need complex functionality, and where your processes can be streamlined, will help you realize the full return of your investment in your GMS, and strike the right balance between functionality for your team, user experience for all of your stakeholders, and long-term manageability of your system.
Tech is just one piece of a much larger puzzle: you also need your people, and processes aligned, or run the risk that at the end of an implementation, your team sticks with the same shadow systems, workarounds, and outdated processes that have become habits.
Applications and Workflows:
Number of Application Types
A large number of application types can contribute to complexity in ongoing management, as changes need to be rolled out to all applications when applicable. The differences among them can also be harder to keep track of, especially for end users determining how to use the system.
The low-end of complexity of this would be one or two application types and the high-end would be seven or more.
Form Complexity
In order to accommodate multiple use cases within fewer application types, some foundations build more complex forms, with detailed visibility and/or compliance logic. This can result in fields being on forms multiple times, and having several layers of visibility conditions applied. This can increase the risk of bugs occurring during testing, and can be more difficult to manage post-launch.
For example, we have worked with foundations who have different questions based on the program area being applied to. Rather than build a separate form for each program area, an applicant selects the program area on the application form and different questions are displayed using conditional logic as a result. If there are different required fields across the programs, every other part of the form is more complex as a result.
A large number of fields, or a lot of custom code to manipulate the design of the form can also increase complexity.
Workflow Complexity
Workflows help move a grant through the various stages of the application, review, and approval processes, and are often based on user roles. At each stage of the workflow, the team member responsible for that function moves the process forward.
On the low end of complexity, workflows are relatively linear, standardized, and short (with a low number of distinct workflow stages). On the higher end of complexity are workflows with complex approval paths, or variables which lead to skipping stages—which need to be defined and coded into the workflow—and long workflows with a large number of distinct stages.
Internal Processes:
Integrations and Automations
Most GMS options offer automation features within the product—i.e. workflow stages that trigger emails, writing data, etc.—but many foundations also leverage an API to expand the system capabilities. APIs allow connections to other systems, or can be used to initiate updates to the database as a result of triggering actions (i.e. a save of a record).
Another common use-case is leveraging middleware connectors or a data warehouse to connect to business intelligence tools such as PowerBI or Tableau. These connections and integrations may or may not be completed by the vendor—if your vendor does commit to this work, it will increase your SoW. If you opt to hire someone else to do the integration work (i.e. a consultant who knows PowerBI really well), or take it on internally, it won’t increase the complexity of your GMS implementation, but will have an impact on your tech ecosystem as a whole.
Custom Data Model
For a GMS implementation, you can expect a common data model (organizations, users, grants, payments, etc), but many foundations have requirements that fall outside of these objects.
Any data objects that fall outside of “standard” grantmaking practices (ex: publication tracking, marketing campaigns, impact measurements, risk management, etc.) will increase the complexity of your GMS. Adding more use cases and unique requirements will broaden the scope of implementation, and increase the complexity of design, build, testing and training.
Security and Permissions
Foundations that operate on a more open permission model—where all staff have access to all data across the organization or programs—sit at the low end of complexity, as they do not need to manage a hierarchy of what users can access which information.
Organizations on the higher end of complexity typically have multiple roles, user types, and rules for who can view information. This can create more complexity when managing your system long-term, as any changes to your system will have to account for (and test) all of the various permission sets that have been set up.
For example: let’s say you have a form set up, and John can see the top half, Marsha can see the bottom half, and Jacob can see the whole thing. If you change something in the top half, you have to remember to test to make sure that those permissions are still intact, and that the change doesn’t lock out John from the top half of the form, or display the top half for Marsha. These permissions settings introduce risk of overlooking something when making changes.
Introducing a hierarchy of permissions also introduces the risk that your users will run into roadblocks, or try to find ways to work around these settings by asking other users to take actions they can’t.
Additional Factors that Impact Complexity:
International Grantmaking
Multi-currency: Many GMS options have multi-currency functionality for FX conversion rates, to convert all grants/payments to a single base currency. Some foundations choose to enable this functionality (higher end of complexity), or to simplify grantmaking by disbursing all funds in the currency of the country where they are based.
Multilingual support: As we discussed in this blog post, building true multilingual functionality in your GMS can introduce complexity as you manage changes and testing in each implemented language.
Collaboration
Multi-partner collaboration: In scenarios where multiple partners/parties need to collaborate on a project proposal, and eventually report back outcomes and activities, additional complexity is introduced. While many GMS’s are configured to handle fiscal sponsorships (standard functionality), other types of collaborations will increase the complexity.
Miscellaneous Factors
External Portals: Portals for your grantees and external reviewers are fairly typical for a standard GMS build. Additional portals (i.e. for board members, or consultants/auditors, etc.) slightly increase the complexity.
Data Reporting and Analysis: Many foundations opt to use middleware to connect to third party tools for impact reporting (i.e. Tableau, PowerBI, etc.), but if you prefer to leverage the reporting capabilities of your GMS, this increases the scope of your build. Many systems have dashboard and custom report features and they vary in their capabilities. The more dashboards and reports built, the more time required in the build, and possible maintenance over time.
Bank Accounts or Other Sensitive Information: Processes to intake, verify and confirm partner banking significantly increases complexity in terms of workflow, security, and permissions for the foundation. If you need to collect and store sensitive information, you need a plan in place to protect it.
As you consider the potential complexity of your next GMS, don’t forget to think through the change management and training implications! Tech is just one piece of a much larger puzzle: you also need your people, and processes aligned, or run the risk that at the end of an implementation, your team sticks with the same shadow systems, workarounds, and outdated processes that have become habits. While it won’t impact the scope/complexity of the build itself, we encourage our clients to dedicate time and resources to change management and training, to make sure that the new system is sticky and delightful for your users.
Understanding where your organization falls in terms of complexity can help you identify areas to consider simplifying, what is a nice-to-have for your new system, and where complexity is necessary for the type of work you do. This will help you allocate resources as you prepare for the build, during implementation, and post launch. Keep in mind that as complexity increases, so too does the importance of testing, so be sure to allocate time for your team to adequately test, and to do the same when rolling out enhancements post-launch.
Grantbook provides implementation support to top foundations around the world. By bringing Grantbook alongside to play roles in business analysis, change and project management, testing, and training, we can ensure that your team participates meaningfully in creating, validating, and building confidence in your new system. Reach out to learn more about how we can help you realize the full promise of your investment.
