If you look at the AgilePM (The DSDM Agile Project Framework) documentation set-up you could ask yourself if it’s not too much for an agile way of working?
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:
- standalone;
- 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 storyboarding, telling a story with PowerPoint slides with pictures and tables,and the concept of building blocks[1].
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:
- standardization (ensure that comparable documents for projects are built up in the same way);
- essence (no extensive passages of text, but only the necessary);
- visualization (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 recognizable and concisely represented manner. With the pressures of work, the time to read and understand documents is limited. Standardization, visualization 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 building blocks):
- 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 created too.
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 non-functional 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.
Figure 1, AgilePM document building blocks
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 learned. The Benefits enablement building block can be used post-project for the Benefits assessment.
Templates
With graphic templates you are able to comply with the requirements of standardization, visualization and essence. The template describes the elements of a building block. This is practical for the project manager. There is little need for words. Visualization 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.
Usage
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.
At the time of writing this article, I have given presentations to government authorities, an energy company, a retailer, consultancy companies and project management departments in order to bring the philosophy behind the standard into the limelight. Different organisations are currently implementing storyboards and building blocks.
It seems possible to systematically provide all concerned with adequate information without falling into the trap of bulky, inaccessible, standalone, and illegible documents. I have introduced the technique of storyboarding as a tool for reporting presentations. This promotes legibility and representation of the essence. I recommend the use of visual representations if it is possible. Storyboarding is a powerful tool to determine consistencies and omissions. I have used the overlap between AgilePM documents for the building block approach. Combining this with storyboarding ensures that executives and project managers use their time more effectively and efficiently.
[1]In my book PRINCE2 in practice, I used the same set-up
Building block explanation video
In this short video (14 minutes) I explain in more detail how this building block approach to create AgilePM documents, works.
Get the building block templates
If you are interested to receive a complete set of AgilePM building blocks (in PowerPoint) please send me a mail henny.portman@gmail.com and we can discuss the terms.
To download this article: AgilePM documentation based on building blocks
Henny Portman's Blog 
Pingback: AgilePM building block approach | Henny Portman's Blog
Pingback: AgilePM documentation based on building blocks - Angelo Giunta's Blog