Get · Sort · Do · Prove · Improve
Every unit of work — a request, a deal, a deliverable, a decision — travels the same five stages. The point of the lifecycle is not to describe them, but to read across all five at once.
An operating model, read across the Core.
An anonymized contract-management value chain — 106 pain points across 32 work nodes, weighted by severity and frequency.
Actors, systems, pain, seams, and requirement signals across the Core.
Read horizontally for handoffs, vertically for lifecycle-stage failure patterns.
Mistaking a process map or status report for what the model can actually do.
No vertical is clean. The pain is systemic, not local — heaviest at Do and Prove, where work is executed and where it must be proven.
Surfacing this stopped the CLO from digitizing a broken model. Correcting the gaps — not the tool — let the rebuild target 60% faster contract review, 95% risk-flag accuracy, and 30% less manual effort, protecting the platform spend before a dollar was committed.
Begin with actual-state. It exposes the enablement requirements hidden by current-state, ideal-state, and launch-first planning.
From a live engagement · See how the full methodology runs →
A status report tells you what moved. GSDPI tells you what converted.
Most reporting watches activity inside one function. Reading the model end to end changes what you can see — and where you look for the break.
Where the lifecycle exposes the break.
Read across all five stages and the pattern is rarely local. Three things surface almost every time.
Handoffs, not tasks
Work stalls between stages — in the intake-to-sort and do-to-prove seams — far more than inside any one of them.
One breaking stage
A single stage usually throttles the whole model. Fix elsewhere and throughput doesn't move; the constraint just re-asserts.
Prove is the weak link
Do and Prove carry the heaviest pain — work is executed, then can't be shown to have held. The result is reported, not proven.
Three moves, in session, with the people who do the work.
The same three moves run wherever ETEGY is reading the work. What changes is the subject — a value stream, a portfolio, a benefit case.
Establish the actual state
Frame the subject, align sponsors, and read how the work genuinely runs — in structured working sessions, not interviews about the org chart.
Locate it on the lifecycle
Every pain point is placed by stage, actor and system across the five stages — weighted by severity and frequency, like the exhibit above.
Convert evidence into a decision
Findings become something a sponsor can act on: a requirement with an owner, a funding gate, a correction — never a list of observations.
The full discipline — instruments, terms and how it underwrites each engagement — is on the methodology page.
GSDPI carries the principle — and has its own body of work.
The lifecycle operationalizes Zero-Based Transformation and is made actual and provable by the instruments. Its full discipline — stages, gates, and practice — is detailed here and across the ETEGY methodology.
Zero-Based Transformation →
The principle GSDPI carries — start from zero, rebuild from evidence.
The instruments →
Voice of the System reads each stage; the Traceability Ratio (the share of delivered work you can follow back to a governed origin) proves the outcome.