RISPU
Make the work visible.
- Explain the direction and relevant tradeoffs.
- Show working increments at agreed review points.
- Surface unknowns and blockers while they can be addressed.
- Prepare the agreed documentation and handover.
HOW WE WORK
From the first question to the next useful improvement. A connected process with room to think, build and review together.
Explore the four stages01—04 / A SHARED PATH
Open each stage to see the work, the outcome and what we need from one another. The depth of each stage follows the scope—not a fixed package.
Find the useful question before choosing the technology.
What leaves the workshopAn agreed brief & success criteria
Map the goals, users, current systems and constraints. Make assumptions and open questions visible.
Share the context, existing work and people who need to be involved. Agree what success should look like.
Make the direction tangible, then turn it into working software.
What leaves the workshopA prototype & reviewed working increments
Explore the important flows, choose a proportionate technical approach and demonstrate progress at agreed review points.
Review the direction, supply authorized content and access, and resolve decisions that affect the agreed scope.
Human review checkpoint Direction, access and release approval
Check the work together. Release only when it is approved.
What leaves the workshopA release checklist & operational handover
Test the agreed scope and document known limits, access and handover needs. Surface unresolved issues before a release.
Review the result, confirm content and permissions, and approve the release. Consequential decisions stay with people.
Let real use inform the next useful change.
What leaves the workshopAn evidence-led next-step plan
Where ongoing work is agreed, review the available product or visibility evidence and prioritize improvements.
Bring feedback from the people using the work. Agree which changes matter and the scope of the next phase.
A GOOD WORKING RELATIONSHIP
RISPU
YOU
BEFORE WE BEGIN
No. A problem, a rough idea or something that already exists is a useful starting point. The first conversation helps clarify the job to be done.
Yes, where the scope and access make it a good fit. We first understand its architecture, ownership and current constraints, rather than assume it needs replacing.
Timing follows the scope, dependencies and review needs. It is agreed after the starting point is understood; there is no universal timetable for every project.
People retain approval of consequential decisions. Which steps can be automated, what needs review and who signs off are made explicit within the agreed scope.
Handover, access and known limitations are agreed before release. Maintenance, support or further improvement can be scoped separately; an ongoing service is not automatically included.