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

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