Understand the work
Start with the people, process, current tools and the change you want to make. A finished specification is not required.
A clear way forward
Understand the business.
Then define the build.
A new idea or an operational change becomes useful software when the process, requirements and delivery are designed together.
From the first conversation to a working outcome.
Each engagement needs a scope suited to its size, risk and requirements.
Agree the starting point
Use a focused review when the answer needs investigation. For a clear website or software requirement, move towards a scoped proposal.
Define the commitment
Record deliverables, exclusions, responsibilities, milestones and how scope changes will be handled. Agree ownership, access and ongoing costs.
Build and check
Plan work in useful stages with agreed acceptance criteria. Testing, technical review and the responsibilities of everyone involved must match the project.
Hand over deliberately
Agree access, documentation, training, maintenance and support before the project is treated as finished.
Engineering the detail
Build around the people, data and decisions.
Define the roles, information and handovers behind each feature. Connect existing tools where they add value, and build custom functionality where the business needs it.
Delivery includes testing against agreed requirements, reviewing access and failure paths, and preparing the documentation and handover needed to use the system.
A plan for after launch.
Running the system
Hosting and services.
Identify the accounts, subscriptions and usage costs, and who owns and pays for them.
Keeping it working
Maintenance and support.
Agree what is covered, availability, responsibilities and how problems are reported.
Making it better
Ongoing improvements.
Where useful, agree a backlog and capacity for new work, separately from running costs.
Your next step
What would you like to build or improve?
You do not need a finished specification to start a conversation.