Giving Implementation Feedback Without Derailing the Project
Feedback during an implementation is a gift only when it's specific and timely. Vague praise and vague criticism both leave the project team guessing what to ch…
Feedback during an implementation is a gift only when it's specific and timely. Vague praise and vague criticism both leave the project team guessing what to change.
Most implementation friction we see doesn't come from bad decisions — it comes from feedback that arrived too late or too vague to act on before the configuration was locked in.
Point at the workflow, not the vendor
"The approval routing is confusing" is actionable. "The system feels clunky" is not. Describe the exact step and the effect it had on your team.
Screen recordings of the actual confusion happening — a user pausing, backtracking, asking a colleague — are worth more to a project team than a paragraph of written description, and take less time to produce.
Timing matters more than tone
The most useful feedback arrives early enough that a configuration choice can still be revisited — not in the retro three weeks after go-live.
Set an explicit cadence for feedback during user acceptance testing — weekly is usually enough — rather than waiting for a single end-of-phase survey that arrives after the relevant decisions have already been made.
Close the loop
Whatever feedback channel you set up, report back on what changed as a result. Teams that see their input acted on give better, more detailed feedback the next round; teams that don't stop bothering to give it at all.
Responses
Sign in to join the conversation.
Sign in