How I work
Questions I ask in every Salesforce project
Before I draw an architecture, I ask questions. Mostly the same ones, and mostly the answers are more interesting than the requirements document. Here is the list. If you have no quick answer to three of them, a call is worth it.
Goal and deadline
- 01
Which problem should no longer exist a year from now?
Not "introduce Salesforce", but for example: plan service visits without calling back for details. Without that goal nobody measures whether the project achieved anything.
- 02
How will the business know that it works?
A number that someone already collects today. If there is none, that is the first work item.
- 03
Does this really belong in Salesforce?
Some requirements belong in the ERP, the phone system or a specialised tool. The question is cheaper before the build than after it.
- 04
What happens if the go-live does not happen on the planned date?
The consequences are usually more expensive than expected: the contract for the old system keeps running, the partner team stays on board longer, the business maintains data twice, and trust in the project drops with every delay. If you know these costs per month, you can decide whether a smaller first go-live beats a big one that comes late.
Ownership and partners
- 05
Who decides when two partners propose different solutions?
If the answer is "the loudest one", an architecture role is missing.
- 06
Who owns the repository, the pipeline and the backlog?
If they sit with the implementation partner, changing partners gets expensive.
- 07
Who reviews what the partners deliver before it goes into acceptance?
Problems that only show up in UAT or production cost many times more.
Data and interfaces
- 08
Which system is the master for customers, products and prices?
Manufacturing projects rarely fail in Salesforce. They fail at the ERP interface and on duplicate master data.
- 09
What happens if the ERP interface is down for an hour?
If nobody knows, it has not been decided yet.
- 10
How much data will be in the system in three years?
What runs with 10,000 records can grind to a halt at 10 million. The sharing model and the automations have to handle that from day one.
Operations
- 11
Who runs this in three years?
If every answer to this question is the name of an external person, a handover plan is missing.
- 12
How does a change get into production, and who can roll it back?
Three Salesforce releases a year plus your own releases need a process, not courage.
- 13
What will the licences cost once the rollout is done?
The licence forecast belongs in the architecture decision, not in the budget round afterwards.
One last question
- 14
What has been tried before and did not work?
The most honest answer in the whole project. It often saves months.