Saturday, 31 August 2013

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.

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.
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.
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.
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.
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.

Saturday, 17 August 2013

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.

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.)

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.

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.

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.

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: for a start, or

Technorati 54MDXUNVCKMD
© Copyright 2013, 2014 Cameron Somerville Web Designers Toolkit Websites