I left off with a company looking to implement a CRM to solve the problem of “we don’t have one.” Maybe they feel left behind because “everyone else has one,” or perhaps a new executive had a great experience with a CRM at their last firm. But before we look at software, we have to start with the Whys.

Imagine a discovery conversation starting like this:

The Analyst: “Why do you believe we need a CRM?”

The Stakeholder: “We need to track sales.”

The Analyst: “Why?”

The Stakeholder: “So we can pay our salespeople their commissions.”

The Analyst: “So the problem you are trying to solve is that we are unable to pay commissions?”

The Stakeholder: “Well, no. We pay them already.”

The Analyst: “Then how would a CRM help?”

The Stakeholder: “It would make the process better. Right now, we gather data on spreadsheets manually. A CRM could calculate it instantly.”

The “Aha!” Moment: The problem isn’t “No CRM.” The problem is that the commission process is prone to error, takes too long, and requires too many manual handoffs.

As the conversation continues, more layers of the work breakdown pyramid emerge:

Vulnerability: Sales reps keep info in their heads or personal files. When they leave, the data leaves with them.

Continuity: New reps have no history to pick up on.

Visibility: Management has no real-time view of the pipeline.

Problem clarification: You moved from a proposed solution to specific concerns that can now be tested against evidence.

Current-state perspective: you’ve gained a high-level view of how work is actually moving (or not moving).

High-level requirements: You are already building the What that the eventual solution must do.

The “automation trap”

In most organizations, this is where they would run out and buy the software. But there is a massive hurdle to clear first: Standardization.

You cannot effectively automate a mess. If three different sales reps have three different “ways” of closing a deal, how do you configure the system? If you try to build a CRM to satisfy everyone’s subjective “special process,” you end up with the rework and resistance I talked about in my last post.

Sometimes, the best recommendation a BA can make is: “Standardize your process first. Buy the system second.”