In an earned value environment, nothing should start without a work authorization document – and yet, it’s one of the most overlooked parts of project setup. In this article we’ll explain what this document is, how it fits into project control and why it’s important, especially in the context of preparing for your Integrated Baseline Review.
What is a work authorization document?
A work authorization document (WAD – not the best acronym, we know!) is a formal document that gives approval to begin work on a specific scope within a project.
It links the scope of work, the control account, budget, schedule and responsible party to each other. Think of it as the formal handoff between planning and execution, an essential part of traceability and accountability. It ensures that every part of the project is clearly authorised, assigned, and trackable.
The US Navy’s Center for Earned Value Management’s guidance on IBRs says:
Work authorization is a formal process related to various levels of the organization. Agreement is reached to each level of authorization so that there is no question as to what is required. The contractor P[roject] M[anager] (or Functional Manager) prepares a document authorizing the C[ontrol] A[ccount] M[anager] to perform work. This C[ontrol] A[ccount] authorization is in essence a mini-contract between the CAM and the authorizing party.
Work authorization is one of the 15 essentials we recommend covering in IBR training.
Why WADs matter in EVM and IBR environments
There are already a lot of acronyms in this article, but if you look past that, you can probably already see why authorizing work is important. These documents ensure that:
- Only authorized work is started
- Budget and schedule are linked to delivery
- Control Account Managers understand their scope and responsibilities.
During an Integrated Baseline Review (IBR), reviewers will often ask if you can show that the work was properly authorized, or ask if you know how the activities tie back to the baseline. If you can pull out a WAD, you can easily show that everything was done in the correct way.
Creating extra documentation is a pain, especially given the amount of documentation and approval chains that earned value management processes create anyway. But without formal approval for the work, scope creep can creep in unnoticed, teams work without clarity, and worst of all, for talking to the reviewers, audit trails are weak or missing.
So, if you are going to prepare these documents, what should you be putting in them?
What should a WAD include?
A strong work authorization document typically includes:
- Unique identifier or code (linked to Work Breakdown Structure or control account)
- Description of work to be performed
- Responsible person or team (this is usually the Control Account Manager)
- Start and end dates
- Budget assigned
- Reference to applicable risks or assumptions
- Signature or approval trail.
Optionally, you could also include related contractual or regulatory references, or the earned value technique to be used (e.g. milestone, Level Of Effort).
The document itself can be a paper form (although we see that less and less these days), a PDF, a digital record in a database or project management tool. The format matters less than the traceability and consistency.
Overall, the document should be concise but clear – enough to explain what’s being delivered, by whom, and within what guardrails.
How WADs support project governance and control
Ideally, work authorization documents should be issued after baseline approval and before task execution begins, so that’s where they fit in the governance cycle. They should align with control account scope and authorized funding.
Remember that these docs are less about writing things down for the sake of it and more about enabling performance tracking. They are also useful for supporting change control, because you can refer back to the baseline approved scope in the document to see what’s different.
We also see them used for helping out when things go wrong. Pull out the WAD as a reminder of who was responsible for what, not so that you can blame them, but so you can get them involved in identifying root causes. Maybe clarifying roles will help avoid that problem from happening again.
Common mistakes to avoid
One of the most common mistakes we see is teams not issuing work authorizations at all and instead relying on verbal handoffs or emails.
Another common problem is where documents are created retrospectively after the work has already started, so they don’t serve their purpose of authorizing the work because that’s already happened. If the document is being created ‘because you should have one’ then it isn’t helping with the delivery of the project and maintaining performance.
The third issue we see from time to time is where the documents are missing key data. For example, there is no control account link, no dates, no budget. Where this happens, the documents again aren’t useful for performance tracking.
Getting round these problems is actually pretty easy. Build WAD templates into your baseline prep checklist. Align WAD creation with your integrated schedule and WBS dictionary finalization so it’s an activity everyone is expected to do. Finally, store WADs in a version-controlled, auditable system and run checks on them to ensure they meet the right standards.
A work authorization document may seem like a formality, but it’s a key piece of earned value and project governance. It helps ensure that work is clearly defined, properly assigned, and directly linked to the project baseline. And they are excellent supports for teams prepping for an IBR. They help signpost that the team members are in control of the work.