Thinking of buying a new system? This post could save you money

It’s tempting to think that buying a new system, whether it’s a top tier ERP product or something more modest will solve all of the problems that plague your company.

Indeed it’s a view that is heartily endorsed and promoted by a legion of sales consultants, industry ‘experts’ and specialist media.

The latest iteration of a new system will come with glossy brochure telling of a wonderful new world where the grass is green and it is sunny all day. Where transactions are rapidly and accurately posted and management accounts simply fly out with no human interaction at all.

The reality though is somewhat different, especially in the area of ERP. In fact research has shown that in most implementations clients never actually gain all of the advantages that they expected and that it may cost more and take longer than first envisaged.

There are a number of reasons for that but to take it right back to the start, the first question you need to answer is whether you need a new system at all.

I’d argue that many of the problems solved by the implementation of a new system could be solved by looking at the processes rather than the software and that smart managers would actually be better off running a ‘ghost’ implementation rather than spending a shed load of cash on something new and shiny.

Now don’t get me wrong, if you want to buy a new system then I’ll be happy to help you implement it. Maybe you’ve got a lot of cash you need to get rid of or you’re pumping a gazillion transactions into Sage line 50 each day. In which case buy, and buy soon.

But actually a lot of the problems that are often ascribed to ‘the system’ are actually a product of behavioral issues or simply down to the fact that the business has moved on since it implemented its current software.

One issue frequently cited as a reason to buy new is the difficulty in getting information out of the black box. It’s a problem that many businesses face and certainly a real factor in the decision to buy.

However often this can be down to a need to reorganise the processes around the business. The oft quoted ‘garbage in garbage out’ is a good example. If your inputs aren’t done to the correct standard or with the required level of detail then the system is irrelevant; you just won’t get the information you need.

Similarly if your chart of accounts no longer fits with the way the business is organised then it’s no wonder that people are downloading information, chopping it up in excel and then reporting it in a different way. This is often seen as a difficulty getting reports out of a system when in fact it is more about how the system is configured.

New systems have loads of bells and whistles. The more they have the more attractive they look. Who could fail to be impressed by TLAs such as ODBC, OCR, CRM and of course CPM*

Oddly though many software producers are now turning away from integrated bells and whistles and either licencing white label versions of popular modules or simply suggesting that the clients buys a different add on for specific purposes.

One of the most striking for me was when a vendor announced in a meeting that their reporting was awful and that the client would be better off buying their mid tier ERP system and then bolting on a third party reporting app!

So if you are going to do that then why not bolt on the reporting app to your current system? It would be cheaper, quicker and cause a lot less disruption.

Indeed in these days of SAAS** connectivity and integration are taken as a given.

Why is it then that many system changes do bring substantial benefits to the clients and end users?

In my opinion it is not the system that provides the benefit, it is actually the process of implementation that helps.

When a client goes through an implementation project they are forced to think about how the system should be used, what the chart of accounts should look like,what reports are really needed and to go through a data migration cleanse.

This kind of deep thinking doesn’t require a new system, you can do it with what is in place already, it just takes the political will and commitment in the company to make it right and as already stated the company can buy third party add ons at any point in its journey.

I’d argue that many companies would be better off running a ‘ghost’ implementation where they go through all the stages of an implementation project such as scoping, design, development and training without actually spending cash on new software.

In many cases the business would benefit greatly from the refresh but wouldn’t suffer the main upheaval of implementing a whole new system.

I realise of course that I’ll be very much a lone voice in this view, after all there’s a whole industry that exists due to its ability to convince you to change.

It is also true that some companies just have to change. Maybe they need a more capable system or their current provider is ceasing support or whatever it may be. I just think that they need to have a more balanced view of the process.

The advert – I’ve run and worked in implementations for companies large and small. I’ve run choice projects and system refresh projects. If you are thinking of buying a new system then why not get in touch?

Maybe I can save you time and money.

* So I’ve been a bad person here. TLAs are my pet hate. TLA= Three Letter Acronym, ODBC=Open DataBase Connectivity, OCR = Optical Character Recognition, CPM= Corporate Performance Management.

** OK so this is Four Letter Acronym. SAAS = Software As A Service. An app that is delivered online that can provide extra capability for a base system or standalone. Good examples would be Gmail as a mail client, Salesforce for CRM or Concur for travel and expenses management.

Isango8 - providing project management and accounting support for SMEs in the South and South West

To compromise or not? that is the question

Seemingly simple decisions can get stuck in the mud and seem to be intractable when you are working on a project. The inspiration for this entry comes from a talk given by Sophie Personne at a networking event I attended recently. Sophie runs an excellent local business called Sophisticated Singles and spoke eloquently about the power of compromise.

Sadly compromise is something that is often lacking in project meetings with political game playing, resistance to change and downright obstinance all playing a part, so how can you push decisions through when things get tough? Here are a few tips to help you on the way.

Tip 1 – Speak to people privately. Sometimes taking 5 minutes out of a meeting environment can help people understand the other’s point of view. Simply taking time to listen can often show up misunderstandings that actually would be masked in a meeting room.

Tip 2 – Find out the real reason. Often people will dig their heels in on an issue for an unrelated reason. I remember one project where an accountant absolutely refused to budge on an issue. It turned out that this was as a result of management not spelling out where he fitted into the organisation post project. Once he’d been given clear sight of his future position he became a positive and valuable team player.

Tip 3 – Understand the impact of everyone’s suggested course of action. If a course of action has no impact on the project, won’t cost anything but makes people feel more included then why wouldn’t you adopt it? Sometimes sitting down with each side and spelling out what the consequences will be can often produce a compromise position easily.

Tip 4 – Use peer power. If people can see how their actions are affecting others then often they will at least compromise or sometimes back down entirely. In a group setting spell out what effect the impasse is having on the rest of the team.

Tip 5 – Get the project sponsor involved. Sometimes whatever you do people refuse to back down. Get the sponsor in to sit people down and clear the blocker. This needs to be used sparingly because the power of the sponsor and the shock of them getting involved tends to wane when they turn up every day to mediate on minor disagreements!

Tip 6 – Get an outsider in. Often people that work together every day will react differently (and be much more grown up) when an outside agency becomes involved. Get an independent (ahem!) professional in to do a project review and see how that moves things along.

If you need help with your project then get in touch for an initial chat and we’ll see if we can get your team to compromise!

12 principles of estimation best practice

Estimating is a key skill in ERP implementation projects. It’s vital to get a clear sight of how much your project is going to cost and how long it will take but what are the best practices for this vital skill?

Magne Jorgensen produced the top 12 estimating best practices and I’ve taken these and added in some of my real world experience and suggestions as to how you can manage the process.

(1) evaluate estimation accuracy, but avoid high evaluation pressure – Studies have shown that giving people a bonus or basing their appraisals on a good estimation track record actually decreases their ability and accuracy. Treat the estimation process as a collaborative effort and you’ll get better accuracy and a happier, more committed team.

(2) avoid conflicting estimation goals – It seems an obvious one but telling your analyst that you need a supremely accurate cost and then telling them that it mustn’t come in over X will make their work less reliable. Go for accuracy and not political expediency.

Thomsett (1996) gives an excellent example in his ‘software estimation game’

Boss: Hi, Mary. How long do you think it will take
to add some customer enquiry screens to the Aardvark
System?
Mary: Gee . . . I guess about six weeks or so.
Boss: WHAAT?!!!! That long?!!! You’re joking, right?
Mary: Oh! Sorry. It could be done perhaps in four
weeks . . .

We’ve all been there right?

(3) ask the estimators to justify and criticize their estimates – Very often a firm will have a culture of perfection and not being able to admit mistakes. In a project environment this is often disastrous. The truth is that any cost prediction will have shortcomings. Ask your estimator what these are and then take a view as to whether you mitigate or look for more information.

(4) avoid irrelevant and unreliable estimation information – Sometimes people include information in their estimate that is unreliable purely because they have nothing better to go on. The truth is you are better off understanding that there is no data rather than basing a decision on something that could be misleading.

(5) use documented data from previous development tasks – If you’ve done work in the area before, or even if you had a project in the company that wasn’t the same you can still use the lessons learned documentation to inform your estimates for the new project. You did do a lessons learned document didn’t you?

(6) find estimation experts with relevant domain background and good estimation records – Music to my ears. Get in an expert even if it is only to help with estimation. Studies show that experience of the software you are putting in is great but across a number of different platforms is even better.

(7) Estimate top-down and bottom-up, independently of each other – Don’t let the golden idea of how long a project should take affect the bottom up process of analysing out how long each task will take. Do both completely separately and you’ll get a much clearer view of the likely cost/time implications.

(8) use estimation checklists – if your software provider or partner has a checklist then so much the better but if not then sit down at the start of the analysis phase and think about all the bases you want to cover. You can add things in along the way if you forget something but make sure by the time you get to the point of choosing your software that you have covered everything in your original list.

(9) combine estimates from different experts and estimation strategies – Two heads are better than one or put another way you want the most expertise from as many different areas and with as many different points of view as you can. Get them all together then aggregate to give you an overall view.

(10) assess the uncertainty of the estimate – The only thing you can be certain about is that there is a certain level of uncertainty (with thanks to Rowan Atkinson). Estimates are only a guide but what you can do is put numbers around key points of your forecast to give you an idea as to how risky the project is.

(11) provide feedback on estimation accuracy and development task relations – this goes to points 5 and 6. If you want to identify who in your organisation is a particularly good analyst of projects then you also need to be developing them. Feedback is a vital component in this. Similarly feedback into a lessons learned document the results of your estimate versus the actual costs. You are keeping a lessons learned document right?

(12) provide estimation training opportunities – as above really. Good experienced estimators have been shown to be much more useful than a statistical model but they have to come from somewhere so start getting people involved in projects. if you are paying an outside consultant to come in and do this for you then make sure you allocate an internal person to shadow them, learn and develop the skills for in-house use.

Using these best practices when producing your project estimates will help give you the confidence that you are on the right lines and produce a better outcome.

If you’d like some external help with producing a cost estimate for your project then please do contact us -we’d be happy to help

References:
Jorgensen. M., 2004. A review of studies on expert estimation of software development effort. Journal of Systems and Software, 70(1–2), pp. 37-60.
Thomsett, R., 1996. Double Dummy Spit and other estimating games.American Programmer 9 (6), 16–22.

Isango8 - providing project management and accounting support for SMEs in the South and South West

The top 5 signs that your project might be going wrong

As a non executive director you’ll probably have oversight of a number of projects during your tenure but how can you tell if things are going awry when you are remote from the project team? These are my top 5 signs that things might be going wrong.

One of the great things about being a non executive director is that you have the opportunity to take a detached higher level view. This gives you a chance to spot things that look out of place when someone much closer and more invested in the project may not be able to see the signs.

There’s an old saying that ‘there’s nothing new in the world’ and in the universe of projects that’s especially true. One thing that shines out from the reams and reams of literature on implementations is the consistency of the type of problems that projects face. The good news is that NEDs can use that consistency to spot when their firm may be facing issues.

There are really only 3 ways in which a project can be classed a failure – the system is late,  over budget and it’s not to the specification required. Here I present my top 5 ways to spot if any of these is on the horizon.

5 – High spending very early on. Projects, especially those that need infrastructure will incur higher costs early on for things like servers, cabling etc. but staff costs should generally be higher towards the end when you are entering the testing/training phase. If your project has used up a very high proportion of its budget or the spending is not matching the project cash flow predictions then it’s time to ask questions because it may well end up using up all of the money when it’s too late to turn back. Make sure a ‘Cost to complete’ is included in the project reports that the board should be getting regularly from the project team.

4 – Things mysteriously disappear from the schedule. I have honestly seen software houses just leave things out of a project report because they decided it was too difficult to deliver. They hoped that if they didn’t mention it then people would forget that they’d asked for it in the first place! Good organisation is the key here. Make sure that when you receive project reports they include all aspects of the proposed implementation and that the risk register is kept up to date.

3 – Missing early deadlines. Through the life of the project there will be mini deadlines that crop up. Producing a system for a ‘look and feel’ demonstration system for instance. It’s usually a sign of how the company providing the goods does business and it’s folly to think that this leopard will change it’s spots halfway through a project. If your provider starts to miss early deadlines then you need to start exercising the firm’s authority and exert proper control over targets.

2 – The project sponsor goes AWOL. One of the key critical success factors cited in the literature is full high level back up from the project sponsor. Unfortunately they are generally very busy people and often, although the project is the focus of their attention on day one, by the time they get halfway through your sponsor will have moved on to more pressing matters. The difficulty is that this is the point at which their input is most needed. As a NED the sponsor is also your direct link to the project so get them to focus. If something else is taking them away then reassign the task.

1 – Lack of clear direction. This is my absolute number 1 priority for any project big or small. The great thing for a NED is that this can be seen right from day 1. If you read the project description and there is no clear and unequivocal statement of what actually will be achieved by investing the firms money then your project will fail. This is also the point where a good NED can add the most value. Challenge (in a constructive way obviously) all the way to the point where the contract is signed. Make sure that the proposed system is properly and completely planned and scoped so that everyone has a clear sight of what the company want to achieve. If you don’t then you can expect trouble!

Above all my advice is to trust your intuition. If something doesn’t sound right, if the project manager becomes evasive or people begin to stare at their feet when budgets or schedules are on the agenda then it may be time to dig a little deeper!

 

Isango8 - providing project management and accounting support for SMEs in the South and South West

Who’s who on a project

There are number of people on a project team that are vital to success - just like a football team playing without a goalkeeper if you leave one of these people out then you risk a failed project!

The Sponsor - Sometimes called 'The project owner' they take ultimate responsibility for the project. They will often kick it off, will present the business case to the board and provide the regular updates. Their job is to remove roadblocks, provide motivation and be the champion for the entire scheme. They set the tone and a good project sponsor is worth their weight in gold.

The Project Manager - An experienced project manager will be the person who plans and runs the project. They will help build the team and continue to provide controls over the budget and work packages on a say to day basis. They enact the sponsor and steering group's decisions an provide feedback and feedforward throughout the teams.

The Specialist - You'll need specialists in functional areas on your project teams. People like finance, operations, HR, payroll are all vital to getting the full picture to ensure that your system is correctly set up.

The Independent Consultant - Someone who has experience from prior projects and different industries. They can bring best practice information to the table and also stay on the side of the company by giving totally independent and unbiased advice.

The Software Consultant - Provided by the vendor company they bring the in depth knowledge of the project and information regarding specific requirements of the software. They will also provide the link between the project and the vendor company.

The Tester - Typically the project will employ people at all levels throughout the organisation and in all departments to make sure that the test system provided does what it says on the tin. They can also be utilised to spread communication to the wider user community about how the project is going,

The Stakeholder - People often think that stakeholders are just people in senior positions but that couldn't be further from the truth. A stakeholder is anyone that has any contact or interest in the system you are putting in. A stakeholder will usually be board members who may not use the system but will want to see a good return on investment, Staff members who will want a system that is easy to use, managers who will want to ensure that controls and reporting are robust, suppliers and clients who may well integrate with the system electronically through order placement and payment services and anyone else who comes into contact with your new software. Each company will have its own stakeholder list and it is always a good idea to think about how you will communicate with them before during and after the project.

If you need help with building your project team or you need an independent consultant or specialist then Call us now and we can talk over the options

Subscribe to Blog via Email

If you'd like to receive notification of our blog postings then sign up here

Isango8 - providing project management and accounting support for SMEs in the South and South West

Making a sandwich – the project management way

This is a little something I did in some spare time and if you’re a project manager who’s a parent then you’ll definitely recognise the behaviour!

1 client (child) says they would like a sandwich

2 project manager(mum) goes back to client and asks what type of sandwich. client says ‘something nice’

3 Project Manager(PM) suggests peanut butter. Client informs PM that they hate peanut butter

4 PM Asks client what they would like instead then. Client says ‘ something nice but not peanut butter’

5 PM decides to check the cupboard and see what’s available

6 Client says ‘where’s my sandwich?’. PM informs client that they haven’t decided what they want yet

7 Client says ‘oh yeah’ and still doesn’t decide

8 PM calls project meeting with client to feedback the options

9 Client doesn’t like any of them and questions why they are paying their PM a fortune to under achieve

10 Client informs PM that they have just met someone at a networking group (school) who really likes baked bean and banana sandwiches

11 PM informs client that they won’t like baked bean and banana sandwiches because they are squidgy and the client hates bananas

12 Client informs PM that they are the client and they’ll have what they want. As an aside they mention that their networking(school) friend has a PM (mum) who always gives them what they want

13 PM asks client if they want their bread buttered, client promises to get back to PM

14 PM gathers together bread, bananas, two knives(in case one is ineffective), a tin of baked beans, a tin opener, a plate and an assistant PM (little brother)

15 PM asks client if they want their bread buttered, client promises to get back to them. PM Points out that this is a critical path item and work will stop until a decision is reached. Client turns volume up on TV so that they can’t hear what the PM is saying

16 PM tasks APM with skinning a banana. PM selects 2 slices of bread and puts them on the plate. APM begins to pick nose whilst staring out of the window.

17 PM carries out a load test of the knives to make sure they work and starts making a training plan for sandwich eating, puts washing into machine and loads dishwasher.

18 Client calls into the kitchen and asks where the sandwich is. PM informs client that they still haven’t made a decision over the critical path item (bread buttering)

19 Client asks what resource the PM was thinking of using to carry out the operation. PM informs client that APM is pencilled in to do it

20 Client goes ‘humph’ and walks away without making a decision

21 PM explains to APM that nose picking is not optimal for this project and sends them to wash hands

22 Client suggests crisis meeting in which they explain that they are very disappointed not to see the project progress any further. PM explains that the team are eager to progress but are waiting on the mission critical decision on bread buttering. Client says that he can’t understand why the PM hasn’t made such a simple decision themselves. After all their friends PM(mum) would have already done this by now. Explains that they are considering changing PMs as a result. Client decides to take more control of the project and fires APM who is singing in the bathroom. Client decides to butter half of the bread and tells PM that ‘it wasn’t so hard after all, was it?’. Goes to watch power rangers.

23 PM butters remaining bread, skins and mashes banana, puts banana into bread opens beans puts beans onto bread puts top on sandwich cuts into four squares and delivers to client. APM stops singing in bathroom and asks why they have been fired.

24 Client informs PM that they didn’t want it cut into squares as they are no longer a child. PM points to project scope document and says that this was not specified and does not affect the operation of the deliverables. Client makes dissatisfaction with PMs performance known.

25 PM begins training plan by telling client to ‘eat your sandwich and shut up’

26 Client informs PM that they hate bananas and asks why the PM thought it appropriate to provide a squidgy sandwich when they hate squidgy sandwiches. PM explains to client that this was noted on the project risks document right at the start and they would have appreciated some feedback before beginning work.

27 Client informs PM in a full and frank exchange of views that they are in fact the worst PM in the entire world. Further, they are stupid and smell too. They wonder why they didn’t use their networking (school) friends PM who always makes great sandwiches.

28 PM removes the application (sandwich) and places it in a secure offline storage facility(bin). Client decides that a cooling off period(sulk) is appropriate

29 Client contacts PM and explains about a great idea they have for a further project for a tuna and honey sandwich and suggests forcefully that, as the PM performed so poorly in the last project that they complete this new improved project ahead of their other projects (little brother’s sandwich) only ‘much better this time’ as recompense.

30 PM explains to client that they have a large amount of projects (washing, cleaning, ironing) to carry out before they feed ungrateful children. Suggests developing an in house capacity (‘do it yourself’) or failing that utilising the services of their networking (school) friend’s PM.

Isango8 - providing project management and accounting support for SMEs in the South and South West

10 things to do before you even choose your software

If you want a successful project then there’s a series of things you need to do before you even get to choose a piece of software

You also need to make sure you do all the steps – missing one out is just like making a cake without one of the ingredients

  1. Analyse the problem – what specific issues are you trying to solve?
  2. Analyse your company strategy – there’s no point in spending a huge amount of money on a shiny ERP system if you intend to sell your company to a trade competitor. They will probably have their own system in place.
  3. Decide whether a new system would work well in light of 1 & 2 – If the problem you are trying to solve is that you can’t recruit the best staff then putting in new software won’t help. It’s an extreme example but it makes the point.
  4. Scope your project – it may seem an early point but decide what you want to achieve and of course what you don’t. If It’s not important to have your people connecting using tablets then don’t bother looking for a system that will do this
  5. Form your steering committee – get the right people in and explain how important this is
  6. Decide what’s vital and what’s nice to have – get your steering committee to decide what are the absolute must haves for any system you consider. If it doesn’t have it then it doesn’t get looked at
  7. Send out your RFQs – Request for Quote (or RFI – Request For Information) cast your net wide and ask the vendors if they can meet your minimum requirements
  8. cull your list – be ruthless, in a couple of months time you’ll be sick of the sight of software
  9. Do your beauty parade – get your short list to present their software to your team and show how they would meet your requirements
  10. Do vendor background research – get independent verification of claims, find out how previous projects went and check that they are financially sound.

The advertisement

I specialise in helping companies through the choice process. There are lots of methods and techniques that I use to ensure that the company gets the best possible fit for it’s purchase. Give me a call and let’s talk

Isango8 - providing project management and accounting support for SMEs in the South and South West

The value of realism

This post is inspired by an article I found on ERP focus by Shane Starr.

Shane explains why ERP will never be the cure for all ills it is often painted to be and this is an important point. Too many companies go into a very expensive and long term project thinking that it will sort out issues they are having all over the organisation – from getting the accounts out on time to painting the garage roof.

The fact of the matter is that any implementation is only as good as the scoping process. If you choose the wrong system then it’ll never be the right system, whatever you do.

Similarly an ERP system won’t fix broken processes or poor organisational behaviour and if you have an inefficient process under your old software then a new system won’t be any better if you just transfer the old way of doing things.

A good analogy is a company having problems with their call centre not answering phone calls quick enough. Putting in a new phone system won’t stop Johnny from nipping out the back for a cigarette or someone answering the call in a surly manner because they had a bad nights sleep.

Of course this is not the image that the phone system company will portray. They’ll explain how quick the system is and how much information can be gleaned from it. It’s the company executives that conflate the problem (slow response times) with the solution (a really quick phone system) without examining the root cause.

Exactly the same thing happens in ERP projects. Hundreds of thousands of pounds are spent on software that will never cure the problems that execs are seeing but will just mean that you can see them a bit better!

What can you do about it?

For a start have a good long look at the problems you are having and decide whether they are truly down to the system, organisation behaviour or your processes.

If you do identify problems with the system then look a bit deeper – are they inherent in the product you have or can you tweek the software to do what you want.

If all else fails and you do decide to take the plunge and buy new then make sure you get someone independent on your side to help you through the choice process. Please don’t take all of your information about what a system will do for you from the vendors. After all they are salesmen and although not all salesmen are sharks it has to be said that they still have a vested interest in making sure you buy their product over those offered by the competition.

6 Rules of effective software implementation

If you want to get your software implementation right, on time and on budget then there are six clear rules to follow.

Decide what you want before you start – it’s very tempting to just lurch in and then call whatever you end up with the system but to be honest it’s the project management equivalent of sticking a pin in a map and calling it your destination.
Don’t rush it – take your time. Good things always come to those that wait. We’re not really advocating waiting around, but take your time over scoping out what you want and making sure that you get the configuration right.
Get the team right – none of us like dealing with sulky teenagers right? Nothing upsets people like being forced to do something they don’t want to do or being excluded from a great trip to the beach, just because they are in the wrong department.
Work out the money then add a bit – this installation is going to cost you more than your software vendor is telling you. They’re not being dishonest just optimistic. Add on a bit extra to the budget then if it’s still left at the end we can have a party.
Make sure you allow your team enough time to get properly involved – Don’t expect people to just shoehorn it into their day. You’re a busy company right? Get in a temp or two if you have to and let people have some time to get the software right.
Get some independent advice – not your mum, or the chap down the pub or the person who is trying to sell you their latest super duper system. Find someone who has implemented more than one system for more than one type of company.

Rule 1 Deciding what you want
This may seem obvious but it’s actually one of the biggest causes of so called ‘failure’. In fact what happens is a company decides to implement part of a package and then along the way finds all sorts of super wonderful things that they’d like to have (prompted of course by the implementation consultants). The budget comes under stress, the timescale increases and people get demotivated.
Be clear at the outset what your definition of success is. IF other things turn up then put them into Phase 2 and plan that separately. Scope the project correctly, make sure you have a plan with timings, costs and people. Make sure you share the definitions of success right at the start with the stakeholders just so that everyone understands what is going on.

Rule 2 Don’t rush it – take your time
Throwing in a system might seem like a really good idea. This is what happens in entrepreneurial big picture type companies. The executives think they are being clever and decisive. Ask Michael Dell how clever and decisive their implementation was. It cost millions and was eventually consigned to the bin.
Take long enough to scope your project, choose your system and make your plan. Every £1 spent planning saves £3 in wasted effort

Rule 3 get your team right
You’d be amazed at how many software projects go ahead with people that can’t be found jobs elsewhere in the organisation or people who have a ‘bit of an idea about IT’. Don’t appoint people because they play golf with the boss, appoint them because they are good at projects.
Make sure you have a full spread of people from the departments that will be affected by the software, that way you’ll not only retain buy in from the very people who will have to use your system, but also have people on your team that may be able to spot potential practical issues before they become a problem. In fact I’d go further and say that if you appoint all executives to your team THEY WILL MISS SOMETHING. Appoint at as low a level as you can and you’ll grab a lot more of the jobs that actually make your organisation run.

Rule 4 – work out the money then add a bit
Trust me this will cost more than you think. IT always does. We always underestimate the number of users, the number of licences, how long implementation will take. FACT. Make sure your project plan has fat, not only in terms of money but also time because that tricky data cleanse will take an awful lot longer than you think.

Rule 5 Make sure you allow your team enough time to get involved
A surprising number of projects are started with the view that Doris from accounts will be able to do her normal day job alongside her duties to the project. Well she won’t. Plan backfill by getting in temps or get a project specialist to work on the team instead but make sure you have enough resource

Rule 6 get some independent advice
Would you buy a used car without getting it checked over first. How much weight do you put on the salesmans words when he says it’s a nice little runner? So why do people commit to very expensive software based purely on the world of what after all is a salesman?

Find someone with experience in choosing (choosing, not implementing, running or selling) software. They’ll make sure it’s the right fit for your company and guide you through the beauty parade. They’ll point you in the right direction for planning the project, deciding on who will do the job and how to go forward. They may even Project Manage it for you. Getting it right at this point will save you a lot of time and money.

The two thirds slump

Every project I have ever worked on big, small, simple or complex has had one of these

Amazingly, the project management books don’t mention it, most websites ignore it and I’ve never seen it on any project management course syllabus but for all that it’s a real phenomenon that can be upsetting and destructive.

So what is the slump?

It’s a general listlessness, frustration, depression or general sense of negativity that settles on a project. It results in arguments, lacklustre performance and extended deadlines. It’s destructive and annoying and at its worst it threatens the very viability of your project.

People tend to get angry and there will be spats and full blown arguments. If you’re really unlucky a fist fight will ensue but that’s a rarity thank goodness!

But overall the project will tend to suffer because people who are happy work better. People who are unhappy don’t.

What causes it?

When you start off a project everything is new. People are all enthused and every day is a discovery. Sure there are challenges but there’s loads of low hanging fruit to grab.

The problem of course is that team members get addicted to achieving. They expect everything to be easy and when something isn’t then it gets put on a back burner until later. Unfortunately later turns up, usually at about the two thirds mark. The team isn’t having as many successes as it once had and every task is a slog. It gets old really quickly.

The project sponsor is probably a high achiever. They are in demand and when the project launches it is the most important thing in their to do list. After a while though other things come along. These things distract their attention and they drift away, if not physically then certainly mentally. The team then isn’t getting the attention it needs or deserves.

Finally people start to forget where they have come from. It’s a natural human trait but we tend to forget what things used to be like. It often manifests itself as rose tinted spectacles, but on a project it typically turns up as people forgetting all the great work their team has done and focusing on the remaining issues.

What can you do about it?

Well for a start employ an experienced project manager. A good PM will have seen this before so it won’t come as a surprise and just like a good football manager he’ll realise that some people will need a kick, some an arm round the shoulder but all the team will need attention and re-energising.

Next – get the project sponsor involved. They don’t have to do a lot but one thing they do need to do is to provide energy and enthusiasm for a vital company project. Get them to reaffirm how important this is to the company and what a great job the team have done.

Keep a success log. Make sure it’s visible and review it regularly. It will help your team to remember what they have already achieved in the project so far and how well they have done.

Make sure that everyone keeps their eyes on the prize. Especially in smaller companies there will be pressure on peoples time and priorities. Ensure that the whole company understands why this is so important to the firm.

Have a non project day. Ban everyone from working on the project, close it down for just a day and if the budget will stretch have an event. Only one rule – no project talk.

Lastly don’t give up. The project was a good idea at the start, a good idea last month and just because there have been a few bumps along the way it doesn’t mean it’s a bad idea now. Push on through and before long you’ll find that actually you’re nearer the end than you thought!