Home / Macro Reporting Concept Report

Macro Reporting Concept Report

Introduction

On one of the projects I worked on we adapted the Feature Driven Development (FDD) Parking Lot idea to provide valuable information to the PMO and senior management. This report was very valuable for status reporting, decision making and transparency.

I have done some thinking on how can this be expanded. I have created a mock-up of a potential way to provide a simplistic visual way to help senior management, stakeholders, the PMO and others driving the ROI to get a holistic and factual picture. I want to emphasise that I have not used this report on a real project and is simply a concept until an opportunity arises to trial it, evaluate it and gather feedback on its effectiveness.

I am using the scrum terms of theme, epic, story but this can easily be changed to fit your situation e.g:

  • business categories -> feature sets -> features

Here are some of my beliefs on macro reporting in the enterprise. I have to adapt or compromise on these depending on the environment and constraints I am placed under.

  • Macro reporting should only focus on the big picture i.e. epic and above
  • Stories are only implementers of epics, and epics are implementers of themes so stories belong at micro (implementation) level, once done their only use is metrics (velocity, portion of parent complete) , triangulation (in relative sizing)  or by team members (for whatever reason.)
  • Macro reporting should only be based on factual information (i.e. measurable) so as to promote visibility and transparency for decision making and direction
  • Macro reporting must be simple, easy to understand and concise
  • Macro reporting should only add value, doing a report because have always done it is costly and a waste of time
  • Macro reporting should be periodically reviewed to ensure continuous improvement of information
  • Macro reporting should be able to be rolled up from release, project, program to portfolio
  • Macro reporting should be automated where possible
  • Macro reporting should compliment prioritisation

 

The Conceptual Report

Click on the image to view a larger readable version…

 

 

 

 

 

 

 

The driving container is the theme. On large enterprise projects we may have 20 + themes.

Colour Coding:

  • White – Not Started
  • Orange – Started / In Progress
  • Green – Done, Done, Done

Interpretation of Report – What potential benefit can be derived from this?

T1 – Managing our Customers Account Information

  • The theme has been decomposed into its epics
  • Work has started on it as it is orange in colour
  • The first epic has been done
  • The second epic work has begun and is in progress, to date 34% of the epic has been completed
  • The other 2 epics have not had any work done on them as they are white in colour
  • The theme as a whole is 15% complete

T2 - Managing our Customers Contacts

  • The theme has been decomposed into epics
  • Work has started on it as it is orange in colour
  • 2 epics have been done
  • The last epic is 2% done
  • Overall the theme is 80% done

T3 – Managing our Customers Orders

  • The theme has been decomposed into epics
  • No works as started as it is white in color

T4 – Managing our Users

  • This theme is done so the entire value of the theme has been realised as it is green in color
  • It was given high priority over the other themes

T5+n

  • These have not been decomposed into epics
  • No work has been done
  • These are lower priority themes

What I like about this visualisation is that people can see the features that a theme will exhibit at a 30,000 ft view. The report can be enhanced but we do not want clutter for example, considerations could be one or more of:

  • An indicator to show if it is in production of not
  • An indicator to show the epic maturity in analysis, decomposed to stories, sprint ready
  • An indicator to show the specific release, but it may span multiple releases causing a problem
  • An indicator (count) to show outstanding bugs
  • An indicator to show resolved bugs
  • An indicator (metric) to show the relative business value of an epic ( If you are doing that)
  • An indicator on the % of automated tests for the epic
  • An indicator of the % of failed tests for the epic
  • An indicator of the % of technical debt for the epic

All of these metrics are available if the structure is setup correctly.