Saturday, 15 November 2014

Three Stages of Activity

When an unusual event occurs in a business, a REACTION occurs, and the situation is dealt with.

Over time the action taken becomes ROUTINE, often being scheduled once a day, week or month.

Finally, the action becomes RITUAL. It is still performed although no longer useful for the business.

An example of RITUAL is a detailed report, prepared for a manager who has long departed. His successor does not know why they keep receiving pages of computer output with only the last line being useful!

Another example is the filing of paper copies of documents, even though there is a perfectly good computer system which was put in place to be used instead of the paper.

People might question RITUAL activities, but only mildly: as life is so busy they keep doing them anyway.

It is often only when an outsider comes in and examines the situation in detail that management truly recognises the time and energy being wasted on these activities.


This might be where a new request for information comes in from outside. A report is prepared (often tediously) and submitted. An example might be for the sales of a particular product in the last month.


The request for information comes in again and staff remember how they dealt with it the first time. The report is prepared again – possibly a spreadsheet is set up containing the requested information, extracted from a computer system (but of course with the information entered manually). The information is now prepared every month and passed to the requesting department.

Possibly they would appreciate having the information differently presented, but because the first request was urgent, they took the information the way it was provided, and no-one has thought to go back and ask for it in a more useful layout. (“Why do they keep giving us sales when I really want deliveries?” one manager asked.)


After months or even years the procedure is followed automatically. Because the first reaction was urgent, no-one has changed the computer system to automatically populate the spreadsheet.

The receiving department possibly has no need of the information – perhaps they have developed their own way of obtaining the information they require, such as direct returns from the branches. But the originating department keeps filling in that spreadsheet!


So, does your business still practise obscure rituals perfected in the dark ages? See how many examples you can spot in the next week!

Saturday, 18 October 2014

How to recognise scam e-mails

Scam e-mails come in various forms. One type tempts you to click on a link which appears to go somewhere safe, but which actually takes you to a site you’d prefer not to visit. 

Even if an e-mail appears to be from someone you know, do not accept the links as genuine unless you were really expecting them, and they pass these tests. 


Recently I received a suspicious e-mail. Although apparently from Facebook Administration (which was already enough to alert me) the actual “From” e-mail address was notification+wysjdtqzmh@facebookmail.comAnything with a random string of letters, or where the “From” name is quite different from the underlying e-mail address should make you suspicious. (In fact Facebook does send e-mails with an apparently random string of letters.) 

Sometimes – if you are only looking at the header – that should be enough to make you delete the message. However, if you wish to check further, and are reading the whole e-mail, check out any other links.


The e-mail said: “Follow the link:” which may look ok, but when I hovered my mouse over the link (as you can do - but don't click) the actual address it was pointing at was something like: http://217.123456.2/~radjan/deviatexxx.html. (I've added some x's to make sure no-one goes to a scam page.)

Seeing that they were quite different, I deleted the e-mail as it was obviously a scam.


Another way of recognising an e-mail as a scam (especially the ones apparently coming from a bank) is to spot glaring errors in grammar or spelling. 

Much as I dislike bankers, I suspect they know how to use a spellchecker! Twice recently I have received e-mails which asked for my “baniking details”. Another one to delete! 


Having written the above, I then received a very professional-looking e-mail again seeming to come from Lloyds. They had obviously read my comments, and avoided most of the mistakes I have mentioned. 

There were still some errors in the grammar (and I don’t have a Lloyds account) but the most obvious aspect was that the e-mail took me to a website where I could input personal information. 

Although this looked like a Lloyds' website, it wasn't. 

This is a Mirroring scam, where the website you are seeing looks and acts like the bank’s website, but it is actually passing your information to a third party! 

How do you know? Well, no bank will e-mail you asking you to input personal information.

The apparent website is a folder on your computer. In fact the website said “We'll never direct you to the log on page from an e-mail” which was effectively what the e-mail was doing! 

As a last piece of sophistication the page had real Lloyds telephone numbers and a link to a Lloyds page saying “How can I tell that this site is secure” !!

For advice on scams and computer security, give me a ring.

Saturday, 20 September 2014

The Devil is in the Detail

Some time ago two clients asked me to look at problems they were having with their systems.

In both cases, far too much clerical effort was being expended where computers should have been helping.


In one office, information was being entered twice, into two separate systems. A departmental system needed details of financial transactions, but these also were being entered into the company’s main accounting system.

When the departmental system was purchased, no-one checked that it could link to the accounting system. So for some time now, double entry of data has been occurring, with all the related issues of boredom, time-wasting and the possibility of errors.

It may not have seemed a major issue originally, but it has grown to be quite a problem.


Another client has a good accounting system. However the detailed reports needed at month end are not produced within the system. Information is exported to Excel and then staff spend at least a day each month manipulating the results into the desired format.

This is not a good idea. There is (once again) far too great a possibility of errors being introduced, and in any case it is a waste of a skilled person’s time. The accounting system should produce the required reports. With a modern system this should be quite feasible, even if it seems a little daunting at first!


When systems are installed, people are nervous about budgets being exceeded, but sometimes they neglect to address the vital aspects of systems.

Where systems use the same information there is a need to be very vigilant. Far too often, staff are typing information from one system into the other, or worse, they type the same information into both. (Or even print it out of one and then type it into the other!) It is worth spending quite a lot of time and energy to make sure that details are transferred automatically from one system to the other.

Also, if the same standard information is needed regularly, make sure your system produces it, rather than having staff spending hours each month manipulating data to produce the correct format of reports.

After all, computer systems should meet your business needs.

This may seem trite, and obvious, but surprisingly often, companies do not have systems which fully meet their needs. Even large systems, which are designed to be complete, often do not produce the required management information for some departments.

Look around you and identify where time (and money) are being wasted.

Let me help identify those areas worth tackling.

Saturday, 23 August 2014

Why staff appraisals matter

I strongly believe that a well-run appraisal system can transform staff effectiveness. 

One manager complained that his staff were not following set procedures. “If I’ve told them once, I’ve told them a thousand times...” he said. And that’s how this manager ran his appraisals: he talked at the staff, without listening to what they had to say. 


Performance appraisals are intended to be an opportunity for manager and employee to work together with the aim of improving results. 

A crucial aspect of the manager’s role is to ensure that his staff are fully aware of what is expected of them, how they are doing and how they can improve and develop.

(See my article Have a Clear Business Strategy for more on this.)


To ensure the appraisal process works, each person involved should write their views of the past year, and their thoughts for the future year. 

(And the manager should talk to additional people who have dealt with the person being appraised. This might mean other managers, people in other departments, or even colleagues of the appraisee.) 


The performance appraisal interview should be structured to encourage the member of staff to give feedback on both the procedure and their manager’s own performance. Both people need to have sufficient confidence and belief in the appraisal process that they are able to speak openly about awkward matters. 

Ideally none of the issues raised at the meeting should be news to either person, but the manager has to listen to make sure he hears what the member of staff is saying, otherwise he will not benefit. (And of course the meeting needs to take place with enough openness that the employee is able to listen too.) 

The appraisal meeting should look back at the year gone, and also look ahead, positively, to the year ahead. 

(Usually the looking forward part should take longer than the looking back part, but all the key issues need to be covered or the participants won’t feel better for the meeting.) 


By the end of the meeting the member of staff should be clear about their aims for the next year, and how their role fits in to the greater scheme of things. 

After this, when they are in doubt about what to do they should be able to apply an understanding of their objectives to determine how to proceed. They should appreciate why they are operating in a particular way; understand the systems and procedures in place; and be able to use them appropriately. 

They should also feel able to comment constructively on what they are doing, and so help the organisation to perform better. 

The end result should thus be more productive and also more satisfied staff.

Saturday, 12 July 2014

Why procedures need to be agreed

Procedures (or Standard Operating Procedures) sound boring, but if documented properly and disseminated appropriately they can make a real difference to staff performance. Far too many people are not clear about the best way to use their IT system, or worse, they claim to be clear but do not use their system the way they should!

Computer systems are designed to function in a particular way, and they have many features which can make a real difference to performance if used properly.

Make sure they are agreed

To get the most out of your system, procedures need to be agreed before a system goes live. They should be discussed with all those involved, including those in other areas who will receive outputs from the system, to ensure that each person will get what they need to perform their job effectively.

In some companies people in other departments get a paper report and then type the information into another system, or into Excel, when they could have got a file that would interface directly – if they’d been asked at the beginning!

Once procedures have been developed and agreed, they should be reviewed some time after implementation (say one to three months later) and modified if need be. They should always be reviewed when business requirements change, and they should be looked at in more detail at least once a year, to address any new features of work which have developed (and to exclude aspects no longer required).

Note that what is required is a clearly documented set of procedures which provides a general understanding of the best way to use your systems. Good procedures include screen shots and maybe even clear handwritten notes. 

Awareness videos or Quick Reference Cards can really make a difference. 


Remember though, even before there can be procedures, there needs to be an agreed objective, a business strategy, so that all involved see how their role fits in with the company’s or the department’s objectives.

Procedures should not be written by managers and handed over to staff without proper training. They need to be discussed and any necessary modifications need to be made. Staff have to understand the procedures, and agree to use them. If they do not agree, the manager needs to understand why – possibly they do not cover all situations, or the staff feel they will be too onerous to implement.

Managers need to check procedures are being followed, and this will also help them validate the procedures.

Saturday, 7 June 2014

Better Staff Training is Worthwhile!

A company I visited had several challenges.

A key one was that none of the staff had been properly trained to use their main software package. This system was used to carry out all invoicing of customers, to make all supplier payments and to prepare the company accounts.

Their offices were a good place to work, with dedicated staff trying to do the best they could. However because the staff had inadequate training they were very inefficient.

For example, there was no Procedures Manual available for staff to use. So when people did not know how to achieve something, they tried various ways of doing things until they found something that seemed to work. They then used that process in future, even though it might not be the best way possible.


Staff time was wasted every day on inefficient processes. In addition there was frustration, and errors crept in with no way of checking they had occurred. 

Spreadsheets were frequently used to provide the required information, instead of reports being produced directly from the system.


This picture applies to many of the companies I visit.

Training in the appropriate use of all software (including Word and Excel) should be provided to the staff who use it. It should be standard practice to provide formal training to new staff, and (especially where no training has been provided) existing staff should be given a refresher so they understand those features which might help them in their daily work.

Make sure an up-to-date Procedures Manual exists and is available for staff to read.

This way, you will benefit from the savings which come from good software being used efficiently.

I can help you develop procedures and train your staff. Use the Contact button above to get in touch.

Saturday, 17 May 2014

Succession Planning

I visited two companies where filing systems came under scrutiny. 

One company was relatively old-fashioned. Even though they had a modern joined-up computer system, most of their data was held in the traditional manner. Copies of internal memos and letters sent out were printed and filed. Letters coming in were kept in the same file. 

This was a fine system in the past, but then along came e-mail.

All e-mails in and out are now printed and filed. As a result, the traditional file has become full to bursting, and not easy to handle. 

There are solutions to this: for example they could move to a paperless office.  


The other company I visited was strikingly different. Their modern offices shrieked State-of-the-Art to all callers. There I met staff in a curious situation. Some years ago their computer system had to be changed, so they bought another system and converted their data across. 

Very old documents are still held in the historic paper files but new letters received are scanned and filed electronically along with copies of letters out.  E-mails are held in another location. 

However the letters and e-mails are not held within the computer system, but separately. The information they contain is not being used to update the system. As a result it has become less and less used. Staff have set up their own spreadsheets and alternative systems, or just depend on people’s memories, or on information held by other departments. 

Thus if a manager asks a question it can take hours of hard labour digging through folders, paper files, e-mails and spreadsheets to produce an answer, with no guarantee that it is right. (Or that asking the question again will produce the same answer.) 

All in all, it appears that the first company has the better system, because they at least hold all their information together. 


The key issue I raised with the second company was one of Succession. I believe they are neglecting their duty of care to the stakeholders of the company, and to their own successors. 

Each of us in business has a responsibility to ensure that our successors have access to our knowledge. We have a moral obligation to make it available to them – possibly, as in the first company, by providing a bulging paper file! 

What has happened in the second company, probably because of a lack of support staff, is that people are too busy to do all of their job. The less urgent elements get neglected, and no consideration is given to making sure that appropriate information is made available for those who will take over the job in future. 

I left the people I met preparing a business case for obtaining resources to get their system up-to-date. 

Maybe their successors won’t be in such a bad way after all.

To have a system audit carried out, or to get advice on a paperless office, please contact me by clicking on "Contact" above.

Saturday, 19 April 2014

What the Customer Actually Wanted

Most IT people know about this set of pictures and find them amusing as they are so true to life. Maybe there is a lesson for us all here. 

Often a customer has simple requirements, but they may have trouble explaining what they need. The result can be needless over-complication, and a system which ends up as unworkable. 

It's up to us, the IT professionals, to provide a better service. 


In my role as a consultant I provide both my listening, and the application of my years of familiarity with IT. 

I start by sitting down with my client and asking them about their business. I ask questions which my experience tells me will draw out those issues of most relevance. Often this intuitive approach allows the client to express not only the more obvious requirements, but also to clarify in their own mind the importance of other previously neglected issues.

This permits them to be explored more thoroughly. 

I don’t just talk to one person. I talk to staff at all levels, and if need be I will go back and talk to people again to ensure we have got to the heart of the matter. 

The result is that my client ends up with a better understanding of their requirements so that we can then move on to prioritise them. 

Not all will be top priority, so some can be left for the moment, or until the budget is available to address them. But they will have been identified, and this ensures they will not be forgotten. 


The next step is then to address the main items, and to identify how much it will cost to deal with them. This can be an extended process which I have already discussed in my article on the Selection of Package Software

The end result is that we do not get the scenario pictured above. The customer’s requirements are at the forefront of our discussions. If need be, all their requirements can be listed and prioritised, allowing us to develop a vision of how much it is worth spending to address them. 

So from a relatively early point in the project the client knows what they will have to spend, and what benefits they should get for their money. 

Better than a cartoon!

Saturday, 29 March 2014

Project Control

Working on a project recently, I found myself in one of those situations which a consultant hates.

The client had very clear time requirements. For various reasons the project had to be completed by a certain date.

But, right from the word go, the client's own managers seemed to forget that.


We started off very effectively. The project leader drew up a chart of actions with dates by when they needed to be done, and everyone agreed with what was proposed. We knew the project plan had a little bit of leeway, but we didn't want to use that up too soon.


Within a week we discovered that the data that had been promised wasn't available. Even when it did arrive it wasn't in the correct format. Extra resources brought in then could have minimised the effect on the project, but (despite warnings) no action was taken, presumably because someone knew there was some leeway, or believed we could all just work a bit harder later on.

But then something else went wrong, and the project slipped to the point where meeting the deadline began to look challenging. I held meetings with key project staff who agreed things were slipping, but client management had other priorities at that time and couldn't even meet up with us. Looking back I see now that no-one wanted to be the "bearer of bad news ", especially as it was still possible we would catch up.


Then it became clear that a relatively simple piece of work in one area was in fact more complex than anyone had realised.

So now we were in deep trouble!

How could we get the project back on schedule? 

Throw money at it? Accept the deadline was going to be missed?


It was agreed we would not do what had been agreed, and that we would "go live" with a system performing only 80% of what had been proposed, with the rest coming on-line in the following months.

As a consultant I hate this. The client is not happy. The developers are not happy. The users will not be happy. 

And the project leader feels control slipping away.

- o O o -

All projects have problems, and it is not possible to know in advance which ones will have most impact on the success or failure of the project. However there are a few guidelines which, if followed, will minimise risks.

To meet your project deadline:
  1. Be clear about what is to be delivered and the intended timescale. When in doubt agree to deliver less, or go for a phased implementation.
  2. Ensure everyone involved understands the time and budget constraints, and discuss in advance what the impact will be if the deadline is missed, and how any slippage will be handled.
  3. Prepare a detailed plan and make sure all involved have agreed that it is workable.
  4. Have an understanding of what resources are required for the project.
  5. Monitor progress carefully. When any slippage occurs, deal with it immediately. Discuss how it is to be addressed and the project brought back on schedule. Warn those who might be affected.**

** This last point is one I have seen ignored on many projects. When things go wrong, no-one wants to be the one who tells senior people the bad news. After all, they are very busy and believe you are coping. Everyone hopes the project can be brought back on to schedule. But if you don't start talking to them early enough, they can't help with resource or budget allocation when it is appropriate to do so. Asking later on for money or a time extension may not be appropriate.

Saturday, 15 March 2014

Why IT projects succeed (or fail)

Why do IT projects succeed or fail?

The Standish Group produces an annual report on the factors which affect whether IT projects succeed or fail. I've just been looking at the 2013 report, which contains some interesting reading. Here are a few quick points.

For example, "a large IT project has virtually no chance of coming in on time, on budget, and within scope".

In the case of small IT projects, "43% were challenged (late, over budget, or with less than the required features) while 18% failed (cancelled or never used)."

The good news is that nearly 40% succeeded!

They deem that the single most important area critical to project success rates is the competency of the executive sponsor, the person "who has the full weight and responsibility for the success or failure of the project squarely on his or her shoulders."

There are many other relevant points in this report, for example the importance of keeping projects small with clear borders. These factors are also relevant to other projects: see for example my article on Complexity Theory.

So what should we do about this?

How can we change the way we deal with IT projects so that we have a higher chance of success?

Firstly, expectations need to be handled appropriately. (See my article "What the Customer Actually Wanted".) The project scope needs to be clarified very early on, and a reasonable budget set.

Secondly, it is clear that the project sponsor needs to be given sufficient support to ensure that the project stays on track. That is where I come in. With my long experience of IT projects I know that the sponsor is typically very busy, without time for the necessary focus and often without anyone at their level to talk to about the project.

My strength is to be with them throughout the project, keeping them on target, adding weight to the project team, asking questions that others might prefer to avoid, ensuring that decisions are thought through fully and all issues are addressed.

Let me help you with your current or next project. Click on Contact above, and get in touch.

Saturday, 8 March 2014

Match processes to systems

Recently I've visited several companies to discuss their IT systems. 

One company had extremely impressive IT. They had adapted their systems to exactly match the company’s needs, using a wide range of the available features, giving everyone access to the files and reports they needed. The staff understood their software, and used it to achieve what they want. There was an enthusiasm about IT which I have found lacking elsewhere.

Some of the other companies I visited were quite different. Two had systems which should have been replaced years ago, but were still in place. They no longer met their users’ needs. The staff had battled on, but it was apparent that they were being driven insane by the shortcomings of their software. Such systems, which do not meet the business requirements, are a continual drain on all involved.

Now it is time for these companies to look for new systems (see “Selection of Package Software”).

However today I want to make another point.


My belief, which cannot be emphasised enough, is that a system installation is only truly successful when the users’ roles are redefined to make best use of the facilities provided by the new system.

When companies buy new software they often fail to use it appropriately because they neglect to change the way they operate. It is very tempting to continue in the old manner – slightly speeded up of course – with, perhaps, a few new reports. This might happen for various reasons such as a lack of management time, or possibly the users are comfortable with the old way of working.

But the real benefit to any organisation when new software becomes available (and this can include even Microsoft Office), is to look at the options provided by your new (or updated) software and be prepared to change how you operate. Amazing efficiencies can be achieved if you carefully examine the opportunities.

(For example, the ease with which files can now be shared among several users rather than each person having a different version is a simple process which has made many people better organised.)


So now take a good look at your software, even if you have had it for a while, and see if there are any features which you do not understand, or which might help to transform your area, department or company, and plan how best to make use of them.

Make sure all the users are trained in the software (even if only “Learning by Example”) and listen to their ideas about how you can make use of the new facilities.

Hopefully you will not end up like those companies I visited, with software which is completely inadequate.

And of course, examine your software regularly and be honest about whether it really meets your needs. If you want advice on this, just contact me.

Saturday, 22 February 2014

Don't use e-mail for bad news

Nowadays almost everyone uses e-mail to communicate speedily and concisely with others. However some lessons are becoming apparent. 


If you use e-mail to pass on bad news, the chances are that you will not be appropriate in your choice of wording. This could hurt the other person and damage your relationship. Worse, your e-mail might get passed to others, and could end up being made public, which you might not relish. 

If you need to give bad news, like 
  • “You are not getting the promotion/pay rise you expected”, 
  • “You’re fired”, or
  • “The boss hated your idea”, 
then go and see the other person and explain the situation to them face-to-face. 

This might make you feel uncomfortable, but not as uncomfortable as you would feel if you could never face the other person again. Also it may be that this is the only way they will really understand how the decision was reached, otherwise they could “bad-mouth” you and those around you for the rest of their lives. 


If you can’t see the person, then at least call them and give them an opportunity to respond. Even if it is bad news, the key benefit for the other person will be to feel truly listened to. It is not necessarily your job to explain all aspects of the bad news, but it is your job to listen. 


Someone once gave me bad news – via a text! Worse, they didn’t make sure I was there to respond. I would have appreciated the opportunity to be listened to, and I could have listened to them. And of course, if I had been able to listen to them, I might have really understood what had gone wrong, and been able to fix it then and there. 


Saturday, 8 February 2014

Have a Clear Business Strategy

I believe that in all companies, or even departments, there needs to be a clear strategy in place so that staff can understand management priorities and thus make sensible decisions on how to proceed even when their manager is not around. In simple words, Have a Clear Aim which everyone understands.

If the aims are not made clear to the staff then the result can be chaos, because staff can spend time disagreeing with each other over priorities, or go in different directions and not perform as a team.

Far too many managers are unclear about their own priorities. This holds staff back when the manager should be carrying out their true role, of helping their staff perform.

I asked one manager about the aims for his department over the next few years. He looked at me, dumbfounded. He apparently had no plans other than to deal with whatever was passed to him by others. A year later he was gone.


It is crucial to have clear, defined aims, because without them, quite simply, staff may not do what is best for the organisation.

As a start, I recommend getting all the staff together and discussing what you all do, allowing each person to comment on what they think might be appropriate aims. (Not too many in a group – for large numbers a different method is required.)

Come up with some simple agreed wording along the lines of “Provide a service to clients/the rest of the company that is quality, appreciated and profitable.”

The result of such a discussion is often a learning exercise where people’s thoughts – that have not been expressed in the past – are articulated for others to hear. This can sometimes be quite painful, especially for the manager! Such a process may well need a facilitator to ensure that all those involved get a chance to talk and be heard rather than criticised.

But out of this comes the start of a team where they begin to realise that there is in fact a clear purpose, and each of them has a contribution to make towards achieving it.


Often junior staff will get quite enthused as they start to see the part they play. Just because they are junior does not mean they are unimportant – the receptionist, for example, is crucial, setting a professional and friendly example to all visitors.

Team building is not some mythical management theory. It is an approach to making a group of people perform which has been proven to be more efficient than having each person act separately. But there can only be a team if someone makes them into a team. This is done by leading them, and with clear aims they will know where they are being led, and why.

If there is no clear aim then there will always be conflict over priorities and allocation of resources, which can lead to jealousy and in-fighting rather than performing.


Having a clear strategy suddenly means that junior members of staff can talk to each other and make informed decisions based on what they know is best for the company. Managers need only get involved in more complex issues, and the result is that you too are freed up to perform better.

Try it and see.

And here is an example of what happens when there is a lack of a clear vision:

One company had a small team of specialists who were always busy. They couldn’t be interrupted because they had so much to do and tight deadlines to meet. 

So I asked them (one by one) to explain what they were doing. 

It became clear that each of them was rushing around typing information (for example) from one spreadsheet into another. Or retyping last month’s information before adding this month’s changes at the end. Or duplicating information that could have been held in a central place. 

I spoke to their manager, who had been there for two years, and he was amazed. He had no idea what his staff were doing; he had not spoken to them about their priorities; they had received no training: what they were doing was a mystery to him. 


Why was he not managing his staff? Well, partly because he also was rushing around, fire fighting, answering other people’s questions... 

What was needed was a Plan, a clear strategy for the department, which they all understood and worked towards. An agreed list of priorities, with appropriate training. 

And then it all needs to be monitored by the manager.

Contact me (click on Contact, above) to help develop a plan for your company or department.

Saturday, 18 January 2014

System Implementation 3

In part 1 and part 2 I covered both the preparations for and the major activities of an implementation project. This article indicates the final items you need to be aware of, as well as a sample implementation plan.
Referring back to a point I made earlier, one of the main reasons that new systems do not perform as desired is that the staff continue to work in the old way, possibly keeping their old software, spreadsheets or even manual systems going. 

New systems need new procedures. These need to be thought through carefully, and checked thoroughly after a few months. 

Installation of a new system always means a strain as old systems are brought to an end and new ones are bedded down. Quite often there is a period of Parallel Running, where old and new systems are kept going until everyone is happy with the results. This also gives you time to check that the new procedures are adequate.
As part of your planning you should have identified a stage in your project where can assess whether you are happy with the new system, in other words decide whether you accept it (or, awful thought, realise that it is not acceptable). Two questions you should have asked at the beginning are:
  • What features and functions are required to make the system “Fit for Purpose”? 
  • What else, such as system availability and usability, is required to make it “Fit for Use”? 
It is important to carry out this process formally, even where the work is being done more casually (by a friend, a colleague, or possibly even yourself). Otherwise the system is never 'finished', it is always under development. 

[One company had a system the Managing Director developed when he was first hired. He was still working on it years later.] 

With an outside supplier “acceptance” is a key step as you move towards live running. It may also affect any final payment.
After acceptance, the next (and possibly most vital) stage is to review the project. Go over what you did, review your initial plan and objectives, identify what went wrong, but also what went right. 


The above approach can help, but even in the best of projects disasters happen. In my experience the most common failings are: 
  • The plan is not believed or supported by those involved, or (in extreme cases) no plan is ever made. This makes the whole project impossible. 
  • The resources allocated are inadequate, or they are never made available even when promised. 
  • For technical reasons (beyond your understanding) the system never works. 
  • Staff are not given appropriate training, or they forget what they learnt, or they cannot cope with both the new system and their old job. Often their new role is never clearly explained. 
  • The data in the system is never trusted and so the old systems which the new one was meant to replace are kept on, using up extra resources.


Here is a sample implementation plan 
  1. Draw up and agree the Project Plan. Carry out an initial identification of the resources required, the timescales and the costs involved. In particular be aware when payments will need to be made. 
  2. Review the resources required with appropriate senior management. Get agreement to their provision, and identify how they will be made available. Confirm any implementation constraints, such as a need to avoid changes at Year End. 
  3. Identify the data required in the new system. 
  4. Decide who will access the new system or its data, and identify the training they will require. 
  5. Draft a map of the new business processes. 
  6. Review all technical issues, including data security and backup, and ensure responsibility for these is delegated appropriately. 
  7. Identify the required interfaces with other systems and ensure they are specified. Identify and agree the reports to be provided. 
  8. Carry out input or conversion of the required data. 
  9. Validate the data – either completely, or by running sample extracts. 
  10. Ensure all the technical issues have been handled and the interfaces have been provided. Test them well before they are required. 
  11. Design user procedures for the new processes and train all staff at an appropriate time before they need to use the new system. 
  12. Check the reports have been provided and validate them. 
  13. Parallel run the system where appropriate. 
  14. Check all the support documentation is complete and the agreed user support service is in place. 
  15. Carry out a formal acceptance procedure.

Good luck!

© Copyright 2013, 2014 Cameron Somerville Web Designers Toolkit Websites