Jelia.nyc

Jelia.nyc / How it works / The work

HOW IT WORKS · STEP THREE

Scoped, priced per outcome, done when agreed

The work is scoped from the audit findings and priced by outcome, not by the hour. What done means is written down and agreed before anything starts.

Scoped from the findings

The audit leaves you with a prioritised list. The work starts by choosing from it. You pick the findings you want fixed, usually the most serious and the quickest wins first, and each one becomes a piece of work with its own scope.

Because the scope comes from findings with evidence behind them, there is very little guesswork at this stage. We both know what is there, what is wrong, and roughly what it takes to put right.

Priced per outcome

Each piece of work has a fixed price for a defined result, such as "every staff application behind single sign-on" or "these four sites moved off the old server". Not a rate multiplied by however long it takes.

That matters for two reasons. You know the cost before you commit. And the incentive is to finish properly rather than to take longer. If something takes me more time than I estimated, that is my problem, not yours.

A definition of done, agreed first

Before any work starts, we write down what done means, in terms you can check without having to trust me. For example:

  • Identity: a test user disabled in one place is locked out of every application in scope.
  • Migration: each site serves from the new platform, the rollback has been run once on purpose, and the old server has been switched off after the agreed watch period.
  • Mail: SPF, DKIM and DMARC pass for every sending domain, verified at the major mail providers.
  • Monitoring: each service is checked for real content, and a test alert has reached a named person.

If it does not meet the definition, it is not done, and the job is not finished.

How the work runs

  1. Plan. The steps, the order, any maintenance windows and who needs to know. Agreed with you before anything is touched.
  2. Change control. Every change to a live system is announced in advance, made in an agreed window where one is needed, and has a way back. If you have your own change process, I work inside it.
  3. Progress you can see. Short, regular updates: what is done, what is next, and anything blocked. Problems are raised when they are found, not at the end.
  4. Scope changes in writing. If something new turns up, or you want something different, we agree the change and its price before it is done. Nothing grows quietly.
  5. Check against the definition of done. Together, item by item.
  6. Handover. Documentation, a walkthrough with your team, and all access returned to you.

Handover and documentation

The work is not finished until your team can run what I built without me. Handover includes:

  • Runbooks for routine tasks and for the bad night: what to check, what to run, and when to stop and escalate.
  • A current inventory and a plain diagram of what changed and how the pieces connect.
  • Credentials held in your systems, not mine, with my own accounts removed at the end.
  • A walkthrough with whoever will look after it, until they are comfortable.

Avoiding key-person risk is half of what an audit looks for. It would be odd to finish a job by creating a new one around myself.

Questions people ask

Do we have to do everything on the findings list?

No. Some findings are cheap enough for your team to fix themselves, and some you may decide to accept. Accepting a risk knowingly is a legitimate decision. It just needs to be written down.

What if something goes wrong during a change?

Every change has a way back, planned in advance. If a step does not behave as expected, the runbook says where to stop and how to roll back, and I tell you straight away.

Can you work alongside our existing provider?

Yes. Often the best result is your provider running things day to day from runbooks they helped shape.