Project Systems Set-up
RemedialFixed FeeFor Subcontractors, Main Contractors & Clients10 working days
The fixes a review ranked for one project, built and put to work on the live job: capture at the point things happen, a variation record that stays current, a CVR that updates rather than gets rebuilt, notices that go out on time. Built in the software you already own, priced against the review's findings before anything starts, and worked beside your team on the job until they run it without me.
The problem
Knowing what is wrong with a job's systems and running better ones are different problems. The team is mid-valuation, nobody has slack to configure anything, and a workflow announced by email lasts about a fortnight before people quietly go back to the spreadsheets they had. So the ranked list sits in a drawer: the hours keep going where they always went, the record keeps thinning, and the gaps that would have been cheap to close while the job was live turn into the expensive kind that get argued about after it has finished.
The solution
I build the fixes on the live job, in the order the review ranked them and in the software you already pay for. Everything is built on established platforms such as Claude, Obsidian and Microsoft 365, in your accounts and on your licences: nothing proprietary, and you own everything. Then I sit beside the people who have to run each piece, through real weeks, until every one of them can run their part without me. The price is fixed against the review's findings before anything is built, so you see the cost and the reason for it side by side; what will be built is written down and signed off by you first, and before anything carries real money the new system runs beside your old one for a full cycle with every difference explained.
Everything I implement is handed over with its own plain-English manual, written for the people who will actually use it. And from handover you have a 24/7 triage contact: report anything at any time, it is logged and triaged straight away, and answered on the support terms we agree.
What you receive
You get a project whose record builds itself as the job runs, a plain written note of what was built and why, and a team that runs it without me. If you want the system kept honest to the final account, the monthly support exists for exactly that; nothing obliges you to take it.
The Handover Pack accompanies the work with its dates and sources, likely outcomes and responses, scope boundaries and ready-to-send correspondence where needed.
Turnaround: ten working days.
The working days start when the agreed scope and required inputs are available. Optional items do not hold the start unless the agreed scope says otherwise.
How it works
You choose how far down the ranked list to go
The review's list is ordered by what each gap is costing the job, so the scope conversation is short: where to draw the line. I put the price for that scope in writing, built from the review's findings, before anything is configured.
You sign off the written specification
What will be built, what it will not do, and how you will know it worked goes to you as a written specification before anything is configured. Building starts on your written sign-off and not before, so a later change is a decision rather than drift.
Scope signed before build
Nothing is configured until you have signed off a written specification of what will be built, so the build starts from an agreed scope.
You give me the access the build needs
Admin rights on the licences you already hold, the job's folders, and real time in the team's diary. The build happens inside your tools from the first hour, so there is nothing to migrate to later.
- A
The completed and accepted review
EssentialWithout it: Building starts against a guess instead of an agreed scope, and the build has nothing fixed to be measured against
Where to find it: You have it; it is the document the price was built from.
Why I need it: Building without it is building on a guess
- B
Tool access and licences for the build
EssentialWithout it: Nothing can actually be configured, so the build stalls before it starts
Where to find it: Whoever pays the subscriptions or runs the tenancy can grant it in minutes.
Why I need it: Nothing can be built without access
- C
The real data, exported as it actually is
EssentialWithout it: The build is tested against tidy data instead of the messy rows that break it in the first live cycle
Where to find it: Whoever exports from the live system, the project surveyor or whoever holds the login; ask for a straight export with nothing cleaned or removed.
Why I need it: The build has to work on real records
- D
The named users, and time in their diaries
EssentialWithout it: Nobody is trained on the system they are meant to run, and the handover has nobody ready to use it
Where to find it: On the job, while the work happens.
Why I need it: Somebody has to use it after handover
- E
Written sign-off on the scope
EssentialWithout it: Scope creep has nothing to stop it, and any dispute about what was agreed has nothing written to point to
Where to find it: Whoever signs off documents on your side, often the same person who accepted the review; a short email confirming the specification is enough.
Why I need it: Scope creep in an implementation is unbounded without it
Copies are fine. Send what you have and I'll tell you what's missing. Download the client request PDF or editable Word version to pass to whoever holds the files.
- A
I build each fix inside the tools you already own
Configuration, not procurement: the capture steps, the registers, the CVR feeds, the reminders around notices. Each step is built to take less than a minute to use, because a step that takes longer stops being used in the first busy week.
I sit with the team while real weeks run
Each person runs their part with me beside them, through live valuations and real variations, until the awkward questions have been asked while somebody is there to answer them. A step people route around is a step built wrong, and it gets rebuilt rather than policed.
Live only after sign-off
Nothing carries a live payment cycle until its handover manual is issued and you have signed off the workflow in writing.
I run the new system beside your old one and reconcile
For one full cycle the new system runs in parallel with the process you already trust, which stays the one relied on. Every difference between the two is traced to its source and explained before anything goes live on real money; where the difference finds a live error in the old process, you hear about it in writing the same day.
Old and new reconciled
The new system runs beside your existing process for a full cycle, and every difference between the two is explained before you rely on it.
I hand the job's system over and step back
Free Service Pack
A step-by-step Handbook, with the templates and working documents you need to carry out the work it covers yourself. You supply your own project information and records.
Follow the Handbook's scope and stopping points, and obtain independent advice where required. The pack is not project-specific advice or independent sign-off.
Tips that raise your odds of success
Questions I get asked often
The full menu of what a set-up can build is on the Build Menu page. The set-up needs a review in front of it, because the price and the build order come from the Project Systems Review. Its business-wide sibling is the Business Systems Set-up, for the systems above the jobs. And once the system is live, Systems Support exists to keep it honest to the final account, if you want it.