Company
How we run engagements
Most project trouble comes from an unwritten assumption. Our method is mostly a set of places where something gets written down and agreed before it can cause damage later.
Five things we insist on
Scope in writing before work starts. Including what is out of scope. This is the single thing that prevents most disputes.
A named person on each side. Someone who can answer a question and make a decision. Projects without this stall in email.
Evidence as we go. Test results, reconciliations, approvals and findings captured when they happen, not reconstructed at the end for an auditor.
Bad news early. If a date is at risk we tell you while there is still time to act. A green status report that turns red in the last week is worse than no report.
Knowledge transfer as a deliverable. You should be able to run what we built after we leave. Runbooks, documentation and a handover session are part of the work, not a favor.
The stages of an engagement
Discovery
A conversation, not a sales process. We are trying to work out what the problem really is and whether we are the right firm for it.
What happens
- A call with someone technical, not only an account manager.
- Questions about the current system, the constraints and what has already been tried.
- An honest answer about whether we have the right people.
- Where we are not the right fit, we say so and, if we can, point you somewhere useful.
What you receive
- A written summary of what we understood.
- A view of the options, including doing nothing.
- An indication of the shape and size of the work.
Scoping
Turning a conversation into something both sides can be held to.
What happens
- Scope, exclusions, assumptions and dependencies written down.
- Deliverables with acceptance criteria.
- Named contacts and an escalation path on both sides.
- Commercial model agreed: time and materials, fixed price or a staffing rate.
- For security testing, written authorization naming the exact targets and the rules of engagement.
What you receive
- A statement of work or a signed requirement, depending on the engagement.
- A schedule with the dependencies that could move it.
- A risk register, started before week one.
Mobilization
Getting the right people and the right access in place without losing two weeks.
What happens
- Team assembled and introduced, with the experience relevant to your work stated.
- Access requested early, because access delays are the most common cause of a slow start.
- Environments confirmed, including whether test data is realistic enough.
- Communication cadence agreed: status note, standups and a decision forum.
What you receive
- A team list with roles and responsibilities.
- An access and environment checklist with owners.
- The first weekly status note.
Delivery
The work itself, run so you can see where it stands at any point.
What happens
- Work broken into increments that can be reviewed rather than one long build.
- Design decisions recorded with the reason, so nobody re-litigates them in month four.
- Testing with evidence captured as it is executed.
- Change control for anything that moves scope, cost or date.
- Risks raised when they appear, with a recommendation attached.
What you receive
- A weekly status note: progress, next week, risks, decisions needed.
- Design and specification documents as they are produced.
- Test results and defect logs.
- Change requests, priced, before they are done.
Validation
Proving it works, in the way the person who signs it off needs to see.
What happens
- Unit, integration and user acceptance testing, with the business doing the acceptance.
- Reconciliation for anything involving data or money, prepared in advance with named approvers.
- Performance tested at realistic volume, not at demo volume.
- Security and authorization testing where the change touches either.
- Rehearsals for any cutover, timed and documented.
What you receive
- Test evidence and a defect position.
- A reconciliation pack with sign-off.
- A cutover runbook with timings from rehearsal, and a rollback plan.
Go-live and hypercare
The riskiest hours, planned to the step, followed by real support.
What happens
- The runbook executed with checkpoints and a rollback decision point.
- Reconciliation and sign-off before users are let in.
- Hypercare with a triage desk and a daily defect review.
- A defined date when support transitions, agreed rather than drifting.
What you receive
- A go-live record of what was done and when.
- A defect log with owners and status.
- A support transition document.
Knowledge transfer
The part most firms skip. You should not need us to keep the lights on.
What happens
- Documentation of what was built and why, in a form your team will actually read.
- Runbooks for the operational tasks, written to be followed by someone new.
- Handover sessions with your team, recorded if they want.
- An honest list of what is unfinished, and what we would do next.
What you receive
- A handover pack.
- Runbooks and operational documentation.
- A written list of open items and recommendations.
Stage names change with the engagement. A two-week assessment does not need all seven. A twelve-month program needs every one of them.
Where security work differs
Authorization first
No testing without written permission.
- Written authorization from someone able to give it
- Exact hosts, applications, accounts and exclusions
- Test window, source addresses and named contacts
- What happens if we find something critical mid-test
- What happens if something breaks
Findings you can act on
Reproducible, prioritized, retested.
- Every finding with reproduction steps and evidence
- Severity with the reasoning, not only a number
- Remediation advice written for engineers
- A debrief call, because reports answer fewer questions than people do
- A retest, so a closed ticket is not the only evidence
When the engagement is staffing rather than a project
-
Intake is a conversation
A recruiter confirms the must-haves, the nice-to-haves, the rate range, the location rules and the start date. A requirement with six must-haves and a two-week window gets challenged, not silently accepted.
-
Screening against your requirement
Questions drawn from your role, asked by someone who understands it. The submission tells you what we asked and what the person said.
-
Submission with consent
Nobody is submitted to you without agreeing to that specific role, so the candidates you see are candidates who want the job.
-
After the start date
We stay in contact with the consultant and with you. Problems in the first month are usually fixable if someone raises them.
Questions people ask
Do you follow a named methodology?
We use the client’s where they have one, and the vendor’s where it fits, such as SAP Activate for an S/4HANA program. What we do not do is impose a method for its own sake. The stages above are what we insist on regardless of what they are called.
Will you work fixed price?
For work with a scope we can define confidently, yes, with change control. For discovery, assessment and anything where the scope depends on what we find, time and materials is more honest and usually cheaper for you.
What if the project goes wrong?
We tell you early, we say what we got wrong, and we put a recovery plan in front of you. That is the whole of it. We would rather have an uncomfortable conversation in month three than a surprise in month eight.
Can you work with our existing partners?
Yes. Joint delivery with another firm is normal, and we agree the split of responsibility in writing. See partners.
Who writes the status note?
The person running the work, not a manager summarizing a summary. It is one page, it includes risks, and it goes out whether or not the news is good.
Related
-
Engagement models
Eight ways to work with us, explained plainly, with a short tool to suggest which to discuss first.
-
How we hire and screen
The path from a requirement to a submitted candidate, and what we check along the way.
-
Solution blueprints
How we approach eight common programs, written out in full. Illustrative, not client work.
-
Project consultation
Tell us what you are trying to do. Answer a few questions and a consultant will reply to arrange a conversation.
Have a technology challenge? Let’s work out the approach.
Discuss a project
Tell us the current system, the target and the timeline. A technical lead replies to talk about scope.
Start the project briefRequest technical talent
Need consultants inside your team rather than a project owner? Send the requirement.
Request talentBecome a partner
Delivery firm, staffing supplier or consulting partner? Register your company.
Register as a partner