Sample scope of work: an internal approval portal.

Example Building Supply Co. (“the Client”) is a mid-sized building-products distributor with a head office and several branches. Employees request business travel and outside training by adding a row to a shared spreadsheet and emailing their manager. Approvals, questions and changes to estimated costs happen in email threads, and Finance and HR piece together the status of each request from the spreadsheet and their inboxes. Requests are missed, approved twice or approved without the right sign-off, and nobody can see at a glance what is waiting on whom.

This project delivers a web portal, signed in to with the Client's existing staff accounts through single sign-on, that replaces the spreadsheet and email process for travel and training requests. The goals are:

• Employees submit a request through one form and can see its status at any time, without chasing anyone by email.
• Each request goes to the right approvers automatically, based on the employee's manager and department in the Client's existing SQL Server HR database and the approval rules Finance and HR agree.
• Every approval, rejection and change is recorded with who made it and when, so Finance and HR work from one agreed record instead of the spreadsheet and inbox searches.
• The Client's IT team can run, change and extend the system after handover without us.

• Request form. Employees create a travel or training request: purpose, dates, destination or provider, estimated costs by category, cost center and attachments (quotes, agendas). Requests can be saved as drafts, submitted and withdrawn.
• Approval routing. Rules that send each request to the employee's manager, then the department head, and then Finance when the estimated total is above the approval limit Finance sets. Approvers approve, reject or return a request with a comment. Approvers and limits are administrator settings, not code.
• Screens. My requests (an employee's own requests and where each one stands), Waiting for me (an approver's queue) and All requests (for Finance and HR: search, filters by status, department and date, and export to Excel).
• Notifications. An email to the next approver when a request reaches them, and to the requester when it is approved, rejected or returned, sent from a shared mailbox on the Client's email system.
• Audit trail. Every submission, approval, rejection, return, edit and withdrawal recorded with the user and time, shown on the request and included in the export.
• Sign-in. Single sign-on through the Client's existing identity provider, over OpenID Connect or SAML, with four roles taken from groups the Client's IT team manages: employee, approver, Finance and HR reviewer, and administrator.
• Data. The portal's own tables in a new database on the Client's existing SQL Server instance; read-only use of the employee, department and cost-center views in the existing HR database; attachments in encrypted storage in the Client's AWS account.
• Spreadsheet import. A one-time import of the requests still open in the current spreadsheet when the portal goes live.
• Infrastructure and delivery. Infrastructure defined as code (AWS CDK), deployed through a CI/CD pipeline (GitHub Actions) into separate test and production environments.
• Monitoring. Alarms for application errors, failed notification emails, database connection failures and sign-in failures.
• Documentation and handover. Runbooks, a data dictionary, architecture and security documentation, and knowledge-transfer sessions, as set out in section 11.

• Booking travel, buying training, paying suppliers or reimbursing employees. The portal records requests and approvals; purchasing and payment stay with the Client's existing processes.
• Expense reports after travel. A candidate for a later phase, quoted separately.
• Any write to the HR database. The portal reads employee, manager, department and cost-center data; changes to that data are made in the HR system, as today.
• Importing closed requests. The current spreadsheet is kept, read-only, as the archive of past requests.
• Other request types, such as equipment or system-access requests. The routing design allows more types to be added (see the “Add a request type” runbook), but configuring them is a separate change.
• Mobile apps and offline use.
• Access for anyone without an account in the Client's identity provider, such as contractors or guests.
• Integration with any other business system.
• Hardware, network changes and software licenses. We specify what is needed; the Client's teams make the changes and hold the licenses.
• Support, maintenance or new features after handover. Available as separately quoted work.

• The Client provides the access in section 4 before the build phase starts. If access arrives later, the schedule moves with it; the price changes only if the scope does.
• Finance and HR sign off the approval routing rules in phase 1. Afterwards, changing an approver or a limit is an administrator setting, not a change; a new kind of rule is a change (section 9).
• The manager and department data in the HR database is correct. Where it isn't, the Client corrects it in the HR system; the portal doesn't keep its own copy of the org chart.
• The Client's database administrator creates the new database, the two logins and the three read-only views to the design agreed in phase 1.
• A site-to-site VPN (or AWS Direct Connect) links the Client's network to its AWS account, set up by the Client's network team.
• The Client names one product owner who can answer questions and accept deliverables, and one contact each in Finance and HR for the approval rules.
• Finance cleans up the open requests in the spreadsheet before the import (one row per request, using the template in the data dictionary).
• The test environment uses a copy of the HR views with test employees, provided by the Client's database administrator. No production personal data is used in test.
• Hosting, license and other third-party costs are billed to the Client's own accounts.

• Source code for the portal, with automated tests, in the Client's repositories.
• Database migration scripts for the portal database, run by the pipeline, so the schema is versioned with the code.
• Infrastructure as code (AWS CDK) for the test and production environments.
• A CI/CD pipeline (GitHub Actions) that tests, builds and deploys every change, authenticating to AWS with OIDC so no AWS keys are stored.
• An architecture and data-flow document for the Client's security review, including every network rule with its source, destination, port and purpose.
• A data dictionary covering every table, view and field the portal reads or writes, plus the spreadsheet import template.
• Runbooks: deploy, roll back, rotate credentials, change an approver or a limit, add a request type, and respond to each alert.
• Knowledge-transfer sessions, listed in section 11.

The system is accepted when every criterion below passes in production. Each one is checked together with the Client's product owner.

Acceptance is judged against these criteria only. Anything not listed here is not a reason to withhold acceptance, and is not in the price; it can be raised as a change (section 9).

Work runs in five phases. Each phase ends on a written exit criterion, and working software is reviewed with the Client in the test environment throughout phases 2 and 3.

Milestone dates: stated here in the real document, agreed with the Client before work starts.

1. Either party raises a change in writing: what is needed and why.
2. We reply in writing with its effect on scope, price and schedule, or confirm that it has none.
3. Nothing changes until the Client's product owner approves it in writing. Approved changes are added to this document as numbered amendments.
4. A change that isn't approved isn't built, and the original scope and price stand.

Until the system is accepted, fixing something that fails an acceptance criterion in section 7 is not a change. It is covered by the fixed price.

The following are prepared for the Client's IT and security teams during phase 1, before the portal connects to any Client system:

• A data-flow diagram showing every connection and its direction. The only connection into the Client's network is the portal's SQL Server connection over the site-to-site VPN, on a single network rule the Client's network team controls.
• A network rule list: source, destination, port, protocol and purpose for each rule.
• Database logins: one read-only login for the HR views and one for the portal database, named and documented. No shared or personal credentials in the running system.
• Sign-in only through the Client's existing identity provider, so the Client's existing multi-factor and access policies apply. Roles come from groups the Client's IT team manages in that identity provider.
• Access checked on every screen and API call: the user's role and, for a request, whether the user is its requester or a current approver.
• Secrets kept in AWS Secrets Manager, never in code, configuration files, tickets or email.
• Encryption in transit on every connection, and at rest for stored data, attachments and backups.
• Logging of sign-ins, deployments and application errors to CloudWatch, retained according to the Client's policy.
• Dependency scanning in the pipeline, with findings reported to the Client before each release.
• Data classification: employee names, work email addresses, departments, travel and training details, and attached quotes and agendas. No payment card or identity-document data is stored, and the request form says so.
• Answers to the Client's security questionnaire, and an architecture walkthrough for the security team.

Handover is part of the fixed price. It is complete when the Client's team has deployed a change, rolled it back and responded to a test alert themselves, using only the documentation. It includes:

• Everything in section 6, confirmed in the Client's repositories and accounts.
• Knowledge-transfer sessions: architecture walkthrough, code tour, supervised deployment, rollback and recovery, changing an approval rule, and a test incident.
• Access and credentials: every account confirmed as the Client's, secrets rotated, and our access removed or reduced to whatever support is agreed.

The full contents of a handover package are shown in the sample handover package. It was written for a different invented project, a plant-floor dashboard, but it is organized the same way for a portal like this one.

• The Client owns all code, infrastructure definitions, documentation and data produced under this scope. There is no license fee and no lock-in.
• Everything is built in the Client's repositories and AWS account. Nothing runs in accounts we control.
• Open-source components remain under their own licenses, which are listed in each repository.
• Confidentiality is covered by the NDA signed before this engagement.

Fixed price: stated here in the real document.

The fixed price covers everything in sections 2, 6, 7 and 11: design, build, testing, deployment to test and production, documentation, knowledge transfer, handover, and fixing anything that fails an acceptance criterion before acceptance.

It does not cover:

• Anything listed as out of scope in section 3.
• Approved changes under section 9, each priced before it starts.
• Hosting, software licenses and other third-party costs, billed directly to the Client's accounts.
• Support, maintenance or new features after handover, quoted separately if wanted.

Invoicing schedule and payment terms: stated here in the real document.

Nothing is built until this scope is accepted. Signing below accepts the scope and the fixed price stated in section 13.