DelPulse
Sign inStart free
Demo mode: payments are simulated. Set Stripe keys and turn DEMO_MODE off before launch., payments simulated
The DelPulse rules

DelPulse rules

The rules that make DelPulse work, one line each. Rules marked default can be tailored in a project charter or product canvas, as long as the tailoring and its reason are recorded. Every other rule applies as written.

Intake and mode

  1. All demand enters through one front door, including proposals for new projects.Nothing is prioritised fairly unless it is visible.
  2. Triage decides the mode: product change, project or programme.New functionality needs different governance from improving what is live.
  3. It is a project if any of these apply: a new system, module, site or service goes live; it needs its own business case or funding; it needs cutover or training at scale; or it is estimated at more than six months.A simple test everyone can apply the same way.
  4. Several projects sharing one outcome, or several organisations, make a programme.Shared outcomes need shared governance.

Programmes and projects

  1. Every programme and project has a named Senior Responsible Owner.Accountability cannot be shared.
  2. Every project has a Project Board: the SRO as Executive, a Senior User and a Senior Supplier.Business, user and supplier interests all decide together (PRINCE2).
  3. No project passes G1 without a named Receiving Product Manager.Someone must be ready to own the product after go-live.
  4. Every gate has written criteria, and every decision is recorded.Clear, auditable decisions protect customers and money.
  5. Every gate from G1 to G3 needs an end stage report that confirms the business case is still justified.A project continues only while it is still worth doing (PRINCE2).
  6. Set tolerances in the charter; a forecast breach goes to the Project Board as an exception report within two working days. defaultThe board manages by exception, not by meeting (PRINCE2).
  7. Projects deliver in sprints, governed by gates.Agile delivery with the assurance boards expect.
  8. A project ends at accepted handover, not at go-live.Go-live is the start of safe use, not the finish.

Go-live, early life support and handover

  1. No go-live without a signed safety case, a test exit report, a rehearsed cutover and a recorded Go / No-Go decision.The four minimum protections for customers and staff.
  2. Go-live is a normal change, authorised by the change authority with a backout plan.Live services change one controlled way (ITIL).
  3. The Service Owner accepts the service into operation before handover.Operations must agree to run what the project built (ITIL).
  4. Early life support ends when its exit criteria are met, not on a date.Evidence, not the calendar, decides when staff are ready.
  5. Handover needs a complete handover pack and a Handover Review.Ownership cannot move without knowledge.
  6. The Receiving Product Manager may accept, accept with dated conditions, or reject a handover.The product owner must be able to say no.
  7. From the day after handover, all change goes through the Product layer.One route for change after go-live.
  8. Architecture decisions, the hazard log and living documents move with the product at handover and are never closed with the project.Knowledge must outlive the project that created it.

Products

  1. One ordered backlog per product, ordered by the DelPulse Value Index.One honest answer to “when will it be done?”
  2. Weekly triage; no request waits more than two weeks. defaultRequesters deserve a timely answer.
  3. Teams work in two-week sprints within WIP limits. defaultSmall batches reduce risk and show progress.
  4. Check the solution library before building anything new.Build once, reuse many.

Safety and quality

  1. A safety rating of 5 goes to the expedite lane, whatever the PVI.Live hazards to people come first.
  2. Safety and compliance evidence is part of Done for every change that affects safety.Safety is built in, not bolted on.
  3. Expedite means faster, never fewer checks.Urgency is not a reason to skip safety.

Evidence

  1. Every item carries a benefit estimate; no baseline, no benefit claim.Benefits must be provable.
  2. Decisions and measures live in Jira, not separate spreadsheets.One source of truth with no extra admin.
  3. Tailor any default rule in the project charter or product canvas, and record why.Flexible, but never silent.