• rm@rmbastien.com

No Speed

No Speed

Once the right path is determined, the most important objective for the teams that deliver your information technology solutions is to do it quickly. There’s no time to loose. Competition is breathing in your neck. Most of the costs associated with IT function are human labor and your IT organization having a quasi-fixed throughput. This means that time also impacts cost.  The faster your IT team delivers the better for your organization, and the cheaper it will be in most cases.  Hence, shouldn’t speed be the ultimate measure of performance?

Attaining Scheduled Dates Is Not a Sign of Speed

Being on-time and on-budget is not a measure of speed since the schedule targets or the financial targets are re-defined for each project.

These OTOB1measures are more a sign of how good your IT function is at committing itself to respect its capacity to deliver than how fast or low-cost they are at delivering. 

Challenges Measuring IT Function Speed

Yes, speed is a core objective for corporate IT when delivering their portion of business change.  But measuring speed is far from obvious.  To understand the problem we need to ask two questions: (a) what is speed for corporate IT and (b) how it is measured?

Speed: Achievement Divided by Time to Achieve

In the case of cars, trains, or marathon runners, the formula is the one we’ve learned at school: distance traveled divided by the time it takes to travel that distance.

It is evident because we all have a sense of what distance means since it’s part of the tangible world we live in and there is a standard gauge for distance.  Same for time: it has standardized units of measurement and universal tools to measure it.

That’s fine for transportation, but speed can be so many other things.  For example, the speed at which an automobile factory produces cars is measured by the number of cars built, divided by the time it takes to build them.  Hence speed can be viewed as the measurement of some achievement divided by the time taken to reach it.

Now that we have a formula applicable to any situation, let’s try to answer the questions above (what is corporate IT speed and how is it measured).  The divisor[2] is always time, so we can forget about it and focus exclusively on the dividend.

Achievement Must Be Quantitative and Comparable

To assess IT speed, you need to know what an achievement is and be able to measure it.  But to be eligible, achievement measurements must have certain characteristics:

  1. They have to be measurable quantitatively; and
  2. Their units of measure must be standardized.

Measures of speed should not be left to qualitative interpretations and should be applicable to all solutions yielded by IT.  What’s the point of measuring speed if you cannot draw comparative conclusions? That’s where the whole corporate IT speed thing collapses.  In the case of the car factory, you count cars, but in the case of corporate IT, what are the units? What is the equivalent of the cars that you count on the shipping dock of the automotive factory?  The frustrating but true answer is that there is likely no such equivalent in your IT shop.

When units of achievement vary between projects or teams, that’s not usable as a valid measure of speed. It’s anecdotal evidence, nothing more.

Current Non-Speed Measures for Corporate IT

In the existing engagement model, there are two avenues that have been taken by corporate IT departments to show some sort of measurement of speed, although none of them are valid:  money and cadence.

Speed of Burning Money

To use money, you have to make the leap of faith that on average, higher-priced change endeavors yield more throughput.  By doing so, cost actuals become a proxy to measure what has been delivered.

Assuming you can bear the assumption, the result is disconcerting: the speed of delivery becomes the budget size of what has been delivered, divided by the time it took to deliver it.  In other words, corporate IT speed is measured by the speed at which money is burnt.  This is far from a valid measure of speed.

RPM as Speed

One of the key novelties in Agile™ is that whole solutions are split into smaller chunks delivered on a regular basis, usually between two to four weeks.  That pre-set period is religiously followed and is called a sprint.  Despite a name that conveys the idea of speed, at the end of a sprint, the team has to deliver something, anything that was agreed before the sprint started, but there is no commitment to speed.  The something is defined by the team, is different than what was delivered in the previous or next sprint, and is not made to be comparable with what other teams are sprinting on.  Hence there is no defined standard unit of measure for what is delivered.  Speed is re-defined as the time taken to attain a time-bound achievement. That’s not speed since the dividend is whatever can be delivered within that time“.

In iterative methods such as Agile™, speed is not measured. The pre-set number of weeks for sprints defines the cadence, not the speed. 

It’s Hard But Required

The challenge is not to position speed as a core objective; everyone should agree on its importance. It is measuring — and improving on — the speed of delivery that is impaired when no standard units are found. There is light at the end of the tunnel and finding standard units of measurement is feasible. The reason it hasn’t happened yet is because of the lack of efficacious business incentives to motivate anyone in IT to tackle the problem. But you can change that!

[1] More details about corporate IT’s performance measures here.

[2] I had to go back to school books for that one: in “a divided by b” (a/b) formula, a is the dividend and b the divisor.


Follow me: