Software implementations can be stressful for your team—in addition to their regular duties, they’re translating their processes into technical requirements for the vendor, validating assumptions and cycles of the configuration, and are both hopeful and nervous about the changes they’ll have to adopt when the system is in place.
The whole point of taking on an implementation project—whether you’re switching to a new system, or implementing a net new tool—is to make things easier for your team. And so roadblocks or delays can be frustrating and costly—especially those that could have been avoided—seeding doubt about whether the project will be worth it in the end.
In our work helping foundations implement and optimize their philanthropy tech systems, we’ve identified four common reasons that implementations get delayed or derailed:
- Underestimating Data Migration
- Building Multilingual Functionality
- Overestimating Document Design Capabilities
- Getting Stuck in Development Cycles
Underestimating Data Migration
It sounds simple: take all your data from one system, and push it into your new system. However, differing data models between systems, “shadow” data sources like individual spreadsheets, and no-longer-relevant historical data can significantly complicate a data migration process.
Moving into a new system provides an opportunity to review your data strategy and governance—what data are you collecting, and why? What do you need to track to measure your impact, understand the communities you’re serving, and build relationships with grantees?
Take some time getting to know the architecture of the system you’re moving into, how your current data maps against it, which fields need to be renamed or restructured, and work through any necessary data cleansing or transformation efforts.
Many foundations have a fear of losing their data—so they figure they’ll just move it all into the system and sort out any issues later. Any data fields from their old system that don't have a direct mapping or translation into the new system’s fields often get moved into a set of custom fields created specifically for holding migrated data. But if that’s your approach, you end up creating a system administrative headache, because you have fields that only apply to migrated data, and not to any new records that are entered post launch. Building and maintaining reports and other system objects are more difficult because the list of possible fields to work with are cluttered with the migration data fields that are only relevant to legacy data, or no longer deemed strategic for impact/program goals. This obstacle to administer the system effectively—juggling separate fields for legacy and new data—then makes it a challenge to fully realize the return on your investment.
Building Multilingual Functionality
The work and time it takes to build true multilingual functionality in a system is often woefully underestimated, especially if you plan to engage external translators. Though it’s possible for many browser-based systems to use the automated translation features provided by the browser with no impact to the implementation work and timeline, most organizations don’t trust the quality of automated translations, and will want to build the system with multilingual texts explicitly provided by a translator.
Getting all of the copy prepped and approved for every stage of the grantmaking process is time consuming in one language—all of your Letter of Intent instructions, application form questions, report requests, email notifications, grant letters and amendments, etc. need to be fine tuned and approved. When you introduce another language, each time a change is made, that copy needs to go back to your translator, approved, uploaded to the system, and verified by a bilingual user who has the context of the copy that’s been translated to verify accuracy.
Inputting the translated text into the system can vary from manual copy/pasting to uploading in a specific format—it usually takes more time than initially expected. The input and testing of the “secondary” languages are often done later in the project (because of the time it takes to get the copy translated), introducing a risk that it will be rushed or forgotten, causing late changes/fixes that add pressure to the timeline.
You’ll want to make sure that you fully understand how multilingual systems will work from start to finish, both for your applicants/grantees, and for your staff. It’s common for systems to treat different languages as separate programs, even if they’re the same in every other way, which means that when it comes to reporting or data analysis, you’ll have to do some manual manipulation to make it work. Alternatively, other systems are made bilingual by entering the copy for each question so that both languages appear in all places, taking up real estate on your screen display.
It’s also common for the system functionality (buttons, instructions, etc.) to default to English, which can be frustrating for non-English speaking users. For a system to be truly multilingual—where a single application form is available in different languages based on user preferences—it often takes a lot of time and resources to do right.
Overestimating Document Design Capabilities
The ability to generate custom documents from a template (e.g. a Grant Agreement form letter, or a project summary for a board report) can be trickier than you might think. It’s common to frequently update the copy in your boilerplate documents, and that creates delays getting it back to the implementation team to get them set up and tested.
Often, there are limitations around the amount of formatting that can be done when merging fields, especially if any conditional logic needs to be used to generate the documents—so the final look and feel of the finished message can be disappointing. If the system isn’t set up to support that kind of customization, you’d be looking at custom coding as opposed to system configuration—which is more time consuming, and may push the project out of scope.
Work closely with your vendor and implementation support partner to fully understand the capabilities and limitations of your system—and be prepared to have conversations about what tradeoffs you’ll need to make in design vs. functionality.
Getting Stuck in Development Cycles
Your vendor will typically work in cycles or towards milestones for your implementation: batching parts of the configuration build and validating them with you before moving on to the next cycle.
The challenge here is that in the validation part of each cycle or phase, it’s common to get bogged down in the minute details. If you try to get every single issue resolved before signing off the cycle and enabling the project to move on to the next phase, you will be extending your project completion date. In this case, the perfect is truly the enemy of the done. A wise project lead will prioritize the defects between the “must fix before launch” to “can address later” piles.
Another challenge is the need for your team to provide detailed requirements to inform the system design at the beginning, when the team doesn’t yet know or fully understand the capabilities and limitations of the system. It can feel like you’re designing blind. It’s common for teams to realize during the validation step that they don’t actually want what they initially asked for, and want to change to an alternative, adding more time to the process. An experienced implementation partner can help your team imagine what the finished product will look and feel like in those early stages, and coach you to recognize where to move quickly and where to spend more time.
Implementation projects get stressful when you encounter an unanticipated roadblock or delay—your team is excited about the possibilities, but nervous about managing the change, and a delay can spark fears that the project isn’t as worth it as they’d hoped. Keep these common challenges in mind so that you can coach your team through the process, and come out on the other side with a system that makes their lives easier.
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.
