Three roles, one lifecycle,
one measurement spine.
► View as a slide presentation
GVS operates as a product developer, a service provider and a support creator. The same delivery lifecycle governs all three, and every piece of work reports into one KPI structure that runs from an individual's day up to a business outcome — so a team member and a board member are looking at the same truth at different resolutions.
What GVS is
Three distinct functions, each answering a different kind of demand. Confusing them is how firms end up promising capacity they don't have.
Product developer
Builds tools that solve a defined problem and then keep working without us. Every product is browser-native and leaves the data on the user's device.
- R&D specific — new capability from first principles
- Domain specific — built for telecom, delivery, quality
- Technology specific — the stack the client already runs
- Process-model specific — fits the method in use
- Project specific — configured to one programme
Service provider
Applies judgement to a client's situation — assessment, advisory, governance and delivery leadership, scoped and time-bound.
- Market demand — what the sector is being forced to solve
- Customer demand — what this client has actually asked for
- Business demand — what the P&L requires
- Project demand — what a specific programme needs now
Support creator
Keeps the tools and the people using them working — configuration, templates, walkthroughs and the operating patterns that make adoption stick.
- Global demand — anyone, anywhere, at no cost
- Organisational demand — configured to one company's model
- Role templates — the daily loop a role actually runs
- Handover material — so the client can run it without us
The three are deliberately unequal. Service is the revenue. Product is the proof. Support is the reach. We do not present the product function as though it produced the revenue, or the support function as though it were staffed like a service desk.
The delivery lifecycle
One route from requirement to feedback. Every engagement runs it; the depth varies, the sequence does not.
Requirements
Client requirement, business demand, constraints and ground rules captured before design.
Design
High-level and low-level design, against standards and acceptance criteria.
Development
Build to the design, with the process model made explicit rather than assumed.
Deployment
Sequenced with a rollback position defined before the window opens.
Operations & support
Run, maintain, and feed defects and friction back into requirements.
Customer feedback
Closes the loop. If it does not change the next cycle, it was not feedback.
Delivery is assessed on what it consumed and what it survived, not only on whether it shipped: software used, cost incurred, effort consumed, tests passed, SLA compliance met, challenges faced, and whether the recovery and rollback plans were real.
The KPI spine
Eleven levels, from one person's day to the business result. Each level aggregates the one below it, so a number at the top can always be traced to work at the bottom.
| Level | What it measures | Representative metrics | Fed by |
|---|---|---|---|
| Operational — the daily layer | |||
| Individual metric | One person's throughput, quality and reliability of commitment | Task completion, defect injection, commitment kept | Daily Task · IAS Office |
| Team metric | A team's collective delivery and health | Velocity, blocker ageing, standup participation | Daily Task · PMS |
| Operational metric | How the running machine behaves day to day | SLA adherence, backlog ageing, turnaround time | Service Hub · IAS Office |
| Tactical — the delivery layer | |||
| Quality metric | Reliability of what is produced | Defect density, UAT pass, fault closing time, leakage | QAS · VVQ |
| Project metric | One project against its baseline | On-time delivery, milestone variance, effort vs estimate | PMS |
| Programme metric | A set of projects and their interdependencies | Commitment accuracy, RAID ageing, dependency slippage | PMS · IAS Office |
| Product metric | A product's own health across releases | Release frequency, escaped defects, adoption | VVQ · Service Hub |
| Service metric | Service delivery against what was contracted | SLA compliance, incident volume, resolution time | Service Hub · CAS |
| Strategic — the outcome layer | |||
| Customer metric | Whether the client is actually served | CSAT, NPS, churn, renewal rate, escalation count | CRM · CAS Renewal |
| Organisational metric | The organisation's capacity to keep delivering | Attrition, competency coverage, succession depth, engagement | — |
| Business metric | The result the board is accountable for | Revenue inflow vs deliverable outflow, margin, pipeline conversion | CRM · CDO Command Center |
This is a measurement framework, not published performance. GVS reports no figures of its own against these levels — the numbers belong to whoever runs the tools. The value of the spine is traceability: a business metric that cannot be walked back down to an individual's day is an assertion, not a measurement.
What the spine produces
Three outputs, each with a different audience and a different failure mode.
Dashboards
Live position for the people doing the work and the people accountable for it.
- Status by project, programme and service
- RAID position and ageing
- KPI against target, with the gap named
Reports
The periodic record — what happened, what it cost, what was invoiced, what came back.
- Status reports, monthly through annual
- Invoices against delivered work
- Customer feedback, captured and routed
Renewals
The commercial consequence of everything above — contracts, agreements and the renewal decision.
- Contract and agreement register
- Obligation tracking against delivery
- Renewal window alerting before expiry
The model is only useful if you can run it.
IAS Office now carries role templates built from this lifecycle — Fault Manager, Delivery Manager, Test Lead and Delivery Executive each get the daily loop, cadence and intake their role actually runs.
Open IAS Office → See the ATDLC model