GovernIT » Metrics

Do your Metrics report performance or help improve performance?

Sridhar — Thu, 09 Dec 2010 20:15:30 +0000

There are many classifications of metrics in the industry – here is one set that I find useful when defining metrics for your project. I find them useful, since they force me to think about my objectives as well as what other decision-makers want from them. These types are commonly used with the term KPI (Key Process Indicator) in many industries. Let us continue calling them as Metrics, as we are focussed more on the Project/Program level.

Lagging or Validation Metrics

These are “after the fact” metrics to show how we performed and if everything is going smoothly. These “validate” the current processes and may show deviation from the expected value. Typically, there is nothing we can do about the completed activities, but can take corrective actions for the next set of activities.

This is generally ok for repeated activities, such as bug-fixing, but not for activities that are unique in the lifecycle. For example, if we have metrics for measuring quality of design, having a report on the defects after the design phase (design defect density, phase containment defects etc) is not terribly useful (even in iterative projects).

Leading or Improvement metrics

These metrics give us early information on the quality or progress of activities that are currently being performed. Considering the same Design phase example, if we can get inputs on the quality of design as it is currently being done, there is scope to make corrections to the process. In software development, these tend to be more of engineering metrics, such as cohesion, coupling etc.

When defining a metrics program, we should be careful in having a balance between these two types of metrics. If Lagging metrics dominate, there is not much you can do if something goes wrong, except as Lessons learned (which I doubt are learned!). If leading metrics dominate, you don’t know how you performed against overall targets or compare against previous projects.

You must be wondering – what has satellite images of a storm got to do with metrics? An analogy that is possibly distant, but the intention is this – Your metrics must be able to show all 3 aspects – what has happened, where do we stand, what is going to happen in the immediate future. If you have defined the right metrics (its easy to define a lot of wrong metrics!), you will then be able to decide how to act.

If you are thinking on where to capture information on the type of metric, the Metrics catalog is a good place to put it in.

10 Takeaways from SEI’s High Maturity Measurements report

Sridhar — Thu, 25 Nov 2010 20:19:29 +0000

This post is based on the “Performance Effects of Measurement and Analysis: Perspectives from CMMI High Maturity Organizations and Appraisers” from the SEI (Relevant page to download the report is here)

The SEI has published a seminal report (although its around 150 pages only), comparing the use of statistical methods and models with high-maturity levels from 2008 and 2009 surveys. The work, as expected, has a lot of details, including validation of the results using statistical analysis!

Key Takeaways:

1. Process Performance Models are used extensively in the areas of defect prediction, cost/schedule performance, estimation accuracy while other areas are relatively low. Interesting: Models for Customer satisfaction are less frequent

2. Many organizations use optimization techniques when building/using process performance models. Monte Carlo simulation and use of probabilistic modeling have grown. Interesting: Other techniques have reduced in popularity, while “don’t know” responses have increased!

3. Level of stakeholder involvement in measurement and analysis is along expected lines with measurement specialists having a high level of involvement. Interesting: It is not clear if all organizations have dedicated measurement specialists or process engineers take on the role as needed. Customer involvement is, predictably, less at organizational level

4. Organizations seem to have invested in training specialists in modeling techniques followed by process engineers. Interesting: It is not clear who the “users” of the models are – in a Software product/service organization, I expect users to be project managers and engineers

5. 75% of managers understand the results of the models well. Interesting: The % itself is interesting, since many of the managers I have met do not understand well how the models are built!

6. Just about 66% of those who build statistical models understand the intent behind it from the CMMI perspective. Interesting: Somehow, this does not resonate well with me. The only explanation I can think of is that the model builders are statisticians who are guided by the Process Engineers in identifying factors, building models and interpreting the results

7. Documenting the models and results well is a significant differentiator for high-maturity organizations. Interesting: No surprise there!

8. Not enough expertise is the only challenge that remained constant between 2008 and 2009. Other reasons have decreased! Interesting: In one year, have our problems decreased? I think in 2008, they were exaggerated!

9. 65% of managers want to use PPMs for knowing when their projects are out of track. Interesting: This is good, because having something just to gain a “high-maturity” tag is not, uh, “high-maturity” [Although, "PPMs are the way in the organization" comes a close second!]

10. There are 5 “healthy” ingredients for a good process performance model that is consistent across many research reports. When all ingredients are present, the value of the PPM to the organization is “substantial”. Interesting: The CMMI does not provide any directions on using such reports as guidance!

My observations:

1. There are many responses that mention the lack of clarity in what is expected from high-maturity practices.

2. Problems like lack of accurate historical data, wide variation in the type and nature of projects, resources etc continue to plague industry

3. There are no peer-reviewed, published reports on factors to be considered in process performance models. Even common ones like defect prediction do not have standard regression equations, where values/co-efficients can be adjusted based on organizational performance

4. Process Performance Models do not have enough documentation to describe the input data that was used to produce them. This causes resistance in using them well

5. Impact of people variation is not usually considered as a factor, but which often skews actual performance

6. Experts in statistical techniques tend to forget that finding the cause of variation is notoriously difficult in software development, which is what managers are more interested in! Stating variance values often brings up the question – “what is causing the variation?”, for which the answer is “Thats what you have to find out”. Silence.

7. High-maturity organizations often have the management commitment to stay the course even in financial difficulties – they believe that having high maturity practices is a necessary element of beating the competition and hence coming out of the financial crisis. Without this belief, High maturity goals remain another management fad

Read the report a few times to digest it. What conclusions did you draw? What aspects do you observe in your organizations? Did I miss something in my observations?

4 different ways to use your Metrics

Sridhar — Wed, 24 Nov 2010 01:48:44 +0000

How do you use your metric? Every metric can provide you with a different information/decision making capability, depending on how you use it. In fact, the way you use it can give an insight into the maturity of your measurement practices. The graphic below gives the 4 most common ways in which a metric can be used.

The mild arrows show how you can mature the metric to the next level of maturity. For example, you can use a metric such as project schedule adherence to control the current projects, but when you can capture historical information and apply to relevant future projects, you gain the ability to predict their schedule adherence.

Now that you have some idea of how metrics can be used, take a hard look at your metrics (your metrics catalog, if you have one, can have this field!) and tell us what % of your metrics fall into each category in the comments.

Metrics Definition – Gaining Agreement from your Stakeholders – Part 2

Sridhar — Fri, 19 Nov 2010 21:00:00 +0000

In the last post, we saw one of two things we should do for communicating and gaining agreement on your Metrics Definition. This week, we will look at something that even experienced people leap over – gaining agreement on the details of collection and presentation.

[Oh and if you are looking at an approach for defining Real Metrics, look no further than the Goal-Question-Metrics approach. You don't need to look further than How Do You Know Your Metrics Are Worth It by Derek Huether]

Standard Templates

I can’t stress this enough. Without standard templates for capturing, reporting and presenting, you will be firefighting every reporting period. Period.

Capturing raw data: Have a standard template in a spreadsheet or a tool to capture data as activities are being performed. For example, if you are going to collect information on bugs, use a bug-tracking tool for the entire Defect resolution process. This will get you the information much faster.

Capturing aggregate data: Once you have defined the granularity at which your data is going to be represented, have a standard template for aggregating the raw data into this. For example, if you are planning to capture helpdesk calls and have some categories for the types of help desk calls (hardware, OS, Standard software installation, network, email etc), aggregate the data for each type into this template for the current reporting period. Be sure to keep this information in some sort of a Document control system – this is the heart of your reporting system!

Presenting data: Create a standard presentation template with dummy data and create charts using the dummy data. Play around with different chart types until you are comfortable with the presentation. Most people don’t think about this much and are left wondering why the chart does not show the one point which the audience should notice. There is a wealth of information on the internet and elsewhere on the presentation of data (think Edward Burke), so I’ll not go over it now.

Tip 1: A good resource to determine which chart type suits your data best is at http://chartchooser.juiceanalytics.com

Tip 2: Have a standard template where people can enter data, but cannot edit the charts themselves. People do try to gloss over bad information by using “tricks” such as changing the axis’ values etc. If you have an honest organization, feel free to ignore this!)

When you are finished with creating the standard presentation with dummy data, make sure you drive it by the key stakeholders – those who are going to produce this information and those who will consume this information. Most of the arguments during presentations are around the representation of the information – how it gives incorrect/incomplete picture, the axis values not starting with zero, colors/fonts not being consistent etc. So, ensure you have buy-in on this part so that people focus on the content subsequently.

Bonus Tip: Automate your templates as much as possible, if you are not using a tool. It makes everyone’s life that much easier. Initially, you will spend a lot of time fixing problems with the automation, but believe me, it saves a lot of pain later.

I have tried to crystallize my learning around getting your metrics accepted and implemented. What has worked for you? Do you have any specific templates/resources that has helped you in getting the numbers out? Share with me below in the comments.

Metrics Definition – Gaining Agreement from your Stakeholders – Part 1

Sridhar — Thu, 18 Nov 2010 03:00:00 +0000

The most common problem in a Metrics program is defining the "why" for each of the metrics. The second most common problem is getting agreement from all stakeholders on the "what-when-where-which-how" parts of the definition. In this 2-part series, we will look at what you can do to make this easier for your stakeholders to understand what to expect from your metrics approach.

Defining a Metrics catalog
Creating standard data collection, reporting and presentation templates

In this part, let us take a look creating a Metrics Catalog to hold the metrics definitions and communicate in an unambiguous way on what the metrics mean and how they will be reported.

Part 2 will look at creating standard templates for the execution, once the metrics are agreed. However, it is often best to gain agreement on the templates along with the definition, since any major change in the templates can cause changes in the mechanics of the definitions.

A Metrics Catalog

A metrics catalog is simply a table with information on the collection and evaluation of Metrics. It can be a spreadsheet with columns for the different parts of the Metric. A set of columns given below can be used as a starting list

Name: Define the metric name. Be careful to make the names consistent (calling one "defect density" and the as "other % reduction in defects across testing cycles " doesn’t help!)

Inputs: What are the raw inputs that you will be using for this metric

Tip: A Metric is always a relationship between two entities")

Formula: How will be the metric be computed? Describe the relationship in mathematical terms.

Objective: Describe the intent of this metric – how will you interpret the values of this metric

Tip: Use general descriptors for the interpretation – don’t say, for example, "if the value is <99%, it means we are not doing good." Rather, say "the values for this metric will help us determine how our customers perceive our services")

Data Source: Identify where the inputs will come from and if possible, who is responsible to collect this information. This is one of the fields where the more detailed the information is, the easier it is for everybody later.

Unit of Measure: Describe the units for the values of the Metric. Is it % or defects/Lines of Code or just a number. Be very careful with this as this will impact how you will report the metrics in a visual form

Target Values: Describe the acceptable range of values for the metric

Tip: Be cautious with this, if you don’t have historical data. Leave it blank for the first few periods and then fill it in with the best performance of the actual values. Once you have sufficient samples, you can devise a proper target value).

Tip 2: Be extra cautious with “industry benchmarks”. Unless they are really similar, don’t thrust them on your organization or you will encounter lot of resistance to the metrics initiative)

Frequency of collection: Describe how often will you collect the inputs, compute and report the metric

Tip: As much as possible, try to keep the frequency constant for all the metrics in the Catalog. Think Collection=Reporting -just because data is available weekly, it doesn’t mean you need to collect and report it weekly.)

Area: Describe which area of the product/service lifecycle does this metric belong to.

Type of metric: List if it is a leading metric or lagging one

Avoiding a common trap during statistical analysis

Sridhar — Tue, 16 Nov 2010 23:00:00 +0000

Are you working on some statistical analysis on your data for identifying variation or for process improvement? Here is a common mistake that many beginners (and even experienced ones!) make when analyzing data during software development – variations have multiple special causes for the same effect!

Remember that manufacturing processes and software development have some major differences. Inputs are not constant, skill/knowledge required to complete 2 "similar" activities are different, people performing the task are different due to the need to use more intellect in day to day work than on the shop floor, standardization has a limit (however far you take that limit).

Don’t make this mistake. Do you know of any other such traps in using concepts/techniques from other industries? Talk to me.

Image courtesy of http://www.thadguy.com/

10 Takeaways from SEI’s High Maturity Measurements report

Forrester research on what CIOs want in 2010

Sridhar — Tue, 22 Dec 2009 04:59:13 +0000

A long title, but that is because I couldn’t find a shorter and apt one.

In this blog by forrester research (posted on CIO.com, by the way), CIOs have identified a few things they would like to see in their organizations in 2010.

I’ll summarize the basic points here, while you can read the rest of the article(rather small, actually) here – CIOs spoke, We listened. The basic idea is to improve Business-IT relationship, which as we know is being tried since IT was considered an industry.

How do we get closer to the Business? Lets try some of these:

1. Future trends in IT: How the next generation of technologies can change the way people interact in and with our business using technology. The Cloud (that sounds like a horror movie), social media, knowledge management etc are the areas which can rock the boat – the boat being Enterprise Architecture in this case.

2. Talent Management – Every industry is grappling with this question – How to find the best people and keep them. Of course, it is heartening to note that IT is slowly realizing that IT is still about people and not about technology.

3. Where do we stand on the scale – Like it or not, humans have reference frames which they use to judge things around them. Corporations are no different. Every senior manager wants to know how he is doing vis-a-vis the competition. This could be in terms of people, services, products etc.

4. IT Governance – Phew! I was afraid this would not be listed. Nothing need be said here, except to note that IT Governance is still considered IT’s headache. Let me reiterate, IT Governance is the Business’ Governance of IT. IT Management is what CIOs do.

5. Communicate value – Everyone needs to market their contributions and value-adds or risk being outsourced. IT still has to do better job in communicating business value, which will come only when IT is one way of doing business, which will come when business realizes the true value and potential of IT and… You get the point.

Observations on IT Metrics

Sridhar — Sun, 11 Oct 2009 11:02:11 +0000

I recently read an article on IT measurement titled, “IT Metrics: Feast or Famine.” It is an interesting piece, emphasizing that metrics should exist for a reason and it makes sense to periodically check if that reason is itself still valid!

As a long time designer of measurement systems, I have a few observations on IT Metrics, which I share with you below. Some of them are humorously written, but true nevertheless:

A useful set of metrics cannot be defined in one go. It takes a minimum of n² iterations to arrive at a stable set of metrics, n being the number of stakeholders who will report the metrics
Metrics that measure the positive side of a transaction are more easily accepted. For example, instead of the number of test failures, the number of tests passed stands a better chance of being accepted
The reporting format is usually the most debated part of a framework. Since this is what everyone will finally see, there will be much angst on how the information is represented. In many cases, the success or failure of a measurement system is measured by the reporting framework
A basket of metrics, with freedom for managers to select different metrics goes down better than a small set of core metrics that are inflexible
Senior management always want comparison – between projects, projects in other departments and against industry standards (specifically in the same type of business). Without this “referential”, no metrics program will be accepted, even though everyone tells you to start small
Someone will invariably ask for traffic light colors in your reporting, even though you stress a thousand times that no metric should be looked at in isolation
Someone will invariably ask for a “Dashboard”, no matter the contents

No related posts.