In this article16 sections
Implementation fails when feedback has no system
In digital projects, feedback is often treated as something natural. The team delivers a version, users review it, send comments and the project moves forward. In practice, that rarely happens by itself. If feedback and testing during implementation are not organized, comments arrive late, repeat themselves, conflict with each other or come from people who do not share the same view of the goal.
The problem is not that users do not want to help. The problem is that they are often not told what exactly to test, how much time they have, how to submit comments, who filters them and what happens when two departments request opposite things. Without rules, testing becomes emotional and fragmented.
Feedback is not a wishlist
Good feedback is not a list of every idea that appears during testing. Good feedback is connected to the goal of the phase. If the goal is to test the basic workflow, distant exceptions should not block the first version. If a report is being tested, feedback should explain which data is missing, why it matters and who uses it.
It is useful to separate three types of comments: bug, improvement and new functionality. A bug means that an agreed feature does not work. An improvement means that it works but could work better. A new functionality means that something outside the agreed scope is being requested.
Testing needs scenarios, deadlines and owners
Testing without scenarios is usually shallow. People click through the system, notice a few things, give general comments and return to their regular work. This kind of testing rarely reveals real problems. Useful testing follows real work: creating a request, approving it, changing it, escalating it, generating a report, searching information or entering data.
Every scenario should have a person responsible for testing and a deadline for feedback. If testing is assigned to a group without ownership, everyone assumes someone else will check the details. Later, when an issue appears, the same group says it did not notice it.
Ownership cannot stay only with the vendor
One dangerous assumption is that implementation is the responsibility of the external partner alone. A partner can provide methodology, configuration, development, integrations, training and guidance. But the partner cannot decide instead of the client how the company wants to work, which exception matters and how the change will be accepted by the team.
Ownership must be shared. Positive is responsible for expertise, solution design, delivery and process guidance. The client is responsible for business decisions, access to people, feedback quality, data and adoption. When one side does not take its part, the project loses balance.
A healthy implementation rhythm is simple
A healthy rhythm does not have to be complex. For most projects, a weekly or biweekly cycle is enough: agree what will be done, deliver or demonstrate, test, collect feedback, decide what goes into the next iteration and record open issues. The important thing is that the rhythm exists and is respected.
One official communication space is essential. If comments are sent through multiple channels, some get lost, some repeat and some lose context. The project needs a single place for tasks, decisions, notes and feedback. Email and chat can help, but they should not be the project’s only memory.
One communication channel protects project memory
Frequent communication is not enough during implementation. It must be organized. If decisions are spread across emails, document comments, Teams messages, chat groups and verbal agreements, the project has no single memory. When a misunderstanding appears, everyone refers to a different source.
That is why one official channel should be defined for tasks, comments, decisions and status. It can be a project tool, ticketing system, ONE or another agreed channel. The point is not the tool name, but having one place where decisions, responsibilities and next steps are visible.
Users need guidance through change, not only training
Training matters, but it is not enough. People can learn where to click and still not understand why the way of working is changing. Implementation should explain the purpose of change: what improves, what is no longer done manually, who sees which data, how errors are reduced and why the new process matters for the whole team.
When users understand the purpose, feedback becomes better. They do not comment only on screens. They understand what the solution is supposed to achieve. That is the difference between a passive user and an active participant in change.
Good implementation prepares the next phase
Every serious implementation should create the foundation for the next phase. When the first phase ends, the team should know what has been accepted, what remains for later, which requests are new, which risks have been reduced and what will be measured next. Without this, the project may be formally complete, but the organization does not know how to continue improving the system.
At the end of a phase, the team should not only close tasks. It should close a learning cycle. The company gains insight into how people use the solution, where the process is still immature and which next step creates the most value. That is when digital transformation stops being a project and starts becoming a management discipline.
Acceptance is a business decision, not only a technical confirmation
At the end of each phase, it should be clear whether the solution is accepted, accepted with corrections or not ready for the next step. Without that decision, the project can remain in endless polishing. Nobody knows whether the phase is complete, and new requests mix with old agreements.
Acceptance does not mean that everything is finished forever. Digital solutions evolve. It means that the agreed phase is good enough to move forward, while improvements are planned in later iterations. That is the difference between controlled development and endless rework.
If you want implementation with clear feedback and accountability
Positive can help you define implementation rhythm, testing scenarios, roles, feedback rules and acceptance criteria before the project starts. Book a consultation and set clear ownership from the beginning.
Questions readers are likely to ask
How should feedback be organized during implementation?
It should be connected to the phase goal, submitted through one channel and separated into bugs, improvements and new requests.
Who should test the solution?
Key users from the departments that will actually use the solution, with clear scenarios and deadlines.
What is a good test scenario?
A scenario that follows a real workflow such as creating a request, approval, reporting, search or data entry.
Who accepts a project phase?
The internal project owner, with input from key users and the implementation team.
Does every comment need to be implemented immediately?
No. Comments should be classified by priority and by whether they belong to the agreed phase or represent a new request.
