SOFTWARE PROJECT MANAGEMENT · THE DECISIONS BEFORE THE DEADLINE
The project board is full. The meetings are booked. Nobody agrees what the first release must actually do.
A software project needs coordination, but activity is a poor substitute for a shared outcome. A deadline becomes useful when the team understands what must work, who decides when priorities conflict and how the result will be accepted.
Before adding another status meeting, settle the questions that can otherwise return as expensive changes.
Write down what should improve
“We need an app” describes a possible solution. “Staff re-enter the same service report after every visit” describes work you can investigate. Watch the current process, find who does it and establish what time, mistakes or delays matter.
The GOV.UK discovery guidance puts understanding the problem before committing to a build. Its rules govern government services, but the sequence is useful in a business project too. Discovery may show that an existing tool or a process change would do the job.
Choose a result that users and the budget holder can recognize. Record the starting point and the conditions for comparison. If faster reporting matters, define which report and how accuracy will be protected.
Give priority decisions a named owner
A team can collect suggestions from everybody without promising to build all of them. Keep a prioritized list and make the first useful release small enough to finish. Separate what the operation needs now from what it may eventually want.
Every new request changes the plan. Explain the effect on effort, cost and the release, then let the authorized owner decide. Keep that decision visible so the same argument does not consume the next meeting.
The Scrum Guide makes the Product Owner accountable for ordering the Product Backlog. You do not need to adopt every Scrum practice to benefit from clear priority ownership. A committee of people who can all add work but cannot remove any is difficult to plan around.
| Question | Useful answer | Evidence |
|---|---|---|
| What must improve? | A named operational outcome. | A baseline and an agreed measure. |
| Who decides priorities? | A person with authority over scope and trade-offs. | A maintained decision and change record. |
| What can block delivery? | Dependencies with owners and dates. | Test access, sample data and supplier commitments. |
| When is it acceptable? | Observable behavior and quality conditions. | Completed acceptance work, not a progress percentage. |
| Who operates it? | Named support and system owners. | A handover, recovery plan and running budget. |
Test the connection before polishing the screen
A screen may take a day to change while access to an external system takes weeks to arrange. Identify the dependencies early: data owners, test accounts, suppliers, devices, payment providers and operational staff who must approve the workflow.
Try the riskiest connection with a small working example. Check the actual permissions and data format. Test a rejected record and decide who resolves it. A promise that a system “has an API” does not establish that your project has the right access or that its business rules match.
Raptool's integration page lists connection approaches including files, databases and web services. Treat that as a starting point for a specific demonstration, not proof that every application connects automatically.
Use a short risk register that people act on. Each important risk needs an owner, a next step and a point at which the team will change the plan. A document that merely records worry will not unblock a release.
Agree what done means while changing it is still cheap
The Scrum Guide distinguishes completed work through a shared Definition of Done. For a business app, translate that into practical evidence: agreed functions work, required permissions have been checked, important errors are handled and the intended users can complete the task.
Write acceptance examples before the demonstration. Include normal work and exceptions. Show progress through a usable slice of the workflow rather than a collection of disconnected screens. The person who will use the app should help judge it.
A short decision can prevent a long rebuild
Suppose a discussion using two total participant-hours resolves a misunderstood approval rule that would otherwise require 24 hours of rework. The net difference is 24 − 2 = 22 hours, worth €1,320 at an assumed €60 an hour.
That is a scenario showing the cost of delayed decisions, not a claim that every meeting saves money. Count the participants' total time and verify whether rework was avoided.
Protect quality when the date becomes uncomfortable. Reduce the scope openly if necessary, and keep the agreed checks for what remains. Concealing unfinished work inside “nearly done” creates a problem for the person who has to operate it.
The launch is a handover
Agree migration, training and rollout with the people who run the operation. Keep a fallback and decide what would cause you to stop or reverse the release. Make support contact details, access ownership and recovery instructions available before the first busy shift.
Budget for maintenance and change. Set a date to review the original outcome after users have worked with the system. Delivery is more convincing when the business can show that the app improved the job it was built to improve.
Good project management makes decisions clear enough that the team can deliver useful software. A full calendar is not evidence that those decisions have been made.
Questions behind the decision
What should a software project settle before development?
The operational outcome, decision authority, first-release scope, important dependencies and observable acceptance criteria.
Does the article require every team to use Scrum?
No. It uses the Scrum Guide as a source for priority ownership and a shared Definition of Done. The practical recommendations can be evaluated with other delivery methods.
When is the project finished?
Agree the required behavior, quality checks and operational handover in advance. Review the intended business outcome after users have worked with the release.
Sources and scope
Research checked October 2026. Sources are linked beside factual claims. Worked scenarios are illustrative, not customer results or supplier quotes. Screenshots show published platform material; device photos are catalog references, not compatibility certification.
