How are we feeling today?

The concept of a “project health check” is well known, and yet not widely applied. Which is strange, because in my experience it is one of the most powerful techniques for project assurance. Perhaps would-be practitioners don’t understand how to go about it? Or could it be seen as too much of an overhead? Maybe there is confusion between a health check and an audit – resulting in fear?

In this blog post, I will describe a simple and effective health check method; one that I have applied successfully dozens if not hundreds of times.

Performing a Health Check

The basic format is this. The reviewers sit down with the project manager for a 2-3 hour meeting, and hold a structured conversation regarding the project. During the course of the conversation, the most relevant issues facing the project are discussed in detail, and brief findings and recommendations are written down.

Reviewers should be experienced project professionals, of a level likely to inspire trust from the project manager. Although I have conducted health checks on my own, my preference is to have two reviewers – as an additional point-of-view is always useful. With a team of two, it is possible to have one of the reviewers from a completely different part of the business; for example a technical project manager reviewing a commercial project (or vice-versa) makes for an interesting conversation.

Any length of conversation can be useful, but experience shows that it takes a 2-3 hour duration to really drill into issues in sufficient depth to make meaningful progress. I try to insist on reserving a 3-hour timeslot, so that the discussion can take as long as needed without pressure to hurry up.

An important aspect is that of trust. The project manager needs to be open and honest. They need to share their concerns, and take full part in discussing alternatives. They need to understand that the reviewers are not looking to find fault, they are not “scoring points”, and their motivation is to ensure project success. Also, the project manager’s authority over the project is not in any doubt: whilst the reviewers can offer suggestions and advice, it is for the project manager to decide how to proceed.

The doctor/patient analogy is useful here: a doctor’s advice is best formulated based on a patient’s honest description of symptoms, and ultimately it is for the patient to decide whether or not to take the medicine. The best doctors often have excellent empathic skills, and they are more likely to ask “how are we feeling today?” than “what’s wrong with you?” Similarly project reviewers need to develop their bedside manner, by making it obvious that they have a shared objective with the project manager of ensuring project success.

I am often asked by project managers what they need to prepare in advance. The answer is: “nothing at all.” The project manager should bring with them whatever project management artefacts actually exist: the project charter, project plan, risk register and status reports. In practice, that means all they need to bring is their lap-top! It should not be necessary to create content specifically for the health check.

As a reviewer, the only thing I like to do by way of preparation is read the most recent project status report. That way I get a stakeholder perspective on the project, and an idea of topics to explore in more detail. It is a useful indicator to see whether the impression I have gained is consistent with what the project manager has to say. If not, then it points to a communications issue.

So what is the most effective structure for performing the health check? Regular readers already know the answer to this one: The Seven Essentials provides an excellent agenda for the meeting.

[table id=1 /]

The Findings

At the conclusion of the health check, it falls to the reviewers to write up some brief notes, containing:

  • A “RAG” status against the Seven Essentials
  • Actions to be taken, normally by the Project Manager (but could also be by the reviewers and/or the Programme Office)

I always send my notes to the PM to gain their agreement and buy-in to the recommendations, because if they are not in agreement then the actions simply aren’t going to happen!

It is important to distinguish between the RAG of the health check and that of the project itself. The health check primarily assesses whether appropriate project management practices are being applied. So it is possible, for example, for a health check to show “green” for risk management – showing that risks are being properly managed – and yet the project status report is at “amber” or “red” due to the level of risk.

What if an audit is needed?

It is both a strength and a weakness of the health check method that it relies on the goodwill of the project manager. In my experience, in over 95% of cases the project manager cooperates fully, and the health check adds value and helps them to deliver their project (and yes, I have conducted surveys of project managers that supports my view).

However, there are occasions when it does not go so well, such as:

  • for whatever reason, the project manager tries to conceal the truth
  • the project manager simply isn’t up to the job – perhaps due to lack of experience or expertise
  • a vendor is running into contractual difficulty, and is protecting their position.

So occasionally, it may be appropriate to invoke a more formal audit. I still tend to follow the same Seven Essentials structure, but the differences are:

  • No statement is taken at face-value. Everything should be evidence-based.
  • Although “open and friendly” is still the best approach, the reviewer is in of a position of authority over the project and it is likely to become more confrontational (“Speak softly, and carry a big stick”, as Theodore Roosevelt puts it).
  • The level of detail takes more time. 2-3 days instead of 2-3 hours. Multiple meetings, involving different parties, may be required.
  • The discussion involves wider members of the project team – not just the project manager – including senior stakeholders. Statements of fact can be cross-checked between the parties.
  • Findings and recommendations are formal, and should not be challenged by the project team.

If an audit of this kind is needed, it will have been triggered by significant problems. So it is likely to lead to fundamental changes in the project, including changes of scope, timescales, suppliers and personnel.



By |2015-08-19T10:54:44+00:00September 29th, 2014|Project Management|3 Comments

What makes a successful project?

In 2013, the APM published a bold vision statement for the profession, that by 2020 we will be in “A World in Which All Projects Succeed”. If nothing else, it has generated controversy and discussion, since we all know of studies showing that 40% of all projects fail (or 50%, 60%, or 70%… you can pretty much pick your own statistic).

The trouble with these studies of project failure – and the beauty of the APM vision – is that it all depends what you mean by “success”. In order to deliver successful projects, we need to know what success looks like. The usual answer is that a project is successful if it meets its triple-constraint of time, cost and quality. But I disagree, as we can surely all think of successful projects that were a bit late, overspent, and/or excluded some scope. Similarly there are projects that met their constraints but were deemed to be failures because they delivered an unwanted white elephant.

At a simplistic level, a project is successful if the project owner says it is (or “sponsor” depending on your preferred terminology). Actually this is quite a useful definition, as it leads the project manager to focus strongly on stakeholder management. Playing under these rules, under extreme circumstances it is possible for a project to be cancelled (e.g. if unforeseen circumstances make the project uneconomic) and for the project owner to be happy with the outcome. So the project would be judged a success, even though nothing was delivered. If for the right reasons, then I think that is a good outcome, and in line with APM’s desire for all projects to succeed.

On the other hand, it does rather assume that the project owner will behave consistently and rationally – and we all know that doesn’t always happen. The owner might be unhappy with the outcome for irrational reasons entirely outside the PM’s control, and it would be a shame to count such a project as a failure.

So what we need is a way to define and measure project success that is impartial and measurable, yet takes into account the stakeholder wishes. The solution is to be found in the definition and application of project success criteria. I think the three steps to project success are as follows:

  1. Define your project success criteria at the outset, during project initiation.
  2. Track and report against project success criteria during project execution.
  3. Measure against the project success criteria at project closure.

Let’s look at each of these in more detail.

Defining Project Success Criteria

This is where the well-known “SMART” acronym comes into play: project success criteria should be Specific, Measurable, Achievable, Relevant and Time-bound. Achievable and relevant both imply that the criteria need to be within the scope that the project manager is delivering; they should not be business objectives that sit outside the project. So, for example, “launch in time for the Christmas marketing campaign” is a valid criterion. But “achieve a 20% improvement in customer satisfaction” is probably not.

These success criteria are likely to include the traditional measures of time, cost and scope. And they might include multiple measures, such as “launch in two countries by August; launch in a further three countries by October”. Also, it is very useful to define “ideal” and “minimum” criteria – so the previous example might become “launch in a minimum of one country by August, and ideally in five countries by October”.

The success criteria need to be agreed with the project owner, and whatever governance sits above the project, for example a steering board. This MUST happen before the project moves from initiation into execution – bitter experience shows that it is too late afterwards!

Tracking Project Success Criteria

During project execution, the status against the project success criteria should be a routine part of the project manager’s status reporting – be that in the form of a dashboard, weekly progress report, or steering board slides. Each criterion can be assigned a RAG status, with the following interpretation:

  • Green: on track to succeed.
  • Amber: at risk. Corrective actions (including escalations) should be identified.
  • Red: not on track to succeed.

The red situation is an interesting one. How many times have we seen projects struggle on, despite the PM clearly stating that the project is doomed? In fact, there are only three options available in this situation:

  1. Do something to get it back on track – now. It isn’t going to be a trivial action, or the PM would already have thought of it. It is more likely to be some form of escalation that was beyond the PM’s immediate control.
  2. Rescope, which means revising the success criteria.
  3. Stop the project! If the minimum success criteria are not going to be met, then why continue? Of course this is a drastic step that few steering boards have the courage to take – but in this situation how can it possibly not be the right thing to do? Stopping the project at the right time and for the right reasons should be considered as a project success.

Rescoping implies that project success criteria are not necessarily locked down for the duration of the project. In fact, under proper change control, it is perfectly reasonable to renegotiate success criteria at any point. Things change, stuff happens, and projects need to be able to adapt accordingly.

Measuring Project Success

At the conclusion of the project, it now becomes almost trivial to measure success. Simply: were the success criteria met? If everything I have described has been applied with rigour, it is hard to think of a circumstance in which the answer will be “no”.

So… all projects can indeed succeed!

By |2015-09-25T14:05:00+00:00September 12th, 2014|Project Management|1 Comment

What do I look for when recruiting a Project Manager?

A blog recently came to my attention over at Software Advice that looks at the differences in project management vacancies across three sectors: aerospace, healthcare and IT. Analysis of 300 Job Listings Reveals What Employers Are Looking For in a Project Manager

It seems that aerospace has the highest entry barriers entry in terms of experience, degree status, and project management qualifications. This is to be expected, as it is an industry that places uncompromising demands on safety, engineering excellence, documentation, and strict adherence to process.

The research being US-based, the most valued PM certification is PMI’s Project Management Professional (PMP). Elsewhere in the world, particularly in the UK, I would expect PMP to be one of several recognised qualifications (including Prince2 Professional and APM’s Registered Project Professional).

It got me thinking: when I’m recruiting a PM, what do I look for? Here are the steps that I would normally take.

Step 1 – Finding Candidates

Who do I know who could do this job?

I have a pretty good personal network of capable project managers, so the first step is always to call on someone that I already know and trust. If that works out (and it often does) then qualifications are irrelevant; I wouldn’t even ask for a CV. An interview – fairly informal – would still be required, as I want to know that the person understands the job and feels confident that they can deliver. I wouldn’t really ask about experience, as that hurdle has already been cleared.

The personal network doesn’t happen by accident. I have always invested plenty of time in maintaining it. Not as a cynical, must-do chore; it is one of the most enjoyable parts of having a career.

Who would you recommend to do this job?

If my direct contacts aren’t available, then I ask if they have any recommendations. Someone that is trusted by someone that I trust is probably pretty good, but this method isn’t infallible. Certainly I would expect to see a CV, and hold a formal interview.

Ask on LinkedIn

This is a new approach for me, but I have tried it, and it works. On my LinkedIn profile, and linked to my Twitter feed, I might ask if anyone knows anyone that can do the job. I’ve only tried it once, but the results were impressive. Unfortunately the project I was recruiting for fell apart, but I had strong candidates lined up.

A Trusted Agency

Sorry, agencies, but you only get a look in once I’ve run out of other ideas. I do have several that I trust, but it still can be a bit of a lottery. Now I’ll probably get CVs to review – so what am I looking for?

Step 2 – The CV Trawl

Relevant experience. That’s 90% of what I’m looking for. Has the candidate worked in this sector before? Have they work with the right technologies? Do they appear to have done the right sort of job (i.e. project management, programme management, etc). It is the relevant experience that gets the interview.

I’m also interested in where the candidate has worked. If they have experience working for companies that take project management seriously, then that is a bonus. For example, both Ericsson and Siemens have a well-established in-house project management standards and training.

I’ll probably scan for degree and certification, but these are “bonus points”. A good degree is really nice to see, but it is not essential. A relevant certification possibly shows that the individual is serious about project management as a profession. Qualifications that I like to see are one or more of:

  • PMP – Project Management Professional (PMI)
  • RPP – Registered Project Professional (APM)
  • APMP – APM Project Management Qualification
  • Prince2 Practioner (UK Cabinet Office)
  • MSP – Managing Successful Programmes (UK Cabinet Office)
  • P3O Practitioner
  • Certified Scrum Master

 Step 3 – The Interview

In an interview, I look to explore the same topics I was looking for in the CV. Experience first and foremost, and then I want to hear what the candidate understands of the job I want them to take on. What are their thoughts – how would they go about tackling the job?

Regarding qualifications, I might ask why they hold a particular certification. What benefit did they expect to get from it, and how is it working out?

Finally, I always like to ask something unexpected, just to see if the candidate can think on their feet. I was once asked in interview “What is the average height of Spain?”. It’s a great question – and I got the job!

What does this mean for Project Managers?

I don’t think my selection method is that unusual, so what are the lessons if you’re a career-building project manager?  I think they are these:

1. Network. That is where your referrals will come from.

2. Always do a good job! That is where your reputation comes from.

3. Make sure your CV describes relevant experience. “Relevant” varies depending on the context, so always tailor your CV to match the opportunity.

4. Invest in relevant training and qualifications, as a way of developing your skills. But don’t expect them to open doors on their own. Contacts, reputation and experience will always trump certificates.


By |2015-08-19T10:54:44+00:00June 9th, 2014|Project Management|Comments Off on What do I look for when recruiting a Project Manager?

Project Management Around The World – Guildford, UK


This post is my contribution to the second #PMFlashBlog, in which project managers from around the world give a regional perspective on their view of project management. This is week two of the sequence, with the spotlight on Europe, and I’m posting from the United Kingdom.

It’s all a matter of culture

At first glance, it is a ridiculous idea to look at project management around the world. Why would it be any different? We’ve  got an ISO standard devoted to project management – which by its very existence proves that project management is the same everywhere. And yet it isn’t. It is sometimes said that “project management is about people”, and – fortunately for all of us – people are not the same everywhere. We come from different cultures, and like it or not that has an influence on the way we behave. For project managers, it gives us a bias in the way we work and it affects the way others see us.

What is “culture”?

The cultural influences that I’m talking about are the behavioural biases that we absorb from early childhood onward. The modes of behaviour that are influenced by our family, friends, teachers, peers and leaders. The common experience of our upbringing – and for sure what I might regard as “common experience” is completely different from someone raised in China, Africa, South America… or even just across the Channel in France.

Our cultural upbringing influences our values, manners, and attitudes. It gives us our body language, tone of voice and sense of humour. It affects our outward display of emotion, our sense of hierarchy, our acceptance (or not) of authority and our attitude towards personal space. It gives us our foundation of attitudes to age, gender, race and religion.

Yet we are all individuals, we are all different, and most of us do not walk around behaving as national stereotypes throughout the working day. We can choose our behaviours to a greater or lesser degree. Or perhaps we only think we can. We can reject the attitudes of our upbringing and choose a different course. There are good project managers and bad project managers in every culture, in every part of the world. Still — we are all influenced by our cultural background, and for a project manager it is essential to be aware of our biases and the effect that these may have on others.

“The best Project Managers come from the UK”

Not my words, but the words of a Swedish client that first made me think about cultural aspects of project management. I was working in Sweden, and we had just come out of a tense project meeting at which a dramatic change of scope had been agreed. It was a difficult decision, but I was happy with the way the meeting had gone, and comfortable with the outcome.

Client: That’s why I like to use a British project manager.

Me: What do you mean?

Client: Because if a Swede had run that meeting, we’d be too worried about hurting people’s feelings to reach a decision.

That conversation got me thinking. Is it true that the best project managers are from the UK? Well, obviously not exclusively, but there are certainly some cultural biases that might help:

  • Good natural mix of “hard” and “soft” skills – which means being able to keep focussed on the objective but without too many casualties along the way
  • An ability to deal with ambiguity – to make progress even in the face of uncertainty
  • A gentle humour – to bring enjoyment into even the most challenging of situations.

What I’m now going to do is risk insulting friends and colleagues by talking about stereotypes! Please bear with me… it’s all in a good cause… and I’ve taken pains to point out we are all individuals and are not bound by our national stereotypes. All of the following are from personal experience in countries where I have worked for extended periods of time.

Disclaimer (in case I haven’t spelt it out clearly enough): I could name many excellent project managers from every one of the countries that I’m using as examples!

Americans: “Hire and Fire”

It’s a tough environment for PMs in the USA, where commercial success is everything and failure leads to a swift exit. Bad news is unwelcome, particularly where executive bonuses are at stake.  There is, sadly, a tendency to the “shoot the messenger”, who more often than not is the project manager. If a PM is punished for honesty, then being economic with the truth becomes a survival tactic, to the detriment of the project.

I’ve seen it happen, and it isn’t pleasant to watch. If you’re working on my project, please don’t be a “good news” PM.

The Dutch are rude!

A quality that I admire in the Dutch is their direct approach to communications. No beating about the bush or British circumlocution here. If you don’t like something, then say so. Argue and fight about it in a business context – and then afterwards go and have a beer as the best of friends, without any hard feelings.

It’s a great approach once you understand it – but be aware that most of the rest of the world regards such confrontational behaviour as ill-mannered and rude!

Germans need a process

In the German approach, every problem has a correct solution; it is just a matter of finding it. Detailed analysis is everything, and I admire the extraordinary effort that I’ve seen being put into the search.

The danger? Of course, it is “analysis paralysis”. Whereas other nationalities might be content to make the best of a bad job and move on, to a German it is better to get to root of the problem before proceeding.

Swedes are too nice

I’ve already touched on the Swedish philosophy that people come first. Let me give an example of a conversation after another meeting that I attended, that had a more typically Swedish outcome.

Me: That was a terrible decision.

Client: Yes, I know.

Me: So why didn’t you speak out in the meeting?

Client: Because everyone felt good about the decision. And sometimes that matters more.

British Project Managers are superficial and lazy

Having established beyond any doubt that the Brits make the best PMs, is there a down-side?

Of course there is, because what I may think of as a positive attribute can be seen negatively through someone else’s cultural filter.

Great sense of humour? No, the British are a constant irritation in the way they trivialise important discussions.

Able to work with ambiguity? That’s just an excuse for being lazy and superficial.

What this means for me, as a British project manager, is that I need to think about and tailor my approach for maximum effectiveness depending on the culture that I’m working in. In the USA, I think carefully about the message. In Sweden, it’s about acceptance by the team. In Germany, I need to apply more rigour to my analysis. And so on.

How to be a better Project Manager

We are, each of us, a product of our cultural background. By being sensitive to these factors – our tendency towards particular behavioural strengths and weaknesses – we can modify our approach to each situation, and become more effective as a Project Manager.

By |2015-08-19T10:54:44+00:00March 10th, 2014|Project Management|3 Comments

Six themes from 2013

Over the last year I have worked with a variety of clients, each with unique challenges. There have also been some common themes. It is the time of year for a bit of reflection, so here are the things that have struck me about project management in 2013.

1. We’re all overworked

Having too much to do is surely far better than getting bored. Being busy is fun, exciting, challenging and stimulating up to a point – but can ultimately lead to stress, physical and mental illness and inefficiency if it goes too far. It’s a fine line.

The key to coping here is prioritisation, at a personal and corporate level. Corporately, the trick is to allocate scarce resources to the right projects, i.e. portfolio management. The science and discipline is well-understood, yet it is poorly executed in practice. I find this strange, since it should be obvious that investment in portfolio management can easily be justified by the savings of avoiding wasted projects.

At an individual level, project managers need to understand that you can’t do everything. You really can’t. And that’s a tough message for the typical “completer-finisher” PM. So instead, make sure that you’re prioritising effectively – always doing the most important thing that needs doing. Always. If you’re confident that you have invested your time in the most important things, then you don’t need to feel guilty about not doing the things you don’t.

2. Senior stakeholders don’t understand risk management

I’m generalising massively here, but project managers seem pretty good at risk management these days. But what is the point in producing a high-quality and quantified risk register, mitigated and managed, if the information is ignored by the decision makers? Why do our stakeholders still think it is acceptable behaviour to set demanding targets, whilst squeezing the budget and timescale to the minimum, and not allowing contingency? Using the classic time/cost/quality measures of success, it means that projects are set up for failure. It’s not acceptable, it isn’t the PM’s fault, and a major re-education effort is needed.

3. Everyone thinks they are doing “lessons learned” badly

As a consultant, this is the plea I hear more than any other – from PMs, PMO and from senior managers: “we don’t record our lessons learned properly; can you help?”

Actually there is a clue in the way the question is usually phrased. Somehow, the focus is always on writing down the lessons, to form some sort of organisational learning database. I think the focus is all wrong. The real value is the learning for the individuals – what happens in their heads – rather than what gets written down.

I hope to return to this topic in more detail in a later blog.

4. Agile

Everyone wants it, but there is a reluctance to provide the right environment in which it can succeed.

5. What is a PMO?

There are so many things that a Project Management Office could do, anything from gating projects based on their fit to corporate strategy (i.e. portfolio management) to looking after room bookings for project team meetings (admin support to the PM). The purpose of a PMO can take a social-worker role of being highly supportive to the projects and project managers, or it can be the policeman of all corporate processes.

Sometimes I get asked “should a PMO do this or not?”. The answer, of course, is “it all depends.”  There is no single correct model for a PMO, and an organisation needs to find what works best for them. In most cases, it will be a subtle blend of the supportive and the authoritative.

6. PMs don’t just come from technical backgrounds

In the past, and particularly in the telecom industry where I’ve worked most of my career, PMs tend to come from a technical background. They are engineers or developers that have moved into project management.

That still happens, but in addition I am increasingly seeing two new breeds:

–        The career project manager, coming direct from higher education into project management

–        People-oriented people, coming from a background of customer services, admin functions, or personal assistants

These newcomers make our profession a richer place to be, and I certainly welcome it.

Those are my thoughts on recent trends and challenges in project management – what are yours?

By |2015-08-19T10:54:45+00:00December 24th, 2013|Project Management|Comments Off on Six themes from 2013