Project delivery vs ongoing maintenance

List the deliverables, supported journeys, content and environments that form the agreed release. For each important requirement, state how it will be checked and who accepts it. Record known limitations with an owner and disposition. A successful deployment is one delivery event, not a substitute for checking the customer’s task. If the scope includes an integration or recovery process, acceptance should include its relevant behavior rather than only a working screen.

A defect is a failure to meet the agreed behavior. An operating task keeps the released system working, such as replacing a credential or applying a compatible update. A new requirement changes what the system should do. For example, a broken agreed export differs from requesting another export format. Document the applicable correction terms and period rather than assuming they last indefinitely. When a request is ambiguous, compare it with the accepted requirement before assigning it to a maintenance allowance.

Provide source access, deployment instructions, configuration inventory, provider-account ownership and an operating contact list. Record how secrets are stored and replaced without including secret values in ordinary documents. Include backup and restore instructions, known limitations and the checks performed for release. Ask the receiving operator to complete a relevant task using the handover material. Google’s launch guidance highlights operational readiness alongside the release itself; the useful question is whether the receiving team can operate what was delivered.

Updates, access changes, monitoring, backups, content edits and incident response all need an owner, even when they are handled by different teams. Identify which dependencies can change outside your release schedule, such as an external API or app-store requirement. Set a review process for approaching end-of-support dates and planned upgrades. Keep maintenance responsibility attached to a named service or team instead of assuming the original developer will always be available.

A recurring support arrangement can fit steady maintenance and a continuing improvement backlog. Separately scoped work can fit a well-defined change that does not require ongoing availability. Either model needs clear coverage, priorities and exclusions. State whether unused effort carries forward, how urgent incidents affect planned work and how requests beyond capacity are estimated. Select the arrangement using expected responsibilities and business impact, rather than treating every live system as requiring the same package.

At each review, record completed maintenance, incidents, deferred changes and decisions needed from the business. Keep an actionable backlog with the reason for each item. Revisit coverage after a new integration, major feature or change in service importance. A website that becomes a customer portal may need a different operating model from its original launch. Preserve current instructions and company-owned access throughout the relationship so maintenance remains transferable and future project work starts from accurate information.