Part 1: OK… Put the cart in front of the horse

If you haven’t already, you may want to read my post on Processes before digging into this one. Consider it “Part 0” in this series.

Abstract

This is an exciting time! We as admins, SFDC geeks, etc. are currently able to reap the benefits of Salesforce’s 50th release: Summer ’16. More than 200 new or improved features, more than 240K IdeaExchange points retired and THERE’S LIGHTNING ALL OVER! Not familiar with all the aforementioned goodness? Check out Adam Olshansky’s fantastic overview of it. The guy did a seriously great job of highlighting the cream of this release’s crop.

Due to the shear magnitude of this release I felt it important to remind the (tens of) people who read my blog that: technology, no matter how awesome, needs to come into play after you’ve been able to fully conceptualize the most important thing you’re working with: the requirements.

Have you ever had a User come to you with a request to create new or change existing functionality? While it may be (in some cases) ok to say “Simple enough! You got it!”, what do you do if something systemic, complicated or that has a broader impact comes across your desk? How do you facilitate the fulfillment of those requests??

Over the next few weeks I’m going to be publishing posts that cover what I’ve found to be a pretty effective methodology for facilitating the improvement/modification of processes in general. This framework is the culmination of my learnings as a shop floor grunt, Manufacturing Supervisor, Continuous Improvement Coordinator, impromptu Business Analyst and general Technology Enthusiast/Geek and is directly applicable to my (our?) current role as a Salesforce Admin. Before we get started…

A Bit of Q & A

1. Am I saying this is the best way to go about process improvement?
   1. No. It’s just what I found to be effective.
2. Am I saying this is the only effective way to improve processes?
   1. Um. No. Please refer to item 1.A.
3. Will I be held accountable for any problems, downfalls, regressions or costs that you may experience/incur as the result of following this (or any) advice given on this blog?
   1. Sorry… No. You’ll be attempting to improve things at your own risk.
4. Would I like there to be an open dialogue regarding what you’ve found to be effective and will questions be responded to?
   1. YES! I learn new things all the time. I’m completely open to having things I say disputed, improved upon or taken a step further.

A Simple Framework

There are six parts of the process I’ll be explaining:

1. Identify/Document the Opportunity for Improvement (OI)
   1. Create Initial Problem Statement
   2. Create Initial Requirements List
   3. Set your BHAG. (Big Hairy Audacious Goal… not the city in Pakistan)
2. Assemble the Troops
   1. Include
      1. Stakeholders
      2. Advocates
      3. Opponents
      4. Sponsor(s)
   2. Create High Level Current State Description
   3. Set Scope
   4. Refine Initial Problem Statement (if need be)
   5. Refine Initial Requirements List (if need be)
3. Dig Into It
   1. Document Low Level Process Components (fine details)
   2. Identify KPIs (Key before/after Performance Indicators)
   3. Observe and Collect KPI Metrics
4. Analyze and Strategize (Plan the Work)
   1. Identify OIs
   2. Prioritize OIs
   3. Set Reasonable Objectives
   4. Pair OIs with Improvement Methods/Technology (SFDC Functionality, Process Changes, etc.)
   5. Creating your PDCA List (Deming Circle)
   6. Take a look around the Parking Lot (Huh??)
5. Implementation (Work the Plan)
6. Sustain (Ongoing Monitoring)
   1. Avoiding the Hawthorn Effect and Other Snares

Part 1: OK… Put the Cart in Front of the Horse

1. Identify/Document the Opportunity for Improvement (OI)
   1. Create Initial Problem Statement
   2. Create Initial Requirements List
   3. Set your B.H.A.G. (Big Hairy Audacious Goal)

Did you notice that? The technology (i.e. the application of scientific knowledge for practical purposes) part didn’t come in until the middle of item 4. Requirements, on the other hand, come into play right after we identify/document that there’s a problem!

Let’s think about that for just a moment. Check out the scenario being played out in the image atop this post. There’s a horse, a cart and a barrel. Without knowing much more than that, it’s safe to assume that the primary objective (read: requirement) of attaching a horse to a cart, is to get whatever is in the cart where it needs to go. Right? Without the thing(s) that are in the cart, there would be no need to attach said cart to said horse in the first place! Requirements are paramount.

At the onset of any implementation, roll-out, update or change… the last thing you should be thinking about is how you’ll be able to use your new ability to execute actions on more than one criteria or to create/edit records offline using Salesforce1 in order to solve a problem or meet requirements. If stuff like this pops into your head while going through any portion of this process prior to 4.D, GREAT!

Grab a big sheet of paper or reserve a portion of a whiteboard by writing “Parking Lot” on it. This is where you’ll “park” the mini-epiphanies you may or may not have while focusing on other things. Revisit Parking Lot items as the proper times present themselves and again before step 5.

One of the first things you’ll need to do, is to create what’s called a Problem Statement. Problem Statements briefly (two or three sentences max) describe the issue(s) needing to be addressed by a team of people. To avoid scope creep, it is imperative that this statement has no more than two iterations. The first version can be though of as a not-so-rough draft and is typically written when the person who initially noticed the OI comes to you (the facilitator) and inquires about it.

Next you’ll need to create a high-level requirements document. In this scenario, Requirements can be defined as “the needs or expectations of a given solution”. 

J. DeLayne Stroud lists the most common objectives of requirements lists as being:

• To gain agreement with stakeholders
• To provide a foundation to communicate to a technology service provider what the solution needs to do to satisfy the customer’s and business’ needs
• To provide input into the next phase for this project
• To describe what (not how) the customer/business needs will be met by the solution

This is another item that, again avoiding scope creep, should have no more than two iterations.

The last part of this step is to create/document your Big Hairy Audacious Goal. The traditional definition of a BHAG is “a strategic business statement similar to a vision statement which is created to focus an organization on a single medium-long term organization-wide goal which is audacious, likely to be externally questionable, but not internally regarded as impossible.” The BHAGs I like to create don’t exactly fit that definition, they’re close. Mine typically end up being equal parts vision statement and shoot for the moon goal oriented. Your initial BHAG should be thought of as something that’s intended to guide and inspire your team to create a more accurate, final version.

While there’s a lot that you and the person who originally discovered the OI can come up with and document, your main goal should be to set the stage for the synergies available via team work. During step one you should be focused on remaining accurate, unbiased (this is the time to take any preconceived notions of what the final solution will look like, set them on fire and bury the ashes), thorough and persuasive all while not getting wrapped around the axle of fineness.

Look for my upcoming post were we’ll look at assembling the troops, mapping the current state of your processes, setting your scope and honing in on refined versions of  your problem statement and requirements list.

Next Post: Part 1.a: Subjectivity is Pretty Much the Devil

Have questions or comments? Leave them below or hit me up on Twitter @SFDCGEEK.

Thanks for reading!