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
- Am I saying this is the best way to go about process improvement?
- No. It’s just what I found to be effective.
- Am I saying this is the only effective way to improve processes?
- Um. No. Please refer to item 1.A.
- 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?
- Sorry… No. You’ll be attempting to improve things at your own risk.
- Would I like there to be an open dialogue regarding what you’ve found to be effective and will questions be responded to?
- 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:
- Identify/Document the Opportunity for Improvement (OI)
- Create Initial Problem Statement
- Create Initial Requirements List
- Set your BHAG. (Big Hairy Audacious Goal… not the city in Pakistan)
- Assemble the Troops
- Include
- Stakeholders
- Advocates
- Opponents
- Sponsor(s)
- Create High Level Current State Description
- Set Scope
- Refine Initial Problem Statement (if need be)
- Refine Initial Requirements List (if need be)
- Include
- Dig Into It
- Document Low Level Process Components (fine details)
- Identify KPIs (Key before/after Performance Indicators)
- Observe and Collect KPI Metrics
- Analyze and Strategize (Plan the Work)
- Identify OIs
- Prioritize OIs
- Set Reasonable Objectives
- Pair OIs with Improvement Methods/Technology (SFDC Functionality, Process Changes, etc.)
- Creating your PDCA List (Deming Circle)
- Take a look around the Parking Lot (Huh??)
- Implementation (Work the Plan)
- Sustain (Ongoing Monitoring)
- Avoiding the Hawthorn Effect and Other Snares
Part 1: OK… Put the Cart in Front of the Horse
- Identify/Document the Opportunity for Improvement (OI)
- Create Initial Problem Statement
- Create Initial Requirements List
- 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!
In the above framework, at what point the technical team ( salesforce admin/developer) engage with the business user or SMEs to review the requirements? One of the challenges I have faced in my past projects working with Project management methodology where Salesforce technical team is not a part of requirements elicitation sessions with business and once all requirements are documented and provided to them, they have additional questions. This leads to several clarification meetings. What would you recommend?
Hi Sumita,
Thanks for the excellent question! Apologies for the delay in my response. Timing is everything, right? Regarding the framework I’m offering up… if you order things correctly… you’ll save yourself a lot of time/headaches and (of course) your company a lot of money. To me, the successful orchestration of a series of meetings/conversations hinges on the answer(s) to a simple question: “When do I bring who into the conversation?”. As mentioned at the end of this post, the next topic I’ll be writing about (almost done organizing my thoughts!) pertains to “Assembling the Troops”. Or, team-building if you’d like. After you’ve identified and documented the opportunity for improvement and set your initial shoot for the moon goal, you need to identify those who you’d A.) like to have on the team and B.) need to have on the team. In your comment, you point out how it can be tough to get people with technical know-how involved at the right time. I’ll be diving more into in my next post, but… this really comes down to a matter of accurately identifying your stakeholders. Stakeholders are those with an interest or concern in something. If a person stands to be impacted by the changes you’re setting out to make, they’re a stakeholder. Keeping your stakeholders on a need-to-know basis, is almost always inadvisable. My advice is to always keep your stakeholders as up-to-date as possible. Your technical team? Yup. They’re stakeholders AND SMEs. They’re going to offer insight that nobody else can. While it’s up to you to facilitate the conversations, it’s the responsibility of those you involve in it to offer advice, ask questions and play devil’s advocate.
Long story, short… I’m not suggesting you invite the entire Technical Team to each of your project’s meetings… but I do suggest acknowledging that they are stakeholders (who’s going to initially set things up and fix them if need be??) and ask them to supply technical representation to the team as such. Perhaps by filling the role of your project’s Technical Lead? More to follow!
Thanks,
Ben
Awesome article, I’m a new SFDC admin and this is exactly what I needed to read today. Thank you.
Hi Dustin,
So glad you found this post of use! More to follow on this subject as I’m able to post it!
Best Regards,
Ben