To transform data into information and to use this information to manage and improve companies, projects, processes or products is a challenging, and at the same time, fascinating work. We can say that what gets measured gets managed and, as general rule,
what gets managed gets better. Well known are quotes such as “If you can’t measure it, you can’t improve it” from Peter Drucker, or “If you can’t measure something, you can’t understand it; if you can’t understand it, you can’t control it; if you can’t control
it, you can’t improve it” from James Harrington.
Sometimes only announcing the fact that something will be measured will automatically cause it to be improved.
In Information Technology we can talk amongst others about financial metrics, productivity metrics, quality metrics, time to deliver metrics, reference metrics, and about what is even more interesting: to know and to manage the different drivers that influence,
in a positive or negative way, those metrics. To collect, to record and to use this strategic information for doing things better might be a must.
But I would like to emphasize the magic word “drivers.” We can say that our productivity in a specific technology and under a set of circumstances is 1.25, for example. We deliver products under this productivity with an extremely low ratio of defects; our
competitors have a lower productivity; and standard market repositories (such as ISBSG, for example) indicate that our productivity ratio is good. But it is totally essential to consider that the “project size”, for example, can influence this 1.25 value:
the productivity can be different if the project is very small, or alternately if we are talking about a two year project with a team of 400 people.
It is important to have different refinement axis such as project size, project team size, time constraints, application criticality, multisite development, or product complexity: all impact productivity.
We need to be able to answer, with recorded and accurate metrics, questions such as, “What is our expected productivity of a 15,000 hour project, under a specific technology and framework?” And “What can change in case of a project of 600 hours?”, “What
are the drivers that affect our productivity, quality or delivery time, and how do they influence them?” Some of these will be internal. Others will be external, for example, on the customer side. Both might be well known and managed, at least the ones that
we can control. It is possible that your answer has been “yes” or a kind of synonym answer like “yes, I am an experienced project manager and I have all of this under control”, but the key words when asking the question are “accurate” and “recorded metrics”.
Do we have accurate and recorded metrics that fulfil the reality?
Sometimes mature IT departments, working with well-defined procedures, technologies, frameworks and products, can easily answer these third-level metrics questions. It will be more difficult for IT companies working for dozens or hundreds of clients, applying
their clients’ procedures, documentation requirements, customer development standards, frameworks and defined rules, to answer those questions with accurate information because sometimes each big customer is a concrete and different world, even if the technology
used is the same.