Skip to main content
Build the future with Agentforce at TDX in San Francisco or on Salesforce+ on March 5–6. Register now.

Define a Feasible Scope for Your Pro Bono Project

Learning Objectives

After completing this unit, you’ll be able to:

  • Apply best practices for engaging your organization.
  • Document requirements through user stories.
  • Define a reasonable scope of work.

How to Scope for Success

Illustration of a map, binoculars, a tent, and a kayak.

To apply your pro bono superpowers effectively, you’ll need to get good at scoping projects. What exactly does that mean? Simply put, project scoping is the process of understanding what an organization wants to accomplish and agreeing on what can (and can’t) be accomplished given the available resources and timeline.

Since Salesforce.org launched its Pro Bono Program in 2014, thousands of Salesforce employees have successfully completed pro bono projects with nonprofit and educational institutions. A whopping 82% of these organizations say they are more effective in managing Salesforce and delivering their missions as a result. The way Salesforce pro bono volunteers scope projects is a key driver of the program’s success—and we’re happy to share our best practices with you!

Bring a Beginner’s Mind

It’s critical to start a pro bono project with a beginner’s mind. Bring curiosity and openness to the project. Don’t assume your experience will always apply to your organization.  

For example, the customer might not know how to change a page layout or send an email in Salesforce, so don’t assume they do. Topics you breeze past in a commercial setting might require some more hands-on guidance with nonprofit and educational institutions.

Image of Salesforce employee, Matthew Watson.

Matthew Watson, APAC Platform & Service Solution Engineering, Salesforce: “Nonprofits use a different language, face different challenges, and have less experience managing technology projects than commercial customers.”

Keep in mind that it's the simple stuff that will enable nonprofit and educational institutions to do a lot with Salesforce. The keys are to:

  • Understand exactly how the organization’s business works.
  • Research the use cases that align with the organization's processes.
  • Take time to explain functionality.
  • Make sure the organization is comfortable working in the system.

A process like importing data might come naturally to you, but you have to make sure the customer can comfortably follow it.

If you bring a beginner’s mind to your pro bono project, you’ll be well on your way to creating a sustainable solution for your organization. 

Keep It Short

You have a ton of demands on your time. Even if you find yourself with some free time now, you never know when a new job opportunity, demanding work project, or family priority might spring up. It’s the same for Salesforce employees who volunteer through our Pro Bono Program. 

That’s why we scope projects through our Pro Bono Program to take no more than 20 hours to complete. Keeping your project to 20 hours or less will minimize the likelihood of unexpected work or personal circumstances derailing the project before it’s finished. 

This doesn’t mean you can’t contribute more hours if you want. Salesforce employees are a generous bunch and will often string together two or three pro bono projects in a row to support a cause they’re passionate about. 

The huge benefit of scoping small chunks of work is that you can always reevaluate your commitment in between projects. This gives you flexibility while enabling you to focus on one discrete task at a time.

Avoid Time-Sensitive or Mission-Critical Projects

Illustration of a woman wearing a cape running away from a clock with legs and arms.

We know you want to give back and make a big impact in the world. That’s why you might be tempted to say “yes” if your organization asks you to do a full implementation or configure their org to support their big fundraising gala that’s just weeks away. We want you to know that it’s ok to say “no.” In fact, we encourage you to pass on projects that are mission-critical or time-sensitive.

In a volunteering capacity, it’s really hard to sustain a long-term commitment or deliver on a fast-paced project with a tight deadline. You just never know when your work or personal circumstances will change—and the last thing you want to do is leave a project before it’s finished. If you agree to help a nonprofit or educational institution, they’ll count on you to follow through.

Nonprofit and educational institutions often don’t have the expertise or resources to salvage your project if you drop the ball. It’s super important to make a commitment that you know you can deliver on.

Get Specific

As you learned in the previous unit, the initial planning meeting is where you get clear on the overall project goals. During the scoping phase of the project, you’ll want to talk to users about the specific ways they use Salesforce and other tools in their daily work. You’ll want to find out what’s easy to do and what’s difficult or frustrating to do. Be sure to focus on the use cases that seem relevant to the project’s goals and look out for any repetitive manual tasks that could be automated. 

The goal is to gain a clear understanding of the problem, how it impacts the organization, and what a better process would look like so that you can recommend the right solution. Here are a few questions you should ask users about their experience:

  • Walk me through how you do [x] task.
  • Is this process working out for you? What’s easy about it? Difficult or frustrating?
  • How important is this task for your work? What if you could do this faster/better?
  • Talk to me about the data that you’re collecting. What kind of data are you tracking and how much? What is the state of the data?

Responses to these questions should give you a sense of where the pain points are and their relative importance to the organization’s mission and operations. From here, you can document functional requirements and then start brainstorming potential solutions.

It’s important to document and share what you learn with your organization. Even a small misunderstanding can send you down the wrong path during the project. 

Document Requirements

Writing user stories is a great way to document and gain alignment on your organization’s specific requirements. Each user story describes a user’s need in simple, non-technical language. 

Illustration of a woman sitting in a chair, drinking coffee and reading a book.

For example, let’s say that you’re volunteering with a small community-based nonprofit that provides free tutoring services to foster youth. The organization relies on a large grant from the State of California to pay its tutors. 

Every month, the nonprofit’s Executive Director sends a financial report to the State per the terms of the grant. It takes her four or five hours to create the report each month. She’d much rather use that time to find new sources of revenue.

You might write a user story that looks something like this:

“As the Executive Director, I want the financial report to run automatically so that I can spend less time creating reports and more time finding new revenue sources.”

Notice how the user story is written from the perspective of the Executive Director (“user”) and describes her need (“what”) and the reason for the need (“why”). The sentence is written in plain language and is easy for non-technical people to understand and provide feedback.

Once your organization signs off on a user story, you can then define the specific requirements. For the example above, you’ll need to identify fields to include, filtering criteria, run date, and reporting period before you can do the work of automating the report.

Determine What’s In-Scope (and What’s Not)

Once you’ve documented the requirements of each user story, you’ll need to estimate the amount of time it will take to achieve those requirements. This is more of an art than a science and will depend on how familiar you are with the desired functionality and whether you need to study additional product documentation.  Do your best to come up with a conservative estimate. 

Then you’ll need to work with your organization to decide which requirements to include in the current project and which requirements to postpone for a future project. Now that you’ve got a realistic project scope in place, it’s time to unleash your Salesforce superpowers to design and build your solution!

Condividi il tuo feedback su Trailhead dalla Guida di Salesforce.

Conoscere la tua esperienza su Trailhead è importante per noi. Ora puoi accedere al modulo per l'invio di feedback in qualsiasi momento dal sito della Guida di Salesforce.

Scopri di più Continua a condividere il tuo feedback