Skip to content


Migration Headaches: Granularity of Data

Image Credit: © Nomad_Soul — #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.

A Modelling Dilemma: Precision and Accuracy

A tape measure and architectural house plan
Image Credit © Richard Villalon –

Understanding tricky business situations often requires us to draw upon our modelling skills. There are a wide range of types of model that we might utilise, ranging from conceptual models that help us understand how stakeholders think the situation ought to be operating, right through to process models, data or information models, state transition diagrams and many, many more beside.

Yet with this plethora of models comes a challenge: how do we create ‘views’ of the situation (or requirements) that are actually meaningful? How can we convey tricky and complex information in an understandable way, to a whole range of interested stakeholders, each of whom have different preferences and needs?

This is a perennial challenge. Executive stakeholders often want a “helicopter view” of a situation, and a detailed process or data model may disengage them. I remember working with one senior manager whose mantra was “one slide”. She took the view that if an idea or proposal couldn’t be distilled to a single slide, then it probably wasn’t well enough thought through (yet).  She was probably right.

Yet, as well as executive and senior managers we need to communicate effectively with end-users, subject matter experts,  vendors, third parties, middle managers and so on, each of whom will have different interests and concerns. Can ‘modelling’ really help us with this?  Don’t we risk creating something that is too high level to be useful, or so detailed that it will swamp and overload our stakeholders?

Precision and Accuracy

I was recently discussing this challenge with a client when a useful analogy emerged. We could perhaps consider communication—of any type, but including communication using models—along two dimensions: Precision and Accuracy

Take these three statements:

Business Analysts: Are You Dementia Aware?

Confusion: PIN or PIN?If you’re based in the UK, you may have heard that it is Dementia Awareness Week. One organisation that does fantastic work in this field is the Alzheimer’s Society, and while reading through their website my mind suddenly jolted back to the day job.

I suspect many people reading this article will have a friend, family member or acquaintance who suffers from some form of dementia. The term ‘dementia’, it turns out, is actually an umbrella term for a wide range of conditions—if you aren’t familiar with the symptoms I’d thoroughly recommend reading this set of articles.  Dementia affects various faculties at different stages, but one key concern is memory. And of course the very people using the systems and processes that we help implement and change may well include people who are living with various stages of dementia.


As business analysts, when working on changes to organisational systems and processes, we’ll often focus on non-functional requirements—and of course useability and accessibility are core considerations. Yet, how often in our projects and change initiatives do we really consider the detailed nuts and bolts of accessibility? How often do we ask things like:


  • What if the user can’t remember or retain a 4 digit PIN
  • What if the user forgets multiple pieces of information and gets frustrated that they can’t access their account
  • What if the user cannot digest a large ‘terms and conditions’ page, and perhaps needs it in a different format (video, audio) or needs the information explained to them so that they can ask questions?
  • Do our processes work if somebody loses mental capacity and a representative with Power of Attorney needs to take over?
  • Have our front line staff been trained to be empathetic to customers who may need a little more time?
  • Are task and process measures and KPIs appropriate or are management setting ‘maximum call length’ targets and penalising staff that allow customers extra time?


Although I have no doubt we all try to keep accessibility and useability firmly in mind I suspect, if we are being honest, the answer will often be ‘we don’t consider these things as much as we could’.


Statistics show that we have an ageing population. With people living longer, it is likely that organisations will be serving more and more customers living with dementia and other conditions. What was once perceived as an ‘exception’ may well become more frequent. As business analysts, we have the opportunity when improving processes, IT systems and broader organisational structures to ask questions like:

Two Useful Additions to a Requirements Package

Expanding Folder

When implementing a new solution within an organisation, communicating and gaining a common understanding of the requirements is crucial. One way of achieving this level of common understanding is to put together a requirements package. The content and style of that package may vary dramatically depending on the organisational context, the nature and size of the problem being solved, and whether the initiative is being delivered in a predictive (waterfall) or adaptive (agile/evolutionary) fashion. Either way, the requirements package is crucial as it helps communicate what the organisation needs.


The focus, quite rightly, when putting this together will be on capturing, analysing and validating the needs of the organisation’s stakeholders. The focus will be on articulating these requirements precisely and succinctly – and it is very tempting to focus purely on the requirements. Yet there are other useful items that we might choose to include that can help to remove ambiguity and create clarity.


In this article we’ll examine two other items that we might choose to include in our requirements package to help aid understanding. Both are relatively simple, but are easy to overlook:

Frustrated man frowning

Discussing Data Can Be Scary. Ignoring It Is terrifying.

Frustrated man frowningDelivering organisational change can be a tricky business.  In order to adapt and grow, a company may need to tweak or change its organisational structure, processes and systems – and often, Information Technology (IT) is an important enabler for change.  Of course, IT will only represent part of a change, but it can be an important catalyst and if implemented well, it could even enhance or create a competitive advantage.


In the rush to implement new IT or different IT, there is often a focus on the required functionality.    People focus on what they want the system to do and the exciting new features that they’ll be able to use.  In the excitement of building or buying a new system, data sometimes becomes the proverbial elephant in the room.  Everyone knows that it’s important, yet somehow it gets pushed from the agenda.  With the focus firmly on the visible functionality, there may be less appetite to discuss data.


Whilst this rush for quick implementation of functionality is understandable, when this pattern occurs, it’s really important to ask the question: Who is considering the data?  There is a real danger if the answer is “nobody”.


Data dangers

Picture of runway with sign "danger aircraft"

The “obviousness” danger that kills projects

Picture of runway with sign "danger aircraft"

I was recently boarding a flight, and whilst I was waiting to climb the steps to the aircraft, I happened to look around the runway.    I saw, at the edge of the tarmac, what appeared (initially) to be a rather obvious sign.  The sign read “Caution Aircraft”.  I smiled – and I sensed others around me found the sign entertaining too.   In fact, I could hear a couple chuckling behind me – I mean, come on.  It’s a runway.  It’s obvious that there are going to be planes there.  Why on earth would we need a sign to remind us of that?


The couple behind me continued to chuckle about the “obviousness” of the sign as we boarded the plane.  As I climbed the steps and boarded, curiosity got the better of me and I looked down from the steps.  From this new vantage point, I noticed that the tarmac was buzzing with activity.  Not only were there planes, but there were trucks carrying fuel, buggies carrying luggage, food delivery vans and more.   When planes landed, these support vehicles rushed over to get them ready for the next flight.  Many of these support vehicles seemed to come onto the tarmac around where the sign was located, so presumably the sign was a ‘reminder’ for vehicles that were entering an active part of the runway. With this in mind, perhaps the sign was reminding them of something that might seem obvious from some vantage points – but something that is crucially important.  The sign only looked obvious from our perspective because we were looking from the tarmac outwards.  If you were driving onto the tarmac from a support road, it might not be clear where the road finishes and the airfield begins.   What’s blindingly obvious from one perspective might not be intuitive or “obvious” at all from other perspectives. 


The danger of “obviousness” on projects.

Never let the customer see into the kitchen. It ruins the magic.

The small differences that make the difference


A few weekends ago, I spent some time catching up with some friends I hadn’t seen for a while.  After spending an enjoyable few hours chatting and drinking coffee, we decided to continue catching up whilst grabbing some food at a local restaurant.  It was a busy Saturday afternoon, and we were worried that the restaurant might be full–but the waiter was extremely helpful and quickly found us a table.  As he seated us he apologised that the table was really near to the kitchen door, and it might be a little noisy.  This didn’t really bother us – we were happy chatting and generally catching up.


Now, I don’t know if you’ve ever sat right next to the kitchen door at a busy restaurant, but it’s quite an interesting experience.  Every time the door opened, I could hear orders being shouted.   The head waiter seemed to be doing an impression of Gordon Ramsey, barking orders across the kitchen which were then relayed by the chef with equal gusto.   I heard everything – how previous customers had received the wrong meals, how table 29 were still waiting for their drinks order—and how one of the other waiting staff just “wasn’t up to the job” in their opinion.   I learned about their booking process, that they hadn’t ordered enough of one particular ingredient and that they were running out of house wine.  I have to say it somewhat spoiled the magic.  A potentially fun experience was made less-then-acceptable by seeing too much of the ‘behind the scenes’ detail.  It would be a bit like seeing a mall worker in a Santa outfit take off his beard and light up a cigarette as he opens the door to a 1980s rusting estate car.  Some things should just be hidden from public view.


It’s not just about kitchens or Santas…

Several pocket watches

Manual workarounds: There’s no such thing as a “few seconds”

Several pocket watchesLet’s face it, we’ve all been there.  Whilst working on a project which will deliver some kind of change within an operational area, we face unexpected difficulties late in the delivery lifecycle.   Perhaps we find out that something we were hoping to do is much more complex than we’d anticipated, or maybe time and budget are running out.  The project manager and sponsor are on the case:  We must deliver on time, so yet another round of prioritisation meetings are called.   We need to take a metaphorical machete to our project and our requirements with a view to delivering something smaller and cheaper that is still “fit for purpose”.     That is quite a challenge, but one that I’m sure will resonate with many readers!


A hypothetical example…

Let’s build on this idea and imagine for a moment that we work in a mid-size organisation that is progressing a project to launch a brand new customer self-service portal.   The objectives are to encourage customers to submit changes online, rather than ringing through to the call centre.   The project’s business case is built around efficiency savings, reduced number of phone calls and intangible benefits including better customer satisfaction.   The original intention was that when a customer submits their information via the web, it’ll automatically feed through to the master customer database, updating the details immediately.


However, we face a sudden and unexpected problem — we’ve suddenly had our project budget cut by 30%, and there are pressures to deliver even quicker than originally planned.   So, we convene an urgent prioritisation meeting.  We take up our role as facilitator and start to discuss what we could do differently, or which features or functions we are going to de-scope from the project.


The conversation gets heated remarkably quickly – our stakeholders egos start to show themselves.  Different stakeholders have different worldviews and are politically exposed in different ways.

The sponsor opens the meeting sternly:


“We absolutely must deliver on time.  We’ve announced the delivery date to the press, and we simply can’t be seen to have yet another delayed project.”


Discussion continues.  People start to ask how this situation has occurred.  A range of potential  re-scoping options are discussed, but it isn’t possible to get agreement.  One stakeholder suggests that we should seriously consider cancelling the project altogether, but this voice is quickly quashed. The conversation is moving on quickly when one of the other senior stakeholders (who used to be an operational team leader 20 years ago) interjects:


 “Right, I think I have a solution.  We can deliver everything on time and within budget”.


The room’s attention is immediately drawn to the stakeholders face.   She waits a moment and then breaks the silence.

Do your customers trust you?

Angry GirlI recently read an intriguing article on the Studio@Gawker site, which described how two remarkably different organisations solved two very different  business problems through gaining a better understanding of their customers.  They achieved this by using analytic and CRM solutions to help anticipate their customers’ needs—but most importantly of all by considering and addressing the thorny issue of trust amongst their customer base.


It struck me when reading this article that trust is something that we don’t talk about enough in business and business analysis circles, yet it is key for retaining customers. Foster a high trust culture with customers and you’re more likely to hold on to them— and this is true irrespective of whether you’re a small, midsize or multinational enterprise.     Yet in many organisations, the issue of trust might not be considered at all when developing new products, services, systems or processes.  This can be a recipe for disappointment. Without considering the impact on customer trust, changes may be made that have an adverse effect to existing customers, leading to damaged or destroyed relationships.


An example: Trust and relationships

Trust is key to relationships.  I’m willing to guess that if you drive a car, you take your car to a mechanic or garage that you trust when you need a repair or service.  In fact, people often stay with a mechanic or garage that they trust for years – even if they know they can get a cheaper deal elsewhere.    Trust helps build customer loyalty, which is extremely beneficial as it’s often stated that signing up a new customer costs on average 4-6 times more than keeping an existing one.  Clearly, this will vary by organisation and industry, but this highlights the importance of retaining customers and continuing to meet or exceed their needs and expectations.


It’s also generally accepted that trust takes time to build, but can be destroyed in a second.  I remember dealing with a telecommunication company as a consumer where I’d received excellent service for years.  They made a small billing error – and when I contacted them it was so  traumatic to put right that I eventually left.  This inconsistency in experience shook my trust.  They had provided excellent service for years, but one inconsistency in service meant that I left.   If they’d made the correction I’d asked for in a more straightforward manner, I’d have stayed.


What does this mean for business and business analysis

We often talk about the “customer experience” in our businesses along with the importance of representing the customer in our projects and product design activities – and there is no doubt this is an exceptionally important factor.  It’s crucial that the customer gets their product or service at the right quality and that they have a valuable experience.  But how often do we talk about the consistency of service?  Perhaps not enough; particularly given this consistency can affect trust.

Portsmouth's Spinnaker Tower

Deadlines are soon forgotten: It’s the quality they remember

Portsmouth's Spinnaker TowerThis is a picture of the Spinnaker Tower, located in my home-town of Portsmouth, UK.  It’s a 170 metre (560 foot) construction with viewing decks at the top that opened in 2005.  It’s a real tourist attraction and if you’re ever in the area be sure to go and see it – there are superb views from the top! (In fact, if you’re going to be in the area contact me and we’ll catch up for a beer…)


If you do visit the tower, you might notice that the building hides a rather embarrassing secret:  It was built with an external scenic lift (elevator) attached to the side that has never worked reliably.  There is an internal lift that you can use, but you may well notice a redundant lift on the exterior.  To my knowledge, it has never been opened for public use.


If you speak to the locals, you’ll be told anecdotes about how on its day of opening several people – allegedly including the project manager – were trapped in the lift for over an hour.   This has been a thorn in the building’s side for years, and the external lift is allegedly being removed.


I heard this story again recently, and it reminded me of something that should be kept firmly in mind when progressing projects: