top of page

Blackbaud CRM™ Customizations: Tips & Tricks

"How long will it take and how much will it cost?”

Sound familiar? In the non-profit world, where every dollar matters, your IT projects require accuracy in scoping, even with small to mid-size or enterprise-sized projects.

If your organization is contracting out for Blackbaud CRM™ customization work, there are tips here that can help you manage projects and help ensure your vendor is estimating as accurately as possible. Good estimation is mutually beneficial, and conversely, poor estimation is accountable to both parties.

In this post we’d like to offer a handful of tips for improving scoping based on issues we’ve encountered.

Apple to Apples - comparable projects

Projects will often be scoped based on comparable functionality of existing projects. An organization may have had a small 10 field data import project estimated last year for 32-hours, and a new customer may need an import with a similar number of fields that may be estimated for a very similar or very different amount of time.

While it may be expedient to estimate a similar number of hours based on a similar number of fields, there may be technical considerations that could increase the effort considerably. The new import may have fields requiring translation, for example, and it could significantly increase the effort of the import past the comparable effort.

Until you examine functionality a little deeper, the distinction may not be apparent.

Even with small projects, it’s worth spending time up front to consider more than just comparable functionality. “Go deep” with these issues, and encourage your senior tech folks to point out distinctions that could change estimates. You may have to rely on your vendor to provide an accurate estimate if you don’t know the software, but you can help ensure their accuracy by providing detailed requirements and use case scenarios upfront.

Roadblock ahead

When estimating a project, it’s extremely helpful to involve resources who can identify where roadblocks may occur and document them as project risks. The vendor may not immediately have a solution in hand, but they can inform the customer about where an estimate may slip and why. Recording risks is great way to document gaps, potential roadblocks and decisions that will impact an estimate .

If you identify a large risk that could affect deadlines and budgets, it’s often worth the effort to spend some time researching the issue, with the vendor or on your own if you have the ability, to understand potential alternative solutions. Prototyping is a great way to eliminate ambiguity in estimation. Prototyping can be worth the time invested for the reward of confident, accurate estimates. In some cases, the vendor may want to charge you for this effort. Paying for this may be reasonable if it’s going to save you significant effort and result in a more accurate estimate. For example, if a vendor provides you an estimate for 300 - 500 hours for a customization, investing 16 hours in prototyping could save you tens of thousands of dollars down the road.

Calling all experts

When you’re working with a vendor to scope a customization, it’s important you have the right people in the room. If your project team is responsible for preparing requirements for estimation, it’s critical that they speak to the experts and not make assumptions about business processes or desired outcomes. That may sound obvious, but more often than not end users aren’t engaged in a project until after scoping is complete.

For example, post to GL customizations are often under-scoped because the right accounting team members weren’t involved in the scoping. Knowing the system you post to and the type of file required is not enough many times. Understanding that there is manual work done to a file before it’s posted is important to ensuring an accurate estimation.

Testing is organized skepticism

The testing phase of these projects can be a real wildcard. Often, organizations will fall into the trap of “one size fits all” with the testing phase, allocating resources as a percentage of the overall effort. In reality, testing and bug remediation should be scoped according to the type of project.

For example, a custom data form may be a complex development effort, but the testable functionality may be relatively limited, perhaps 15% of the overall effort.

In contrast, a customized import of prospective donors may be relatively straightforward to develop, but edge-case data in testing may require several iterations of testing and bug fixes.

Having experience with different development scenarios will help with estimating your testing phase. Be realistic about your project; there are development efforts where testing can be almost a formality, and there are other efforts where there will be significant errors and remediation work.

Don’t rigidly try to correlate testing to code development; take it as a completely separate estimate. Be sure to make your vendor aware of your testing capability and resource skills, and be sure you understand what testing the vendor will complete on your behalf.


Don’t just take people’s word that a project should take X number of hours. Ask yourself the following questions when requesting an estimate:

  • Did we provide the vendor enough accurate information so that they can provide an estimate?

  • Have we/the vendor identified risks and roadblocks? What alternate solutions were proposed?

  • Is there anything else we can do to make the estimate more accurate or the range of the estimate more accurate?

  • Have we accurately estimated the testing required for this project?

Approach your scoping skeptically and analytically. If you still have questions about your estimate, ask for a second opinion from another vendor, a technical expert or colleague who has been through the same process.

To learn more about Brightvine, and take advantage of a complimentary, no obligation assessment, contact Stacey Segal today via email or phone: (843) 900-4287.

bottom of page