Software Development for Businesses: Phases, Checks and Handover

Agree the outcome and the decision process before work starts

If you are still deciding whether the application should be built at all, start with the comparison of off-the-shelf software, integration and custom development.

Describe the business situation that needs to change and who will verify the change. One example of an outcome: a manager can process a procurement request in a single workflow, with the decision and the rejection reason visible.

Also define what the project does not cover for now. The first scope may cover a request and its approval but not automatic ordering from a supplier or posting to the ERP. That boundary has to be clear to both the business team and the vendor.

On the client side, name one person who sets priorities and a deputy for when they are unavailable. Experts from procurement, finance or the warehouse still need to take part in checking their own tasks. One accountable person does not mean one person knows every detail.

Every phase should leave something you can review

A project does not have to follow one universal sequence. Some activities are repeated while requirements are clarified. The working table below helps you track the collaboration.

A prototype shows the proposed way of working. It does not prove that integrations are connected, data migrated or permissions enforced. Ask what in the demonstration is actually connected and what is there only for display.

Turn a general requirement into a verifiable example

A requirement such as “the manager approves procurement” leaves open questions: does that mean every request, can the amount be changed, and what happens when the person is away?

The following hypothetical example uses invented internal rules. The company wants the manager to approve every request, with finance confirming amounts above EUR 2,000. That figure is not a legal threshold or a market standard.

Clarify before development:

• whether the threshold applies to amounts with or without tax;
• what happens when a later edit pushes a request over the threshold;
• whether a requester can approve their own request;
• who takes over approvals during an absence;
• what the user sees after a rejection or a request returned for revision.

An acceptance criterion might read: changing the amount after approval returns the request for the required check, and the earlier decision stays visible. A sentence like that can become a test case you review together.

Build security and accessibility into the work items

Do not leave them as vague items on a final checklist. State the sensitive data, the permitted actions, the expected sign-in method and the process for removing a former employee's access.

NIST's SSDF describes security practices that can be included in different development processes. It is a useful framework for questions to a vendor, without promising that a single review removes every risk.

For the interface, prepare tasks that can be checked, such as entering and correcting a form with a keyboard. W3C's guidance on planning and managing accessibility covers responsibilities and early, repeated evaluation. Agree who runs these checks and what counts as an acceptable result.

Record changes during development before deciding

A new idea is not automatically a mistake in a project. The problem starts when its effect on the existing agreement is never considered.

A change request needs a clear record: what changes, why, which functions and data it touches, and the proposed effect on schedule and price. Also note the option of postponing or replacing another item.

In the procurement example, an extra finance approval can change notifications, permissions, status display and tests. An agreement to “add one more confirmation” does not show that scope.

Distinguish a deviation from an already accepted criterion from a new requirement. Agree how changes are recorded, owned and billed together; this article does not determine the contractual classification of a specific case.

Run acceptance on real user-role tasks

Prepare cases that business people will check, with support from the development team. Use realistic test data and permissions close to day-to-day work. An administrator who can see everything passing the test is not proof that the same procedure works for an employee with limited access.

Microsoft's go-live checklist for Dynamics 365 includes edge cases, appropriate roles and verification of migrated data in acceptance. You can adapt the same kind of questions to your project.

For every defect, record the steps to reproduce it, the expected and actual result, and its importance to the work. Decide who confirms the fix. Review open items before deciding on go-live instead of assuming, without checking, that none of them affects users.

Plan go-live as a separate event

Agree when data entry into the old system stops, who checks the final transfer and how users get access. If you run a pilot, state who takes part and where the line is between pilot data and live work.

You also need an agreed procedure for when the conditions for launch are not met. Reverting to the old way of working may require reconciling new data; it is not simply a matter of switching the previous application back on.

On launch day, users need to know who to report a problem to, what information to send and how to check that the report has been picked up.

What should be clear at application handover

Review the list of accounts and access for the domain, infrastructure, third-party services and code, according to the agreed model of cooperation. Clarify rights to the materials produced and the licences used. Custom development by itself does not replace that agreement.

Ask for instructions for routine administrative tasks, known limitations and a description of support. Distinguish fixing existing behaviour, a security update, a third-party service change and development of a new feature. State who monitors which events and how additional work is agreed.

If you are preparing a custom software development project, start from a function you can describe and accept. Send Novero an example process and the expected deliverable so the conversation covers handover, not just the start of development.

Sources

• NIST: Secure Software Development Framework (SSDF), SP 800-218 — security practices that can be included in development processes.
• W3C: Planning and Managing Web Accessibility — responsibilities and early, repeated evaluation of accessibility.
• Microsoft: Prepare for go-live checklist (Dynamics 365) — edge cases, appropriate roles and verification of migrated data at go-live.