Month: June 2019

Beware “Ruthless Efficiency”: You Need Slack To Adapt

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 problematic.

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….

Continue reading Beware “Ruthless Efficiency”: You Need Slack To Adapt

Migration Headaches: Granularity of Data

Image Credit: © Nomad_Soul — stock.adobe.com #133340326

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’ data.

Continue reading Migration Headaches: Granularity of Data