V-Modell XT, exactly as the standard intends
Decision gates with quality gates, products with traceable states, clear responsibility for every result and project-specific tailoring through process modules - mapped with features that genuinely exist, right next to your agile teams.
Where V-Modell XT sits on the spectrum
And how close the neighbouring methods are
V-Modell XT: product- and decision-gate-driven
V-Modell XT sits far on the classic side - defined products, ordered decision gates and documented sign-offs. In WORKSPACE.PM that is no straitjacket: through the container concept each subproject gets its own way of working, so a system undertaking run under V-Modell XT can carry an agile development strand without losing the chain of evidence.
Exemplary specifications, lost in the tool
What often slows the standard down in day-to-day projects
The structure lives in file shares
Process modules, products and decision gates are rebuilt in folder trees and templates - the tool itself has no notion of them.
Releases without solid evidence
Which decision gate was approved on the basis of which products? The trail is scattered across minutes and mailboxes instead of sitting in the project.
Products without a visible state
Whether a product is in progress, submitted or accepted has to be asked - the current status is known only on request.
Every cut by hand
Tailoring the model happens in copied templates and turns out differently on every project - that is not reproducible.
From the process model to the tool - seven core elements
Every core element of V-Modell XT and the feature that maps it in WORKSPACE.PM - in the standard's own vocabulary.
Project type and execution strategy
V-Modell XT distinguishes client and contractor projects and sets an order of decision gates for each undertaking.
Project-type setup and an editable phase pipeline
From client to contractor projects, you set up each undertaking to fit: you arrange the order of your decision gates in an editable phase pipeline - existing phases are preserved. Proven sequences are saved as a reusable structure module, so every project type starts with its own execution strategy.
Roles and responsibility per product
Every product and work package clearly states who is accountable and who contributes.
AKV matrix and four-level rights down to the work package
The AKV matrix assigns work packages to each person with the markers A, E, I, K, M and P - accountable and contributing kept cleanly apart. A four-level rights model from view-only to administration governs access down to the individual work package, project-wide or overridden per container.
Process modules and tailoring
V-Modell XT is tailored to each project by selecting the fitting process modules - the eponymous eXtreme tailoring.
Toggle container modules on and off per subproject
Per subproject you activate exactly what it needs from thirteen functional modules - from quality gates and risks to documentation and Kanban. Recurring structures are stored as a module template in a tenant-wide library and inserted again with a single click.
Decision gates
At each decision gate, the submitted products determine whether the project moves into the next phase.
Quality gates as their own structure node with product evidence
The quality gate is its own node type in the project structure - alongside container and milestone. At each gate you see the products to be submitted at a glance, capture verifiable criteria with named approvers and document the release in an audit-proof way with a full history.
Products and product states
V-Modell XT plans from the result: every product passes through defined states until completion.
Deliverables with a state sequence and QA
The deliverables register keeps every product with an owner, due date and progress. Products move traceably through their states - from in progress via in review to released - progress can be derived from seven methods, and quality assurance stands as a check before release. From your own Word templates, the associated documents - from the project handbook to the QA report - are generated directly from the current project data.
Requirements and verification as first-class objects
V-Modell XT requires verifiable requirements per product and their evidence through verification and validation.
Requirement and verification objects with states and results
Every requirement is a versioned object of its own, with attributes and acceptance criteria - from which the verification case derives directly. Verification runs record result, tester and evidence; a failed run creates the linked defect on the affected product.
Verification, validation and traceability
Verification checks whether a product was built correctly; validation whether it meets the requirement - both fully demonstrable.
Trace matrix with coverage analysis and suspect links
Requirements, verification cases and results are connected through typed, two-way links; the trace matrix shows coverage per level and flags requirements without verification. When a requirement changes, WORKSPACE.PM marks dependent verifications “to re-check” automatically, and the formal acceptance happens at the decision gate.
One standard, two working worlds
V-Modell XT and agile teams are not mutually exclusive. Through the container concept, a system subproject run strictly by the process model carries an agile development strand - each subproject with its own way of working, all under one reporting path and one continuous chain of evidence.
Where V-Modell XT is at home
Project worlds and teams that benefit most from the process model
Frequently asked questions about V-Modell XT in WORKSPACE.PM
Which concrete tools carry the process model day to day
Yes - WORKSPACE.PM maps the core elements of V-Modell XT with concrete features: roles and responsibility through the AKV matrix and a four-level rights model, decision gates through quality gates as their own structure node, products through the deliverables register with states, and project-specific tailoring through container modules that can be toggled on and off. Your processes carry the model, the system provides the structure.
A quality gate is its own node type alongside container and milestone. You define verifiable criteria with named approvers, vote each release as approved or rejected with a comment - with a PMO override if needed - and the full history is retained in an audit-proof way. In scheduling, decision and review milestones appear as their own symbols without duration.
The deliverables register keeps every product with an owner, due date, progress and status. Products pass through traceable states from in progress via in review to released, and progress can be derived from seven methods - from manual to automatic from sub-elements. Status reports additionally run through three release stages and freeze their values at the reporting date. The many standardized documents of the process model are produced from your own Word templates, which WORKSPACE.PM fills with the current project data.
Per subproject you activate exactly what it needs from thirteen functional modules - such as quality gates, risks, documentation, effort or Kanban. Recurring structures are stored as a module template in a tenant-wide library and reinserted together with their configuration. So every project type starts with its own cut.
Requirements, verification cases and results are versioned objects of their own, connected through typed, two-way links. The trace matrix shows coverage per level and lists requirements without verification; when a requirement changes, the system automatically marks dependent verifications as “to re-check”. The formal acceptance happens at the decision gate with a full history.
V-Modell XT fits systems engineering, IT undertakings and public projects with a high need for evidence. In WORKSPACE.PM it stays hybrid-capable: every subproject can work agile while the decision gates of the process model form the bracket - a strictly documented system subproject and an agile development strand run within the same project.
Requirements management in WORKSPACE.PM
The part of this method that needs the most tooling - as an area of its own.
Related methods
Neighbours in the classic and engineering-oriented space
Run your next system undertaking natively with V-Modell XT
Start for free and set up decision gates, products and modules the right way from the start.