Assembling the right team is one sure path to long-term success. The right team ensures you have all the facts and build buy-in throughout the initiative.
Below are a few of my insights (and a handy infographic) into key timing and roles that can make a difference in the success of your Salesforce implementation. There’s a breakdown of project phases and ideal stakeholders to be involved. At Red Argyle, our Salesforce consultants recommend change management planning as part of your Salesforce implementation strategy.
If you already have a Salesforce project in motion – fear not! It’s never too late to loop people in and gain alignment to maximize success.
Note: this article primarily looks at a typical Scrum approach, but the parties involved are often the same for Waterfall projects. About 60% of our projects run under the Scrum model, but we can support both methodologies.
Initial Discovery
Initial Discovery is the early stage of a Salesforce implementation.
Before a project is ever a project, someone has an idea or identifies a need that a technical solution can help. During these early conversations, the focus tends to be:
- Challenge identification
- Understanding what form of solution would be helpful (hiring, technology, infrastructure)
- Kicking the tires with some partners and vendors to see what’s out there
In my opinion, the Initial Discovery phase is the most critical part of a Salesforce implementation or project. If you don’t spend time defining your problem, the whole project is subject to be a “solution looking for a problem” and can greatly impact the project’s direction. It’s easy to embark on the wrong path and incur high costs prohibiting progress.
I’ve seen this happen before and during my time in the Salesforce ecosystem. The discussion is often around replacing a system because of something considered broken. Because of this, a huge effort is invested into finding and replacing a system instead of questioning if it needs to be repaired or if it’s worth replacing (i.e., no one is asking “Why”?)
To avoid losing time, try the following:
- Have a cross-section of internal stakeholders that can accurately describe the problem. This usually includes individuals who use the tools daily but also need input from management, executives, legal, and finance.
- Learning from Salesforce partners or vendors is a part of the process. Gain an understanding of what value they can provide and any unique perspectives.
- Work directly with Salesforce. This can also provide access to subject matter experts (for free!) to help with ideation.
- Search out experts in the community of the technology you’re investigating. This can give you unbiased opinions and real-world stories. In Salesforce, MVPs are a very vocal bunch. We’re happy to share our experience to help folks out as fellow community members first (connect and message me on LinkedIn).
At Red Argyle, we take a consultative approach to Salesforce implementations. We’re always happy to provide an hour or two of big-brain thinking to help understand the problems and provide free feedback not motivated by making a sale. As Salesforce implementation consultants and partners, we’ve got over 2,000 Salesforce projects under our belts.
Backlog Refinement
Once you’ve decided to invest in Salesforce, it’s time for formal Salesforce project planning. Yay!
During the Backlog Refinement phase, Discovery is complete, the RFPs are done, you’ve found a Salesforce partner or vendor (congratulations!), and it’s time to get to work.
The good news is that your partner or vendor owns most of the project planning responsibility, but not all. This planning process needs to remain collaborative to ensure positive outcomes.
At this stage of a successful Salesforce project, the team and roles often look like this:
- Executive sponsor. This is someone from your team who is accountable for the project’s success and will aid in removing blockers or dealing with changes.
- Internal tech lead. This is IT or a Salesforce admin who will maintain control of the system throughout the project lifecycle.
- Legal. If you have compliance requirements that must be managed, keeping your legal team informed and validating compliance is important. (We often help our customers with this and act as a go-between with Legal teams to aid in compliance.)
- Finance. This team manages budgets and change requests, and many systems often have financial impacts (i.e., POS or Sales tools), so their input is necessary and helpful in aligning with Finance needs.
- Project managers. This individual owns Project Management (PM) and is often required for complex projects.
- Super Users or Champions. These knowledgeable and passionate people have a lot of skin in the game; giving 2-3 of them a voice early in the project can later assist with user adoption and long-term success
- Vendor tech lead. This person is the Chief Architect/Solution owner for the project.
- Vendor developers. This [vendor] team executes the project. The title Developer is used loosely to categorize “people from the vendor who are doing the work.”
Notice that most of the roles above are internal. This is by design. I often see Salesforce implementation planning too contained to IT without gaining full alignment with business stakeholders.
Protip: Surprising your finance or legal team with a project is never a great idea.
Build Sprints
Once the project is off and running, the active team on the project generally shrinks while the work is being done.
Tactical day-to-day meetings are managed to execute the plan, which receives broad buy-in before core stakeholders shift to:
- Project managers (vendor and internal), keeping the project moving and communication flowing to the larger team.
- Vendor developers building the solution.
- Internal tech lead/IT validating the direction of the project.
- Testers and Quality Assurance (QA) on both sides validating the project meets success criteria. Including your previously identified Super Users or Champions as testers can help ensure key objectives are met.
As the Build Sprints phase completes, the project will launch with a thoroughly fleshed-out project plan collaborated on between you and the vendor(s) for success. That could be another blog post entirely! Assuming the launch goes well, the next phase of stakeholder engagement begins.
Post Launch!
Like the Initial Discovery phase, the Post-Launch phase is critical.
Key user opinions are formed about the tool, initial feedback and data are produced that contribute (or detract) from success, and customer experience is often impacted by the tool (positive or negative).
Once in Production, two key activities are paramount:
- Support. This helps customers and users succeed.
- Iteration. This activity helps determine any gaps that exist in the tool which require updates or new features.
To help with support and iteration activities, the project team often consists of:
- Internal support via IT or trained power users to help customers and users through the initial day-to-day usage once it is live.
- Vendor support to help with everything from office hours, re-training, and tackling more challenging requests.
- Your steering committee (from the Initial Discovery phase) to effectively re-plan the next steps and analyze the project’s success criteria. The committee aims to achieve project success by learning from the tool’s production usage and accepting that iterating will be necessary.
- Account manager and tech lead from your vendor to aid in planning and designing possible iterations along with ensuring smooth support.
Long-Term Support (Ongoing Discovery and Backlog Refinement)
After the first few months following the launch of the tool and the excitement has worn off, the final project phase is ongoing planning and ideation of the tools’ successes, challenges, and roadblocks. Even within months, business needs change and evolve, and technology can rapidly become stale if not maintained to support the pace of change.
Not calling a project “done.”
It’s important to check their maturity level of completion, adoption, and alignment with business needs.
Monitor.
Your internal tech lead or Salesforce administrator can monitor adoption and continue to solicit user opinions and feedback. A famous admin, Mike Gerholdt, invented the term “SABWA,” which means Salesforce Administration by Walking Around, to describe a great way to visit the field and gain user opinions. We might need to do more “Slack Around” in distributed offices now.
Keep in touch with your vendor.
Your account manager should keep in touch and offer ongoing innovation support.
Red Argyle budget and innovation workshops as needed. These workshops aim to help our customers and prospects plan for the next 12-24 months of an implementation’s lifecycle to help maintain alignment with business needs and financial goals/constraints.
Inform Legal & IT.
If necessary, continue to inform Legal & IT teams to validate compliance.
The Continued, Iterative Cycle
What I covered above can continue with another round of planning, execution, launch, and support. Keep in mind that technology is never really “done,” and the project team may evolve as the focus of the work shifts. For example, you might bring in additional champions or SMEs as you take on a new epic.
Your business and tools continue to evolve and need constant care and feeding over decades. If, along the way, you need some help, we’re here! Reach out to get the conversation started.
