Last updated on
Plutora Blog - Release Management

Release reporting metrics, it’s art rather than science

Reading time 4 minutes

Release Reporting, the two words every Delivery and Release Manager dreed. The two words that senior management like CIO’sand CTO’s inquire about but your not sure they actually care or even worse read the reports and digest the information. You spend a few hours crafting the email you send weekly or montly with all the facts and figures neatly presently in a well prepared spreadsheet template and never get a reply back from any of the reciepients. We have all been there!

Delivering a release in a complex and geographically dispersed environment is a hard thing to do when dealing with the challenges of trying to keep the release tracking to a green RAG status. It gets worse when management ask for status updates or a custom release dashboard and need it by close of business for tomorrows steering group meeting.

Reports and metrics in the release management space vastly differ from organisation to organisation. Unlike test management reporting or project management reporting which get baselined against industry standards Release Managers find themselves building out custom reports from scores of datasources such as spreadsheets, word docs, Sharepoint sites, Jira instances, powerpoint presentations and ITSM tools like Remedy and Service-Now.

At Plutora HQ we always advise customers to deliver reports which add value and can be interpreted by non-IT folks. Release managers often try to apply to much science and report on what we call non-value numbers (metrics which don’t allow for decisions).

The time needed to construct reports is significant because of the non-centralization of data needed to produce release metrics. Acquiring the data takes time, analysing the data takes time and the presenting it in the correct format takes time and because of the three steps you can’t blame Release Managers and Coordinators for sometimes feeling like there role is a release governance and reporting (MIS) function rather than one of leadership. A good example of above was when I worked for a global bank and there was a Release Manager who used to send out a weekly release dashboard in spreadsheet format with about 10 workbook tabs. I would open the spreadsheet and get bomboarded with charts, tables and instrucutions on how to navigate xls in order to understand the data. It got to the point that when I recieved these reporting emails from her I would just hit the “mark as read” button in outlook and move on without even worrying about the content.

Release reports and metrics need to be simple to read and easily accesible. Attaching reports to emails or uploading to a Sharepoint site is not going to cut it these days especially now when other teams in the same organisations spam you with there own reports trying to show case how well there team KPI’s look. Collaboration is the big push in the world of Agile and that means collaborating with colleagues who have access to the same real time information.

Stakeholders at every level from the CIO through to business and vendors require real-time reports. A single source of truth that allows them to log in from any location and get the data when they need it. This is one of the foundation requirements we noted down when founding Plutora. We looked at how releases where being constructed and realised that Release Managers are spending too many hours on duplicating reports and the gap was that by the time they had sent out a release report the metrics where more than likely already out. Plutora changes this, reports don’t get duplicated, data doesn’t get duplicated and the time spent on running reports is dramatically reduce, literally one button and it’s there.

Release Managers need to get much smarter with how they collect and report on releases and the required reporting metrics. If they don’t they will find themselves always having to justify there existence to the business and value they add to delivery lifecycle.

Release metrics are very important, the allow decisions to be made and provide powerful insight into historical, in-flight and forecasted pipeline activity.

I’ll be doing a follow-on post in the coming months about Post Implementation reporting which outlines what some of the key KPIs and indicators needed to track how successful releases have been against quality and business expectations.