How I work
Sample delivery artifacts
The plans, reports, and controls I use to keep a project on time and on budget. These are illustrative samples and hold no confidential client information.
Download these as free, editable templatesDelivery plan
The step by step plan for bringing several organisations onto a single, well managed system.
-
Research
Weeks 1 to 3- Review the existing tools
- Agree what the single system should cover
-
Building
Weeks 4 to 10- Build the main system
- Move the shared information across
-
Bringing organisations on
Weeks 11 to 14 In progress- Move each organisation onto the single system
- Provide training and written guidance
-
Launch
Week 15- Switch over to the new system
- Obtain formal approval
-
Support and improvement
Week 16 onwards- Provide close support after the launch
- Review what went well and what could be improved
Budget management plan
How I planned, tracked and kept control of the budget on a publicly funded project. The figures below are illustrative.
- Total budget
- £120,000
- Spent to date
- £72,000
- Remaining
- £48,000
- Budget used
- 60%
How to read this: Remaining is the budget minus what has been spent. Used is the amount spent as a share of the budget. The figures are illustrative.
| Category | Budget | Spent | Remaining | Used | Status |
|---|---|---|---|---|---|
| Development | £54,000 | £36,000 | £18,000 | 67% | On track |
| Testing and quality | £18,000 | £7,000 | £11,000 | 39% | On track |
| Project management | £18,000 | £11,000 | £7,000 | 61% | On track |
| Design | £12,000 | £10,000 | £2,000 | 83% | On track |
| Setup and running costs | £12,000 | £6,000 | £6,000 | 50% | On track |
| Contingency reserve | £6,000 | £2,000 | £4,000 | 33% | At risk |
| Total | £120,000 | £72,000 | £48,000 | 60% |
How the budget is controlled
- Reporting
- Spending is reviewed and reported every two weeks.
- Approval
- Any spending above the agreed limit needs the client to approve it first.
- Change control
- Any change to the scope is costed and agreed before the work starts.
- Contingency
- A small reserve is kept for unexpected work and released only when needed.
Weekly status report
The short weekly summary I used to keep the client and the team informed of progress.
- Work included
- The booking, engagement, messaging and reporting features have all been agreed and confirmed.
- Timing
- The reporting section is running a little behind. A plan to recover the time has been agreed.
- Budget
- Spending remains in line with the plan.
- Risk and compliance
- The protection of personal information was built into the plan from the very beginning.
Key stages
- Requirements agreed Stage 1
- Booking and engagement features built Stage 2
- Reporting and administration Stage 3
- Client testing and launch Stage 4
Risk and issue log
How I tracked the risks, assumptions, issues and dependencies on a product that holds private staff wellbeing information.
| ID | Type | Item | Impact | Owner | Status and response |
|---|---|---|---|---|---|
| R1 | Risk | Staff wellbeing information is private and must be protected at every step. | High | Project Manager and development lead | Managed. Data protection was built into the plan from the first stage and checked at each release. |
| D1 | Dependency | Booking, messaging and reporting all rely on one shared set of records. | Medium | Development team | Tracked. The shared records were agreed early so the parts stayed in step. |
| A1 | Assumption | Employers manage their own staff and settings from an admin area. | Medium | Product team | Confirmed with the client before the work began. |
| I1 | Issue | The reporting section was running a little behind the plan. | Medium | Project Manager | Resolved. A short recovery plan brought the timing back in line. |
Delivery board
A view of the board I used to keep the work visible and moving.
To do 2
-
Upload of identity documents
New feature -
Exporting account statements
New feature
In progress 2
-
The loan application process
New feature -
Matching of payments
New feature
Client review 1
-
The sign up screens
Awaiting client approval
Completed 2
-
Sign in and user permissions
Delivered -
The main dashboard
Delivered
Risk and issue log
How I tracked the risks and dependencies on a finance platform where security and accurate records matter most.
| ID | Type | Item | Impact | Owner | Status and response |
|---|---|---|---|---|---|
| R1 | Risk | A change to one payment feature could affect the reports and account balances. | High | Project Manager and development lead | Managed. The dependencies were mapped and each change was reviewed before release. |
| R2 | Risk | Security and access controls must hold at every release. | High | Development and testing teams | Managed. Security checks were part of every release, not left to the end. |
| D1 | Dependency | The payment service must be available and tested before go live. | High | Development team | Tracked. The connection was confirmed and tested ahead of each release. |
| A1 | Assumption | Releases follow a steady, agreed schedule the business can plan around. | Medium | Project Manager | Confirmed with the client at the start. |
Responsibilities matrix
Who was responsible for what while delivering one shared product across three countries.
| Activity | Project Manager | Client | Development | Support |
|---|---|---|---|---|
| Agree what each country needs | R | A | C | I |
| Build the shared product | A | I | R | C |
| Test across each region | A | C | R | C |
| Roll out to each country | R | A | C | C |
| Support after launch | C | I | C | R |
Priority list
How I sorted the features by priority, so the shop and the buying process were solid before the extra material was added.
Must have
- The product range and store
- The buying and checkout process
- Secure payment
Should have
- The educational material
- Customer accounts and order history
Could have
- Saved favourites
- Product recommendations
Will not this time
- A subscription plan
- A separate web store
Launch readiness checklist
The checklist I used to launch the mobile store on time and ahead of an important sales period.
Before launch
- Full testing of the buying process
- Payment and checkout confirmed
- Product information checked
- A plan to undo the launch if needed
Launch day
- Final checks before going live
- Make the store available
- Watch for early problems
After launch
- Close support during the sales period
- Review how the launch went
Release readiness checklist
The checklist I worked through to release the payment application safely.
Before release
- Test every step of a payment
- Confirm the security checks
- Agree what a successful payment looks like
Release
- Release to a small group first
- Check that real payments work
After release
- Open the application to everyone
- Watch closely and support users
Decision log
A record of the main choices made during the project and the reasons behind them.
| Decision | Options considered | Choice | Reason |
|---|---|---|---|
| How to show spending | A simple list, or charts | Charts with a simple list underneath | Clear at a glance while still showing the detail |
| How budgets are set | Automatic, or set by hand | Set by hand first, automatic later | A simpler first version, agreed with the client |
| How each screen is designed | Build then review, or agree first | Agree each screen with the designer before building | Less repeated work and a consistent look |
Gantt chart
The timeline I used to plan the work across the client, the delivery team and the outside partner, showing who owned each part and when.
Communication plan
How I kept the client, the delivery team and the outside partner informed and working to one plan.
| Who | Purpose | How often | Format |
|---|---|---|---|
| Client sponsors | Agree the direction and approve the work | Weekly | Short written update and a call |
| Delivery team | Plan the work and clear any blockers | Daily | Short stand up meeting |
| Outside partner | Line up the shared work and the dates | Weekly | Working call and shared notes |
| Wider stakeholders | Give an overall view of progress | Every two weeks | Status report |
Communication plan
How I kept teams in different countries and time zones informed and working to one plan.
| Who | Purpose | How often | Format |
|---|---|---|---|
| Client sponsors | Share progress and agree decisions | Weekly | Written summary and a call |
| Development teams | Plan the work and clear any blockers | Daily | Short stand up meeting |
| Wider stakeholders | Give an overall view of progress | Every two weeks | Status report |
| All teams across time zones | Make sure no one is left behind | As needed | Written notes shared with everyone |
Risk and issue log
A record of how I tracked the risks, assumptions, issues and dependencies on a project where safety was essential.
| ID | Type | Item | Impact | Owner | Status and response |
|---|---|---|---|---|---|
| R1 | Risk | The phone restriction must never prevent a genuine emergency call. | High | Project Manager and mobile leads | Addressed. The emergency exception was built and tested first, in a dedicated round of testing. |
| D1 | Dependency | The rules must work in exactly the same way on both Apple and Android devices. | High | Apple and Android leads | Being tracked. The behaviour on both types of device is reviewed every week. |
| A1 | Assumption | Parents sign up and adjust the limits from the online dashboard. | Medium | Product team | Confirmed with the client before the work began. |
| I1 | Issue | The locking behaved inconsistently on older Android devices. | Medium | Testing team | Resolved before launch. |
Release readiness checklist
The checklist I worked through to release a safety application, with extra care around the emergency cases.
Before release
- Test that the phone limits work while the car is moving
- Test that a genuine emergency is never blocked
- Confirm the same behaviour on Apple and Android
- Agree what a successful result looks like
Release
- Release to a small group of families first
- Check the controls that parents use from a distance
After release
- Open the application to everyone
- Watch closely and support families
Delivery schedule
The simple schedule I used to deliver the website on time for the client in Australia.
- Agree the goals and the content Week 1 Done
- Design and build the website Weeks 2 to 3 Done
- Review together with the client Week 4 Done
- Launch the website Week 4 Done
Priority list
How I sorted the features by priority, so the most important parts of the education system were delivered first.
Must have
- Student and staff records
- Attendance and daily tasks
- Access rights for each type of user
Should have
- Reports for managers
- Fees and payment records
Could have
- Messages to parents
- Timetable planning
Will not this time
- A separate mobile application
- Online examinations
Priority list
How I sorted the features by priority, so agencies could browse and book the core North India trips before the extra options were added.
Must have
- The destination and hotel catalogue
- The trip and package builder
- The booking and enquiry process
- Agency accounts and access rights
Should have
- Transport and ground handling
- Pricing and quotes for agencies
Could have
- Saved itineraries
- Sightseeing and activity add ons
Will not this time
- Direct booking for holidaymakers
- Online card payment
Risk and issue log
How I tracked the risks and dependencies on a travel platform where the plan, the price and the ground support all had to stay in step.
| ID | Type | Item | Impact | Owner | Status and response |
|---|---|---|---|---|---|
| R1 | Risk | Hotels, transport and sightseeing all connect, so a change to one can affect the price or the plan of another. | High | Project Manager and development lead | Managed. The dependencies were mapped and each change was reviewed before release. |
| R2 | Risk | What agencies see on screen must match what their clients actually get on the trip. | High | Development and content teams | Managed. Availability and details were kept current and checked before each release. |
| D1 | Dependency | The hotel and transport partner information must be in place before the booking process can be trusted. | High | Content and development teams | Tracked. Partner details were confirmed and loaded ahead of each release. |
| A1 | Assumption | Agencies plan and book through their own accounts rather than one shared login. | Medium | Product team | Confirmed with the client before the work began. |
Decision log
A record of the main choices made while building the website, and the reasons behind them.
| Decision | Options considered | Choice | Reason |
|---|---|---|---|
| How much animation to use | Heavy motion everywhere, or motion with restraint | Rich motion on the hero, lighter touches elsewhere | Keeps the playful feel without slowing the page on a phone |
| What the page asks visitors to do | Many links, or a few clear actions | Two clear actions: visit the stall or order on Swiggy | Late night customers decide fast, so the choice stays simple |
| How to build the front end | A simple static site, or a modern animated stack | Next.js and React with Tailwind, Framer Motion, GSAP and Lenis | Gives the lively brand feel while staying quick to load |
| How each section is agreed | Build then review, or agree first | Agree each section with the client before building | Less repeated work and a consistent look |
Delivery schedule
The simple schedule I used to design, build and launch the website on time.
- Agree the goals and the brand feel Week 1 Done
- Design and build the pages Weeks 2 to 3 Done
- Add the motion and tune the loading speed Week 4 Done
- Review together with the client Week 4 Done
- Launch the website Week 5 Done