First time visitors read!

If you are new to this Blog, read about it's purpose and how to get the best from it

Free Project Management Training

Go through the site content in a structured manner to teach you Project Management or improve your success rate

No English?

Can't speak English? No problem!!

Why the Sheepdog Analogy?

A Project Manager is a necessary evil. Why? Well, the PM doesn't produce anything - write code, lay concrete or whatever. However, don't have one and see what happens!

Always telegraph your Punches as a Project Manager

Sometimes as a Project Manager you need to throw a "Project Manager punch" but not a literal one please!

Isaac Newton's contribution to Project Management

Newton's laws, especially his first law of motion, should be as important to a Project Manager as it is to a Physicist. Why?

O Sponsor, Sponsor! wherefore art thou Sponsor?

You are given a project to run. Amongst your early questions should be, "who is the Sponsor?"

Always remember the Human side

It is very easy to get hung up in the technical and management side of Projects and forget that they need to be delivered by human teams. So "Always remember the human side" is the key phrase!

Why writing a Project Status Report is not a chore

I've met several Project Managers who view writing any Project status report as a chore. I think the opposite.

Planning is the key Project Management discipline

I have been asked a few times, "What are the top xx things to focus in on as a Project Manager? If pressed, I always fall back to Planning

Tuesday, 15 July 2014

Help your Sponsor through the Project minefield

In a previous post I have already spoken about the need to be given or to seek the right owner for the project, typically called a Sponsor and in PRINCE2, augmented by other roles to form a Project Board. But don't assume that the Sponsor or Board know their role within a project framework and the jargon that comes along with projects so be prepared to help and educate!
A Project Manager should help his Sponsor through the Project Minefield

Don't expect too much and you won't be disappointed

It would be great if Sponsors turned up with a good vision for the project, the business case to justify making the investment and a full understanding of the Project processes within the organisation. I've never been this lucky yet.

In the previous post I spoke of WHY as being the word in my mind when meeting or seeking a Sponsor for the first time. If the Sponsor doesn't have the vision for what the Project is achieving for the organisation, then alarm bells should ring. Everything after the vision is an optional extra as far as I am concerned and I will aim to be the Sponsor's right hand man (even if I will challenge the Sponsor at times) and help with the rest of the Project minefield.

The best Sponsors I have come across are senior folk in the business so the other thing you should assume is that they will be busy and have limited time.

Educate the Sponsor on their Project role

One of the first things I will do is ensure they understand what I expect of the Sponsor and Project Board. I will typically suggest formal monthly Project Board meetings (augmented by weekly status reports) and in the PowerPoint deck for the first ever Board meeting, you will also see summarised in one or two slides the following points re the Sponsor/Board "owner" role:
  • accountable to the business for the investment in the project and achieving the project benefits
  • owning the project execution (that is different from day to day management which is the responsibility of the Project Manager)
  • approving key documents at various points in the project life-cycle
  • making timely decisions as requested by the Project Manager
  • assistance in securing resources
  • championing the project in the organisation (and potentially externally)

Help Sponsor develop the business case

Although I expect the Sponsor to have a vision for the project they may need help in articulating the project business case which will justify why the investment is warranted and what benefits will be achieved. I will return to this topic in more detail in a future post but the key point for now is to be prepared to help in the preparation of this document.

Help the Sponsor through the Project Minefield minimising jargon

Help your Sponsor through any organisational processes such as external Gate reviews and the Project life-cycle itself giving them a heads up on what is coming up in the next month to 3 month horizon. Try and minimise the Project Management jargon as much as humanly possible and when it is difficult to avoid at least explain what you mean rather than assuming that they know.

Minimise the detail with the Sponsor

Remember your Sponsor is likely to be very busy, time poor and by nature of the role that they are likely to have in the organisation, be a personality type which doesn't want to wallow in detail and just want enough information to make a decision or direct others (in Myers-Briggs terminology they could well be ENTJ). So plan your communications to be snappy with underpinning detail held separately to only be used where necessary.

In summary - gain the Sponsor's confidence in you

This probably won't be achieved overnight but focus on the relationship so that the partnership works well to deliver the Project. I always look to: 
  • be helpful and take load of the Sponsor where ever possible
  • most importantly be honest in my assessments on project status and minimise escalation to those that really need Sponsor / Board discussion and/or action
  • unless requested, minimise the time taken with the Sponsor 
  • summarise the detail in communications (with underpinning detail available)
  • avoid jargon and when it is used at least explain in advance if possible
  • generally help the Sponsor through the Project minefield giving advanced notice of up and coming activities which need their involvement
  • plan ahead in the Sponsor's calendar avoiding meetings organised at short notice unless unavoidable
To conclude, once you have found the right visionary Sponsor look to build a good working relationship and be prepared to help them through the Project minefield because they are unlikely to know it all.

Tuesday, 1 July 2014

Do you suffer from Planner's Droop?

The good news is that Planner's Droop is not medical. However, it is a potential project plan condition you need to be aware of in your project and determine how you are going to address it. In this post I explain what it is and some suggestions on how to handle.
Planners Droop - Project Plan Quality Reduces over Time
You need to recognise that in many projects the plan quality and detail degrades over time into the future. The time-scales vary with different project types and where you are in each phase but a very general rule of thumb I use in the IT world is to have a good level of detail in the next month horizon, less detail over 2-3 month horizon and more of an outline after that.

Sometimes your droop is more dramatic

Ideally your plan should be based on a variety of Estimates, I personally prefer bottom up estimates checked by top down. However, sometimes the plan quality "falls off a cliff" because good bottom-up estimates of latter phases depends on the results of earlier phases. This can often be seen in IT waterfall life-cycles where Requirements Analysis and Systems Design need to be completed before confident bottom up estimates of downstream phases can be produced.

Use of PRINCE2 Stages for severe Planner's Droop

A potential solution to plan droop falling off a cliff is to adopt PRINCE2 Stages in your Project. This allows you to "commit" a plan section by section when there is a good justification like the IT waterfall development model above. So in this example, you would have a firm plan (hopefully based on some bottom up estimates out of Initiation) up to the end of Systems Design and a more outline plan for the remainder of the project typically based on top down estimates.

The Project Owner approves this firm plan at the end of Initiation and when the project has confirmed the business requirements and system design, this should allow bottom up estimates to be produced for the remaining key phases such as Construction, Testing and Implementation. The plan & budget is adjusted as necessary and a further commitment of the next Stage is made by the Project Owner. 

PRINCE2 Stages fit well with formal gated reviews of projects, a topic I will return to in a future post but briefly it is a formal assessment of the project at key points to see it is still viable.

Other activities to address Planner's Droop

Whether you utilise Stages or don't, if you recognise Planner's Droop in your plans, you need to be looking ahead and have a rolling activity to undertake detailed planning for those parts of the plan which aren't at a detailed enough level. So maybe this could be a once a month activity to look forward six weeks and ensure that the required detail is established.

Twitter Delicious Facebook Digg Stumbleupon Favorites More