Why Partner with Oblytech for Your Salesforce Needs Assessment?

Discovery purpose and the decisions it settles

Discovery is the opening stage of any Salesforce implementation, and it is the stage that turns a general wish for a better Salesforce into a set of decisions a build team can act on. It answers four questions: which process the first release must support, who uses that process and what they need from it, what data and systems the process depends on, and what the release will and will not include. A buyer who skips discovery usually pays for it later, because the build team will make these decisions implicitly, in configuration, and the business will discover them only when users reject the result.

The outputs of discovery are therefore the main thing a buyer should evaluate before committing to a program. A discovery phase that produces an enthusiastic summary and no list of decisions has not finished its work. A useful phase ends with a document that a steering group can sign and a backlog that a build team can start from.

Discovery phase artifacts and their approvers

The most useful discovery output is not a single report. It is a small set of working artifacts, each with a purpose and a named approver. The table below sets out the artifacts that most programs need, what each one settles, and who should sign it.

The table is a checklist for the steering group rather than a list of deliverables to be produced in full. Some artifacts will be thin for a small program and detailed for a large one. What matters is that each one exists in a form that someone is accountable for. The data inventory in particular feeds directly into data migration and integration work, which the data migration and integration page covers, so it should be finished before that work is priced.

Stakeholder interviews that reveal the real process

Stakeholder interviews are the main source of discovery information, and they are also the easiest place for a phase to go wrong. Interviews that ask people what they want tend to produce wish lists. Interviews that ask people to walk through the last three times they completed a task tend to produce a process. The second approach is slower but far more useful, because it reveals the exceptions, the workarounds and the points where people wait for others.

The interview group should include people from each function that touches the process, not only senior managers. Frontline users often know which fields are ignored, which automations misfire and which reports are never opened. Their accounts should be checked against the views of managers, because the two will differ. The differences are findings. A manager who believes a process is followed will hear from a frontline user that it is followed only for certain customers, and that difference will decide where the release must be flexible.

Sales-process requests in particular benefit from the stage definitions covered in the sales workflow design guide, since those definitions drive much of what follows. Discovery should also capture the questions the business cannot yet answer. A question such as which team should own a shared object is a finding, not a gap to be hidden. It should be logged with an owner and a decision date.

Scope setting and price explanation in discovery

Scope is the most contested output of discovery, because every request has a sponsor. A reliable way to set scope is to tie each requested capability to a process step and to a measurable outcome. Requests that cannot be tied to either are moved to the deferred list with a reason. When a request is really about direction rather than process, it belongs in a strategy conversation, and the strategy and roadmap development page covers that area. This is not a rejection of the requests. It keeps the first release focused and gives the business a visible queue for later releases.

Pricing follows from scope, and buyers should expect a provider to explain what drives the price rather than to offer a number before discovery is complete. A fixed figure given before these drivers are known is often either a guess or a sign that the provider has not examined the work.

Buyers should also ask what the client must provide during discovery. Interview time, access to sample records, access to current reports and a named decision-maker for each process are the usual requirements. If those cannot be provided, the discovery timetable will lengthen, and the cost of waiting should be included in the planning.

Warning signs of a skipped or rushed discovery

Certain patterns signal that discovery has been shortened or replaced by a template. The proposal describes the same workshop sequence regardless of the client’s business. The data review consists of a request for a file rather than an examination of its contents. The future-state design is produced before the current state has been mapped. The scope statement has no deferred list, which usually means the phase has not made any hard choices. Each of these can be corrected by asking the provider to show how the findings change the plan, and a provider with a real discovery method will be able to answer that question with examples from the work. Once discovery closes, the future-state design becomes the input to build work, which the configuration and customization page covers.

A buyer should also watch for discovery that ends with a long list of recommendations and no decisions. Recommendations are cheap. The useful question at the end of discovery is which decisions the steering group has taken, which remain open, and who owns each open one.

Questions buyers ask before funding discovery

Is discovery worth paying for if we already know what we want?

Usually yes, because a clear wish is not the same as a clear process. Discovery tests the wish against the way the work is done, and it often reveals that the first release should be smaller or different. The cost of that test is far lower than the cost of rebuilding a release that solved the wrong problem.

Can discovery be done remotely?

It can, provided that the interviews include the people who do the work and that sample records and reports can be shared securely. Remote discovery needs a little more planning for scheduling and for reviewing screens, but it does not reduce the need for the same evidence.

How long should the discovery phase last?

The length depends on how many processes are in scope, how many teams must be interviewed and how quickly the client can answer questions. It should be set during scoping and written into the plan with the client’s responsibilities. A phase with no stated end point tends to keep producing findings.

What if the discovery findings suggest we should not proceed?

That is a valid and valuable outcome. A discovery phase that recommends a smaller release, a consulting step, or a delay while data is cleaned has done its job. A provider that treats such a finding as a failure of the phase is not thinking about the client’s interests.

Discovery funding decision and next step

Before you approve discovery, name the sponsor, the process to be examined and the people who run it day to day. With those three items agreed, the phase can be scoped and its outputs can be checked against what was promised. Get in touch about your discovery and needs assessment when you are ready to scope it.