System Implementation 2

In part 1 I covered the key activities to be completed before you start an implementation project.

Now we start!

7. MONITOR PROGRESS REGULARLY

Once you have started implementation it is vital that you have regular, minuted, progress meetings (usually at least monthly) with a formal agenda. (See my article on meetings for more detail.)

At a minimum you should cover the following items: 

• Work that should have been done since the last meeting 
• Work actually done since the last meeting (which will usually be quite different) 
• The effect this has on the schedule and budget (so you become aware of delays and over-runs as soon as possible) 
• What needs to be done about this? (Usually something needs re-scheduled, or additional resources are required.) 
• Who should be told (i.e. who does it affect)? 
• Work to be done by the next meeting 

The questions in bold must not be neglected. A lesson that all project managers learn only too painfully is that any slippage must be identified as early as possible, and appropriate action taken quickly. 

8. MAKE SURE THE SYSTEM IS PHYSICALLY INSTALLED AND WORKS

This area deserves a separate section of its own. Ensure the system is physically installed and, no matter how many other people are involved, make sure you actually see it running in some kind of test mode. Once installed, check that any technical issues have been resolved, and - crucially - get signatures from all the technical people involved that they are happy with the situation – or identify why they are not.

9. HAVE A COMPREHENSIVE TRAINING PLAN

A major part of the implementation plan must cover training. This should be discussed and agreed at an early stage. Be clear about who is to be trained, how long the training will take and when it should be provided. People who receive training must know beforehand why are being trained, and they must have time available immediately after the training when they can apply what they have learned to real project work.

One of the worst shortcomings about a system is often the lack of adequate training. Users typically feel that the training they received was inappropriate or not put in context. This often happens because the supplier does not understand your own situation. Make sure they are adequately briefed, and give training specific to the needs of those they are training.

10. ENSURE THE CORRECT DATA HAS BEEN INPUT

The data required for the valid operation of the new system must be available somewhere in people’s heads, on paper, or elsewhere. There needs to be a process which ensures that the appropriate data gets into your new system, within a reasonable timescale. Planning for this can be the largest part of the implementation. 

Nowadays much of the data you require may be converted from older systems. But even then it needs to be thoroughly validated (see the next section). 

Also, as soon as data is in the new system it needs to be kept up-to-date, and of course old systems cannot just be abandoned. They must be kept going until the new system is accepted, and then they should no longer be used except (possibly) for historical enquiries.

11. ENSURE YOUR NEW DATA IS VALID

Any data put into a new system has to be validated. This can be done in several ways. It can be checked by a senior person; accounting-style data can be parallel run (see below); or reports can be replicated. 

Whatever happens, it is crucial that the data really is checked, and its validation signed off. This process, like most of the others, should involve all those affected by the project, so no-one can feel their opinion was ignored. Once data has been validated, it should be verified once or twice over the succeeding months. 

Systems often fail because users do not believe the data is valid. 

[Everyone knows that "Old Bill" has the correct information locked in his head, or the only way to check how much material there really is in the stores is to go and look...] 

Concluded in part 3

System Implementation 1

The process of implementing a new system can be extremely stressful for all those involved. There might be a great atmosphere at project initiation, but after a few setbacks the initial enthusiasm can fade away. As a result of this, some systems never get properly implemented. What a terrible waste of resources! 

It is tough, getting a new system up and running, but I believe that following a careful plan (as outlined here) can ensure you achieve the intended results. 

This first article starts with the pre-project planning.

1. KNOW WHAT IS EXPECTED FROM THE SYSTEM

Even before you have purchased your new system (if it is a package), or specified your requirements to the developers (in the case of a bespoke system), decide exactly which features you want to implement, and in what sequence. 

In the case of a large system you might want to carry out a phased implementation. In this case, do ensure that this is discussed fully with all those affected, so there are no surprises. 

The key to successful implementation is good communication!

2. MAKE SURE THAT THOSE INVOLVED KNOW WHAT IS INTENDED

You must ensure that all those involved understand the intended timescale, what is expected of them, and how they will benefit. After all, if they don’t benefit, why should they help? Clients often ask me to look at “failed” systems: ones which have perhaps only achieved 10% of the benefits expected when the system was purchased. Most often, the issues that need to be addressed are “political” – the involved people are just not committed to the system working, usually because they see no benefit in it. 

It is crucial that your project has the backing of the appropriate senior managers and that they really understand what resources will be required. New systems soak up resources, often for several months (if not years). Like a new by-pass they can take a long time to get going, with a lot of disruption to the lives of those involved, but once they are fully functional everyone can benefit.

3. PREPARE A DETAILED PLAN AND ENSURE OTHERS “BUY-IN” TO YOUR PLAN

The initial planning sessions are vital. Draw up a detailed implementation plan and share it with everyone who might be affected. Actively seek opinions: ask if new problems might arise as side effects of the plan. Be open to the responses and ensure you incorporate any recommendations. This process means that later on, when you need support, no-one is unclear about the issues, and you don’t have people waiting to sabotage you. 

[I know of several companies where package software was bought against the wishes of some staff, where the opponents did everything they could to hinder its implementation.]

4. UNDERSTAND CLEARLY THE DATA AND THE RESOURCES REQUIRED

Be clear about the information required for the reports the system must produce. Also look at any systems which have to be linked in and work out the data which they will need. From this you can decide the data which has to be input into the new system. Realise that it must be kept up-to-date and decide exactly whose responsibility this will be. (This is covered later.) 

Decide who is going to collect (or convert) and then verify your data. Guesstimate how long this will take, by looking at a sample set of records and working out how long it will take to (a) find the data and (b) input it for the full set of records. 

[One company I spoke to were still collecting data for a system they had purchased three years earlier.] 

Doing such a detailed assessment at an early stage will allow the development of a realistic view of the total time and resources required.

5. HANDLE THE TECHNICAL ISSUES

Take time to find out what technical hoops have to be gone through to get the system working. And make sure that the appropriate IT people are involved at all stages of the project, from selection right through to final implementation.

6. IDENTIFY THE PROJECT END POINT – AND THE PROJECT LEADER

Agree how to identify (at the end of implementation) whether the finished system actually meets your organisation’s needs. It needs to be “Fit for Purpose” (in other words, do what you decided it should in 1. above) and also “Fit for Use” (in other words, do it in a way that is acceptable to the users). 

Also, decide who is going to manage the project internally. This is a key position, and should be a person who is not going to be pulled away on other projects, or be swamped by work on this one. Ensure the project manager is committed and has adequate clout to get things done. The software supplier should also appoint a project manager. 

Now you are ready to start! 

To be continued.

Learning by Example

According to Google, there are around 32,000 web pages on “Sitting by Nellie”.

This is the approach to teaching someone a new task, where they sit down with a more experienced person and watch how the task is done. We have all done this at some time in our lives – perhaps some of you learnt to drive this way? – and this is how many of us learnt to cook.

I am sure this can be useful in companies, for example when a new member of staff joins, as long as the weaknesses of the approach are recognised and handled.

The worst case, which I have seen only too often, is where the company has a complex computer system which is understood by only one member of staff. For various reasons this person suddenly decides (or is told) to leave, and a new person is elected to take over and become the expert.

HALF A DAY HANDOVER

The appointee sits down with the true expert for half a day or at most a day, which is all the time that can be spared for the handover.

The experienced person then leaves, before the new person fully understands the complexity of their role or even all the tasks they must do.

The result is chaos. Not all jobs are done, not all are understood, not all are completed. Management fail to benefit from information they got in the past. Crucial steps are missed.

There is, in truth, no way that a manager can expect the new person to be as competent as the “expert” after a few hours! How many hours driving practice did you need?

HOW LONG DOES IT TAKE TO BECOME AN EXPERT?

Unfortunately this is what I have seen happen in several companies. In one instance an experienced member of staff was made redundant and it took six months for the department to catch up on the resulting loss of knowledge.

In another case, a crucial process was missed out of the training and only spotted eight months later! (Oh, by the way Joan, where is the month-end report we used to get?)

Because the manager does not fully understand the job they underestimate what is required – and may not listen when they are told otherwise.

Sitting by Nellie can be a great way of cheaply and effectively training new staff if an experienced person is able to monitor the on-going quality of the work being done. Or as a way of covering holidays, given that the expert will come back after their break and can fill in any gaps. It is then in their own interest to ensure that the training is done to an acceptable quality.

DOCUMENT YOUR PROCEDURES FULLY

In fact it is crucial in a business not to allow one person to become so expert that they cannot be replaced. All procedures should be fully documented, and then checked by someone else actually doing the job (for example when the expert is on holiday) so the gaps can be identified.

(In one of my customers a senior manager was the only person who could carry out the weekly run when the secretary was on holiday... Not good practice!)

So use Sitting by Nellie as good economics, but make sure Nellie sticks around to check up on how the training went!

We are responsible for the quality of our systems

WHO IS RESPONSIBLE?

Many people have problems with the computer systems they use, but they do nothing about them. They feel that someone else is responsible for dealing with their problems.

However I believe that we are each responsible for the quality of the systems we use.

Who else might be responsible?

IT staff are often far away, and very busy, except to deal with emergencies. 

Telephone support staff often cannot see your priorities: the good ones handle your immediate problems, but they are usually too busy to look at the bigger picture.

Line managers are often reluctant to get involved.

So, if your systems are not good, you have to do something about it. If you are not ok with your system, how can you be expected to do your job, or expect your own staff to perform? 

UNDERSTAND YOUR SYSTEM

One key aspect about being responsible for your system is understanding it. How much training have you had? Is it adequate? How much time did you spend after your training making sure you understood the system?

Most users I meet are not fully aware of all the benefits offered by their systems. Often there is a fear issue. I regularly take users through aspects of their systems so that they understand what is actually possible with it. 

But it is obviously in their long-term interests to keep abreast of what can be done with their software. Why have they not looked? (a) Because they are busy, and (b) Because they were scared they might break something! 

DON’T BE SCARED

If I had a dollar for every person who has told me they know nothing about systems I would be very rich! Yet these people can often fascinate me with their expertise in other areas of their personal or business life.

Many people now accept that it is possible to understand how cars operate. Why not computers? For things to change, you have to take responsibility.

START SIMPLE

Start by getting a notebook (yes, paper) and keeping track of issues that affect you. 

Is your machine fast at one time and slow at another? Keep a note. You are the person who sees the differences, and you can help in problem diagnosis.

If someone installs something on your PC, write down what they did, and when it happened. Do the same for downloads and upgrades where you click to accept the installation. Know what you’ve done! Then if things don’t go well over the next few days you can (hopefully) tie it back to a cause.

If you do get new software, make sure you get appropriate training. If you don’t, then speak up. Tell your manager. Or tell his manager. How can you do your job properly without adequate training? 

Remember WE ARE EACH RESPONSIBLE FOR THE QUALITY OF THE SYSTEMS WE USE.

Selection of Package Software – Part 2

In my previous article (Selection of Package Software - Part 1) I explained the importance of preparing a detailed Statement of Requirements. Here is the conclusion to this process.

---

6. DEVELOP A FORMAL TENDER DOCUMENT

Depending on the customer’s size, and how formal an approach they have to purchasing, we then use the Statement of Requirements as the basis for either a full Invitation to Tender (ITT) or a simpler Request for Information (RfI). 

This is sent out to an agreed list of suppliers with a clear timetable for the receipt of replies. Such a document ensures that suppliers have to formally assess the client’s requirements, and (if worded appropriately) can create a contractual obligation on them to meet their claims. 

The formal document should be sent to only a few suppliers (say, a maximum of six, but not less than three) as there is considerable effort involved in liaising with them, answering their questions, and reviewing their responses.

7. REVIEW THE RESPONSES AND SHORTLIST SUPPLIERS

When the responses are received I carry out a detailed review, identifying for each supplier which of the key features they can supply, the overall charge for their offering (often using the total costs over five years as a guide) and the specific resources required for implementation. I also tackle any areas where there may be doubt, to make sure they really can meet the client’s needs. 

The results of this review are discussed thoroughly with the client so that we end up with a preferred shortlist of suppliers for further consideration.

8. DEMONSTRATIONS

Final demonstrations are then arranged. Here I would we ideally recommend a maximum of three to four sessions, although getting clients to agree to this can be tough! (They either want too few or far too many.) 

There is quite an art to making sure the demonstrations are not merely flashy occasions for the salesman to show off the features of his software. The process must cover the client’s requirements, and prove that the system can meet them. Some suppliers might ask for sample business scenarios, or even test data they can use. Others might not, and this helps in identifying who the client might prefer to do business with. 

It is crucial for key staff to attend the demonstrations, and for a review to take place immediately afterwards. We recommend that a checksheet is available so staff can identify – in a structured fashion – the good and bad points about each system. 

And don’t have too many demos in one day! One of my clients had five in two days and as a result the company’s board of directors was completely shattered at the end. I am glad they did not have any crises to deal with.

9. FINAL SELECTION

Once the demonstrations have taken place everyone should formally review all of the shortlisted systems and decide the one or possibly two (but not three) who merit final consideration. 

I obtain detailed references by talking to a random selection of users to find out what it is really like using each system, and what the supplier is like: Do they provide the level of support which they claim? Is the system really as easy to use as they say? 

Depending on the references it may be that one supplier is clearly head and shoulders above the others. Sometimes matters are not as clear cut, in which case additional demonstrations may be necessary. (A final demonstration of the preferred system might also be necessary just to show that the system really can do all that was promised.) 

I also like to arrange visits to representative users who can spend time (without the supplier being present) talking directly to the client about how they work with the software. Several clients have said this is one of the most useful parts of the selection process.

10. CONTRACT NEGOTIATION

We then agree who should be the final supplier and complete contract and price negotiations with them. 

(I strongly recommend continually making it clear that you have other options available, which gives a better negotiating stance.) 

The outcome of this process is a system where it is clear (a) why it was purchased, (b) what alternatives were considered and rejected, and (c) what the implementation schedule is. 

The result is more confident management and often a more committed team.

Selection of Package Software – Part 1

Over the past 30 years I have developed a structured approach to the selection of package software, which I find makes for a consistently successful process, ensuring the client obtains an appropriate system.

Typically, as a result of this, we are able to weed out suppliers who look superficially attractive but whose software is not right for the business. The client often starts with a limited view of the marketplace which can be addressed using the approach outlined below.

This process has a large number of key stages, none of which should be skipped. 

I hope you find it useful.

---

1. PREPARE AND AGREE A DETAILED LIST OF REQUIREMENTS

My approach is to firstly talk to all those involved about how they currently operate, and what their needs might be for the future. I also meet senior managers and help them to review their business strategy. From these discussions a detailed list of requirements is produced. 

It is useful to note that it is particularly useful to engage with staff at all levels. Doing so ensures that those involved are clear both about why the software is being obtained, and about the overall priorities. It is crucial to get the users committed early on to a project which can disrupt their work lives for several years. 

It is also worth having a few initial demonstrations if some staff (or managers) are not familiar with the kind of features available in modern systems. This gives them a chance to discuss how the organisation or its processes might be restructured with a new system.

One of my clients – a large bank – really benefited from this. I brought in a demonstration disk of new software and showed it to various members of staff on a laptop. They all got extremely excited about the new possibilities they could see, and as a result both managers and staff became more committed to getting a new system. 

Instead of feeling I was pushing them, it became a matter of them pushing me.

2. REVIEW POSSIBLE SUPPLIERS

In parallel with the consultation process I prepare a list of systems to be considered based on knowledge of the suppliers available and their relevance to the client. At this stage I usually talk to a few users of each system to see how satisfied they are with the overall service they receive.

3. ESTABLISH ROUGH COSTINGS AND TIMESCALES

It is also important early on to talk to suppliers about the client’s approximate requirements and their size. This helps to identify rough overall costs before we have gone too far. Like the conversations with users, it also clarifies which of the systems will be appropriate for later consideration. Some will get excluded on the basis of price, others (for example) because their culture clashes with that of the customer – an aspect which I often feel is neglected. 

In talking to suppliers I also get a better idea of the overall timescale for the project given the likely resources which may be available.

4. PREPARE AN INITIAL IMPLEMENTATION PLAN

With the information already available I begin the preparation of a detailed System Implementation Plan, building up realistic timescales and estimates of the resources which will actually be required. Starting at this early stage encourages everyone (especially management) to have an understanding of the scope and implications of the project from an early point onwards.

5. THOROUGHLY REVIEW THE REQUIREMENTS

In consultation with client staff the requirements list is then reviewed and prioritised to finalise the features which are to be presented to potential suppliers. This becomes the basis of a formal Statement of Requirements. As part of this process it is helpful to identify which features are Essential, which would be Desirable, and which would be nice to have if they were free. This prevents a system being selected just because the Chairman likes one particular feature. 

In the later stages the requirements are finalised and then sent out to shortlisted suppliers, their responses are reviewed and final demonstrations take place. 

Continued in Selection of Package Software - Part 2.

Complexity Theory and Project Planning

We all do a lot of planning. However, we also know that sometimes the desired results are not achieved, despite having excellent plans.

How can we tackle this?

Recently I have been looking at an approach called “Complexity Theory”, and its impact on business in general, and on projects in particular.

COMPLEXITY THEORY
You and I might consider that a major task of management is to decide where an organisation is going, and to take decisions designed to get it there.

However, Complexity Theory says that in human situations (such as the average business) the future is inherently unknowable, and so the approach of assuming one’s plans will work can be a dangerous delusion. (My italics!)

Of course we should continue to plan, but we should not assume that what we plan will happen. (This is closely related to Murphy’s Law.)

SUMMARY
Complexity Theory says that we are never in total control (for example of a computer project). Mistakes will always creep in, and we have to be ready to cope with whatever occurs.

---

EXAMPLE
While supplying services to a large organisation I realised that they were trying to exert strong control over all the suppliers, but they had not considered their own staff.

One person in particular become overworked and consistently missed deadlines.The eventual result was a major slippage in the project timescale despite the overall control the company was trying to exert.

---

MY APPROACH
I believe the way forward with a project is first of all to clearly identify the desired outcomes. Then (having prepared a draft plan) it is important to carefully monitor what actually happens and to be prepared to take appropriate action immediately the project drifts off course. (A little like dealing with a supertanker.)

If outcomes are not being achieved, determine why.

Complexity theory explains that there might for example be a conflict between management's expressed desires and the true desires of management or staff. If people – who are already busy – are asked to take on additional work, they might decide their normal daily work is more important and let other tasks drift.

Once we truly understand what is happening and see why outcomes are not being achieved, we can take a fresh look at the problem.

In many projects, a slippage just leads to exhortations to catch up, without tackling the root causes of the slippage.

---

In the example above, we should have reviewed the project objectives after the first slip occurred, and openly discussed why there had been the slippage. We could then have reviewed people’s workloads.

---

HELP TO MANAGEMENT
The role of an external consultant is frequently to help management see why there are mismatches between what they want to achieve and what is actually happening. This examination of such areas can initially be challenging, but eventually extremely rewarding!

For further reading on Complexity Theory see: http://necsi.edu/guide/ for a start, or http://human-nature.com/science-as-culture/rosenhead.html.

Technorati 54MDXUNVCKMD

Meetings – how to have good ones!

Recently a client complained that all their meetings started late, took longer than expected and did not achieve what was intended. This made me realise that most of us are not taught how to hold a meeting – if we are lucky we pick up some relevant skills earlier rather than later in life.

WHY DO PEOPLE LIKE MEETINGS?
Many people like meetings. It gets them away from their desk, and they have a chance to talk to people they might not otherwise spend time with. And since meetings frequently start late, there is time to chat about holidays, football or colleagues. Anything but work!

Here are a few key points to ensure you have good meetings. (And these points apply to all who attend – not just to the person organising the meeting.)

1. Agree a mutually convenient time for the meeting
2. Agree the agenda and the appropriate attendees
3. Start on time
4. Minute agreed actions– with timescales and who is responsible
5. Review the previous minutes
6. Don’t ramble on – listen, then leave

---

1. AGREE A MUTUALLY CONVENIENT TIME FOR THE MEETING

Make sure the meeting takes place at a time that suits all involved. If you are arranging the meeting, emphasise to the others that you are arranging it to suit them and they are expected to be there on time.

2. AGREE THE AGENDA AND ATTENDEES

The agenda should be clear and concise – this helps to decide who should attend, and how long the meeting should take. As a minimum it should contain Minutes of the last meeting, Matters arising, Key items to be handled or reviewed, and Date of next meeting.

The attendees should include only those to whom the agenda is relevant. You may want to tell other people the meeting is taking place, but don’t invite them if they don’t need to be there. You can always agree to send them a copy of the minutes. However, if this causes any issues then make sure you handle them face-to-face, not by e-mail! 

3. START ON TIME!

How many people regularly spend 5 or 10 minutes sitting around chatting while they wait for meetings to start?

In order to start on time, handle this at a meeting which doesn’t start on time.

Before it gets going, when all the latecomers have arrived (and are still feeling a little guilty, or at least aware of the issue) say to everyone that you would like to ensure that future meetings start on time.

Ask them how they want to handle it. Should you take the chair if the chairman has not arrived? Should you handle minor agenda items until the key people arrive? No-one really feels it’s ok to waste others’ time, but most people will not speak out. If you do, you will find that your approach gets a lot of support.

And subsequently, when someone is late and finds the meeting has already started, you will find that they are better at turning up on time in future.

4. MANAGE THE MINUTES

All meetings need a chairperson and someone (briefed in advance) to take minutes. (And make sure the minutes are sent out right after the meeting. One of my clients – when not persuaded otherwise – regularly sent the minutes out just before the next meeting. How was anyone going to remember what they were supposed to do?)

Minutes themselves are important. While not usually designed to record the discussion in full, they should cover the key items and record decisions taken.

Any actions to be carried out should be clearly allocated, with a timescale. In a perfect world actions should be allocated to only one person – having more than one name against an action ends up meaning that no-one is responsible. If more than one name is needed, clearly indicate the key person in charge.

If the person who should do the work is not at the meeting, make sure someone is delegated to inform them and get their agreement. (This itself becomes an action.)

5. REVIEW THE MINUTES

Very early in each meeting, review the actions from the last meeting. If an action has not been carried out, decide why, whether it still needs to be done, by when, and what impact not doing it has had. (This helps people to understand the effect on the organisation or project if they don’t keep their agreements.)

Projects run late by people consistently not taking agreed action, and this costs companies millions.

Note – if an action has not been done, is it truly necessary? Is it being handled by the correct person?

6. FINISH APPROPRIATELY

During the meeting, try to ensure that you and your colleagues only talk about matters on the agenda, and do not ramble on. Also, do not use the meeting as an excuse to avoid going back to your desk. The number of people I know who moan about having too much work and then sit chatting long after the formal part of a meeting is over...! 

At the end, get up, thank the others, and leave.

And let me know how useful you find these points.

Plan before you purchase

Organisations purchase systems for a variety of purposes, usually to make a difference to the way they operate. They might want to save money, generate efficiencies of scale or provide better management information. 

If you intend installing a new system, the best way of ensuring you have a successful outcome is to be clear exactly why you want to change, and to plan appropriately.

LACK OF A CLEAR VISION

Many managers purchase a new system simply because the old one is a bit long in the tooth, but they lack a clear vision about where they are going with the new one. The result is often that the new software barely performs better than the old, and after a few years it, too, is a bit long in the tooth and needs replacing. 

Before a system is selected, the organisation should have a clear idea as to why they are buying it. They should understand the benefits it is intended the new system should bring, thus justifying its cost.

---

TIME FOR A CHANGE

Some time ago I met a manager who was about to spend a large sum of money on a new system. He felt it was time for a change, and he had been given a budget to spend. Various colleagues from IT and Purchasing were assisting him, so the technical process of buying the system could not be faulted. 

BUT HE HAD NO VISION ABOUT WHAT WAS INTENDED FOR THE NEW SOFTWARE! 

Yes, there were lots of new features he might implement, but he had not costed the resources required to set them up. The danger I saw was that he would commit his organisation to a large expense, with no-one having a clear view as to why this money was being spent.

---

AUDIT

Another customer, who bought an excellent system a few years ago, called me in to carry out an audit of their installation. It was apparent that the company was operating in much the same way as it had before they installed the new software. Adequate management reports were being produced, but few of the new facilities available with the new system had been implemented. 

The system had merely replaced its predecessor –it was faster and easier to use – but a wide range of benefits had been completely ignored. Managers were so busy with their day job that they had forgotten why they had purchased the new system. My main recommendation to this customer was to start using their system differently, getting true benefits from it including reduced costs and better management information.

PLAN YOUR PROJECT
If you are going to spend a significant amount of money then start with a clear list of benefits which you propose to get from the project. Prepare a plan so that the new features are implemented within an appropriate timescale. 

Then ensure that the project is managed in such a way that the anticipated benefits are achieved. And review the project at the end to make sure you actually did what you intended.

Manage your staff so they aim for excellence

I believe that Successful Management, which is the key to success in business, can be achieved by the following:

1. Have clear aims.
2. Ensure the aims are communicated openly to your staff – and make sure you listen to their responses.
3. Monitor their progress.
4. Give and receive feedback.
5. Be honest in your dealings with all around you.

THE STEPS

Step 1, Have Clear Aims, may not be easy at first.  Often I have found that the best approach is to involve all the staff in a group discussion where each person speaks about what they believe the aims should be (guided by the manager), with the agreed aims being defined at the end of the meeting. 

Using the business strategy as a guide helps here.

This leads to Step 2, Communicate the Aims Openly, which means making sure the staff know what you expect them to achieve.  But please ensure you listen to and address their responses.  I have worked with too many managers who think it is their role to speak to their staff without listening.  (If a member of staff says a target date is not going to be made, listen to their explanation why and then go home and think about it before responding.  Often they will know better than you what is really going on.)

Don’t be afraid of setting a challenge, but the key here is Step 3, Monitor Progress.  Depending on what it is you actually do, targets may need to be monitored daily, weekly or monthly.  Share the good and bad news – it is wonderful to discover the commitment staff have to achieving the impossible.

However Step 4 Give and Receive Feedback should be applied much more often.  Make sure you meet at least some of your staff every day.  Exchange a casual word with them.  (Don’t spend ten minutes discussing the cricket score).  Say “Everything ok?” or “How are things going?”.  At this point you don’t need to do other than listen.

Throughout all this apply Step 5.  Be honest.  Why be honest?  Well, the simplest reason is that if you are not honest you can guarantee that you will eventually be found out by your staff.  I've worked with managers who made a habit of telling different stories to different members of staff.  This simply created an atmosphere of mistrust.  If they believe you can be trusted then they themselves will act in a trustworthy manner.

For example, before claiming unjustified expenses or taking long lunches, ask yourself what would be reasonable for your staff.  How would you react if you found they were doing this?

If you pay one staff member more than another, you can guarantee that they will find out.  How will they react?  Are you being fair?

AIM FOR EXCELLENCE

I have found that by following the above short set of steps, by engaging with your staff as adults, they begin to act differently.

They relish a challenge when they understand why it has been set, or have been involved in creating the aim.

If they can talk to you about how they are feeling then they don’t waste time complaining to other members of staff.  If you give them appropriate, honest, feedback then they will perform well in carrying out their job.

If you talk about Excellence, they will understand what you mean, and Excellent Performance will result.

Good IT Systems Make a Difference!

Good IT systems can make a remarkable difference both to company performance, and also to the way staff feel about their work.  Unfortunately, a recent survey by KPMG showed only 37% of users rated their systems as “good”.  What about you?  

And what do your staff think?

I have met many people who are unhappy with their systems.  Often they are also unhappy with their work.  This is not a coincidence! I have regularly seen staff – who felt that their system did not meet their needs – spending time talking about their problems, and as a result spending less time working. 

But there are people who are keen on their systems.  They are proud of what they can achieve, and they understand they are using their software in the best way possible.

GOOD SYSTEMS

Typically, a good IT system will allow users to input crucial data easily, without duplication or having to move between a vast number of screens.  Also, reports will be readily available in the required format.

POOR SYSTEMS

As far too many of us know, a lot of systems do not produce good management information.  It can take forever to get the right information out.  In some cases, 2 or 3 separate reports may need to be run off and data extracted into spreadsheets in order to achieve the required format.  

One company described this as their “automated approach to reporting”. (Another survey showed 58% of companies were not receiving adequate information from their finance system.)

ENTHUSIASTIC USER

One of my clients explained why she was so keen on her software.  She has a well-known software package which can sometimes be challenging.

But she has taken the time to learn what is possible with the system. 

She looked at her job, and then looked at the software to see the best way to carry out each task, given the software's limitations and features.  Where necessary she called the helpline to ascertain exactly what needed to be done. 

The result is an enthusiastic user.  She understands that the software has flaws, but feels she can work her way round most of these, and as a result her daily job is much easier.

EXCELLENT SYSTEM

Another excellent result has been achieved at one of the UK’s leading tourist attractions.  The management proudly demonstrated their new management information system to me.  This presented each manager with the key information they needed each day to do their job: indicators such as number of visitors the previous day, average spend per visitor, restaurant and shop turnover etc. 

From my point of view it was a delight to see people using IT in such a way, and to perceive that they were clear why they were collecting all this information.  Knowledge is power, and with this information – literally at their fingertips – they could quickly decide whether, for example, to make special offers, to advertise locally or nationally, or to change the prices in their shops.

So good IT systems are obviously well worthwhile.  The difference in productivity and staff satisfaction is worth addressing. 

Let me help improve your systems.  Click on Contact above and get in touch.