Posted by: Jeff Timmins | September 21, 2013

Tackling the KPI problem

What KPIs should be used for Release Management?

Couldn’t sleep so indulged in my favorite activity – searching for Release Management stuff on Google. This time the search was “Release Management KPI” which resulted in a lot of good hits.

While writing this piece I thought I should tackle the “what is success” first so feel free to read that first.

Anyway, the idea of KPIs for Release Managers has been on my mind for awhile. It has been on my ignored list for awhile and that has made me nervous. I fear that one of these days someone will demand a list of KPIs related to Release Management (RM) in the next day or someone will ask “tell me about your KPI experience” during an interview and I’ll freeze without being able to answer intelligently. So, now is the time to figure it out. How knows, if they make enough sense, maybe I could start using KPIs!

I have addressed KPIs in a past post (see “Examples of Key Performance Indicators (KPIs)” but will go more in-depth today. Of course first thing is first – what parts of the Release process are thought to be “gradable” for an RM?

website-kpis-seo-success

  • Creating a worthy Change Request (CR) – Probably not, too many variables to grade
  • Presenting the CR to the Change Manager for approved by the required deadline and details correct the first time – Yes
  • Need for Emergency and/or Unscheduled Release – Maybe (someone is at fault for the previous Release that wasn’t “good enough” and that could be the RM)
  • Successful notification of the deployement before, during and after the deployment – Yes
  • Successful management of the actual deployment (i.e. started only after pre-deployment criteria had been met, deploy doesn’t start if a production issue is progress, started on time, deployment steps followed, deployment closed on time, etc.) – Yes
  • Deploy errors or new defects found by QE during deployment window – No
  • Calling for and managing a successful rollback of the CR (if needed) – Yes
  • Details of the Release documented before & afterwards so the rest of the team can access them as needed – Yes
  • Deployment has no greater impact to the customer than what was already communicated or expected due to code issues – No
  • Release scheduled – Maybe (someone is at fault – bad planning or bad code – and/or to be congratulated – standing up and saying “Not yet”)
  • Changes in the code deployed to Production were a) what was tested the “lower environments” – e.g. UAT, Pre-Prod, etc. – and b) included only what was planned – e.g. part of the official list that QA validated the code against – Yes (some may disagree this is part of the RM role but I believe the RM is the best one to do it)

Note – the above are general categories that should be customized for your environment as needed.

There you go, 6 areas that we can grade an RM – Presenting the CR to the Change Manager, communication of the change, management of the deployment to Prod, management of the rollback as needed, documenting the details of the change and validating the contents of the changes.

If you take time to track these categories for your Release Manager you will have a good measurement of how successful they are.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: