EGGO Projects

My Project Blog

How to measure project success?

Estimates of how many projects fail are usually between 40-60%… but how do we measure the success or failure of a project?

The normal way is financial… profitability at the end of the project. For some with a little more insight it is the three project factors: financial, schedule and quality. To my view it is long term stakeholder satisfaction.

A few examples should illustrate my point:

1. A large meteor is heading towards the earth and a project is put together to divert or destroy the meteor. Failure of schedule would be a disaster… the meteor would wipe us out before we did anything. Failure of quality or performance would be bad, although partial success could save mankind. Financial overruns would be fairly insignificant as long as the meteor was diverted or destroyed on time. The obvious place to measure success is some time after the meteor should have impacted, and not at the point you send the device from your factory.

2. A public address system is renewed in the premises of a new customer. A small cost over run or a small slip in the schedule might seem to be failures at the end of the project, however after 1 year these would probably have been forgotten, but if the announcements cannot be heard well this would be remembered by the customer as a failure. The obvious place to measure success is after a year of operation and not at the point of system handover.

Of course financial disaster on a project can be catastrophic for your company, and often schedule slip or quality issues can also be a disaster financially… but there are so many factors involved including reputation, reference value, experience, IPR, company survival, resource over usage and individual personal relationships, that the goals become difficult to quantify.

So I propose that you can set your interim goals in terms of financial, quality and schedule as required to give the project team guidance… but real project success should be measured after 1 year by stakeholder surveys. Is your company satisfied with the outcome of the project? Is the end customer satisfied? Is the contractor satisfied? Are the other stakeholders satisfied? Communication after 1 year with all the stakeholders would be a good thing anyway, and probably a good time to close out the warranty issues, seek further contracts or even to repair any broken relationships.

Two pieces of advice

Most advice is heard and forgotten, but in this post I hand over two pieces of advice which have held me in good stead throughout my project career.

Firstly an old and well known piece of advice which my grandfather told me when I was very young:

Measure Twice, Cut Once

In projects one of the difficult issues to get across to some business leaders is the fact that project management is a worthwhile exercise and expense. I have heard from business leaders “the engineers have managed OK” and “project management is just a cost which will erode the margin”, and such comments as “If it ain’t broken, don’t fix it”. Well, there are two fundamental drawbacks with this ad hoc approach.

Firstly, are you aware of the risks you are facing? Without an efficient risk management process in place you are not identifying and dealing with the risks you have on the project. If one of these risks occurs your business can suffer, your bottom line can suffer and your reputation can be damaged. Each risk has a probability, and there is a good chance it will pop up one day. PM is like an insurance policy in this respect, but also with good risk management you can often avoid the risks altogether with simple steps.

And secondly, are you sure you are doing well? Are you wasting time on issues which you should have learnt your lessons from? Are your subcontractors and suppliers well managed? Are you continuously improving? Are your costs really assigned well, and are you sure that you are not losing money on some types of projects and making higher profits on other types.

Measuring your risks and performance, and improving, is a necessity and you should invest in it.

The second piece of advice I have taken on board was given to me by a senior PM in Philips in the Netherlands:

Think of the problem’s impact 2 months from today

This is great advice. When things go wrong, and things will go wrong some time, do not go into a panic mode and start making changes and disrupting the team before you have analysed the situation. Panic is not a good bedfellow to reasoning.Try to think of the problem in two months time… I give an example.

You have received your first prototype of a new product and it has a design flaw. Instead of speaking doom and gloom, slumping at your desk, blowing your top, blaming the supplier, your engineers, your quality team, making excuses to the customer or whatever else first comes to mind, just try to imagine what the situation will be in 2 months time if you can come up with a good solution and your plans are implemented well. People already know that this is a problem, and are looking for someone to lead them out of the problem.
Create your plan calmly with the intent that in two months time you will look back and wonder why you were worrying. In two months time, the problem will probably be insignificant if you can implement a good solution, and your reputation as an excellent project manager will be enhanced.

Project Management - its all about the risks

Project Management is all about risks, and their management. Risks are not a bad thing as long as you know about them, and manage them well.

Simply put, project management is the process of identifying risks and managing them, whether they are financial, contractual, product development, team, schedule, IPR related, environmental, technical ambiguities or any other factor.

There is a risk you will lose money, there is a risk that you will lose market share, there is a risk that you product has mistakes, there is a risk that your relationship with your customer will lead to further problems, there is a risk your competition will come out with a better, groundbreaking product, there is a risk that your deliveries from your factory will be delayed, there is a risk your supplier will go bankrupt and so on.

Firstly you need to identify your risks. This is sometimes a little tricky as most people think about the large impact risks, such as liquidated damages, customers going broke, floods etc and overlook the smaller impact but higher probability risks. You will also learn from your previous projects (even if the risk did not materialise into an impact), your work breakdown structure, experts in the field, your employees, your partners and your competition. A known risk is manageable, and unknown risk is not.

Once you have identified the risks, you need to analyse them. Impact is what it would cost if the risk happens, probability is the chance of it happening. This process might be quantitive (actual euro figures) or qualitative (rankings such as high, medium and low). The overall risk is probability x impact. Once you have this you can prioritise your risks for management.

Management of risks is broken down into four strategies:

  • Avoidance - Not accepting the risk
  • Retention - Accepting the risk, and see what happens
  • Control - Accepting the risk and doing your best to minimise it
  • Deflection - Transferring the risk to others

For every risk you should try and come up with a set of strategies which cover the four options above, and then discuss which is the most appropriate for the risk you are analysing. You can then decide how to manage the risk.

Risk management then continues throughout the project, and is continually updated as things change. At the end of the project you should analyse your risk management strategies, what worked and what did not, and learn for your next project.

Some people have said I have been lucky with the projects I have managed, I like to think I played the odds!

Outsourced Project Management

Outsourced project management is a new concept, so I try to explain how it works and the pros and cons.

Many of the problems in the project management field are caused by inexperienced project managers, and project managers working under high stress levels ,and those who are so administrative that they forget the people in the project.

Typically the project manager gets bogged down in problems, and concentrates on solving them, and by default does not concentrate on planning and risk management. Thus the vicious cycle of ‘firefighting’ starts up… never enough time to stop problems occurring because more problems keep arising.

The other main problem is the old but true cliché of ‘communication, communication, communication’. Inexperienced, and bad, project managers stop communicating when problems arise, and try to solve them by themselves without valuable input from the team. It is one of the simplest things to write a project report with facts, hiding all the risks and problems, but when problems occur communication should be increasing. Communication with your team, management, suppliers and your customers are excellent ways of solving problems.

By outsourcing your project management you can put the project management in the hands of experienced and qualified project managers who do not fall into these traps, their job and competences are planning, organising, managing teams, risks, customers, suppliers, lessons learnt and all those other issues which are part of parcel of projects.

The project managers can work remotely or in your office, they can have your company’s e-mail and business cards, they can be full time or part time, they are contractually bound to certain deliverables, they are experts in projects - you and your customers should be delighted… it is difficult to find arguments against the process.

If you can also fix your PM costs against a fixed budget, then you remove the risk of margin slippage for overspends by your own project managers, and you can clearly cover these fixed costs in your quotation.

You can concentrate on your core business and leave your project management in safe hands. The only thing you need to do is find your reliable and professional partner.

Earned Value-less

OK, many years ago I learnt all about Earned Value, and to quote my tutor it "allows for common understanding".

I get it... putting value, or money in normal terms, into your time schedule does give some benefits. You can see how you are doing, and it gets over the problems that Gantt alone does not look into financial performance, and could be misleading.

But I believe I do not need it because I can read and understand my budget information and my schedule information side by side and understand what is going on in my project. So, that leaves the common understanding or communication with other people. I have tried it a few times, but explaining to non-experts is even more difficult than just explaining the schedule and budget and their interdependency. Non-experts do not understand what EV is, but understand schedules and budgets.

It is also cash-flow misleading... and takes a lot of time to get right.

Maybe in R&D type or other internal projects there is something here, but in delivery type projects I cannot see where or why to use it.

I know that some people will say I am doing this automatically, but if I am then here comes my question... If my boss, my colleagues and my customers do not want to see EV results and I do not need to use it, then why should I use the system?... Just because PMBOK says so? Or because it is a feature of the planning software?

Do PMPs hate me for saying this? I guess the only response I can expect is 'resistant to change'... as normal, cliches rule!

Or, please send me a new customer who would like me to show them so I can use my PM skills better.

PM Alternative ToolKit: 1. The Shit Umbrella

I am compiling a list of tools which should, but do not, appear in the PM Toolbox, the first being the Shit Umbrella.

I know that this is a term which recently has had some fame from Google and Gmail, but I first heard it in 1991 when I started out in Projects.

A key role of the PM is to ensure that their team is working efficiently, and protect them from the shit that flies from above and outside. With your new Shit Umbrella you can protect your team from the pointless meetings, stupid requests and questions, spam and neverending reporting that is hitting us all the time.

Never pass on the shit to your team members because you do not want to deal with it.

Hopefully your manager has his up as well!

Gantt chart wallpaper

One of my pet dislikes is PMs who make a Gantt chart at the start of the project, and then tape it up on the wall next to their desk. It never gets updated, and is joined by others until the wall is covered with out of date Gantt charts.

I would like to suggest to the wallpaper manufacturers that they make a design covered with Gantt charts... It must be a good seller, thousands of project managers decorate their walls at work with the same design and happily stare at it for 8 hours per day every day!

Rip them down, and put up photos of your family!

The Peter Principal for Projects

It was stated in 1969 by Dr Laurence J Peter and Raymond Hull that 'employees tend to be given more authority until they cannot continue to work competently'.

The more common version of 'employees tend to rise to the level of their incompetence' is too easy to rebuke, so I will stick to the first definition.

With regard to project management, you should look into the typical career path of: engineer, engineer with added importance (senior engineer, lead engineer etc), project manager, senior project manager, other important PM titles (project director, programme manager etc), operations manager etc etc

In delivery type projects most project managers started as engineers. It is an often discussed, but usually ignored, that engineers are not the best people to become project managers. I assume that this is mostly because the people in the higher roles went through the same path. So I continue building my case without thinking of accountants, or sales people, or any other trade as being better PM applicants...

Engineers are typically valued for their attention to detail... If they are good then the engineers are then moved into a lead engineer position where they need to take a 'bigger view'. If they are good at this then they are moved into a position where they need a 'helicopter view' ie Project Manager. It then continues up until senior management where you need a bigger and wider view.

So, engineers who are valued for their attention to detail get promoted until they cannot ignore the details enough.

I was lucky, I was an adequate engineer and my boss noticed that I was not so happy and he suggested that I should move into PM as I was not a VERY good engineer. I started managing projects aged 22, and was clearly the odd one out as all my counterparts were at least 40. I turned into a great project manager, through education and experience.

So, how about we keep our good engineers as engineers and promote our average engineers to project managers.

New starts

I have now transferred my blog to the company web page…

I love to write and argue about project management, and the experiences I have had over the last 20 years… many of the posts are tongue in check and only to make people think a little and laugh a little and get a little angry… not to be taken too seriously!