How to manage software project change requests

1. Describe the requirement, not just a proposed solution

Explain who encounters the problem, in what situation and what outcome is expected. Identify the project, author, proposed priority and benefit. Add a target date or version when one is known.

Illustrative example: “The client manager needs to export orders for the monthly reconciliation. Today, each row is copied manually.” This explains why the feature matters, beyond asking for an Export button.

2. Classify and assess the request

Distinguish an improvement, a new feature, a bug fix and technical maintenance. Check whether the requirement is already covered, who is affected and which dependencies could complicate implementation.

Urgency should have a concrete reason. Compare expected benefit with estimated effort. A missing estimate is more honest than a number presented as certain without investigation. Keep questions and answers in the request comments.

3. Make the decision visible

The project manager or administrator accepts or rejects the request. It can remain “To review” while information is missing. If it is rejected, record a reason so the author understands the decision and can refine the requirement where appropriate.

• Proposed: the requirement is captured.
• To review: benefit, constraints and effort are clarified.
• Accepted: implementation is approved.
• Planned: implementation tasks are created.
• In progress: implementation has started.
• Delivered: the change has been handed over and validated according to your process.
• Rejected: the decision and its reason are preserved.

4. Turn an accepted request into tasks

Break implementation into actions that can be checked. An order export could require defining the columns, generating the file and testing access permissions. Assign each task and set a deadline when you can make a commitment.

Keep tasks linked to the original request. In SuiviDev, an accepted request can become one to thirty tasks in a single operation. Its status becomes “Planned”, and a second conversion is rejected to prevent duplicates.

5. Track delivery and scope changes

The new tasks now contribute to project progress; the original idea did not. Adding tasks can lower the percentage because the scope has grown. Explain that change to the team and client.

Preserve the target version or date, comments and decision history. In SuiviDev, moving the request to “In progress” and then “Delivered” remains an explicit management decision, distinct from moving an individual task card.

Review the backlog regularly

Review proposals with the project manager. Clarify incomplete requests, reject those that no longer address a need and plan those whose benefit justifies the effort. The aim is understandable decisions, rather than a growing list of ideas with no outcome.

The change backlog then keeps its purpose: capturing future needs while the task board shows the work the team has actually committed to.