Peter Drucker, a celebrated management thinker, rightly said, "If it cannot be measured, it can't be managed,"
Measure, improvise, implement- are the three golden rules that almost every industry, especially the IT industry, needs to embrace.
As a visionary leader, you want your business operations to be cost-efficient. You want effective resource allocation to ensure timely delivery, quality services and most importantly, good ROI.
And one of the most efficient ways to accomplish that is through KPI (Key Performance Indicators) metrics. With an efficient IT management tool, you can easily measure, evaluate and understand how your organisation or department performs. In the release management process and outcomes, these KPIs function as the compass, helping you understand whether you're in the correct direction to meet business goals or need to alter your course.
But there can be right and wrong metrics. Therefore, before moving to which metric you should include in your release management process, let's understand how to choose the KPIs.
How To Choose The KPIs For Your Release Process?
While evaluating a performance indicator/parameter, ensure to consider the following questions:
- Can you accurately quantify the parameter?
- Does it relate to your organisational/business goals and objectives?
- Is it incorruptible and can't be tweaked to deliver false values?
- Will you be able to act on this performance indication ( scope for improvement, adopt XYZ method as best practice, etc.)?
- Is the metric future relevant?
Also, you'll need to filter out performance indicators that don't deliver value to your organisation.
- Outdated or redundant performance metrics aren't relevant to your current projects and organisational goals.
- Short-sighted fancy metrics that might seem to be a great fit for a few projects but don't bring long-term value.
- Unattainable and irrational indicators that might foster a sense of helplessness. Such metrics can hamper productivity and ultimately alter business outcomes.
Key Performance Indicators
You can use various release management software to visualise, evaluate and understand the metrics.
1. Downtime KPIs
Indicates the total duration when the application/ software is unavailable to the users because changes/updates are getting released. This KPI is measured in minutes. The goal should be to reduce the downtime as much as possible using various deployment techniques.
2. Estimated Release Downtime
This is an expected downtime duration built into the release plan. Record this value before the release cycle starts.
3. Actual Release Downtime
After completing the release, record the actual amount of downtime your application experiences during the deployment.
Aim for a minimal gap between actual and estimated release duration. Discrepancies suggested room for improvement and refining future release plans.
4. Release Success Rate Percentage
This performance parameter indicates the percentage of planned/scheduled releases having timely deployed. Deployments can be delayed due to changing priorities, miscommunication and reduced visibility of the process.
With the correct IT management tool, you can eliminate release bottlenecks and improve your release success rate. When pinpointing bottlenecks in your release process, it's helpful to have a quick, all-inclusive view of where you are spending your time.
5. Escaped Defect Percentage
Indicates the defects that escaped quality testing, made it past production and are found by users in the live environment. Generally calculated in percentage.
6. Defect Density
Indicates the quantity of known defects per module or in X lines of code. Defect density is a direct indicator of codebase quality. 1 defect per 1000 lines of the codebase is generally considered a "good" quality standard.
7. Number Of Releases
The number of releases over a given duration (yearly, monthly, 3-year duration, etc.). This KPI helps you understand whether your release frequency is increasing, decreasing, consistent or inconsistent. Similar to the other KPIs, context is helpful here. Therefore, breaking down this data by the type of project or portfolio gives more insightful information.
8. On-Time Delivery
On-Time delivery indicates the number of days after a scheduled release date the application is deployed and made available for end-users.
9. Major Coordinated Releases
Coordinated releases involve coordination and active collaboration of multiple platforms and applications. Major releases include substantial changes to the application. Major coordinated release involves a higher level of the ceremony due to the greater risk associated with multi-department orchestration and multi-organisations involvement.
Major coordinated releases generally require weeks of planning, preparation and dedicated environments, dedicated release management software, tools and resources to test integration between different applications. These releases are planned quarterly or half-yearly.
10. Minor Coordinated Releases
These involve minor updates to application features or software systems across application and departmental boundaries. These releases often have a monthly frequency. Major Isolated Releases
11. Major isolated release
generally involves a single application team and specialised QA groups. Unlike major coordinated releases, these releases introduce less risk and fewer unknowns.
These releases can generally be executed with ten or fewer professionals and are a regular, monthly drill.
12. Emergency Production Patches
Emergency production patches are emergency foxes required on a live application. Such patches can have unpredictable risks. A patch/fix can involve anything from a completely broken feature to a vital typo fix on a web page.
