EVMS System Description Document Explained

<div class="ge-article-wrapper"><nav class="ge-toc" aria-label="Table of contents"><p class="ge-toc-label">In this article</p><ul class="ge-toc-list"><li><a href="#what-goes-into-a-system-description">What Goes Into a System Description</a></li><li><a href="#when-is-a-system-description-required">When Is a System Description Required?</a></li><li><a href="#who-reviews-it">Who Reviews It?</a></li><li><a href="#worked-example-building-a-system-description-for-a-30m-project">Worked Example: Building a System Description for a £30M Project</a></li><li><a href="#common-mistakes">Common Mistakes</a></li><li><a href="#frequently-asked-questions">Frequently Asked Questions</a></li></ul></nav><article class="ge-article-body"><p>An EVMS system description is the formal document that explains how your organisation implements earned value management. Not the theory. Not the textbook definition. Your specific processes, roles, tools, data flows, and reporting procedures. It's the document that a reviewer picks up during an Integrated Baseline Review and compares against what your team is actually doing. If the two don't match, you fail.</p><p>Think of it as the user manual for your <a href="/en/earned-value/definitions/earned-value-management">earned value management</a> system. It describes exactly how you meet the <a href="/en/earned-value/definitions/eia-748-standard">EIA-748 32 criteria</a> on this specific project.</p><p>This term is part of the <a href="/en/earned-value/definitions">earned value definitions glossary</a>. For the practical setup process, see the <a href="/en/earned-value/implementation-guide">EVM implementation guide</a>.</p><h2 id="what-goes-into-a-system-description">What Goes Into a System Description</h2><p>A system description isn't a generic EVM policy. It's project-specific (or at least organisation-specific with project-level annexes). Here's the typical structure:</p><pre class="ge-ascii-diagram ge-anim"> EVMS SYSTEM DESCRIPTION ======================== Table of Contents 1.0 INTRODUCTION +-- 1.1 Purpose and Scope +-- 1.2 Project Overview +-- 1.3 Contract Reference +-- 1.4 Applicable Standards (EIA-748) 2.0 ORGANISATION +-- 2.1 Work Breakdown Structure (WBS) +-- 2.2 Organisational Breakdown Structure (OBS) +-- 2.3 Responsibility Assignment Matrix (RAM) +-- 2.4 Control Account Structure +-- 2.5 Roles and Responsibilities |-- Control Account Manager (CAM) |-- Project Controls Manager |-- Cost Engineer |-- Planner/Scheduler 3.0 PLANNING, SCHEDULING &amp; BUDGETING +-- 3.1 Scheduling Process +-- 3.2 Work Package Definition +-- 3.3 Budget Development +-- 3.4 Performance Measurement Baseline (PMB) +-- 3.5 Management Reserve (MR) +-- 3.6 Undistributed Budget (UB) +-- 3.7 Earned Value Techniques |-- Discrete (milestones, % complete, 50/50) |-- Apportioned |-- Level of Effort (LOE) 4.0 ACCOUNTING +-- 4.1 Cost Collection Process +-- 4.2 Direct Cost Recording +-- 4.3 Indirect/Overhead Allocation +-- 4.4 Material Accounting +-- 4.5 Subcontract Integration 5.0 ANALYSIS &amp; REPORTING +-- 5.1 Variance Analysis Thresholds +-- 5.2 EAC Development Process +-- 5.3 Monthly Reporting Cycle +-- 5.4 Management Review Process +-- 5.5 Corrective Action Procedures 6.0 BASELINE MAINTENANCE +-- 6.1 Change Control Process +-- 6.2 Baseline Change Requests +-- 6.3 Management Reserve Log +-- 6.4 Retroactive Change Prohibition +-- 6.5 Re-baseline Procedures APPENDICES +-- A: WBS Dictionary +-- B: OBS Chart +-- C: RAM (Control Account to CAM mapping) +-- D: EV Technique Assignment by Work Package +-- E: Report Templates +-- F: Process Flow Diagrams </pre><p>That's between 40 and 80 pages on a major project. It sounds like a lot of effort. It is. But every page serves a purpose, and the alternative is trying to explain your system verbally during a review while the assessor looks increasingly sceptical.</p><h2 id="when-is-a-system-description-required">When Is a System Description Required?</h2><p>Not every project needs one. Here's the practical guide:</p><div class="ge-table-wrap ge-anim"><table class="ge-table"><thead><tr><th>Context</th><th>Required?</th><th>Detail Level</th></tr></thead><tbody><tr><td>MOD procurement (DEFCON 649)</td><td>Yes, mandatory</td><td>Full document, reviewed at IBR</td></tr><tr><td>Network Rail GRIP 5+ above £50M</td><td>Effectively yes</td><td>May be called "EVM Procedures Manual"</td></tr><tr><td>National Highways major schemes</td><td>Usually yes</td><td>Required for programme-level EVM</td></tr><tr><td>NEC4 Option C above £20M with EVM clause</td><td>Often requested</td><td>Simplified version acceptable</td></tr><tr><td>Private sector projects</td><td>Rarely formally</td><td>But having one makes IBR much smoother</td></tr><tr><td>Internal use only</td><td>No, but recommended</td><td>Even a 10-page version improves consistency</td></tr></tbody></table></div><p>On one rail electrification project I worked on, the client asked for a "description of your EVM processes" in the contract requirements. The project team submitted a 3-page summary. The client's assurance team rejected it and asked for a proper system description covering all five EIA-748 categories. That cost the team 4 weeks of rework. Don't make that mistake. If EVM is required, assume the system description is required too.</p><h2 id="who-reviews-it">Who Reviews It?</h2><p>The system description is reviewed during the Integrated Baseline Review (IBR). The review team typically includes:</p><ul><li><strong>Client's project controls team</strong>: they need confidence that your system will produce reliable data</li><li><strong>Independent assurance consultants</strong>: on MOD or major government projects</li><li><strong>Your own senior management</strong>: they're approving the processes their teams will follow</li></ul><p>The review isn't just a read-through. The IBR team will compare the system description against your actual tools and reports. If the document says you calculate <a href="/en/earned-value/definitions/estimate-at-completion">EAC</a> using BAC/<a href="/en/earned-value/definitions/cost-performance-index">CPI</a> but your monthly report shows a different approach, that's a finding. If the document says the Control Account Manager reviews variances monthly but the CAM has never seen a variance report, that's a bigger finding.</p><h2 id="worked-example-building-a-system-description-for-a-30m-project">Worked Example: Building a System Description for a £30M Project</h2><span class="ge-worked-label">Worked Example</span><div class="ge-callout ge-anim"><p><strong>Scenario:</strong> Your company has won a £30M NEC4 Option C water infrastructure package. The contract requires EVM reporting. You've been asked to produce the EVMS system description before the IBR, scheduled for week 8 of the project.</p><p><strong>Week 1 to 2: Define the structure</strong></p><ul><li>Map the WBS to the project's cost code structure (5 levels, 23 control accounts)</li><li>Map the OBS to section engineers and package managers (8 CAMs identified)</li><li>Create the Responsibility Assignment Matrix: each of the 23 control accounts assigned to one of 8 CAMs</li></ul><p><strong>Week 3 to 4: Document the processes</strong></p><ul><li>Scheduling: Primavera P6, updated fortnightly, resource-loaded</li><li>Budget: £30M <a href="/en/earned-value/definitions/budget-at-completion">BAC</a>, allocated to 23 control accounts, with £900K management reserve held separately</li><li>EV techniques: Milestones for procurement packages, weighted % complete for construction, LOE for site management</li><li>Cost collection: SAP, weekly timesheet uploads, monthly subcontractor accruals</li></ul><p><strong>Week 5 to 6: Document reporting and analysis</strong></p><ul><li>Monthly cycle: Progress cut-off on last Friday, cost cut-off on last working day, report issued by day 10 of following month</li><li>Variance thresholds: >5% or >£50K at control account level triggers formal explanation</li><li><a href="/en/earned-value/definitions/estimate-at-completion">EAC</a> process: BAC/CPI primary method, bottom-up <a href="/en/earned-value/definitions/estimate-to-complete">ETC</a> at quarter-end</li><li>Corrective actions: Logged in project risk register, tracked to closure</li></ul><p><strong>Week 7: Internal review and finalisation</strong></p><ul><li>Senior management walkthrough</li><li>Check every section against actual tools and processes</li><li>Ensure appendices are complete (WBS dictionary, OBS chart, RAM)</li></ul><p><strong>Week 8: IBR</strong></p><ul><li>Present system description to client assurance team</li><li>Walk through each section with supporting evidence</li><li>Address findings (expect 5 to 10 minor findings on a first IBR)</li></ul><p><strong>Estimated effort:</strong> 120 to 160 person-hours across the commercial and planning team. On a £30M contract, that's roughly £15,000 to £20,000 in staff time. Worth every penny when the alternative is ad-hoc reporting that nobody trusts.</p></div><h2 id="common-mistakes">Common Mistakes</h2><p><strong>Writing a generic document.</strong> Copy-pasting a system description from another project without updating it for the current WBS, OBS, tools, and team. Reviewers spot this immediately. If the document references "Primavera P6" but the project uses Asta Powerproject, your credibility is gone.</p><p><strong>Describing what should happen, not what does happen.</strong> The system description must reflect reality. If your CAMs don't actually review variance reports monthly (because they're too busy managing construction), don't write that they do. Either change the process or be honest about the frequency. Reviewers will interview the CAMs.</p><p><strong>Forgetting to maintain it.</strong> The system description isn't a one-off document. When processes change (new tools, revised reporting frequency, additional control accounts after a scope change), the document must be updated. Version control matters. I've reviewed projects where the system description was two years out of date and bore almost no resemblance to current practice.</p><p><strong>Over-engineering it.</strong> On a £15M project, a 100-page system description with 30 appendices is overkill. Scale the document to the project. The <a href="/en/earned-value/definitions/eia-748-standard">EIA-748 criteria</a> must be covered, but a concise 30-page document that accurately describes what you do is better than a 100-page document that nobody reads.</p><div class="ge-product-note ge-anim"><p><strong>How Gather helps.</strong> Gather's AI reads your site diaries daily and maps progress against your cost-loaded programme, giving you accurate earned value data without manual spreadsheet updates. <a href="https://gatherinsights.com/contact">Book a demo</a> to see it working on a live NEC4 project.</p></div><h2 id="frequently-asked-questions">Frequently Asked Questions</h2><h3>How long should an EVMS system description be?</h3><p>It depends on project complexity. For a £20M to £50M project: 30 to 50 pages plus appendices. For a £100M+ programme: 60 to 100 pages. The length is less important than completeness and accuracy. Every section of the <a href="/en/earned-value/definitions/eia-748-standard">EIA-748 standard</a> must be addressed, but you can be concise where your approach is straightforward.</p><h3>Can I use a corporate system description across multiple projects?</h3><p>Yes, if it's structured as a corporate-level document with project-specific annexes. The core processes (cost collection, reporting cycles, change control) are often consistent across projects. The project-specific elements (WBS, OBS, BAC, tool configuration) go in annexes that are tailored for each contract.</p><h3>What happens if the IBR finds gaps in the system description?</h3><p>Findings are categorised as major or minor. Minor findings (documentation gaps, missing appendices) typically get a corrective action with a 30-day deadline. Major findings (fundamental process gaps, no evidence of variance analysis) can result in a failed IBR. A failed IBR doesn't necessarily stop the project, but it puts the contractor on a remediation plan and erodes client confidence significantly.</p><h3>Is a system description the same as an EVM procedures manual?</h3><p>Functionally, yes. Different organisations use different names. "EVMS System Description," "EVM Procedures Manual," "EVM Implementation Plan," and "Project Controls Manual" all refer to broadly the same document. The key is that it describes your specific processes against the <a href="/en/earned-value/definitions/eia-748-standard">EIA-748 criteria</a> and is reviewed during the IBR.</p></article></div>