Working together

Start with the business.
Define the right engagement.

A good project begins with a shared understanding of the problem. Here is how I approach the decisions, reviews and handover around a website or software build.

Before committing

Show me how the work happens today.

A brief becomes much more useful when we can follow an actual task. How does a customer enquire? Who responds? Where does the information go? Which part currently takes too much effort?

If you already have a platform, we start by understanding what works and what needs attention. A full rebuild is one option, not the automatic answer. Existing records, integrations and the people using the system all affect the decision.

What we need to agree

The proposal should identify the people using the system, the first-release scope, dependencies and the outcome we will review. Content, account access and third-party approvals need owners as well.

We discuss investment and timing against that scope. If a requirement is still uncertain, it belongs in the discovery work rather than being hidden inside a confident estimate.

Prepare a useful project brief

During the build

Review the journey, not just the screen.

Visual direction and application behaviour belong in the same conversation. A clear enquiry page also needs an understandable next step. An administration screen needs permissions that match the people using it.

Reviews should follow the important tasks from beginning to end, on the devices that matter. We also look at the relevant exceptions: an invalid entry, a missing record or a request that does not complete.

Keep decisions visible

The review process and points for feedback are agreed for the engagement. Feedback is easier to act on when it identifies the task, what happened and what you expected to happen.

New ideas can be valuable without all belonging in the first release. When a request changes the agreed work, we discuss the effect on scope, timing and cost before treating it as part of delivery.

Explore the work

At handover

Know what you are taking forward.

Delivery includes reviewing the agreed acceptance checks and recording anything still outstanding. The handover should make it clear how the work is operated, who controls the relevant accounts and what depends on another provider.

A launch also needs a decision about what happens afterwards. Routine content changes, technical maintenance and new features are different responsibilities, so support is scoped rather than assumed.

Leave a usable record

The agreed documentation and access arrangements should help the business manage the delivered work. For an existing platform, migration and recovery requirements need their own checks; a working homepage alone does not establish that every workflow survived.

Before closing the engagement, we clarify the remaining actions and the route for future requests. The aim is for your team to know what has been delivered and where to go next.

Tell me about your project