A worked example is worth a dozen frameworks. Here is how the 6Ws methodology plays out end to end on a real build: a timesheet and expense tracking application for a distributed consultancy. Each W is framed practically, so you can see how the thinking compresses into a fast, focused, user-centred delivery plan.
Who: users and stakeholders
Primary users:
- Consultants submitting time and expenses
- Project managers approving submissions and reviewing budgets
Secondary users:
- Finance team processing payroll and reimbursements
- HR monitoring workload and compliance
System integrations:
- Payroll provider API for monthly processing
- Cloud document store for receipt uploads
- Authentication via Firebase Auth
Stakeholders: Operations Director, Head of Finance, Head of Delivery.
See Who: the actors and users of the system for how we get to this list.
What: outcomes and actions
Consultant actions:
- Log hours against projects
- Attach receipts and submit expense claims
- View leave balance and tracking history
Manager actions:
- Approve or reject timesheets and expense claims
- View budget vs actuals by project
Finance actions:
- Export approved data for payroll
- Generate expense and cost reports
Features:
- Timesheet entry (daily or weekly)
- Expense entry with document upload
- Multi-level approval workflows
- Export to payroll
- Audit trail and reporting dashboard
See What: outcomes and actions for how we capture these.
Why: business value
| Feature | Benefit | Metric |
|---|---|---|
| Timesheet submission | Accurate billing | Timeliness, billing completeness |
| Expense tracking | Transparent reimbursement | Processing time, accuracy |
| Approvals and workflows | Accountability and compliance | Approval lead time, rework rate |
| Export to payroll | Less manual processing | Staff hours saved monthly |
Objectives:
- Cut timesheet processing time by 40%
- Improve payroll data accuracy to 99.5%
- Increase user satisfaction with finance workflows
See Why: the business benefit for how we build the Why.
How: technical design
Frontend:
- Web: React/Next.js
- Mobile: Flutter with offline-first mode
Backend:
- Go with GORM for MySQL
- Redis for sessions and project metadata
- REST + GraphQL exposed via an API gateway
Authentication: Firebase Auth with SSO for company domains.
Architecture:
- Deployed on AKS (Azure Kubernetes Service)
- Stateless services for compute
- Helm-managed CI/CD via GitHub Actions
- Observability via Prometheus, Grafana, Loki
Key components: Timesheet Service, Expense Service, Approval Workflow Engine, Notification Service.
See How: technical design for the thinking behind these choices.
Where: hosting and infrastructure
Environment:
- AKS with managed node pools
- Spot instances for async jobs and reports
- MySQL on a managed HA database service with backups
- Redis in a dedicated low-latency cluster
Deployment:
- GitHub Actions for CI/CD
- Helm charts for versioning and rollback
- Secrets via K8s secrets + GitHub OIDC
Scaling:
- HPA based on queue length and CPU/memory thresholds
- Redis cache reduces DB reads by around 60%
Backup and DR:
- Daily backups for MySQL and Redis snapshots
- Restore tested quarterly in a DR region
See Where: the hosting strategy for the full pattern.
When: planning, estimation, delivery
Project phases:
- Phase 1: Timesheet MVP (3 devs, 4 weeks)
- Phase 2: Expenses + approval flow (3 devs, 5 weeks)
- Phase 3: Reporting + payroll export (2 devs, 3 weeks)
Planning tools: Jira for backlog, Notion for documentation, GitHub Projects for visibility.
Estimates:
- Story points with weighted scoring (complexity, confidence, reusability)
- Cost estimate: roughly £60k total build at blended rates
- Infra estimate: roughly £250/month (AKS, DB, Redis, Auth)
Triage plan:
- Weekly scope and effort check-ins
- Red / Amber / Green dashboard for blockers
- RICE re-prioritisation during backlog grooming
See When: planning, estimation, and prioritisation for the supporting techniques.
What the 6Ws surfaced early
The real value of running this pass was not the neat artefacts. It was the awkward questions that surfaced before a line of code was written.
- Consultants, not managers, are the highest-volume users. The original brief assumed the approval workflow was the centre of the product. The Who work made clear that daily submission was. That single reordering moved mobile-first and offline-first to the top of the How.
- Finance is a tier-two user but a tier-one blocker. Their export format constraints were non-negotiable and fed directly into the data model. Discovering that in Who rather than in UAT saved two weeks of rework.
- HR is a stakeholder, not a user. They wanted visibility, not interaction. That reshaped the reporting surface from "HR dashboard" to "read-only export", which cut three stories.
- Payroll is not a single integration. It is an integration per country, each with its own file format and cut-off. The What expanded here, and the When accommodated it, rather than the team discovering it on day ninety.
- Audit is a feature, not a log. Finance and HR both needed to prove compliance on demand. That turned "write things to a log" into "query-ready audit trail with retention rules", which is a very different data design.
Each of those realisations cost an afternoon in discovery and saved weeks in rebuild. That is the whole pitch for the 6Ws compressed into five bullet points.
Risks logged during the pass
A good 6Ws run does not just surface what you will build. It surfaces what could go wrong. A compressed version of the risk log from this project:
| Risk | Where surfaced | Mitigation |
|---|---|---|
| Offline mobile submission data conflict | How + Where | Client-side timestamps, server-side last-write-wins with conflict flag |
| Payroll export cut-off missed by late approvals | Why + When | Auto-reminder 24 hours before cut-off, flagged dashboard at 4 hours |
| Receipt uploads exceeding document store limits | How + Where | Pre-upload compression, clear user messaging, async processing |
| Approver unavailability during peak periods | Who + What | Automatic delegation rules, manual override path |
| Regulatory change to leave policy | Why + What | Policy engine externalised from code so changes do not require a release |
None of these risks are exotic. All of them are boring. Boring risks are the ones that ship bugs to production because the team assumed they were too obvious to list. The 6Ws pass is the place they get written down and dealt with.
Summary
Following the 6Ws, the delivery of this app becomes:
- Clear in its purpose
- Focused on value
- Grounded in real-world infrastructure
- Planned with confidence
It turns a generic request ("build a timesheet tool") into a roadmap with purpose, precision, and user-first execution.
What would have happened without the 6Ws
It is worth imagining the counterfactual. Without the discovery pass, the same brief would almost certainly have produced a different project.
The team would likely have built a desktop-first web app with a monolithic approval screen, because the most vocal stakeholder in the kickoff meeting was a senior manager. Offline-first mobile would have shown up in phase two as a bolt-on, after consultants complained. The payroll export would have been a spreadsheet download rather than an API, because spreadsheets are easier to ship. HR would have lobbied for a bespoke dashboard and got one that nobody used. Three months in, the team would have been arguing about scope while the Why quietly drifted.
None of that is hypothetical. That is the default trajectory for this kind of brief when the thinking is rushed. The 6Ws are the difference between the default trajectory and a deliberate one. Same team, same tools, same budget. Different outcome.
