Blogs

To Measure or Not to Measure

Peter Drucker said, “What gets measured gets managed”.

With the storm of analytical tools available these days, you can just about measure anything – the number of pages, seconds on page, previous page, calls to action. You name it and there is a tool to measure it.

But are we measuring the right things? Measuring the wrong things may not solve the problem. They may create a bigger problem!

Knowing what to measure is more important than measuring itself.

Define the Problem

Define the problem you are trying solve and look at it holistically from different perspectives:

  • Customers – what are the issues and expectations
  • Deliverables – what are our deliverables
  • Process – What is the process we are currently following
  • Inputs – What are we using to create the documents – content from previous releases, information from development or other teams
  • Stakeholders – who are the key stakeholders and how does the problem affect them or how do they contribute towards the solution.

Suppose I am looking to reduce the cost of printed documentation. The document ships as a multi-language book – English, French, and Spanish. Considering customers would read only one, the easiest way to solve the problem would be to go single language and the customer decides the language while placing the order.

Brilliant? Not really. If our suppliers had no way of identifying the language the customer chose while ordering online, we’d landed up sending them three single language books instead.

If we do not include the supplier’s perspective while defining the problem, we miss out on including a critical measure – what is actually getting shipped?

Link Your Measurables to Your Goals

Once we have a holistic understanding of the problem it becomes easier to identify the key measurables. In most cases, we may have a measure for Customer, Deliverables, Process, Inputs, and Stakeholders. There may also be occasions where some have no impact. The key is to measure only what impacts us.

Going back to our printed document example, we’d have the following:

  • Customer – Languages by country and page count
  • Deliverables – Total number of docs
  • Process – Legal requirements by country and language
  • Inputs – no impact
  • Stakeholders – Countries shipped to and cost per book

Slice the Data

Most often initiatives based on analytics fail as the project teams get overwhelmed with the data they receive or are unable to interpret it accurately. Looking at data all at once can be quite daunting. To get actionable measures, identify stratification factors and slice the data. For example, in our printed doc problem, we could look at documents shipping to a specific region or country, instead of looking to solve the problem for all the countries at once.

Closing Thoughts

Data in itself is useless. Data is only useful if you apply it correctly. Define clear goals and measures. Experiment with a subset and refine your action plans. It’s a continuous improvement process!

 

Rashmi Ramaswamy is a part of Innovatia’s Information Architecture team with a varied experience – support, training, tech pubs, project management, and information architecture. Her experience working with different teams helps her bring the best practices from each team to achieve a common goal – customer satisfaction.

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Share This