Chapter 8: What Is the Organization Trying to Achieve?

Once you have worked to create an atmosphere that will welcome change, the next step is to understand the organization's needs, resources, and what they are looking for in critical outcomes. This phase is what many call discovery—that is, discovering as much as possible about the organization and what it wants to accomplish by implementing new technology. Salesforce recommends an adaptive methodology that combines Waterfall and Agile approaches to meet expectations and retain the ability to adapt throughout the project. Here, we will explore the following topics:

  • The iterative interrogative technique of five whys
  • A case study interrogating a mentorship program to confirm the organization's needs
  • A case study to define the organization's critical success factors for the mentoring program
  • A case study defining business processes to capture the organization's needs and critical success factors
  • An overview of defining success for the implementation

The aforementioned topics will appear in the following sections:

  • Why five whys?
  • Interrogating a mentorship program
  • Defining program processes
  • How does the organization define success?

By the end of this chapter, you will be able to define the organization's goals for implementing Nonprofit Cloud and its functionality. You will also be able to identify pain points that can be alleviated by Nonprofit Cloud and/or one of its components, as well as prioritizing goals and outcomes for the Nonprofit Cloud implementation.

As we work through each of these areas, remember how vitally important it is to truly understand the organization and what its goals are with the Nonprofit Cloud implementation. To do this well, you need to understand all the Nonprofit Cloud components we have already discussed and all the information around change management and discovery.

In the next chapter, when we begin with the installation of the Nonprofit Success Pack (NPSP) and other components, you will see the importance of what we will be doing in this chapter. So, let's begin.

Why five whys?

Organizations must address challenges when they start discussing new technology implementation. Sometimes, they are very certain that they know the solution to their problems, and sometimes, the only knowledge they have is they need a solution. Using the five whys is a great opportunity to better understand the organization's needs, pain points, and business processes. Sakichi Toyoda is credited with the development of the five whys methodology, and it is a part of the problem-solving skills used in the Toyota Production System (TPS). It is an interactive interrogative process to identify the root cause of a problem. By asking "why?", the cause and effect become apparent so that the problem itself can be solved instead of one or more of the effects of the problem. With a little adaptation for the specific circumstances, the five whys is a helpful discovery mechanism.

Here is a blank template of the progression of discovery using the five whys technique:

Figure 8.1 – Five whys template for discovery

Figure 8.1 – Five whys template for discovery

Using this template, you can begin with whatever the organization states as a problem and refine the actual challenge from there. It may be a quick and easy process to get to the root cause, or it may require quite a bit of discussion for a larger team. Either way, the goal is to work through the process, dispel any assumptions, and learn as much as possible along the way.

Let's explore how this might work for a group that is working to define its mentorship program.

Interrogating a mentorship program

Mentors R Us (MRU), a nonprofit tasked with mentoring, are interested in leveraging Nonprofit Cloud to automate what they can for their local mentoring program. They have done a great job of selecting their partners and perfecting the matching process. They prepare mentees and mentors and keep their participants informed. The roadblock for their mentoring program is collecting data to share with their collaborators on the success of their program.

The problem

The first step is to have the organization state the problem in a concise and focused way. The problem statement should not be too broad, or the resolution will not be helpful because it will not be focused enough to implement a specific change. After some discussion with the mentorship program team, it becomes evident that they are struggling with showing impact because program participants are not reporting progress.

The problem: Participants do not report progress, as we can see from the updated template here:

Figure 8.2 – Start with a concise problem statement

Figure 8.2 – Start with a concise problem statement

Ask the five whys

Next, you begin to ask why and fill in each step of the template, as follows:

  1. Why don't participants report on progress?

The program team responded that in the current training and business processes, participants were asked to email a progress report or to call regarding the progress report. The team got feedback from participants that it was too difficult to remember this, and they were not sure what to include in the progress report.

  1. Why do participants have to email or call?

The program team mentions that they did not have another way to get information from the participants. They do not have a form capability to outline specific information that should be submitted, and they do not have any consistent way to remind participants to submit information.

  1. Why doesn't the organization have a form capability?

The program team explored different ways to use forms last year—everything was cost-prohibitive and offered nothing that automatically populated Salesforce with the data from the forms. Additionally, there was no way to automate reminders.

  1. Why are forms too expensive?

Based on the cost involved, the program team believed that emails and phone calls would be more efficient. But participants said it was just too hard to remember to report and then create an email or make a phone call when the mentoring center was open.

  1. Why is it too hard to report progress?

Participants need reminders and a form that captures pertinent data rather than relying on mentors and mentees to cover everything freeform in an email or a call.

Here, you can see an updated version of the template with each step filled in:

Figure 8.3 – Template with five whys and answers filled in

Figure 8.3 – Template with five whys and answers filled in

As you can imagine, discussing this with the team would take much longer than reading the preceding outline. However, after the end of the discussion and asking the five whys, you will be able to find the root causes.

The root causes

If you have been paying attention throughout the entire conversation with the MRU program team, you will notice that each of the five times you asked "why?", the team delved a little deeper into a better understanding of why participants were not reporting their progress.

They worked through the idea that their assumptions about feedback costs were wrong. The team also acknowledged the feedback they were getting from participants and what they needed. The root cause of why participants were not reporting progress was simple: participants need reminders and an easier way to share information.

What is the goal of the mentorship program?

You have now successfully identified the root cause of the problem that the mentorship program is trying to solve. That was the first step.

Now, we need to look at the following areas:

  • What are the goals of the mentorship program and why it is so important that participants report on progress?
  • Which data will show progress toward the mentorship program goals?
  • Who needs to see that data and why?
  • What is the most effective way to collect that data?
  • Most importantly, if the data is not actionable, why are you collecting it?

First goal

The first goal that MRU wants to measure is mentee confidence and increased skills. Sharing progress on this goal will require data from the mentee to start the program and combined data from the mentee and the mentor to show improvement in confidence and skills.

Creating user stories around this goal using who, what, and why will help us understand the ways that users may interact with the mentorship program, the data, and the Nonprofit Cloud implementation. The widely accepted format for a user story is: As a <who>, I want <what> so that <why>. This is Step 1 of creating a user story.

Here are some example user stories around the first goal:

  • Example 1: As the executive director, I want to pull a report once a month so that I can show the progress that our mentees are making in increasing their self-confidence and skills.
  • Example 2: As a mentee, I want a simple way to share initial information on my confidence levels and skills so that my progress can be measured.
  • Example 3: As a mentee, I want a simple way to share information throughout the mentor program on my confidence levels and skills so that my progress can be measured.
  • Example 4: As a mentee, I want a reminder so that I can submit information on a timely basis.

The user stories should be small, independent, testable stories that provide value to the end user. The formula is simple; however, a story-writing workshop to develop those user stories can be time-consuming and inestimably valuable.

Second goal

The second goal for the MRU program is centered around specific tasks such as creating LinkedIn profiles and resumes/curricula vitae (CVs) and completing Trailhead modules and certifications. Mentors grade the quality of the LinkedIn profiles and resumes/CVs and monitor the number of Trailhead modules that are completed. The thought is that mentees who complete these tasks will gain confidence as well as skills. Tracking these quantifiable numbers against the more qualitative numbers in the first goal gives positive outcomes and refines the mentoring process.

The second part of a user story is the acceptance criteria. Let's look at some examples of user stories that the mentoring program team created and the acceptance criteria, a clear pass/fail statement, that goes with them, as follows:

  • Example 1: As a mentor, I want a quick way to report a score for a mentee's LinkedIn profile so that the mentee can receive feedback.

Acceptance criteria: A mentor can report a score on the mentee's profile with one click.

  • Example 2: As a program director, I want up-to-date information on how many Trailhead modules a mentee has completed so that I can assist mentors in encouraging their mentees.

Acceptance criteria:

  • A program director can see the current total number of completed Trailhead modules on the mentee profile.
  • A program director can send an email to the mentor and/or mentee.
  • A program director has access to mentee profiles where those mentees fall under the program director in the hierarchy.

    Remember

    Acceptance criteria should be specific and testable. If it is too vague, it is much more difficult to decide when that user story's work is completed.

Figure 8.4 – User story and acceptance criteria template

Figure 8.4 – User story and acceptance criteria template

User stories and acceptance criteria do not require a complicated matrix or template. The simple template example shown in Figure 8.4 is based on a user story template from Accenture, a global Salesforce partner.

Defining program processes

After the robust discussions around user stories, MRU are excited to get started implementing their new mentor program using Nonprofit Cloud. Before you start to create a solution, you need a set of directions to make certain that the functionality outlined in the user stories is present in the solution.

First, assign a unique identifier (UID) to each user story. Again, it does not have to be complicated. See the following example:

Mentoring Management system

Table 8.1 – Example of user story numbering and categorizing

Table 8.1 – Example of user story numbering and categorizing

With the user story IDs assigned, we can associate the functional requirements with those user stories. You see how the actual function correlates to the user story in the following example:

Table 8.2 – Example of functional requirements documentation

Table 8.2 – Example of functional requirements documentation

These functional requirements are a road map, especially for those stakeholders who create or configure the systems, to implement the processes that are needed to provide the organization with a successful implementation.

Another useful tool is a business process map. Universal Process Notation (UPN) is a helpful way to document the business processes for an organization so that all the stakeholders can easily understand each step and decision in a process from start to finish. See the following sample of UPN for NPSP:

Figure 8.5 – Sample UPN for NPSP

Figure 8.5 – Sample UPN for NPSP

Regardless of the tools you use, it is important to agree with stakeholders on what is needed.

How does the organization define success?

In Chapter 7, Is Change Difficult for Your Organization?, we covered the definition of success viewed from Vision, Values, Methods, Obstacles, and Measures (V2MOM) and the organization's alignment. We also talked about SMART metrics: Specific, Measurable, Achievable, Relevant, Timely.

In this section, the success we want to define is the success of the Nonprofit Cloud implementation itself. The Agile process promotes continual and iterative improvements. How do you and the organization know when the implementation is finished?

Everything we have discussed in this chapter so far helps with defining the success of the project. Using the five whys methodology, you should be able to eliminate assumptions and get to the root causes of problems. Creating user stories with the team brings into focus the goals for the implementation. The acceptance criteria associated with the user stories are what is used to test for the successful completion of each user story. When the acceptance criteria are met, the requirement itself can be checked off as completed. Understanding and documenting the business processes, decision points, and outcomes provides an overall picture for the implementation.

Additional help is a benchmark. A benchmark is a standard or a point of reference provided for assessment or comparison. Establishing benchmarks provides a way to measure success, incrementally, throughout the implementation instead of waiting until the very end of the project for an overall assessment. Benchmarks also provide decisions that will affect the project going forward—they are great tools for retaining focus. Examples of some initial benchmarks we want to set for the mentoring project are provided here:

  • How long does it currently take a mentor to submit scores for a LinkedIn profile created by a mentee?
  • Can you create a reliable average length of time?

If you can answer these questions, you can use them as initial benchmarks. When the requirements around mentors submitting these scores are ready for user acceptance testing (UAT), you can time how long the new process takes. By using a benchmark this way, you offer quantifiable value to the organization.

Another form of measuring success is a timeline. Of course, much depends on how complex the implementation is, but even for a simple implementation, a written timeline helps manage expectations and keep everyone on track.

Here is an example of a timeline for the implementation of a managed package that requires little discovery:

Standard onboarding timeline

Table 8.3 – Sample managed package implementation timeline

Table 8.3 – Sample managed package implementation timeline

Note

This schedule may vary based on the complexity of an existing Salesforce implementation, the complexity of data to be migrated, and any customization or additional modules or functionality that may need to be applied (* indicates that this may not apply to your onboarding).

This simple timeline also serves to delineate who is responsible for the major steps in the implementation process and helps to keep the process moving.

Summary

This chapter and the preceding chapter (Chapter 7, Is Change Difficult for Your Organization?) covered a vast array of important information and techniques to pass the Nonprofit Cloud Consultant Certification and to successfully prepare to implement Nonprofit Cloud for an organization. In Chapter 7, Is Change Difficult for Your Organization?, we learned about organizational alignment and change management, the importance of governance and Centers of Excellence (CoEs), and user adoption and metrics for success.

In this chapter, we learned what the five whys methodology is and how to use it to interrogate pain points. Using the five whys, you can establish the root cause of problems. We also learned about user stories and how those stories define the functionality needed to achieve the goals of implementing new technology. The second half of the user story, the acceptance criteria, is a key part of defining the success of the implementation itself. With user stories and acceptance criteria in hand, we created simple requirements for stakeholders to implement and configure the new technology. UPN provides a way to see the business processes themselves and the decision points along the way to further document and confirm that all parts and pieces of the implementation come together to create a successful whole. UAT, benchmarking, and meeting timelines were introduced as ways to measure a successful implementation strategy.

Implementation Strategies and Best Practices make up 21% of the Nonprofit Cloud Consultant exam. We've covered a lot in Chapter 7 and Chapter 8, Requirements – User Stories – Business Processes – What Is Your Organization Trying to Achieve? Next, in Chapter 9, Installing Nonprofit Cloud Solutions, we will get down to the nitty-gritty of implementing solutions from Nonprofit Cloud.

Resources and additional reading

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.21.104.183