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.