Atholl Consulting Ltd
  • Home
  • Who
  • What
  • Why
  • How
  • Expertise
  • Where
  • Examples
  • Contact
  • Atholl Blog

Effective Communications during a project

7/10/2014

0 Comments

 
Addressing the right audiences at the right time, with the right messages has often been a little more than lip service, so that an activity on a checklist can be ticked off by the Project Manager.  All too often Change projects have failed not (just) because of the technical aspects, but because of the people aspects and, as previously mentioned in Requirements gathering, done properly a huge opportunity to make real improvements within the organisation is missed.

For far too long, traditional project communications has been seen as more a question of telling Management what you want them to hear and telling the staff what you THINK they want to hear.  However, truly successful projects are notable by the absence of one-directional "reporting" strategies because everyone who needs to be is actively engaged, contributing and accountable and the traditional hierarchy and associated blame culture has been removed and replaced with people who know their role, accept their responsibilities and are motivated to work and to ensure the project succeeds, instead of trying to firewall themselves from blame for its failure.

Effective communication in a project is not a question of just progress reporting (although reporting is important), it is a question of collaboration and co-operation towards a shared vision of success, where people understand their role in the ultimate outcome and work as part of a team to achieve it.  In a game of football, is it all the goal-keeper's fault for letting the ball go past him into the net, or do the other 10 players share the responsibility for letting the opposition get into a position to shoot at goal in the first place?

As mentioned in "Effective Communications at the start of a project", it is important to be clear about:

  • WHO - is involved and who is impacted?
  • WHAT - is happening and what it will mean for me?
  • WHEN - is it happening and when will I need to be involved?
  • WHY - it is happening and why it "makes sense"?
  • HOW - it impacts me and how can I get involved?


But the key thing here is that if you start building a communications plan AFTER you've already started the project, then it is a bit too late - the communications should have started in earnest before the formal project began.


This approach is important for many of reasons, but especially:

Planning
You will need to take critical personnel away from their desks for periods of time - so you must ensure that appropriate cover is arranged in advance and that key people are not on holiday.  Likewise, that you don't completely break critical processes by removing numerous links from the chain simultaneously.

Timing
As with planning, you need to get this right - for instance, month ends are not a good time to engage Sales or Finance because they are trying to get stuff done and closed out.  So trying to talk about payroll, when Finance is trying to do the payroll is a bad idea!

Justification
People impacted by Change need to know that their contribution is important and VALUED.  If they don't understand why their input is important, or don't want to make the time to actively participate, and their boss doesn't get it either and doesn't reinforce these messages, these staff are worse than useless - and so is their boss!

Engagement
If change is being thrust upon me, I may well resist it (passively or even actively) because that is human nature.  However, if I have helped to shape it and have actually helped to create the justification for it, then it is my change - I own a stake in it and it will help me do my job better.  Then I will support it and will encourage others to do the same.

It is easy to think of Project Communications as an outbound, broadcast activity from the Project Management Office (PMO) to the "target audiences", instead of a two-way process. However, for a project to succeed during both the delivery phase and after handover (assuming the requirements gathering was done well!), the audience for Change should not simply be "communicated with", as in talked to, they need to FEEL heard and listened to for it to be effective.

Scheduling workshop sessions in the Requirements Gathering phase, including the documentation of Business Processes MUST ensure a balanced mix of people - you need to hear from grass roots staff and Managers and, most importantly, you need to explain the context and benefits of what you're trying to achieve.  If they perceive this whole process as an "unwelcome interruption", rather than an opportunity to make things better, then you've explained it wrong and, more importantly, these poor communications will lead to resistance and obstructive behaviours!

In the lead up to a new system, before formal work even starts, people need to be engaged and to FEEL able to speak freely about what currently works well and what doesn't, without fear of being singled out as a trouble-maker, or a problem.  So ensuring staff are there without their Managers and that you have staff who represent inter-connected parts of an overall process, who can discuss things openly may be a critical success factor.  For instance, one process may work perfectly in isolation, but after the handover it may go wrong, causing errors that you never knew about . . .

How about communication during development, what should you tell them?  "We're cutting code and we're on schedule" isn't going to inspire people or make them feel part of it.

OK, so, you're in the middle of building the system and it's half finished and you have the opportunity  to show some key system screens to the team that will use it.  Good idea or not?  Some will argue that showing them the system in a "half-baked" state is a very bad idea.  

But how about this - Most people can only visualise something they are already familiar with, so they can't visualise a new system, unless it looks just like the old one.  If the team (or a few key people) see the system at this point and can provide input to clarify the stated requirements, to further improve it, then it will probably be a fast fix for the coders to tweak it at this stage.  Whereas, do it right at the end will be a major piece of work, if it's even possible!  

Yet how often does iterative showcasing happen in software development projects? This level of transparency and openness makes the users feel much more engaged and an important part of the process, which makes them more supportive and better ambassadors for the project with their colleagues.  Usually, however, the "techies" don't trust the users and the users think the techies don't "get it" and there is a significant gap between them, which causes resentment and friction and a breakdown in communication.

Communication needs to be about talking openly and exchanging views and building team spirit, with a shared vision of what success feels like, and looks like.  A blog that gives status updates is NOT communication!

Now compare this approach, of actively engaging users, with the classic scenario of a newsletter pinned to the staff noticeboard, which nobody ever stops to read because it is positioned in a busy corridor, or a blog that gets updated once a month on progress that is almost meaningless to anyone outside the project team.  

Products like Yammer and other Social Media tools are becoming more common in some progressive organisations as a way of creating a dialogue and sharing information, but don't just approach it on a "Build it and they will come" basis - people need to be invited to participate, to subscribe to the blog, to join the Yammer group and given reasons to engage beyond having a "Name the new application" competition.

5 Tips for Effective Communication:

  • Be open, honest, transparent and authentic in your communications styles
  • Accept negative feedback as being equally valuable - it often is!
  • Use a multi-channel strategy - newsletters, blog, Social Media, informal face-to-face meetings
  • Actively engage your audience and do it regularly - encourage input, ideas and feedback
  • Explain clearly what the benefits to the organisation are, as well as the benefits to individuals


The next article will be on Managing Conflicting Requirements.

0 Comments

Understanding Business Process

7/8/2014

0 Comments

 
As well as requirements gathering, a critical aspect of work BEFORE starting work on a new system is to understand the underlying business processes that people do on a daily basis, whether or not they are done in systems or on paper.

A timely reminder of this came yesterday, over lunch with a friend who owns a recruitment company. A key member of staff is soon leaving his organisation after many years and, when he took time to understand what she did, he discovered that a lot of her activity was re-keying information others had already input into another system and then manually processing paperwork with checklists to ensure she didn't miss anything.

He will now be able to automate most of her work with software that he already has, or new software that is very cheap to license, and will not need to replace her with a new member of staff, saving time and money, reducing errors and improving both candidate and client experience - WOW!

In an African Telecoms giant, it was possible to instantly remove $10m of unnecessary cost and waste from their operations through business process improvement, without impacting any of their systems!  They had always worked in a particular way and this hadn't changed in years, by re-thinking this huge savings were made, costs were removed and obsolete equipment that was sitting on their shelves was quickly identified and sold off.

As previously mentioned in Requirements gathering, done properly, it is crucial to think in terms of People, Processes and Systems because it is the People who do interact with eachother and with the systems and if you don't consider the whole environment, then you will miss aspects.  Moreover, if you simply ask people how they do things, then key aspects may get missed because they do these things very often and their familiarity means they no longer think in detail about precisely what they do.

It is also important not to assume that everyone does it the same way.  In a large UK Telecoms company different teams doing essentially the same jobs operated differently, despite the fact that they all sat in the same room and had, at different times, worked in most of the other teams.  Amazingly, one of the teams doing more complex operations had evolved a far more efficient process than the ones doing simpler versions of the same basic functions (possibly because they had to simplify it in order to cope), but this had not been shared with others!  By capturing their processes in great detail, it was then possible to further improve them and to roll this way of working out to the other teams, making their jobs even faster and more efficient, with less potential for errors and improved customer satisfaction!  This process improvement was done before the new IT system was implemented, which meant that the Change Management activity was almost seamless at cut-over.

In "Effective Communications at the start of a project" the concept of engaging staff in a dialogue to identify ways of improving systems and processes was covered in some detail and when it comes to business process, this is critical because the people who do it every day are also the ones who can often tell you how to do it more efficiently.  This engagement process needs, however, to be facilitated because quite often solving a minor issue in one area causes further issues elsewhere that will not be obvious until the end-to-end process is analysed.  Furthermore, simply asking the staff is often just scratching the surface because they are too close to it and can't think in fresh ways about how to simplify what they do and make things more efficient, as in the African Telco example above.

It is critical, therefore, to ensure that you consider processes not simply as a series of serial or parallel tasks but also in terms of:
  • Who does it (which machine, system, person, team or department)
  • How they do it (is it manual or system based, is it automated), 
  • When they do it (what is the trigger event, is it a serial task or one of a number of parallel tasks), 
  • Why they do it (is it necessary) 
  • What they actually do
  • What checks are there (that it has happened to time, quality, etc.) Who checks?
  • What Escalations/Dependencies/Pre-requisites - if it doesn't happen or hasn't happened what are the impacts?

It may be necessary to map the process as a flow and as "swim-lanes" and to have sub-processes to capture other aspects that happen elsewhere as part of the overall process.  For instance, if the warehouse needs to ship a router to a client as part of supplying a new broadband circuit, then what is the process at the warehouse once they receive the order from the CRM system?  Does somebody actually type out the address label from the details on their screen and stick it on the box, or is that label sent directly from the CRM system?

Once the end-to-end processes are understood in detail, these can be validated against the findings of the requirements gathering exercise and also analysed to find aspects that can be automated, done more efficiently, or completely removed to make things simpler, faster, cheaper and potentially improve employee and customer satisfaction.

As an example, I have recently received three deliveries in one day from Amazon.co.uk and also, on another occasion, received 4 items in 4 different boxes - I ordered four camping chairs and they each came in their own huge box, when all four would have fitted into one box!  Now multiply these little irritations that I suffered by a business the size of theirs and imagine the potential savings from process improvement and consolidation!!

Again, impatience can have a huge impact on the quality and thoroughness of this activity and it is easy to see the potential consequences of not doing it properly, either in terms of completely missing a critical area or of missing out on a massive opportunity to improve how your company does business.  Potentially, you could significantly diminish the benefits of a new system if the processes aren't correctly reflected in the new system and associated working practices.

The next article will be on Effective Communications during a Project.
0 Comments

Effective Communications at the start of a project

7/7/2014

0 Comments

 
The first record of a project failing due to poor communications that I have been able to find is the Bible story of the Tower of Babel, which is also documented by the Romans in 1 A.D. and in the Hebrew Scriptures, so this issue has existed for a while.

As previously mentioned, it is critical in any major project to ensure all the people impacted by the proposed change understand:
  • WHO - is involved and who is impacted
  • WHAT - is happening and what it will mean for them
  • WHEN - it is happening and when they will need to be involved
  • WHY - it is happening and why it "makes sense"
  • HOW - it impacts them and how they can get involved


With advanced Social Media tools, this has become a lot easier and I produced a presentation about this around 4 years ago called Social Media Strategies for Change Management which highlighted the issues and some approaches to ensure the process went smoothly.

The biggest issue I see time after time, is that communication doesn't start early enough and tends to be "Top-down, command and control" in nature - in other words, a message from The Management saying something along the lines of, "We're doing this and we will let you know what you need to know, when you need to know it!  In the meantime, carry on!"  This type of message inevitably leads to speculation, rumour and resistance, which is almost impossible to fully overcome.

In reality, a major project that has a big budget and significant impacts on how people do their job (good or bad) needs a more inclusive and consultative approach and the sooner this process starts, the better it will be for everyone and here's why:

  1. By being inclusive and actively seeking input, you'll get the vast majority of people, including some hard-core cynics on side. You will gain loyalty from your workforce for simply asking them, "If you could do one thing to improve (the company's efficiency / your efficiency / your job satisfaction / customer satisfaction / save money / increase profit) what would it be?"
  2. Get people used to the idea - start gently with simple questions about what's wrong at the moment and/or how things can be done better, it will gain momentum surprising quickly, with more and more people offering opinions and supporting the process.
  3. The more you can find out about what's currently wrong and what can be done better, the more informed your business plan will be, giving you a better picture of the likely benefits, Return on Investment timescales and some additional ideas for improving your business processes.
  4. You may find that what you thought were significant issues aren't and that what you thought were root causes are actually just symptoms and you've been looking in the wrong place(s) for solutions - you may not need that new system, you may need something different!
  5. You'll probably identify some rising stars and significant assets in people you had never thought of (and may identify some dead wood too!)  You'll certainly get a clear idea of who to include in the workshop activities and, maybe, some of the people you will want to avoid.
  6. With a bit of analysis you will be able to prioritise these issues in terms of severity and impact and will be able to start planning the key areas that need most focus within the upcoming project.
  7. Harnessing this enthusiasm before the formal process starts means that when it comes to the real work of Requirements Gathering it will be a great deal easier, well supported and far more comprehensive.
  8. Your staff can't justify resisting change or complain about it if they, themselves, told you what was wrong and possibly how to fix it too.
  9. All of this great insight can be achieved without any disruption to business-as-usual and at zero cost - no need for meetings or workshops! You just put the question(s) out there, scoop up the feedback, say "Thank you!" to those who participated and compile the results.  (You may want to publish the results to demonstrate that you take staff feedback seriously!)

Honesty and transparency really is best in scenarios like this because your staff and customers are expressing opinions anyway, it's just a question of whether you are even aware of it!

Communications is a two-way thing, not a monologue telling people what you think they need to know - give them a voice and you may hear some uncomfortable truths, but they are being spoken out of your earshot, if you're choosing not to engage.

The next article will be Understanding Business Process

0 Comments

Requirements gathering, done properly

7/3/2014

1 Comment

 
To quote Einstein: "Insanity is doing the same thing over and over again and expecting a different result"

You're not mad are you?  Maybe a little silly sometimes, but not stark, raving bonkers - that's why you're running this show and why your people come to you for advice, right?

So, you're confronted with an opportunity to make a radical difference to your business by harnessing IT and making it do the work, so you and your people can do a better job, more efficiently and your company can be more competitive, more profitable, with superb satisfaction ratings from both employees and customers.

Now what?  How are you going to maximise this opportunity to make a transformation happen?

Do you want to be perceived more like Mel Gibson in Lethal Weapon, or more like Clint Eastwood in, well, pretty-much anything . . ?

Are you going to rush headlong into the unknown and work it out as it happens, risking everything, like the Banking Community did in the dizzy heights of Gordon Brown's "No more Boom and Bust" years?  Or are you going to pause for thought, be a touch cautious, be perceived and respected as a cool head?

The basic fact is that if requirements aren't properly gathered, then you can't build and configure the new system properly, let alone test it.  In fact, you can't even choose the best supplier to provide the system and, in all probability, your project is going to be consigned to history as one of the failures and you may well follow it!

Remember that the people who will be using the system want something as familiar as possible - same screens, same look and feel, just a bit easier - evolutionary thought will be a challenge, revolutionary thought close to impossible.  

So here's an approach that may help, if applied by skilled people, who know how to ask the right questions.

MOSCOW, may not seem like the obvious place to start, but in this context it's "MoSCoW" and it's a method of prioritisation for requirements that really helps, as follows:

  • M – MUST = a requirement that must be satisfied in the solution.
  • S – SHOULD = an important item that should be included if possible.
  • C – COULD = a requirement which is desirable but not essential. 
  • W - WOULD (“be nice to have”) = a requirement that will not be implemented in a given release, but may be considered for the future.


Next we need to understand Functional versus Non-functional requirements, this can sometimes be a grey area, but let's start from the following definitions:

Functional requirements are specific characteristics and capabilities of the system – what it is supposed to do at any given moment.  Using the scenario of a car, you might specify that there must be a gearbox, which is capable of accommodating forward, reverse or neutral modes. (Note that you haven't specified that it's manual or automatic or how many gears in this particular statement, these would be sub-statements)

Non-Functional requirements are attributes of the system which impact its usability and performance but are not specific to the fundamental capability.  In terms of the gearbox scenario, expanding on the Functional requirement, you might state whether it is manual or automatic, and how mode or gear selection might work.

I suspect you visualised your own car in the above example and immediately had preconceptions - stick shift, column shift, auto, manual, flappy paddles, tiptronic, sequential, H format, whatever . . . and that's the challenge with asking people, who do the job everyday, to provide meaningful requirements for a new system, they will refer to the familiar and won't give scope for different or better ways of doing things.


Three's a Crowd!

The challenge is that there are three key aspects to be considered and two fundamental approaches to a project like this and any of these could trip you up - and many projects that are "successful" still fail to meet their ultimate objectives or potential because of the following.  The 3 key aspects are People, Process and Systems and if you don’t get all three of these correct, aligned and in harmony, then your ultimate project outcome is likely to be sub-optimal.

People – your people must understand why this change is happening, what it means to them and actively buy-in to the process and feel like they are contributing to the outcome for their own reasons and, most importantly, WANT to use the system they "helped to build".

Processes – business processes evolve over time for many reasons, so what people think they do is often different from what they actually do.   But they don’t think about this in detail because it’s too familiar, like your journey to work, or even the process of driving itself.

Systems – the IT systems that are used and how the processes manifest themselves within the IT systems and, more importantly, how the people use them.

The two basic approaches to choosing and delivering a new system are Vendor-Driven or Company-Driven:

  • A Vendor-Driven implementation means that you have chosen to nail your colours to the mast of a specific supplier BEFORE you have worked out what you REALLY need the system to do.

  • The Company-Driven approach means your people are driving the requirements definition based on their perceptions and beliefs of what good looks like and are unlikely to get the best from the final system – In other words, they will try to keep it familiar and you may end up in the, “If you always do what you've always done, then you’ll always get what you always got” situation and the new system will just be an up-to-date version of what you had before.

As-is or To-be, that is the question!

Are your business processes as good as they can be?  Yes, everyone knows them, but does that mean they're efficient and effective?  We saved an African Telecoms company $10m in one month by improving their processes. Their network repair processes were fairly fast and quite slick, but they were costing themselves a fortune because the back-end processes were poor.  Another company were incurring additional costs that equated to 10% of the overall production costs through poor procurement and supply-chain.

The bottom line is that the implementation of a new system is the perfect time to evaluate and (if necessary) change processes, but if everyone is comfortable with the status quo, then they won't identify ways to improve and this will be a lost opportunity.  But it will probably manifest itself a bit later when other aspects become more efficient and poor process becomes the bottle-neck, by which time a quick fix will be impossible.

Off the back of the requirements analysis, you need to do a business process analysis and either validate your processes as fit for purpose, or identify ways to do things better, either way this is money well spent!  These issues are rarely visible to senior management because operational staff fix them, or get round them in real time and never flag them as issues.


Culture, culture everywhere but not a stop to think!

The biggest issue in all of this is not just giving your people permission to speak freely, but making them want to be part of the process because if this is done well, then their lives will be improved.

However, so many Change Initiatives are communicated badly and the people impacted are naturally resistant to change in any form.  Overcoming this “inertia” and getting people to think in fresh ways takes effort, time and skill and demands that the people driving the requirements gathering activity are not part of that team, so they ask “dumb questions” and challenge entrenched thinking.  As well as looking at the WHAT and HOW, it also needs to ask WHY and encourage people to find better ways of doing things because it’s is highly likely that processes can be improved and that this is accurately captured in the Functional and Non-functional mapping, as well as in the process flows.

The challenge here is that this investment in time and effort means people will be away from their desks whilst they are involved in workshops, etc. – some people will welcome this as a break from work, others will embrace the opportunity to improve the way they work, others will resent and resist it.

This is an extremely important consideration because, without top-down buy-in and effective communication from Management, people won’t make time or be incentivised to be an active contributor.  In fact, many people will try and avoid it, or will attend but not contribute freely and positively to the process, because they won’t understand that it will actually improve the way they work.

Moreover, this is an iterative process and you may have to go through the cycle a number of times to get it right – workshops to capture the information, document findings, present back and clarify, document clarifications, present back. . . .

Furthermore, you need to do this with every team and capture the end to end processes across multiple teams and then validate those processes, because different teams may see things differently and they may have their own external systems and processes that you were unaware of until that point in time, which creates further dependencies and complications that hadn’t previously been catered for, even if it’s just an Excel spreadsheet where they track information, it could be important!  

Furthermore, different teams may have different ways of doing the same (or very similar) things and there may be efficiencies or a previously undiscovered “best practice” in this that could make life easier or more complicated.  Things like Service Oriented Architecture (SOA) may come into play here and make life much easier, but that’s another story . . .

The next article will be on Effective Communications at the start of a project
1 Comment

M2M - So what?

5/2/2013

0 Comments

 
Rory Murray, one of the Founders of Atholl Consulting recently attended a round table event, with a group of worthy and highly accomplished people who are experts in their respective fields, to discuss the future of Machine to Machine “M2M”. 

Here’s what he learned:

It was an excellent event, hosted by Harvey Nash and chaired by David Wood of Delta Wisdom.

We discussed many aspects around M2M, from the potential size of the market and compelling use cases, to obstacles to adoption and risks, what the next two years might look like and so on . . .

One key thing that I hadn’t previously thought about in detail, although it’s obvious when you do think about it is that M2M is not just about cellular applications.  In-building solutions are probably connected by wire and, in that context, it must be remembered that the Utilities have been doing machine to machine for decades already with their SCADA systems.  We tend to think of Smart-Metering as the obvious emerging M2M application for Utilities, but we’ve already been doing it for a very long time!

In terms of size of market, it really depends what you mean – total number of connected devices, number of monitored things (e.g. cars, houses, etc) because these could each contain dozens, even hundreds of devices all monitoring aspects of overall status.  Think about a car, for instance, the brakes, tyre pressures, throttle, fluid levels, lights, etc., etc. all have monitoring devices that are talking back to a central brain within the vehicle which, in turn could be sending data in real-time to some central manufacturer’s database with real-time diagnostics.  It could be linked to the GPS so that if you’re running low on fuel the GPS suggests the best options for filling up – preferred brand, cheapest, closest, etc.

One really critical aspect to come out of the meeting was the fact that there are no dominant players in the M2M space in terms of technologies, operating systems, software, standards, applications, hardware, communications, etc – this means small companies are on a relatively level playing field with the big boys.  This represents both a threat and a huge opportunity because the market is immature enough and so incredibly diverse, in terms of the plethora of opportunities and applications, that everyone could make an impact in their chosen niche(s).  But there is a need for these various organisations to collaborate closely if they want to make progress and to keep the value chain as short and simple as possible.

Another key consideration, which has not been addressed to date, is international roaming, if you have a car with one of these systems, how will it work when you go abroad and are using another cellular network?  Who pays the bills?  On the subject of costs and value, what will deliver a compelling enough case to make us want to use these systems and who will pick up the tab for it all?  In eHealth, it could be a question of saving significant money through early intervention, meaning the business case works for the health provider and they pay.  For cars, it will probably be the manufacturer who pays, but there is an interesting pay-as-you-use model for insurance, road-tax, etc. too.

Another point of note was getting to the stage where the complexity was hidden and you could buy the complete service without having to think about how it works.  This speaks to some of the issues raised above, but if you want to offer a service, then the service must JUST WORK with no additional subscriptions, software downloads, or any other user intervention and again, this means an ecosystem of companies coming together to create a seamless and transparent value proposition that people or companies will buy because it delivers value.

In the case of smart-metering, this means it must work well for both the consumer and supplier because having real-time measurement must be something that has value for both parties – it helps me, as a homeowner to manage my consumption and bills, as well as helping my energy provider to give me a better service.

Lastly, many of these services create security and intrusion concerns – I don’t want my daily activities spied on and I don’t want to be hacked or defrauded either as an individual or as an organisation.  The solutions are there to many of these issues, but can cottage companies confidently deliver robust solutions to market at a price point that represents value whilst taking care of our personal data?  At what point does the potential loss of privacy get outweighed by the benefits?

In summary, I think we ended up with many unanswered and unanswerable questions, it was a bit like a Donald Rumsfeld speech –

There are known knowns; there are things we know that we know.
There are known unknowns; that is to say, there are things that we now know we don't know.
But there are also unknown unknowns – there are things we do not know we don’t know.


My main conclusion is that the opportunity is vast and is basically only limited by imagination and the ability to create a compelling business case for that makes individuals or companies want it enough to pay for it.  Some will be mass market and some will be highly specialised niche markets, but the opportunity for small companies to make a big dent and vast fortunes is probably as big today as it was when a small group of guys decided to build a search engine that is now a verb in daily use.

0 Comments

BIG Data - Not such a big deal!

4/26/2013

0 Comments

 
Why “Big Data” is no big deal

There’s a lot of talk about big data these days like it is something new and mysterious and only a small elite group “get it”.  This is simply not true.

The fact is that nobody, apart from the hardware and software vendors, care about data, oh and the people who peddle themselves as “experts”. NOBODY! 

What we do care about is information, knowledge, insight, intelligence.

Big data has existed for years, the data has always been there, we just didn’t know how to use it, or have the tools to make sense of it.  Now we do and in just the same way that we escaped having to navigate to our documents by typing C:\\my documents\work\customer\invoices and could simply click an icon, we now have tools that will give us the information we need at the click of a mouse because the complexity is in the code behind that mouse click, but it’s not rocket science!

Let’s take a supermarket as an example:

They have rows and rows of shelves stacked full of goods and every one of those items has a barcode and a price and a sell-by date and they know how many they have and they know their weight and locations, both on the shop floor and in the warehouse.  There are thousands, even tens of thousands of individual items to keep track of!  Then there are the buy-one-get-one-free type deals, where the price you pay must be adjusted in real time to give you discounts on specific combinations of items - That’s not “small data!”

Then you do your shopping and you go to the till and they scan or weigh each item and add it to your total bill, but they also deduct it from the inventory, so they know what’s been sold and what they need to re-order.

You also have the mark-downs, where they reduce the prices of items that are near their sell-by date, so they don’t have to waste those items, but if they fail to sell, then they do zero-rate them and dispose of them – that’s all being captured by the systems.

They’re also tracking you, if you’re a regular customer with a loyalty card – they know a lot about you and your family and they can target special offers at you for things they think you’ll buy.

They’re also tracking the weather and if it’s going to be a lovely weekend, then they change their ranges to promote items that you will want to buy – salads, beers, soft drinks, barbeque food, etc.  and you have to get it right because you don’t want to be left with vast amounts of unsold food that has a short shelf life that ends up getting wasted!

What about the staff, you have to ensure you have the right number of staff with the right skills on duty at the right time, you have to calculate their hours and pay, overtime, pensions, deductions, etc.

There’s a lot going on and that’s just one store!  Now think about it on a regional and national level, with hundreds or thousands of stores and potentially different weather across the nation or state.

BUT who needs to know how many cans of baked beans got sold last week, probably just a handful of people in the whole company.  Likewise for most of the other products, especially long-life and non-perishables.  The fighter-pilots in this scenario are the ones predicting sales of short-life perishables like fish, meat, salads and fresh fruit – they have to get it as close to perfect every day, without fail.  So they need a lot of information and dashboards and projections.

But they are actually the same information, dashboards and projections as the person with responsibility for baked beans, they’re just glad that if they get it wrong, they can sit in the warehouse for a week.

The bottom line is the data is the same, it’s sliced and diced into graphs and charts and exception reports in almost the exact same way for all products and the people for who it matters get those reports at store level and at regional and national level.  Then there are summary reports for managers because they don’t need to know how many kilos of fish got sold UNLESS a lot wasn’t sold and it has made a loss.

Let’s not forget that this data is also analysed by time of day, day of the week, season, weather, festivities and celebrations, etc. and the data is stored for years, so they can look back at previous trends to inform their decision-making.  “What happened last time we had good weather for the May Bank Holiday?”.  It’s also being analysed to see how we respond to advertising and news stories across both traditional channels like TV, radio, magazines, etc. but also new media – Facebook, Twitter, etc.

So, YES!, there’s a lot of data and a lot of real-time data because every barcode that is scanned is real-time data, changing the shop’s inventory before that customer has even left the shop and they know if you always buy that, sometimes buy it or have never bought it before, if you’re a card-carrying loyal customer.

But is it really BIG Data and what does that even mean?

Well it’s certainly big in terms of sheer volume and that’s why we’re hearing so much more about it now than we used to because we now have the applications and the hardware to process it into meaningful information within reasonable timescales.  Apparently 90% of all the data ever created has happened in the last 2 years- incredible when you think how old man-kind is.  But data is not information, it’s just bits and bytes on a disk somewhere until someone makes sense of it!

The really big news is around data augmentation, which is basically taking seemingly unrelated data and merging it with other data – the weather affecting sales of salad is augmented data – sales + weather data.  Mad cow disease or horsemeat scares impacting sales of processed beef products is augmented data- news + sales, but again, not rocket science! 

But some of it gets very clever and those abilities to predict trends could change our lives! The speed at which they were able to crunch all the video footage of Boston, find the bombers and publish their photos was big data, kind-of.  If the Russian information had been managed properly and the CIA and FBI had shared their data and the incident had been stopped before it even happened, that would have been big news for big data, but still not exactly rocket science.


0 Comments

    Author

    Rory Murray has 25+ years of experience creating and delivering high value, strategic solutions for diverse organisations across Europe, Middle East, Africa, India and North America.  In this time he has accumulated extensive expertise covering Sales and Marketing, Pre-sales and Technical Design, Operational and Management, Project / Programme Management and Delivery.

    Archives

    July 2014
    May 2013
    April 2013

    Categories

    All
    Analytics
    Big Data
    Business Analysis
    Business Process
    Change Management
    Communication
    Communications
    Complexity
    Dialogue
    Failure
    Information
    Insight
    IT Project
    M2m
    Machine-machine
    Machine-to-machine
    Planning
    Process Improvement
    Program
    Programme
    Project
    Project Failure
    Requirements Gathering
    Strategy

    RSS Feed

Copyright Atholl Consulting Ltd 2013.  All rights reserved.Registered Office - 17 Cosgrove Road, Old Stratford, Milton Keynes, MK19 6AG || 
Registered in England No. 4845027