AgilePM documentation based on building blocks
08 October 2019
Posted by: Henny Portman
In AgilePM the following documents are described:
• Terms of Reference
• Business Case
• Prioritised Requirements List
• Solution Architecture Definition
• Development Approach Definition
• Delivery Plan
• Management Approach Definition
• Feasibility Assessment
• Foundation Summary
• Evolving Solution
• Timebox Plan
• Timebox Review Record
• Project Review Report
• Benefits Assessment
If I look at templates used by organisations you are running the risk of large documents.
How many board members have ever read these bulky documents? How many board members have searched through these documents for the project scope and for their tasks and responsibilities in the project? Documents based on these templates are:
• descriptive and not concise;
• multi interpretable;
• labour-intensive to complete;
• bothersome to read;
This begs the following question:
"Is it possible to provide stakeholders with adequate information without falling into the trap of bulky, inaccessible, standalone, and illegible documents?"
If the answer to this question is positive, then it should also be possible to enhance the quality of projects. After all, the stakeholders gain a better insight, which brings about more effective and efficient decision making by the Project Board. The project manager can be more focused upon managing the project instead of writing bulky (progress) reports.
In the search for an answer to this question I used story-boarding, telling a story with PowerPoint slides with pictures and tables, and the concept of building blocks1.
Building block concept
AgilePM documents consist in part of identical information blocks. Each block can be seen as a building block of an AgilePM document. A building block is therefore an independent subdivision of a document.
Take for example the Terms of Reference with among other parts the business drivers and objectives to the project. If you make a building block for the Terms of Reference, it is information to be used as the trigger for the project, the Feasibility assessment, the Foundation summary and the Project Review Report.
The use of building blocks reduces the chance of miscommunication and the loss of information, causing de-motivation of the parties concerned.
The combination of the building blocks and the philosophy behind the storyboard (each picture is a building block) leads to the following requirements for the AgilePM documents:
• standardisation (ensure that comparable documents for projects are built up in the same way);
• essence (no extensive passages of text, but only the necessary);
• visualisation (make use of pictures, blocks, etc.: one picture says more than a thousand words).
The result of this procedure is that the stakeholders, e.g. Business Sponsor and Business Visionary receives the information in a recognisable and concisely represented manner.
With the pressures of work, the time to read and understand documents is limited. Standardisation, visualisation and essence increase the possibility of reading everything, interpreting, understanding and reviewing. The Business Sponsor and Business Visionary can use their time effectively and efficiently.
Comparable arguments apply to the position of the project manager. The project manager wishes to represent the information concisely, without repeating anything and writing things up only once. The project manager has need of a handle that enforces consistency, promotes clarity and upgrades quality. The growth of a document on the basis of selected building blocks motivates and is efficient and effective.
Structure of AgilePM documents
In the development of the documentation standard I have integrated the following AgilePM
documents (see Figure 1 for a simple view of the different documents and corresponding
• Terms of Reference
• Feasibility assessment
• Foundation summary
• Progress reporting
• Project review report
• Benefits assessment
The Feasibility report consists of the updated Terms of Reference building block. The
building blocks for the business case, the Business impact assessment and the prioritized
requirements list complete the Feasibility report. In case multiple solutions are possible
the two building blocks Business case and Business impact assessment can be repeated
for each proposed solution. For approval and history, a document history building block is
The building blocks of the Feasibility assessment, after being updated and the selected
solution, forms the basis of the Foundation summary. The Foundation summary is created
through the expansion of the Feasibility assessment by means of the following building
blocks: Business implementation strategy, System architecture and Non-functional
requirements complete the Solution Architecture Definition (System architecture and nonfunctional requirements only if part of the solution are IT related), Project approach, Project organisation, Project control, Delivery plan, Risk management and the Project Approach Questionnaire (all part of the Management Approach Definition). For large projects an additional Delivery plan building block is developed to show the high-level picture. For assurance purpose a Governance check building block is added.
After the Project Board has approved the Foundation summary, the project manager will
report on the progress periodically. The basis of this reporting are the Terms of Reference
and the Delivery plan. The project manager, in principle, takes the Terms of Reference
building block over unchanged.
A change in the Terms of Reference gives cause for the Project Board to review the Business Case once again. A specific Delivery summary building block that can act as a Timebox Review Record can complete the reporting.
A standard progress report with e.g. a burn-down and burn-up chart and project control indicators can help with the total picture.
The Project review report is based on the following existing, but updated, building blocks:
Terms of Reference, Business Case and Delivery summary. On top of this we see the
following additional building blocks Benefits enablement, Recapitulation and Lessons
The Benefits enablement building block can be used post-project for the Benefits
With graphic templates you are able to comply with the requirements of standardisation, visualisation and essence. The template describes the elements of a building block. This is practical for the project manager. There is little need for words. Visualisation with graphics, drawings and tables is very convenient. The document can be identified by its format and use of colour. It is accessible and easy to understand. On the basis of available building blocks it enables the project manager to create quick reports and presentations.
For some time now, the application of the proposed procedure has been utilised by a financial service provider (for all their projects). This organisation has developed around 20 building blocks. Each building block has its own form (template). If a building block is not relevant to a particular project, it will not be included.
Project Board members endorse the omission of irrelevant building blocks. They emphasise that standardised reporting saves time. They are able to determine the status of a project quickly. The decision points provide insight.
Figure 1, AgilePM document building blocks
Henny Portman is blogger / reviewer, author, international speaker and partner, trainer and senior consultant P3M3 Maturity at HWP Consulting.
View the orginal blog article here (Including a short video to explain in more detail how this building block approach to create AgilePM documents, works)