Ok, it’s not real ‘peril’ if you ignore these elements. It’s not like you’re going to crop down a cliff edge or slip on a soapy floor. But it is very important to focus on some key principles if you’re about to embark on a Salesforce Project with the help of a Salesforce Consulting Partner.
***
So, you’ve decided you might want to implement Salesforce to improve some part of your business.
How do you know how long it will take and how much it will cost to build this system that will automate everything, and streamline processes, and reduce AHT (Average Handling Time, and all sorts of amazing stuff?*
Generally the first view of the problem is gained by the Consulting Partner’s Account managers or the sales people, who would get an idea of what the client is looking to achieve.
Sometimes, there might be an RFP or RFQ issued by an organisation, with a document outlining the requirements, and allowing Consulting Partners to bid and formulate a response, and a proposed cost for the solution.
In almost all cases, (unless the requirements are very simple and straightforward as understood by all parties) a Discovery is the next step. This is where the consulting team come in for a fixed period of time, and get down into the details of the requirements.
In the first of a series of articles about the Salesforce Project Discovery, I write about the elements that is important to think about, from both points of view (client and consulting) but mainly outlining my learnings and experience from the Consulting Partner’s point of view.
The Process
The Discovery phase is generally a fixed price engagement because it’s done over a fixed period of time and the team size is known. This is where the team would run a series of workshops in order to understand and analyse the issues and pain that the business is experiencing, and to design a proposed solution that would address those issues.
Documentation (also called ‘Deliverables’ which are contractually produced at the end of this stage) generally include the following topics and scope:
- Functional & Non-Functional design
- Reporting & Analytics Requirements
- Technical landscape (Current and future state)
- Integration Interfaces
- Data migration plan
- Test strategy and plan
- Deployment plans
- Estimated Project plan and costing
It is in this phase that foundation for success is constructed. It is where the business and the Salesforce Consulting Partner come together and understand the current business and technical landscape, and the ultimate goal. The ‘How to get there’ comes together once we know where you are, and where you want to get to.
The first thing to do is to schedule all the ‘as-is’ workshops are required to understand business’s current processes, how they do what they do, and what opportunities for improvements can be found within the hand-offs, or other specific areas of those processes. These might include, for example, automation where duplicated manual processes are found.
Next comes the ‘to-be’ future state workshops, where the project team (this includes individuals within the business’s internal team and the Consulting Partner’s team who are jointly on the project) explore how best to use the new platform to create efficiencies and achieve the business goals with the key business users. For example, this might include sales processes which are to be enhanced with development of ‘Apps’ that users and customers could utilise to quickly order and customise purchases that are integrated with the supply chain and delivery processes.
The People
The roles from the Consulting Partner’s Discovery Team typically consists of the following:
- Project Management – to understand the broad requirements and effort required to fulfill them, in order to produce a feasible project plan and costing
- Functional skills – to understand the current (as-is) business processes, and articulate the future state (to-be) processes that will be supported by Salesforce
- Technical skills – to understand if there are any non-standard requirements and the best way to achieve them (e.g. using custom development or utilising third party tools or applications) as well as any technical or business operation implications in the future
Sometimes, for a small project, the above roles can all sit in one super Consultant. A very experienced and capable Consultant can potentially run the ‘Discovery’ over a few days to produce a quote or SoW for a 1-3 week build project.
A team of three: Project Manager, Functional Consultant and a Technical Architect might be needed for a Discovery running anywhere from 3 to 6 weeks, in order to scope, plan and cost an Implementation project that could take up to 6 months and a build team of maybe up to 10 people.
Sometimes, for much larger projects, there might be up to 8 or more in a Discovery team to fully flesh out the details of a global engagement, perhaps with multiple phases, with complications of language translations as well as compliance with local legal and financial regulations. Security, GDPR, and cross-border implication of data privacy laws are examples of the more complex undertakings that will need to be detailed during this phase.
Of course, the above examples are very rough illustrations of the timeframe, size of team and project, and is highly dependent on many factors as well as layers of complexity involved.
In a previous article, I wrote about hiring your internal Salesforce Champion, and understanding why it is important to choose the right person for the job. There is a lot of work to be done by the client in partnership with the right Salesforce Consulting Partner and having the right kind of relationship makes all the difference.
When both the client and Consulting Partner establish trust and rapport within the relationship, things generally move along beautifully, as everyone concentrates on tackling the challenge of making the change happen. Sometimes, though, internal business politics and personalities clash, and both sides are unable to navigate the relationship well, and that is when things get a bit sticky.
Rules for getting a Salesforce project done right.
1. Choose your internal champion, and then choose the right partner.
2. See first rule.
But what about the System?
They say that People, Processes and Systems are the three elements of organisational change. That’s what we are talking about here, isn’t it? Implementing Salesforce, or any other business solution, is about organisational change.
It may be that the change will only affect the Sales teams, or the Marketing teams, or the Service/helpdesk/operational team – nonetheless, it’s change on a not-insignificant scale.
The System element is generally the easiest to change and affect. It’s clean, i.e. can the system do the function required or not? If not, can a third party plug-in do the job? Or can it be done with development to get a more bespoke solution? Yes/no answers have a definitive next step.
I love data migration for the same reason. Data and Rules are clean and clear**. CRUDs and Upsert rules and logic for ETL and the like.
And it’s what Technology partners are REALLY good at. The System side of things.
They have Consultants who specialise in Databases, Business Intelligence, Marketing rules and automation, complex Integration using point-to-point and other Middleware, Data Migration experts… the list goes on. Systems are SO much easier to understand and implement.
The Very Important ‘messy’ elements
People and Processes are a little ‘messier’, and not clear cut. But get these two right, and you’ve got one of those projects that everyone will talk about in the same vein as an exhilarating journey to conquer the icy Antarctica with your team on roller skates, dressed in the skimpiest bikini/mankini outfits and hunting the polar bears*** for food along the journey. And where nobody dies. Or get frostbite and lose an ear.
To be clear, I mean that these will probably be the projects that we would recount fondly as being an “Amazingly Awesome****” project that we hold very dear to our hearts. When we meet up with ex-colleagues who were on the same project so many decades ago, we would still shed a happy tear and share crazy memories of all-nighters with the client team who made it all worthwhile.
These are the kind of projects we live for.
So, to summarise: It’s the People and the Process. That’s the answer to the question.
It’s the human element and connection that matters.
* Not sure I can come up with more jargon and acronyms before it starts sounding like bovine methane emissions.
** The DBA in me will admit that data quality can be messy, but Rules on how to deal with them are clear. Unlike human interactions, especially little humans!
*** which is almost an impossible feat because polar bears live in the Arctic Circle!
**** I reserve the right to use the word ‘Awesome’ because I cannot think of a better, funkier word to describe how I feel 🙂
Important note: Almost everything I write can be applied to just about any software projects, not just Salesforce ones.