Seeing the Forest for the Trees

You’ve spent months working with your client to sort out exactly what fields they need on which objects and where they are placed on the page. Phew. That was a lot of work. Now you’re rolling out the build to a broader audience and getting a bombardment of questions or objections or the dreaded, “This doesn’t do what I need it to do.” And for a moment, you believe it. Even though every execution is backed by careful deliberation, you begin questioning, “Maybe this doesn’t do what it’s supposed to do.”

But then you take a step back and a deep breath, and you realize that while the granular decisions were being made, you lost sight of the bigger picture — the why behind even launching into a project of this scale.

You’ve lost sight of the forest for the trees.

The tree is beautiful up close. The bark, the leaves, the roots shooting through the ground. Stare at the tree. Admire it. Celebrate how amazingly strong and huge it has become. Now take a step back. Now another. As you step away from this specific tree, you begin to see how all of the trees work together. Their root systems share the same water source. Their branches rustle against each other. The richness of the forest brings out attributes of the tree you couldn’t see when you were standing next to it.

You guessed it. The tree is a metaphor.

Up close your fields operate the way they were intended — they auto-populate where they should, roll-up appropriately, and even have the proper help text to guide the user along. The page layouts provide context for how the fields interact, grouping them together in a way that facilitates data entry. The objects relate seamlessly, after all, a great deal of thought was put into their architecture. You’ve agonized over mapping the data correctly until your import was finally clean. Still the tree.

If that’s all part of the tree, then what is the forest?

The forest is how the instance of Salesforce that you built fits into the larger picture of your client’s business needs. It’s the reason you decided to architect the database the way you did. It’s migrating 100+ different instances onto one platform. It’s moving off of spreadsheets tucked in people’s drawers so that all of the data has visibility. It’s breaking down silos from department to department to give greater meaning to the data being collected. It’s a smoother platform that’s user friendly and adaptable as needs change. It’s reports with live data instead of monthly, or worse yet, annual reports.

And guess what, if you’ve lost sight of the forest, so has your client. No matter how you slice it, this is major change for them. Even when you’ve been talking about the impact and the next steps after they go-live with their new system, it’s hard to grasp if you’ve never been through this scale of a migration before. That’s why you’re there. It’s your role as a consultant to aid them in this transition and remind them of the reasons they’ve undertaken the project. Help them take a few steps back and survey the forest. It’s really quite beautiful when you stop and look.

Ideas are best when shared. How do you help your clients remember the benefits of the disruption and change that comes with a new database? What are your tried and true ways to put them at ease?