A recommendation can be sensible and still be difficult to put into practice. The team receiving it has existing systems to maintain, other commitments, and questions the plan may not answer.
Who will own the change? What has to happen first? How will people use it? What happens if it fails?
Those questions belong in the planning work.
Follow the process before changing it
We walk a process from input to output with the people responsible for it. We look at where time goes, which decisions wait, and how exceptions are handled. Written procedures are useful, but they need to be checked against the way people work today.
That gives a recommendation enough context to be tested. A proposed automation might save time in one step while adding review work in another. A platform change might solve a reporting problem but create an integration problem. Those details affect whether the project is worth doing.
Make the next step specific
A useful implementation plan names an owner, the systems involved, the dependencies, and the first result to test. It also explains what the team needs to stop doing or do differently.
Estimate the costs and benefits where you can. Show the assumptions and identify the parts that need evidence from a pilot. A precise-looking forecast is not a substitute for that evidence.
Give the receiving team a chance to question it
The people doing the work should be able to explain how the recommendation would fit into their day. If they cannot, there is more planning to do.
That conversation is often where a broad recommendation becomes a manageable project. It may also reveal that a smaller change would be enough.
Ron Davis
Founder
Three decades building enterprise platforms. Started Joust to close the gap between strategy decks and the work they're supposed to change.