Anyone who works on a project-basis will know that they aren’t always ‘plain sailing’. Projects exist to bring about change in an organization. While process and technology-centric, they all have one element in common – human interaction.
The Prince2 definition of risk is, “an uncertain set of events that, should it occur, will have an effect on the achievement of objectives. A risk is measured by a combination of the probability of a perceived threat or opportunity and the magnitude of its impact on objectives”. With this combination of elements to consider, we dive into the top Salesforce project risks that bubble up along the delivery path, and how to mitigate them.
Tracking Salesforce Project Risks
Project managers will track risks in a RAID Log (Risk, Assumptions, Issues, and Dependencies) throughout the project. Identifying risks is the first step to getting each one resolved or accepted by the project team and/or business.
These risks could be resource issues, or budgetary constraints, or awaiting an SoW (statement of work) sign-off. Each risk needs to be mitigated, and when they do arise, should be quickly resolved to keep the project on track.
Check out the free RAID log example – simply download, or make a copy for yourself!
There are some risks during a Salesforce project that may be considered too contentious or political to be put on a public shared list. However, it’s these risks that typically have the greatest impact on project delivery and overall success.
Note: We refer to ‘clients’ throughout the guide. This applies not only to consultancies delivering Salesforce projects for organizations that pay for their services, but also to any in-house project managers serving their ‘internal’ clients.
10. The ‘Too-Good-to-be-True Sales Pitch’
The sales team, removed from the technology, could paint a misleading picture of what’s required to meet the client’s needs. With this, the sale, such as the SoW (statement of work), doesn’t cover the true extent or cost of the project. For example, they could promote the proposed solution as standard functionality, when in reality, it will involve custom development (therefore, it is more complex and time-consuming).
This is a temptation for the salesperson – they offer a competitive quote to win the deal. The result? It leaves the team in an over-promise and under-deliver situation.
How to mitigate this risk:
- Pre-sales: The delivery team should have some presence during the pre-sales process, so they can guide parties towards the optimum (realistic) solution.
- Statement of work (SoW): Read the SoW carefully to ensure all requirements are accounted for, and the delivery timeline is reasonable.
- Stay on point: Throughout the project, stay on point with budget, resources, and timeline.
- Change requests: Use change requests with the client to ensure that all outcomes can be delivered within an accepted time frame and cost while still being of quality – without breaking the delivery team.
9. Budget vs. Expectations
When the client’s budget doesn’t match their expectations, you could call this “champagne tastes, beer budget”, and it can be a big issue for a project.
Beyond successful implementation, the cost of maintaining a healthy system is misjudged by clients. Some organizations could budget for the license cost and initial implementation, but then forget about ongoing costs. Some may get the idea that they can configure the system themselves, while other clients’ expectations on what they’d like the system to do won’t be covered by their budget.
How to mitigate this risk:
- Long-term investment: As a client, you should consider systems, like Salesforce, as long-term investments.
- Center of excellence: Establish a center of excellence within the business to define a product team, development team, and key stakeholders. This working group will continue to shape the solution as business processes change.
- Iterations: Build solutions in iterations, starting with simple outcomes, and adding complexity as budget allows. Priorities frequently change over time as the business uses the system.
8. Toxic Delivery Team Members
We’ve probably all met someone whose behavior can threaten the performance of the project team, and ultimately, the success of a project. Most of the time, this behavior isn’t malicious, but let it run free rein, and it will escalate.
There’s a range of reasons why toxic behavior occurs – the architect with insufficient experience who designs a solution that is not scalable, the developer who over-engineers a solution to boost their ego, or a team member who fails to communicate their progress.
How to mitigate this risk:
- Act immediately: If you identify toxic behavior, act immediately because it can disrupt the project’s flow.
- Investigate: Get to the root cause of the unwanted behavior to mitigate the issue quickly.
- Address their own behavior: Allow the individual who created the disruption the chance to address their own behavior, and be ‘back in the fold’ of a high performing team.
- Removal: If the behavior isn’t changed, remove the toxicity from the delivery team to save the rest of the project team.
7. A Lack of Collaboration
A project’s success is based on its inputs and how they glue together. This relies on collaboration in all areas – ‘collaborate or die’, to be extreme. If there are mismatches in delivery, client, or technology collaboration, then problems can occur.
This could be a team member who fails to show up for meetings, update tickets, or deliver their work outputs according to the defined timeline. It may also relate to the client who doesn’t get the right people in the room to make decisions, or provide sufficient information for the project. Or, it could relate to technology, when apps or integrations cannot connect, or are built with conflicting code.
How to mitigate this risk:
- Support: If team members are feeling overwhelmed by the project, support them.
- Stakeholders ‘at the table’: Ensure the client gets the right stakeholders to attend the meetings that require alignment on decisions, and to not withhold information that would be useful to the project.
- Review and test: Before making ‘expensive’ (time and effort) commitments that won’t work, thoroughly review and test technology.
6. Dirty Data and No Data Strategy
Data – another misjudged element of a project – can fall victim to a lack of review into a) what is captured during the customer journey, b) why it’s captured, and c) the quality of the input.
When timelines get squeezed, it is tempting to push legacy data into the target model (new system), which only exacerbates poor data management, now replicated in the new system. This can result in issues in end-user adoption, unhappy customers when having to correct their data, or the business breaching data protection laws.
How to mitigate this risk:
- Data strategy and process: Spend time defining the new data strategy and process – what data is required at each stage of the customer journey in the new system?
- What moves vs. being archived: Review all legacy data to assess what moves into the ‘new world’ and what should be archived (left in the ‘old world’).
- Data cleaning: Before uploading into the new system, clean data in line with data quality standards.
- Preserve data quality: Define business process and system rules (e.g. Salesforce validation rules) to preserve data quality into the future.
5. No Roadmap for the Future
When stakeholders believe they only have one shot at a Salesforce implementation, they often ask for the world to be delivered in the first phase.
The list of requirements becomes the size of an encyclopedia. They attempt to replicate the ‘world’ that exists in their current systems. Meanwhile, other teams will have to wait for their turn. This risk ‘rears its ugly head’ as an imbalance in time spent between sets of stakeholders, not appreciating the capabilities of the new system, and never getting beyond the discovery phase of the project. Without a proper roadmap for future enhancements and projects, the organization will be embarking on the ‘roadmap to nowhere’.
How to mitigate this risk:
- The top-line: Create a roadmap of top-line proposed activities, share it with key stakeholders, and keep it up to date.
- Dependencies: Log any dependencies, such as integrations or resource expertise, which may affect the success of a project.
- Roadmap review: Periodically check if the projects are still relevant and prioritized accordingly to the business needs.
4. Change Management is Forgotten
Change management is core to get projects ‘over the line’. If change management isn’t addressed, you risk the organization not being ready for change.
Remember the example organization from earlier that wanted to replicate their existing processes – to ‘lift and shift’ their legacy data into the new system? These are textbook traits of poor change management.
Simply put, the stakeholders involved in the project aren’t open to doing things differently. This could be due to lack of time to assess the need or not being empowered to experiment. A project can fail if the proposed change isn’t bold enough. Regardless of how many iterations it takes to get to the end result, the technology won’t achieve their goal.
How to mitigate this risk:
- The ‘why’: Explain reasons behind the project, and the need for business change.
- Communication: Explain the process so that stakeholders are aware of the project’s milestones, and how it may affect them.
- Illicit feedback: To track and/or to mitigate issues arising, ask stakeholders for feedback at every stage of the project, to keep it on track.
3. Stakeholders Are Overlooked
Stakeholders are the people who will be affected by what is implemented. Often, projects won’t get the right combination of stakeholders involved. A classic example is decisions being made by the management level, even though these stakeholders are too far removed from the day-to-day so can’t speak on behalf of other people’s needs.
Another example is when people are pulled onto a project, without support for their day job (essentially, their workload doubles). Other stakeholders could become worried about the relationship between the project outcomes and their livelihoods.
How to mitigate this risk:
- Involvement at all levels: Get the right people involved in the project, and empower them to make informed decisions. Don’t assume that the management layer will know the nuances of their team’s work processes.
- Support day jobs: Support stakeholders by backfilling their day jobs so they can dedicate their time to the project, and are able to meet deadlines.
- Communicate progress: Update stakeholders on the project’s progress and illicit feedback, using different formats, appropriate to their needs – meetings, emails, ‘town halls’, videos, etc.
2. Customer Experience Doesn’t Come First
We turn our focus from the ‘client’ to our client’s own customers (which, in an in-house project, would also be your customers). Implementations will consider the process for the internal end users, but they do not think deeply enough about the customers’ experience.
When asked about capturing customer insights, some departments are keen to capture any, and all forms of, data possible. They form an attachment to data without rationally considering the sensitivity and relevance of the data.
Other businesses are focused on chasing the next target, winning the business, and acting too short-term. This has the potential to wreck relationships, brand loyalty, and repeat business.
Go deep into what really needs to be tracked at each stage of the customer journey to benefit the customer.
How to mitigate this risk:
- Simplify: Focus on quality outputs from your product offering. Get your customer journey to ‘yes’ quickly and reduce unnecessary processes.
- Data necessity: Consider the data you capture during the customer journey, and think rationally whether it serves a necessary purpose.
- Think long term: Build the relationship with your customer and place importance on customer lifetime value.
1. Leadership Misalignment
Taking the top spot in the risk run-down is leadership. ‘Trouble at the top’ is the greatest risk to a project.
If your leadership team is not aligned on the project goals, then executives can end up flexing their muscles to play against one another. Each individual comes ‘to the table’ with their own department’s interests or personal career progression, but it’s in the worst case scenario that they’ll play for control and power.
The ‘command and control’ leader believes that the project must progress in a certain way for it to succeed. Other examples may include having invested in a certain technology that isn’t the best solution in the long run, and not considering its scalability, or the future needs of the business. Pride and ego are at stake, and admitting they were wrong would damage them. So, they stick firmly with the decision made, costing the project time, and wasting money.
How to mitigate this risk:
- Stick to the facts: Remove any emotion or blame when highlighting issues, in order to protect egos. As a result, mitigating decisions can be made swiftly.
- Find allies: Anyone high in the org chart, or more knowledgeable, who shares your opinion on the issues raised can help to build gravitas on the situation, and escalate when needed.
- Protect yourself: Keep evidence and escalate if you can. If you are not feeling supported, not progressing or unable to challenge, walk away. No project is worth your wellbeing.
Summary
You’ll notice that these risks are heavily people orientated and that is no real surprise. Projects affect people in many different ways – as you step onto a project, carefully assess the human interactions you will be facing. Could any of them become potential risks to the successful delivery? Identify them as early as possible and use the tips in this top 10 for their mitigation.
Comments: