How to Read This List
The following ten mistakes are not ordered by frequency, but by their appearance in a project's timeline. For each, three things are provided: the early warning sign that can be identified in real-time, the preventative action, and the stage after which correction becomes significantly more expensive. The idea is simple — almost every one of these mistakes costs very little if addressed during the correct two-week window.
1. Starting with a Feature List Instead of a Process
The Sign: The requirements document is structured as a table of desired capabilities, with no row describing a business outcome.
What Actually Happens: The project produces a system that fulfills the list but doesn't change how work is done. A year later, management asks what has changed, and there's no measurable answer.
Prevention: For each requirement, attach the process it serves and the metric it's supposed to impact. Any requirement without answers to these two questions moves to a waiting list. The set of deliverables that prevents this pattern is detailed in the CRM Discovery Guide.
2. No Single Process Owner
The Sign: Four people from the same department attend meetings, and none are authorized to say "this is how it will be."
What Actually Happens: Every decision is settled through a compromise that tries to please everyone, meaning two paths are built instead of one. The system becomes twice as complex as necessary.
Prevention: Assign a single individual as the owner for each process. The recommended division of roles is detailed in the Salesforce Project Team Roles guide.
3. Pushing Architectural Decisions to the End
The Sign: The team proceeds with building screens while the question "what is the single source of truth for the customer" remains open.
What Actually Happens: When the decision is finally made, it contradicts what has already been built. Some work is discarded, and the initial project estimate becomes irrelevant.
Prevention: Early on, identify the three to five decisions that are costly to change—core data model, source of truth, permissions model—and set a decision deadline for them before construction begins.
4. Importing the Debt of the Old System
The Sign: The migration specification includes all fields from the previous system, including those ending in "_old_2".
What Actually Happens: The new platform is born with two hundred fields that no one maintains, reports relying on unreliable data, and users concluding that the new system isn't serious either.
Prevention: Every field that is migrated must have an owner and a proven use within the last year. The rest go to a readable archive, not into the live system.
5. Measuring Progress with Closed Stories
The Sign: The weekly report shows high completion percentages, but no one has yet been able to run a complete end-to-end process.
What Actually Happens: The project looks like a success on the chart until the week before go-live, when it's discovered that all parts work in isolation and no one tested the connections.
Prevention: Define an "first live end-to-end process" milestone as early as possible, even if it covers only one scenario. Until this is achieved, completion percentages are not informative.
6. Required Fields as a Substitute for Data Discipline
The Sign: A record creation screen includes twelve required fields, three of which no one knows who is supposed to know their values.
What Actually Happens: Users select the first value in the list to move forward. Reports receive completely full but also completely incorrect data.
Prevention: A field is only required if it's needed for a decision at the point it's requested. Fields needed later in the process are enforced later in the process.
7. Building Automation Before the Process Is Stable
The Sign: There are three automation mechanisms operating on the same object, and no one knows their execution order.
What Actually Happens: Unexpected side effects, update loops, and critically, an inability to change a process without fearing what will break.
Prevention: Run a manual or semi-manual process for several weeks before automating it. Automation solidifies a decision — it's best if that decision is the right one.
8. UAT Performed by the Builders
The Sign: Test scripts were written by the same team that developed them, and they primarily cover the happy path.
What Actually Happens: The issues that reach production are exceptions — cancellations, credits, duplicate customers, users who left a process incomplete.
Prevention: Testing is performed by process owners, using data similar to real data, with defined responsibility for approval or rejection.
9. Training as a One-Time Event
The Sign: The implementation plan includes two workshops in the week before go-live, and nothing afterward.
What Actually Happens: Users learn screens, not processes, forget within two weeks, and turn to colleagues or an Excel sheet. System usage gradually declines unnoticed.
Prevention: Role-based training, as close as possible to when the employee will actually perform the action, with an available support point in the first few weeks.
10. No Ownership After Go-Live
The Sign: The project plan has no line item describing who manages the system in the third month.
What Actually Happens: Change requests pile up unanswered, minor bugs become workarounds, and the system quickly becomes outdated.
Prevention: Define operational ownership, a request intake mechanism, and a regular release cadence before go-live, not after. In large organizations, this is typically done through a structured governance model, as described in the Enterprise Salesforce Implementation guide.
Cost of Correction by Stage
| Mistake | Correction in Discovery | Correction in Build | Correction After Go-Live |
|---|---|---|---|
| Incorrect Data Model | Diagram change | Object rebuild | Full internal migration and re-testing |
| Lack of Process Owner | Appointment | Stalling and repeated decisions | Maintaining a duplicate process forever |
| Debt from Old System | Field list filtering | Pre-load clean-up | Clean-up on a live system |
| Unnecessary Required Fields | Decision in screen design | Configuration change | Cleaning up accumulated incorrect data |
| Lack of Operational Ownership | Definition in plan | Recruitment or training | Rebuilding user trust |
Illustrative Example: A Medium-Sized Insurance Company
This hypothetical scenario is for illustration purposes. An insurance company went live with Salesforce for agent management. Three months later, it was found that the update rate of agent records was low. The investigation didn't find a single technical fault: three of the above mistakes were found concurrently — unnecessary required fields on the creation screen, lack of an owner for the agent recruitment process, and training given two months before the first new agents started using the system.
The fix was not technical. Six required fields were removed, a single process owner from the operations department was appointed, and training was split into short segments delivered in the week each group started work. The only architectural change required was deferring the requirement for two fields to a later stage in the process.
What to Do with This List
Go through the ten mistakes and mark if the early warning sign currently exists in your situation. Three or more signs in a project that has not yet gone live warrant a short pause and correction, not acceleration. The same three signs in a system that is already live justify a structured diagnosis before adding new capabilities atop an unstable foundation.