What project benefits really mean for the project manager

I had a long and protracted email ‘conversation’ with a project manager based in Europe. He was adamant that the prime reason that anyone ran with a project was to deliver benefits. Our email ‘conversation’ went on for some time and we both agreed that there was not enough emphasis put on benefits management and benefits realisation in projects. 

Our emails covered many aspects including what benefits realisation means to the project manager. We finally agreed that at its simplest, it means ensuring project benefits are clearly identified and articulated and realised in projects. 

So, what does this all mean for the project manager? 

  1. Establishing clear project benefits early in the life of the project: these need to be clear and realistic and need to take account of “delusional optimism.” This is over-emphasising projects’ potential benefits and underestimating likely costs, spinning success scenarios while ignoring the likelihood of possible mistakes. (See Defeating ‘Benefits Fraud - Stephen Jenner
  2. Asking questions: easy questions, difficult questions and dumb question of your stakeholders. The project manager needs to tease out the real business benefits. and to do this you need answers to questions; answers your stakeholders will often find difficult to answer. On our project management training courses we talk a lot about developing questioning skills and you may find this  helpful   
  3. Developing clear measurement criteria: too often I hear project managers talking about project benefits they have identified. When challenged there are no measurement criteria against them and no process in place to check that the benefits have been achieved post project. Do remember ‘delusional optimism ‘in point 1 above 
  4. Marketing the benefits: we have had many comments from people on our project management courses  that say something like “we cannot get finance on board” or “HR do not want to buy into this project”. If the benefits were packaged and sold to them effectively then maybe, just maybe they would come on board or buy into the project  
  5. Ensuring benefit management is integrated into your project: is the focus on delivering the project or the project benefits? You may argue they are the same however we have seen people drive delivery without the inclusion of project benefits! Project management benefits are integral to project management, not an ‘add on’ 
  6. Recognising that benefit realisation can be a staged process: if the project is to say save money or improve quality then the project to deliver these may have ended before the savings or the quality improvement are realised. An analysis of project benefits may need to be picked up some months after project closure, maybe it is a project in its own right 
  7. Making recommendations; project managers often complain of not enough resources (time, money, and people). There is pressure to deliver more with less however sometimes the project manager must be able to suggest or recommend to their sponsor that certain projects take priority over others. Rather Why not use clearly identified and measured benefits to help you do this. Compare and contrast one set of benefits against another. Of course, the priority decisions need to be made by classifying project benefits it can help

 There is a clear trend for more emphasis on benefits management. This will mean project managers developing realistic benefits that add real value to projects. Project managers will need to sell benefits to stakeholders including project sponsors and ensure effective monitoring takes place. Don’t forget, a benefit may take some time to be realised so you need to have a process that follows up; often some time later. 

We do not need a business case.

Project Manager (PM) - I have looked at the ideas around the project you mentioned recently and wanted to talk about it.

Project Sponsor (PS) - What, you haven’t started the project yet?

PM - I have, but not in the way you are referring to. I have developed a business case which I want to talk through.

PS - What’s a business case?

PM - It is a process that among other things analyses;

• the business benefits of carrying out the project
• it looks at rates of return
• looks at initial risks
• looks at the priority of the project

There are some interesting things coming out of the business case study you should be aware of

PS - Such as?

PM -

• the business benefits - as I see it (others agree with me) there is one key benefit - improving throughput on processing by around 12%. The key question is this; is that benefit worth the 9 months of project management time, client time and the £55,000 training and software costs

• risks - this software you have suggested is untried. No one has used it before and I believe this is a big risk for us to take on. We are guinea pigs for the software company. Because it is so new, the software may need customising which will cost extra and take more time

• priority of this project - the southern team are undergoing a big re-organisation. There is already training scheduled for everyone on the new telephone system in place. Plus we are losing 4 staff in the next 3 months and recruitment freeze will mean extra pressure on the teams. I am unsure as to the priority of this project

• return on investment - this is more complex however finance have calculated that the return on this investment will take nearly 2 years. It is not a fixed estimate - more a quick look however it is something we should consider and look at in more detail

• the project team - we already have 4 major projects under way. With this and all of the above I do not think we should tackle this one.

Having heard all of this, what are your thoughts?

Let’s bring back the real meaning of “deadline” in projects…

Do you know the real meaning of the word deadline? Its origins go back a long way. Dictionary.com suggests it is:

“a boundary around a military prison beyond which a prisoner could not venture without risk of being shot by the guards.”

I have spoken to many people who complain that the person “did not deliver against the deadline”. Issues such as the “figures did not arrive before the deadline,” or “the report missed the deadline.”

It is the main responsibility of the project manager to check that whatever is due actually gets delivered. From evidence given to me and Project Agency (www.projectagency.co.uk) colleagues it seems that more rigorous systems are needed to ensure delivery takes place on the correct date it should and that the quality of the product is what is required by the client.

What could be included in such a process? Here are some possible examples:

• a variation form  - this is a simple form that shows which activity will not be delivered by the due date or budget. However, before everyone starts developing a variation form see next few points
• hold review meetings. At the start of every project the project manager should engender the honest reporting code. It is exactly that, honestly reporting where an activity is, against the plan at the meeting. You may want to use some of the project management templates we have

• ensure people adopt the Margaret Thatcher approach when she said of Lord Young “He brings me solutions, not problems”.
• I had a boss who held what we called ‘production meetings.’ These were every 2 weeks and we had to bring along proof of where we were against the plan. He explained that he simply wanted to ensure that we were on course and wanted proof of it!
• ensure project team members receive project management training - this includes project sponsor training
• leadership - you could adopt the situational leadership approach - this is an excellent tool where the project manager uses a range of styles to bring about project success:

 directing
 supporting
 coaching
 delegating

This approach suggests that the project manager uses different style for different people against different tasks

So, let’s go back to the definition of the word deadline. When someone says that they have not delivered, suggest you are bringing back the real meaning of the word deadline (”a boundary around a military prison beyond which a prisoner could not venture without risk of being shot by the guards.”) That should ensure delivery on time, on budget and with the right results.

Where’s my whistle?

I was talking to my good friend Mike Clayton today talking about holidays and suddenly said; “hold it, where’s my whistle?” Of course, Mike could not answer, it was my whistle?

Why do I need a whistle? Mike and I were talking about management of risks and I suddenly realised that my risk analysis for our forthcoming holiday was suspect! You see, my wife Sue and I are going walking along the coastal path from Penzance around past Lands End, Porthcurno and back to Penzance. The bags are (almost) packed and the discussion with Mike reminded me that we did not have a whistle….just in case we get lost, fall or befall some ‘other problem.’

There are many instances where “where’s my whistle questions” would have been very useful. Why? I suggested to Mike that companies do not appear to be as systematic as they ought to be in identifying and managing risks in projects.

During project management training courses we have had people giving real examples of risks that have failed to be identified. The result, huge amounts of time and hard cash to rectify the risk once it has struck or in a few cases the project languishing and ultimately dying.

So, where is your whistle? Have you got a systematic company project risk process? Do you really identify all of the risks in your projects and if so, are they being effectively managed?

I thought I had been very thorough with my risk analysis. No formal project management training course for me! But I was wrong.

I’m away walking along the coastal path from Wednesday. I did my risk analysis and realised it could be better. What about yours?

You can follow my progress on Twitter @ronrosenhead (if the phone signal permits!)

We’re only brought in at the project planning stage

That was the plaintiff cry from some of a group on a recent project management course  

Those who made the comment suggested that looking at aspects such as developing a business case or identifying and managing stakeholders and risks was not relevant to them. As you can imagine, this caused quite a stir; from other course members and especially from me! 

I asked the 4 people who said this to try and look at things slightly differently. I suggested that even though they were only brought in to put together the project plan, they should know about the whole of the project management lifecycle. After a brief discussion, they reluctantly agreed! 

I then suggested that as managers in the business they should be managing projects rather than simply putting together the project plan. A similar discussion and another agreement reached. I then said that they would not know enough about the project to put the plan together without the business case, risks and stakeholders and of courser the project initiation document (PID). 

This discussion took slightly longer! They finally agreed. 

The interesting issue is that senior managers who commissioned the course definitely saw the target group running projects - all the way from idea to delivery. But not the group on the course! 

As a tutor on project management courses I often have to challenge people - sometimes like this I can convince them. However, it does not bode well for projects. Why not? If senior managers cannot brief people sufficiently well about attendance on courses then how well will they brief them on projects?