Projects have an expected outcome. When the outcome does not meet minimum expectations the project has not been successful. Industry experts often boiled down project expectations around several key project parameters:
- Scope – Did what was delivered meet expectations?
- Timeline – Was it delivered on time?
- Budget – Did it get delivered at the expected cost?
There are many other types of parameters such as quality, scalability, extensibility, etc. but we’ll assume these are lumped under “Scope” – did you get what addresses the goals. A well-conducted project process (from set up to execution to completion) reduces the chance of an unsuccessful project. Likewise, a good project process can detect potential problems sooner so that corrective action can take place. It’s much better to turn around a project showing warning signs than to be in the thick of a problem.
MondayCall has conducted thousands of projects, some small and some very large scale. Every project has very specific challenges, but we have seen a number of common problems that surface time and time again. We compiled a number of the most common reasons projects start to turn yellow:
- The customer is unprepared or does not have the proper time allocated
- Allocate Enough Time – This is the #1 reason projects go south. Amongst the project parameters above, this mostly affects the timeline. If a project has for example, a 6-week schedule, the pace of the project is rapid. A lot has to happen even in that first week. During the project, a customer may also be learning Salesforce, making business process decisions, getting approvals and reviewing work, and giving feedback all in a small window of time. The customer’s product owner (the main owner of the business requirements) must devote sufficient time to the project to keep the pace moving and as with all important projects, it’s almost always more time than you think.
- Know Your Situation and Objective – As part of any project, you need to assess where you are and where you want to go. Surprisingly, product owners can enter a project without a clear articulation of the business problems they are trying to solve. Part of this vision is informed by the technology options available. Correctly, most product owners are very open to the different ways a business problem can be solved. Design decisions have to be made without complete and perfect information however going in, the specific business objectives should be clear.
- Get Familiar with Salesforce– Getting Salesforce training will make a project go smoother. When the customer knows the capabilities (and limitations) of Salesforce, they can help to make better decisions and set proper expectations. For example, yes, it is true that having a spreadsheet-like interface might make the transition easier for the end-users and might be visually how you think about it — and Salesforce’s UI capabilities could make it possible — but it may not be the best, cost-effective and long-term solution to meet the business requirements.
- Take Ownership – Product owners must be prepared to “own” the solution. If the customer does not elect for an ongoing managed service, the system will not automatically self-manage. In these situations, the customer not only must groom an owner but must also get that owner trained (for example, getting a Salesforce certification(s) and understanding how to administer the system). There are additionally many levels of governance that can be established, depending upon the needs of the organization.
- Organizational structure and processes may also affect project outcomes.
- Clear Decision Making – It’s important for the product owner to have a clear process for decision-making. We often like to ask customers, “how are decisions made here?” Many customers haven’t necessarily dissected how decisions are made in their organization and what its ramifications are. For instance, some organizations are consensus-driven and require multiple approvals for any decision to be made. Ineffective committee-based decision-making can create project drag. In other organizations, there may be a single C-level executive who makes all of the decisions. Big challenges can occur when this individual is unavailable and disconnected from the project. Other projects are driven by IT, but are disconnected from the business units which increases the likelihood of a mismatch in expectations in the final stages.
- Executive Involvement – Similarly, lack of executive support can really harm a project. Executive support can ensure alignment so that what gets produced meets the “big goals”. Without executive support, the project will rely too much on luck when trying to solve a business need and lead to a potential mismatch.
- Single-Point-of-Contact – For consultants, ‘herding the cats’ can create wasted cycles. It is much more efficient for the customer to elect a single point-of-contact who can arrange access and facilitate decision-making. If left to the consultant, it adds extra difficulties since the consultant is not necessarily there day-to-day and does not have the benefit of “being on the inside.”
- Lack of Pace – Timing is everything and when attention is paid to the project, results can be achieved much faster. On the flip side, a slow-moving project greatly increases all manners of risk – increased likelihood of changing requirements, staff changes, and organizational shifts. This most often occurs because the customer has competing priorities and has not allocated enough time for the success of the Salesforce project. Another contributor to a slower pace is analysis paralysis. Focusing on the business requirements and not on how technically the solution should be often help to make decisions faster. Keeping pace is a whole team effort.
- Scope Creep – Salesforce has so many wonderful features and a flexible platform that can pretty much create anything you can envision. However, scope creep is the negative side effect of trying to cram too much into the first release. Good project stewards like to define a “minimum viable product” or MVP. The word “minimum” often has a negative connotation however what it truly means is defining the minimum requirements and deliverables in order to have a successful launch. Adding stuff outside what is minimally needed can add technical complexity which results in delays and potentially more testing and a higher likelihood of additional states or situations that need to be accounted for. Always catch yourself when you say, “it would be nice if we could…” — that’s a clear sign that it may not be necessary. Keep it small and keep it simple. A “big bang” approach can be appropriate at times but also carries inherent risks. Even a “big bang” project can be structured in phases to smartly reduce risk.
- Not taking into Account Adoption – Effective user adoption is one of the biggest challenges for any system. End-users have to see the value so that you see strong usage (and therefore data in the system) and good satisfaction scores. Understanding the psychology of the end-users (which includes all users, management, indirect users, etc.) is extremely important – what are their needs and concerns, skill levels and ‘what’s in it for them?’ Good change management starts early with good awareness campaigns, strong and clear training, easy to understand and effective business rules and support throughout the process and ongoing. Think about the carrot and stick approach. Here’s another blog entry on Getting Sales People to Adopt Salesforce.com which has additional tips.
The list can go on for miles…easily. There are as many points of failure as there are people, business requirements, product features, and organizational situations in a project (and possible combinations of). But when customers can be aware of the most common pitfalls, understand and internalize them and solve them before the project begins, we are well on the road to success. While the issues above can railroad a project, all of these are very addressable and can be mitigated through good preparation, strong communication, and team effort.