Project Managers need to delegate

Published
by
admin
on September 7, 2010
in delegation, project management, project managers and project managment
. 0 Comments

The project is in full swing; the project manager is so busy they cannot talk about the football match last night and was in early (again) today. The deadline for the procurement report (a significant part of the project) is a day late and you need it urgently.

Meanwhile, you notice the project team are relaxed, not too busy and to be honest, there are strong indications that team members do not have enough work to do.

You identify that the project manager needs to learn how to delegate.

Far from the truth? No!

Over the last 12 months I have had a lot of requests to train people how to delegate. Now you should bear in mind that these requests came during project management courses  that we run, not soft skills or management skills courses. Depending upon the time available I do one of two things:

  •  give a handout which contains my 6 simple stages to effective delegation
  •  use role play based around the 6 simple stages

So, what are the stages? They are:

1. The project manager needs to explain why the task or job is important and has to be done. It may be obvious to you why the task needs to be done, but maybe not so by project team members (including stakeholders) you are delegating to. They may not have been part of the discussions you were involved in. It helps to put the task into a context and helps to motivate the individual who does the task.

2. Define results you want very clearly so that the person understands what is expected of them. You may need to discuss the results with the person you are delegating to and re-visit part way through. An unclear steer from you will result in a missed opportunity. Check their level of understanding by asking questions

3. Define the authority the person has e.g. “you can decide on anything except for money.” Or, “any work that links into the south west team should be referred back to me.” Your role is to ensure the task does not go wrong but if it does, you must retain ultimate accountability i.e. you carry the can!

4. Agree a deadline when the task has to be completed - you may want an interim deadline such as let’s review this in 3 days and see how you are going - see also 6 below

5. Ask and get feedback that the person understands what is required. Check understanding with very specific “what?”, “why?” “how?” questions

6. Set up controls to review progress - bear in mind the level of authority given; be careful not to remove the authority you have given to the person www.deliverthatproject.com/main.html;ivering the task

Feedback I receive and Project Agency  Consultants suggests that this approach works! Try it and see how you go.

 

What project benefits really mean for the project manager

Published
by
admin
on September 2, 2010
in Uncategorized, benefits management, benefits of project management, project benefits, project management training and project managment
. 4 Comments

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.

Published
by
admin
on August 26, 2010
in project, project management, project risks and return on investment
. 4 Comments

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…

Published
by
Ron
on August 12, 2010
in milestones, project management training and project reporting
. 1 Comment

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?

Published
by
Ron
on August 10, 2010
in governance, project, project management and project risks
. 0 Comments

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!)