Within some organisations there seems to be a management
mantra of “pursuing ruthless efficiency”.
On the face of it, other than sounding like something that ought to
appear on a “buzzword bingo” sheet, this seems like a sensible thing to aim for—I
mean if we can hit the “sweet spot” of being more efficient (i.e. incurring
less costs) whilst also being effective
and delivering what our customers want, that has to be a good thing, right?
Well yes, this statement is probably true—to an extent—but there
are some important nuances that are easily overlooked. Efficiency is crucial, but like most things
in life, it becomes problematic when taken to an extreme. Balanced efficiency can be an excellent thing
to aim for—it can actually mean you exceed customers’ expectations (“You can
deliver quicker than I expected? Awesome!”).
Ruthless efficiency, on the other
hand, where an organisation cuts, cuts,
cuts without looking and thinking holistically at the impact is far more
An example of Ruthless Efficiency: A Gym
I was mulling this over recently when working out at my
gym. I’ve been a member of this particular
gym for over 15 years, and I’ve seen managers and gym staff come and go. The gym itself has changed ownership in that
time, and in the past five years it’s pretty obvious that they have been cost
cutting presumably with the aim of being “ruthlessly efficient”. In fact, a few years ago they even lowered their monthly subscription
charges, to make them more in line with their competitors. Something that is pretty rare! So how has the drive for ruthless efficiency
affected them (and their stakeholders)? Read on….
I am sure many people reading this article will have worked on one, or probably many, projects which involve migration of data from one IT system to another. One of the things that the data migration elements of these projects tend to have in common is that they are painful. It is not that migration of data itself is always tricky, it is more that the quality of data on the source system tends to be an issue. Data cleansing and data mapping can be tricky, particularly when there has been poor data governance and stewardship. In a worst case scenario, we might even find fields being used for different purposes by different teams, or there might be ‘debates’ over what specific data items actually mean (“Order date is the date the order is received”. “No! Order date is the date that the order is accepted, which means payment has also been made”).
There are so many issues that we could discuss, I’d like to
zoom in on one: the granularity of data.
What Does ‘Granularity of Data’ Mean for Migration?
This is probably best illuminated with an example. My home insurance was recently up for
renewal, which I purchased via a large online insurer. Technically, they are a broker rather than an insurer—but you wouldn’t know that to look at
them (as the policies are branded with their logo, and you have to look pretty
hard to find out which insurer actually underwrites them).
Close to the renewal date I shopped around and found some
slightly better prices . I rang my
insurer to see if they could price-match, and I was surprised as they asked me
for a whole bunch of information that they already
had on file.
Concerned, I asked why, and the agent explained to me that they had
migrated from one IT system to another, and he no longer had access to the ‘legacy’