Tag Archives: English Post

Bimodal Portfolio Management

Introduction

1*ORjFcvHHbyWBTA1WIijXYwAt the moment, many organizations are in the middle, or on the brink of, a radical change to more business agility. I receive quite often the question how to cope with both an agile portfolio as well as a more traditional portfolio with temporary projects and programs. Existing frameworks supports either an agile IT portfolio or a more traditional portfolio, but I haven’t seen frameworks which supports both.

If I look at existing traditional and agile IT portfolio management frameworks, I asked myself if combining these frameworks can bring an answer for those organizations who need to manage an agile as well as a more traditional portfolio?

In this article I will start with a brief explanation of the existing portfolio management frameworks by explaining the principles and the process (Management of Portfolios, Standard for Portfolio Management, Disciplined Agile Portfolio Management, Agile Portfolio Management, Evidence-Based Portfolio Management, and SAFe Lean Portfolio Management).

MoP P3O SAFe Hybrid (190621) v0.1In the second part of this article I focus on Bimodal Portfolio Management where I combine the best of these worlds and offer a solution for both worlds in the form of a Bimodal Portfolio Kanban (see figure), Bimodal Portfolio Management Principles and Bimodal Portfolio Roadmaps.

To download the article: Bimodal Portfolio Management (article, 190626) v1.0

 

Advertisements

Review User Story Mapping

User story mappingJeff Patton wrote the book User Story Mapping. Story mapping it’s a tool to enable your team to hold better conversations about the project throughout the development process. Your team will learn to come away with a shared understanding of what you’re attempting to build and why.

The book offers 18 chapters:

  1. The big picture. This chapter will help to get a basic understanding of a story map and what it means to tell stories.
  2. Plan to build less. Now you have a basis understanding of a map some more details are added. What’s the backbone of the map, what type of users are playing a role, which big activities are the performing, how can those activities be divided into smaller steps, how can we split a single step into more details.
  3. Plan to learn faster. Are we going to deliver everything in one big release, or can we have multiple releases? How are we going to set up the individual releases? How can we learn from the users using the release (validated learning, build – measure – learn)?
  4. Plan to finish on time. Don’t release each slice. Divide your release in an opening game (see it work), mid game (make it better) and an end game (make it releasable). Include risk stories to make risk visible.
  5. You already know how. Based on the previous chapters you now have a pretty good understanding of a story map. In this chapter you can prove you really understand it by creating a story map of all the things you have done this morning when you woke up until you’ve gotten ready for work. Will be fun, definitely when you do this with some more people and start to discuss differences. QRC (story mapping, 190606) v1.0To download: QRC (story mapping, 190606) v1.0
  6. The real story about stories. The founding father of the idea of stories was Kent Beck (eXtreme Programming). His idea was to stop working so hard on writing the perfect document, and to get to tell stories get their name not from how they’re supposed to be written, but from how they’re supposed to be used. Ron Jeffries describe the story process as 3 C’s: Card, Conversation and Conformation.
  7. Telling better stories. Stay away from template zombies. Start talking about the who, what, why, what goes wrong, what happens outside the software, questions and assumptions, better solutions, how and how long.
  8. It’s not all on the card. You could scribble everything you like on a card. E.g. short title, description, story number, estimate, size or budget, value, metrics, dependencies, status, dates. You could even flip the chart to the back and write additional notes or bulleted acceptance criteria.
  9. The card is just the beginning. The 3 C’s are just the beginning. Two more C’s complete it: Construction and Consequences (evaluate with team first, then with business stakeholders and in tests with customers and users).
  10. Bake stories like cake. Ask lots of who, what, and why questions. Ask about the context (where, when, how many). Talk long enough to build shared understanding. If the story describes a solution that’s too expensive, consider a different solution that helps you reach the goal. If the story describes a solution that’s affordable but big, break it into smaller parts that allow you to evaluate and see progress sooner.
  11. Rock breaking. A right-sized story from a user’s perspective is one that fulfills a need. A right-sized story from a development team’s perspective is one that takes just a few days to build and test. A right-sized story from a business perspective is one that helps a business achieve a business outcome. Conversations are one of the best tools for breaking down big stories.
  12. Rock breakers. A small, cross-functional team led by a product owner orchestrates product discovery work. The ideal size for a product discovery team is two to four people – dinner-conversation-sized so the members can quickly build shared understanding. The solution we want is valuable, feasible and usable (the three concerns; triad).
  13. Start with opportunities. Have conversations about opportunities and decide whether to move forward with them or trash them. If you agree to take on everything you are not helping anyone. Aggressively trash opportunities that don’t offer much hope of creating the outcomes you hope for.
  14. Using discovery to build shared understanding. Discovery work isn’t about building shippable software, it’s about learning. What problems are we really solving? What solutions could be valuable? What does a usable solution look like? What’s feasible to build given the time and tools that we have? Use four essential steps to discovery: frame the idea, understand customers and users, envision your solution and minimize and plan.
  15. Using discovery for validated learning. During discovery and validated learning, you may be telling stories constantly, breaking ideas and work down into small buildable pieces and agreeing on exactly what to build. You’ll be doing it so fast that it won’t be clear you’re using stories. But you are.
  16. Refine, define, and build. Play the Good-Better-Best game for splitting stories (What’s good enough to get things working, what would make it better, what’s the best version we can imagine?).
  17. Stories are actually like asteroids. Break stories down progressively, and just in time. To avoid a backlog filled with lots of tiny stories, take a bundle of stories that go together, and write all their titles on a single card as a bulleted list. Summarize those tittles with a single title on your new card and you’ve got one big story. In this way you can clean-up your backlog.
  18. Learn from everything you build. There are many opportunities to learn: review as a team, review with others in your organization, learn from users, learn from release to users, and use a map to evaluate release readiness.

Conclusion: A must read for product owners and agile team members. It’s the most complete book on story mapping I have read, and it will answer all (or most of) your questions regarding user story mapping.The book will definitely help you to use story mapping to deliver results that satisfy your customers.

To order: User Story Mapping

 

Review: An Introduction to Evidence-Based Portfolio Management

portfolio 2Scrum.org wrote the whitepaper An Introduction to Evidence-Based Portfolio Management. Evidence-Based Portfolio Management is an approach that applies lean and agile principles to the challenge of deciding where to invest to derive the greatest business benefit.

It enables organizations to quickly test ideas by actually building and validating the smallest solution that will deliver a single outcome to a single set of customers or users.

Evidence-Based Portfolio Management takes a Principles Based Approach:

  1. Separate capacity-for-growth from focus-of-work
  2. Make the best decision you can, based on the best evidence available
  3. Invest in improving business impacts using hypotheses, don’t just fund activity
  4. Continuously (re)evaluate and (re)order opportunities
  5. Minimize avoidable loss
  6. Let teams pull work as they have capacity
  7. Improve status reporting with increased engagement and transparency.

QRC E-B PfMTo download the QRC: QRC E-B PfM

Evidence-Based Portfolio Management focusses on outcomes to produce better results. It states that the organizational mission, vision, outcomes, and strategy must be centralized, and the product vision, strategy, and execution must be decentralized.

The art of portfolio management is deciding what not to work on and the number of teams you have will limit how many ideas you can work on at once.

To download the whitepaper: An Introduction to Evidence-Based Portfolio Management

This framework fits in the Portfolio level block of my bird’s eye view on the agile frameworks forest (see also the complete article).

Grasp session (Scaling Agile, 190603) v1.1

 

 

The Agile Fluency model

The Agile Fluency model, developed by Diana Larsen and James Shore in 2012 and substantially updated in 2018, is a framework to help teams understand their current position and to help them develop an individual road map. Agile teams pass through four distinct zones of fluency as they learn (fluency evolves). Diana Larsen defines fluency as things that you do automatically without thinking. Each zone brings specific benefits:

  1. Focusing teams produce business value (agile fundamentals). The team thinks and plans in terms of the benefits their sponsors, customers, and users will see from their software.
  2. Delivering teams deliver on the market cadence (agile sustainability). The team can release their latest work, at minimal risk and cost, whenever the business desires.
  3. Optimizing teams lead their market (innovative business agility, agile’s promise). The team understands what their market wants, what your business needs, and how to meet those needs.
  4. Strengthening teams make their organizations stronger (possible future of agile). The team understands its role in the larger organizational system and actively works to make that system more successful.

Schermafdruk 2019-05-30 15.52.02A team’s fluency comes from the ability of team members to self-organize so that individual skills are applied to the right problems at the right times. A team is fluent in a zone when it’s fluent in all of the zone’s proficiencies, including predecessor zones.

The appropriate zone for your teams depends on your organization and can be different from team to team. It is not a ranking system, but is about understanding and working towards the appropriate level of fluency for your needs at a particular point in time. Delivering or Optimizing are often the best targets, but Focusing and Strengthening can also be good choices. Fluency is more a matter of habits than skills.

Video: The Agile Fluency Model Explained: A Brief Guide to Success with Agile

The Agile Fluency Model whitepaper

Agile Fluency Simulation — an educational, exciting board game

This model definitely fits into the culture-targeted block of my bird’s eye view on the agile frameworks forest (see also the complete article):Grasp session (Scaling Agile, 190506) v1.1

 

Agile NXT Future Friday retrospect

Schermafdruk 2019-04-08 15.16.29Friday May 10, 2019, I was one of the 40 participants of the first Agile NXT Future Day conference organized by Xebia.

It was perfectly organized, really interesting and next level topics, great food, and enough time to network. The conference offered seven thought leaders to sharpen our mind and to help to improve your own organization’s performance. The group was split in two to facilitate discussion and active participation. Four sessions of 1,5 hour that made it possible to get some theoretical background and workshop set-ups to learn by doing.

The first session – Why the Agile “Fixed-Team” Dogma is Wrong (Laïla Nouijeh & Laurens Bonnema) was somewhat controversial. Fixed teams are the ideal world and now they say this is wrong. Luckily, it’s not that black and white but the reality is that people are entering and leaving the teams on unexpected moments, sometimes due to management decisions, sometimes as a result of a team mismatch, sometimes on a person’s own initiative and in most cases it will have a negative impact on the team’s performance. If you take this for granted and accept that reteaming is inevitable, make sure you get good at it. To become good in reteaming you can look e.g. at techniques like pair programming or MOB programming to speed up the process of integrating new members or create a checklist to facilitate on-boarding and make sure the questions are definitely a lot of fun to answer. To build, reshuffle or reteam teams you can also make use of self-selection. This will speed up the process of teaming too and ultimately you will have more engaged teams. In the last part we had a workshop to discover how to implement dynamic reteaming experiments in your organization.72

An interesting book to read is Dynamic Reteaming: The Art and Wisdom of Changing Teams by Heidi Helfand.

The second session – Stop Copy-Paste Agility, Start Agile Problem Solving (Daniel Burm) focused on the question: Is your agile “copy-paste” or “problem-solving-specific? If you only imitate, you’ll never innovate. Daniel started the session with a video from David Kelley, founder of IDEO. How they countermeasure solution thinking (what is deep dive) about designing a shopping cart.

Based on this video the question was asked if this design thinking process could be used for organization changes too? In a workshop setup all attendees got the chance to practice some techniques which were explained upfront. E.g. the Design thinking process for change based on a holistic approach: Empathize (scoping, 360 research and synthesize), Ideate (impact mapping: goal – actor – impact – deliverable), Experiment (run controlled experiments, experiment canvas). We practiced the change urgency interview resulting in a first problem statement, we reframed problems into challenges, and we created an experiment setup including an underlying hypothesis. All attendees received a workbook including the used templates and tools and the advice to learn what it takes to solve your own companies’ problems, your way—the agile way.impact mapping

An interesting book to read is Impact Mapping by Gojko Adzic.

In the third session Structure Your Organization For Tomorrow (Roel Trienekens & Just Meddens) we learned how to confront the real challenges of current work-impacting trends. Gain practical knowledge for your organization’s future-fit toolkit. Referring to David Marquet’s book Turn the ship around and showing the Pirates of the Caribbean – At World’s End – Up Is Down Scene.

Using three-dot voting all attendees selected a few themes out of ten. We started to discuss pros and cons of radical transparency. What if you have access to …

  • everyone’s planning?
  • everyone’s experience?
  • everyone’s to do list?
  • everyone’s goals and targets?
  • the complete company finances?
  • everyone’s performance reviews?
  • everyone’s salary and benefits?
  • everyone’s e-mail communication?

There are organizations, e.g. Buffer or Semco, where this works, so why would it not work at your place, but you need for sure a mindset shift to accept this way of transparency.

The second topic we discussed was about a new way of decision making. How are decisions being taken? Do you know how much a reasonable decision costs in your organization? You can use an autocratic decision-making process, a democratic process (“The process of voting creates losers” – Rick Falkvinge), consensus and using the process of consent (holacracy, sociocracy). We experiment with consent decision making starting with the statement is this good enough for now & safe enough to try in stead of ‘is everyone in favor?

swarmwiseAn interesting book to read is Swarmwise by Rick Falkvinge.

height_90_width_90_DeToekomstVanOrganisatiesInteresting Podcasts: http://detoekomstvanorganisaties.nl

The fourth session When Agile Meets Culture … And Clashes (Ellen Barree) helps you to open your eyes to the “invisible elements” that often undermine transformations. If you want to change the culture you need alignment between the three layers: rituals and artifacts, exposed values and behavior and underlaying assumptions. What can we learn from how David Attenborough observes? Take e.g. how David explains The Software Developer.

We experiment how to make culture change more tangible and sustainable by using the corporate culture map (A3 placemat). Starting with the desired cultural change: What do you want to see and hear? What do you believe in and how do we act? What are they not telling you and truly feel, think, percept? Folowed by describing the current culture: what do you see and hear? What do we believe in and how do we act? What are they not telling you and truly feel, think, percept? And as a final step creating the movement from current to desired with care.

9789462760363-480x600Interesting books to read:9789462761759-480x600 De Corporate Tribe – Organisatielessen uit de antropologie by Danielle Braun, Jitske Kramer.

Building Tribes – Reisgids voor organisaties by Jitske Kramer, Danielle Braun

The conference ended with the keynote from Margriet Sitskoorn How Agile is Our Human Brain? Take a trip through the plasticity of your mind and gain insight into how you can express your talents and best accomplish your goals in the age of agility. Magriet explained what it means to live in a VUCA (Volatile, Uncertain, Complex, Ambiguous) world. How can you develop your executive skills to be successful in a VUCA world? These executive skills are related to your pre-frontal lobe and help you to change from puppet to master. We experienced working memory, inhibition and inhibition and flexibility. To develop your pre-frontal lobe, you have to do something new. For this purpose, she developed the EFFECT program (Enriched environment, Flow-focus training, Fixed sleep pattern, Exercise, Connect today with tomorrow, and Time).

Some interesting book to read:

 

When we left, we received a goody bag with a pair of Xebia happy socks and the book Agile NXT insights and foresights for your next step in agile.

The next Agile NXT Future Friday will be held Friday September 13, 2019. If it will have the same quality of this first one, it’s definitely a conference I would like to attend.

Review: An executive’s guide to disciplined agile

DAThe book An executive’s guide to disciplined agile – Winning the race to business agility written by Scott W. Ambler and Mark Lines give a good overview of Disciplined Agile.

Disciplined Agile (DA) provides light-weight guidance to help organizations streamline their Information Technology (IT) and business processes in a context-sensitive manner. DA provides the process foundation for business agility.

There are seven principles to highlight the discipled agile mindset: delight customers, be awesome, pragmatism, context counts, choice is good, optimize flow and enterprise awareness. To stress the ability of being disciplined there are additional principles: master your craft, technical excellence, collaborate, measure wisely, transparency, lean continuously, purposeful experiments, deliver continuously, visualize workflow, whole team, stable team and trust and respect.

DA (QRC, 190407) v1.0DA consists of four parts (and are covered in chapters 3-6, the main part of the book):

  • Disciplined Agile Delivery (DAD). DAD addresses all aspects of solution delivery
  • Disciplined DevOps. This is the streamlining of IT solution development and IT operations
  • Disciplined Agile IT (DAIT). DAIT addresses how to apply agile and lean strategies to all aspects of IT
  • Disciplined Agile Enterprise (DAE). DAE is able to anticipate and respond swiftly to changes in the marketplace.

Within DAD we see the following roles:

  • Primary roles: Stakeholder and Team roles (Team lead, Product Owner, Team Member and Architecture Owner)
  • Secondary roles: Specialist, Independent Tester, Domain Expert, Technical Expert and Integrator.

The non-prescriptive DAD lifecycle consists of three phases inception, construction and transition. There are several versions of this lifecycle:

  • Agile/Basis lifecycle based on scrum. This lifecycle starts with the inception phase where modelling, planning and organization takes place and the initial backlog and release plan will be created. The other phases are similar with the Agile continuous delivery lifecycle (see below)
  • Lean/advanced lifecycle based on Kanban. This lifecycle starts with the inception phase where modelling, planning and organization takes place and the initial backlog will be created. The other phases are similar with the Lean continuous delivery lifecycle (see below)
  • Agile continuous delivery lifecycle: a single permanent agile team using Scrum giving a continuous stream of development (construction phase), released at the end of each iteration (short transition phase) and no need for an inception phase
  • Lean continuous delivery lifecycle: a single permanent agile team using Kanban giving a continuous stream of development (construction phase), and short transition phases and no need for an inception phase
  • Exploratory lifecycle based on Lean Start-up. This lifecycle starts with Envision, followed by Build a little, Deploy, Observe and Measure and Cancel or Productize the idea. I would say this is not a complete delivery lifecycle. To productize you have to use one of the other lifecycles
  • When you need more teams to build the service or product you need to coordinate the effort of the different teams to ensure they work together effectively towards the common goal. This is called in DA program management for large agile teams with the corresponding leadership team roles like a Program Manager/Coordinator, Product Delivery, Product Ownership and Architecture Ownership. The book doesn’t describe that much but, on the website, you can find much more information about program management.

The non-prescriptive set-up is emphasised by goal diagrams. Mindmaps to summarize the goals of a specific activity, e.g. addressing changing stakeholder needs, explore the initial scope or continuous improvement to mention a few.

Real life examples are missing in this book but can be found in their book Introduction to disciplined agile delivery

Disciplined DevOps explains what it means to bridge the gap between the agile teams and IT operations. In the book the workflow between Solution Delivery and IT Operations and other departments like Business Operations (BizDevOps), Security (DevSecOps), Data Management (DevDataOps) and Release Management and IT Support are explained. Reasons to adopt a Disciplined DevOps approach are faster time to market, improved market competitiveness, improved customer service, increased dependability, increased staff retention, improved governance and lower cost.

Disciplined Agile IT addresses how to apply agile and lean strategies to all aspects of IT. The workflow of Disciplined Agile IT is explained with a focus Disciplined DevOps, IT Operations, Release Management, Support, Security, Data Management and IT Governance, Reuse Engineering, Enterprise Architecture, People Management, Product Management, Continuous Improvement and Portfolio Management. On several place you get goal diagrams.

Portfolio Management addresses the following issues: spend IT investment wisely, balance exploring new business with exploiting existing value streams, monitor and guide ongoing activities, rolling-wave budgeting and planning, prefer small initiatives over large initiatives, cull “failures” quickly, invest in quality and enable team effectiveness.

To become a Disciplined Agile Enterprise, you have to embrace the following fundamental ideas:

  • Your organization and your people must be agile
  • It’s all about value streams
  • There is no one right answer
  • You need to sense and respond
  • You must be a learning organization
  • Self-organizing teams need fast access to resources.

In the workflow for Disciplined Agile Enterprise we see besides the ones mentioned in the Disciplined Agile IT workflow, Marketing, Sales, Control, Finance, Procurement and Legal. The authors explain the Disciplined Agile approaches in the different functions.

Next the authors give some insights what it means if you want to transform your organisation from a traditional structure and culture to one exhibiting true business agility. This will be very hard and will take a long time. Focus will vary over time in the following areas: executive education, executive coaching, middle-management coaching, agile training, agile/lean pilot teams, delivery team coaching, IT coaching, business coaching, skils training, agile centre of excellence, communication, experiments and communities of practice. The chapter ends with an example of a transformation and adoption roadmap anf how to measure your way to success. A separate chapter focusses on the final step in the transition, your organization has to become a learning organization (continuous improvement) and this will never end.

Conclusion: If you are not familiar with disciplined Agile and you want to get a clear overview of this framework, this book is a very good start. Looking at the different delivery cycles, there must be ones that have the right fit for your projects. If you want to implement disciplined Agile you probable need more information (as explained in the book too), and training and coaching too.

To order: An executive’s guide to disciplined agile – Winning the race to business agility

Positionering of Disciplined Agile in my birds eye view on the agile frameworks forest:Agile (50 shades of gray NTTP, 190415) v0.1

 

 

 

AgilePM documentation based on building blocks

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.Project name (AgilePM building blocks 2019xxxx) v1.0Figure 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@planet.nl and we can discuss the terms.

To download this article: AgilePM documentation based on building blocks