Launch Considerations Checklist: 10 things to ensure a smooth launch of your new GMS, and what to expect in your first year.
You’ve spent months selecting a vendor, preparing requirements, implementing, and testing a new system. With a launch date on the horizon and your teams preparing for a new round of intake for the first time in the new system, what can you do to ensure your project is a success and not a flop?
Across over 200 digital transformation projects, many of them in implementation and implementation support, we’ve developed this list of considerations for how to prepare for a successful launch of your new GMS.
As your go live-date approaches, keep these 10 things in mind:
Confirm you have user accounts created for your staff and users with the appropriate profiles and permissions, so that you avoid issues out of the gate when users start using the system for the first time. Your vendor or implementation team should be able to provide reports or dashboards listing all users with their respective roles/profiles/permissions. These reports are also handy to have for regular system audit purposes—we recommend that admins monitor who has access, on at least an annual or quarterly basis.
Have a plan for going live with grantees. Know when to turn on registration and ensure that you have staff briefed and available during those periods to respond to any issues.
- Will you be sending a mass email to subscribers letting them know to register?
- Will you have to reset passwords of users who were migrated into your system?
- Will you have to coordinate with your marketing/communications team to make an announcement on your website or newsletter, with a link to your registration?
- Who will be approving, processing, or providing support for issues with registrations?
Set up dashboards and reports before launch, so that your staff are equipped out of the gate to do their work. This may include dashboards that show filtered information relevant to specific roles/users, (i.e. payments they have to send out, proposals awaiting feedback/review, grants pending final approval), or program specific dashboards that show all relevant details.
Know your support resources and where you can turn to for help. Having your resources lined up before you actually need to troubleshoot issues will save you time during a stressful situation.
- Collect any build documentation and training materials from your vendor or implementation partner in one place.
- Sign up for the vendor’s support community or knowledge base.
- Subscribe to any release or product announcements from the vendor and any integration partners.
- Know where to find the support numbers, contact forms, etc., and ensure you have an account with the vendor’s support ticketing system.
Setup an internal ticketing system or inbox for your internal staff to contact you with any questions or issues post-launch. This can be a Slack channel, a MS Teams chat, an email inbox, or online form such as Airtable for staff to report any issues.
Confirm if your email notifications are configured and enabled for your GMS. Some GMS’s have the option to route notifications through your own email server, while others may send emails out directly from the vendor’s mail servers (in which case, you should confirm the reply-to and sender name is configured with your foundation’s name, and that replies are sent to a specified inbox).
- Will email notifications be sent out automatically? Some systems have an email queue that holds all triggered emails for review instead of sending them out automatically. This can be a good safeguard to enable for the first few weeks post-launch to ensure there is a safety mechanism to catch any errant emails.
Clean up any test records in your system left over from testing, and establish a convention for test records in production going forward. You may want to keep some test records in production for training purposes (and for staff to experiment with). In these cases, it is best practice to follow these guidelines:
- Have a way to clearly identify test records (checkbox, flag, or prefix in the name). For example, “TEST Organization”, “TEST Grantee.”
- If you normally grant in whole amounts, use amounts with cents (ex. $0.99) for any payment or grant amounts on test records. This will allow you to quickly spot if any reports or aggregations contain test records.
- Use small amounts for test records so that the results/impacts are less disastrous if they were accidentally included in reports or communications (a $19.99 test grant being included will have less impact than a $1,999,999 test grant).
Confirm that you have a sandbox or pre-production environment configured and up to date. You may need to make configuration changes post-launch, and it is extremely recommended to test such changes first in a test environment before making the change in production.
Have a mechanism in place to collect grantee feedback on their experience in the new system after grantees have registered or submitted an application. Ensure your grantees feel safe and confident that their responses will not affect the review of their application by directing them to a third-party, anonymized survey form such as SurveyMonkey or Google Forms, or direct them to submit a review via GrantAdvisor. Sample types of feedback you can collect include:
- Was the registration process quick?
- How long did it take to fill out the application and gather the necessary attachments?
- Were the questions on the application clear and unambiguous?
- Is the portal intuitive and easy to navigate?
Celebrate your launch! This step is often overlooked, but is essential for the success of this launch, and in laying the groundwork for future projects. Often with the stress of the impending launch it is easy to lose sight of the journey so far and how much work the team has put in to get this far. Celebrate this significant milestone and show your appreciation for your team for supporting this project.
Common Post Launch Questions & Issues:
While your launch day is an exciting milestone to celebrate, it’s far from the end of your journey with your new system.
Here are some observations on the common questions or issues a GMS admin can expect to face in the months following a rollout—make sure that they’re empowered with the resources they need to address these common issues, to ensure a smooth path to team-wide adoption of your new system:
1-2 months post-launch:
Your team and stakeholders will likely need some support in the following areas:
- Access issues (how to login, reset password, browser compatibility issues).
- How to find information and where to search.
- How to find dashboards or reports.
- Understanding any new processes that have been built out in the GMS (e.g. who do I send this application to next?).
2-3 months:
As staff start to use the application more and are putting applications through the end to end approval process, they may start to encounter specific issues such as:
- Cannot approve or move an application at a particular stage.
- Cannot edit or create records, reports, letters or email.
- Problems or questions relating to specific tasks in the system (ex.voiding payments, rescheduling progress reports, etc.)
6+ months:
Typically after a foundation has completed a full granting application cycle in a new system, suggestions for changes and improvements based on feedback will arise such as:
- Adding, reorganizing, relabelling, or removing fields on the form.
- New dashboards or reports.
- Adding or changing email notifications.
- New letter templates.
- New application forms or new programs launching in the GMS.
- Changes in the approval workflow.
To help ensure that you realize the full return on your investment in your new system, plan for a thoughtful launch, and make sure that you allocate resources for ongoing maintenance, updates, and training.
Grantbook's team of experts can help you select, implement, and optimize your philanthropy tech. We'd love to schedule a call to learn more about your needs.
