How the work runs.

Five stages, one responsibility. Four carry a colour and launch is the cut-over between them. The same pipeline whether it ends in a product deployed or a system built, and it does not stop at handover. Week counts are published per engagement on the work index, not as a table.

  1. 1 diagnose
    2 to 3 wktexxen, with the function owner and the people who live with the systems
    in
    access, and a fixed fee
    out
    the diagnostic: what runs now, what nobody owns end to end, every defect paired with its fix; the first layer scoped, later layers named
    signed
    the diagnostic, on its own
  2. 2 design
    [wk]texxen; IT and information security review the architecture
    in
    the diagnostic, the integration and hosting constraints
    out
    an architecture both sides can sign, and the identity and public surface around it
    signed
    the scope and the term
  3. 3 build
    [wk]texxen accountable end to end
    in
    signed scope, access
    out
    a product deployed into your own environment where one fits, built where none does; signed off against the scoped output
    signed
    acceptance against the scope
  4. 4 launch
    [wk]texxen with the function’s own team
    in
    the accepted build
    out
    cutover, the first month’s cadence, the first weekly note
    signed
    the operated term begins
  5. 5 operate
    and runningtexxen, staffed directly on regulated accounts
    in
    the retainer, access to the instance in your environment, the cadence
    out
    a weekly operating note, a monthly review, releases applied on the published cadence, and the record that names the next layer
    signed
    annual or longer, with continuity and exit obligations

Each stage carries its own hue, which is the symbol rule applied to the rail: the solid bar is diagnose, the two dashes are design and build, and the tail that runs off the edge is operate. Launch sits between them in ink. The dashed operate stage keeps its colour and still does not animate.

Inside an institution, four more steps wrap the pipeline

Vendor assessment, before any scope exists

Vendor management runs it; texxen answers. Financials, controls, continuity, audit rights. It can end the process here, which is why the document set is written before it is asked for.

Security and architecture review

IT and information security, at the design stage. Integration, data handling, hosting, access. The output is an architecture both sides can sign.

Pilot

A bounded scope with a result the institution can measure, before the full term is signed.

Contracting

Procurement, on the institution’s paper where required. Annual or longer, with continuity and exit obligations attached. [operated terms for institutional contracting, question 4]

Where brand and web sit

In the design stage, as the front of the pipeline. The identity and the public surface are built there, beside the architecture, not offered beside it.

The stage that does not end

Operating is what the pipeline ends in. A deployed product is operated in your own environment on the same footing as a system built for you. A year in, the weekly notes are a record of the function nobody pitching could have. That record is what names the next layer, and each layer is signed on its own.

Public procurement

A procuring entity does not begin with a conversation. It begins with documents, and a bids and awards committee assesses them rather than texxen. That path is on the contact page.

the public path