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.

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

The biggest mistake is, in one word, "IMPATIENCE", although this covers a multitude of sins.

This often applies to IT projects often, but not exclusively - rushing into it without proper planning, biting off more than they can chew.  That might sound glaringly obvious, but it happens all the time . . .

There's a large project and everyone wants to get on with it because "time is money!".  But what happens next is that everyone is in such a hurry that they don't think it through properly:

• They don't consider the risks that could impact the project
• They don't ensure they have the requirements properly documented
  
• They've thought about what they do today, not what they will need tomorrow
• They try to do too much in one go

IT is far from unique in terms of failures and no country or industry is immune either - it's happening all the time for the same fundamental reasons!

Some examples:

• Spain's tallest residential skyscraper (47 floors) with no elevators
  
• Surrey police crime management system scrapped after spending £14.8m
• UK £12bn National Health Service computer system scrapped
• Healthcare.gov and a history of failed projects

I believe a lot of it ultimately comes down to ego and bravado, few people would admit to this, but that's what it is.  Everyone is eager to get going, show progress, make it happen, justify their existence and position in the project and this, in turn, causes the team (as a whole) to underestimate the complexities and over-estimate their abilities because they don't actually understand what it's going to take to make this thing happen and think they can solve issues as they arise - maybe they can, but the costs will go up and time scales will slip! 

Clearly, nobody goes into a project hoping to fail, so where does it so often go wrong?

There used to be a generally accepted rule of thumb that whatever the software licenses cost, it would cost between two and five times as much to get it properly implemented.  The advent of Open Source and Software as a Service (SaaS) or "Cloud" or "Hosted" applications has changed this model, but it still holds true that the cost of implementation will almost always be more than the software itself - but now we could be talking 100 times as much!  The important thing to realise is that trying to save money in the wrong areas is going to cost you dearly!

The really key thing here is that if you don't have a VERY clear set of requirements, then you don't know what you're building.  You wouldn't start building a family home (or bigger) without a set of architect's drawings, would you?  Or start without a clear idea of the manpower, time-scales, materials, budgets, timings for each of the different jobs and when the trades would come on site. . ? Well, would you?  Yet we are tempted to do this in IT projects.

Then, just like every project of every type, there's the good old, "CYJ Factor" - "Can you just . . . .?" Move this?  Do that? Add this?  Change that . . . It would be great if . . .  You know, stuff that wasn't considered when the job was being scoped, but now it is important and can be miraculously added without impacting budgets or timescales.

So, for me the most important part of a project, from 25+ years of experience, is actually gathering accurate requirements and doing the Business Analysis to establish what's absolutely critical, what's important, what would be "nice to have" etc.  Because, without this information you're flying blind and you don't even know where you're heading for.

HOWEVER, the real challenge here is that you're going to ask the people who do their job every day what they want, aren't you? And, guess what, chances are they're going to describe what they have today as what they need tomorrow.  If you had asked a typist in 1990 for the perfect specification of a word processing package, there's a good chance they would have described a blue screen with white text, because WordPerfect 5.1 was the de facto standard then.  The colour of the screen wasn't a CRITICAL requirement, it was just what they were used to - and that's the danger of getting people who do the job every day to provide requirements for a new system - you're going to end up with a detailed description of what you have right now, with a few minor tweaks.

So, here you are, with the best opportunity in years to change the way your organisation operates and the ability to revolutionise your business, decrease costs, improve efficiency, surge ahead of your competitors, make money, save money, etc. and the specification you are likely to be given by your people is a slightly updated version of what you already have!  The opportunity to leverage technologies, radically improve processes, integrate systems, become leaner and more efficient and you end up with your current system on new hardware, because that's what your people just told you they NEED. 

The really bad news is that's just the start of your issues, because now a team of people who don't know your business are going to start cutting code based on the specification you just gave them!  Moreover, they probably don't speak English as a first language and they're not going to question what you meant by XYZ because that would be disrespectful - they're just going to code it and hope for the best!!

And when user requirements are translated by software guys, it all goes horribly wrong . . . . have you heard this joke:

A wife asks her husband, a software engineer...
"Could you please go shopping for me and buy one carton of milk, and if they have eggs, get 6!" 
A short time later the husband comes back with 6 cartons of milk. 
The wife asks him, "Why the hell did you buy 6 cartons of milk?" 
He replied, "They had eggs."

The next article will be on Requirements Gathering . . .