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

Friday, 19 June 2015

Preparing for your Project Board meetings

You have established your Sponsor and Project Board and need to prepare for the next formal meeting. What is the agenda for the meeting, what do you say, what material do in issue in support of the meeting? Here are some suggestions on the approach to take.
Project Board Meeting Preparation
Firstly, the PM in the cartoon is what I call a "Good News Project Manager" (someone who only wants to give good news to stakeholders) and despite the humour, please do not become one of these - hiding from the truth is of no use to anyone. If the status is bad, look for potential recovery strategies with your team and discuss with the Project Board who own the Project.

Materials to Support the Project Board Meetings

There are two key documents I use for running Project Board meetings. Remember the chair of the meeting is really the Sponsor but the PM will typically write the materials. Please check with the Sponsor whether to run through the materials with him/her for comment and amendment prior to the meeting. 
  1. Presentation Pack using a package such as PowerPoint. This contains the meeting Agenda, supporting slides and Appendices which can be referred to if necessary
  2. Minutes / Actions - Document detailing these from previous Project Board meetings. My preference is to maintain these in a spreadsheet but to cut relevant information into each Pack
Don't forget that the Board may not be experienced in Projects or Programmes so try and minimise jargon and help them through the minefield of Projects processes / terminology including any local organisation processes.

The first Project Board is special

I have some special slides I look to include in the first ever Project Board. This should cover the roles & responsibilities of the Board as the owner of the Project specific responsibilities of each members of the Board. I covered this in a previous post.

Typical Structure of Pack and Meeting

This is a typical structure I utilise, I may move some "supporting material" to Appendices depending on how much to get through in time:
  1. Agenda including Decisions required from the meeting if you need something specific
  2. Actions carried forward from the Board(s) before the last one
  3. Minutes & Actions from the last Board - as Board members are too busy to agree Minutes when circulated after meetings, I like to include them in the next Pack to ensure there is full agreement
  4. Summary Status slide - RAG status against Time, Cost, Quality/Scope and Benefits indicators. Status description in a paragraph with major updates. Basically gives the Board member a picture of where the Project is on one slide.
  5. Key milestones tracking. In the PID or Stage Plan I will always publish a set of key milestones for ongoing monitoring and reporting to the Project Board. In the pack I show as a table (see example below) with description, owner, baseline date, forecast date if not yet met, actual date milestone met, days late (calculated), RAGB status (Blue = met), Comments
  6. Key Products Tracking. The key Products to be delivered by the Project (probably a subset of all Products, these are key ones which are important to the Board). In the pack I show as a table (see example below) with Name, Status (Not Started, Being Drafted, Draft Issued, Partially Approved, Approved), Author, Comments, Draft Dates (Baseline, Forecast, Actual, Days Late), Fully Approved Dates (Baseline, Forecast, Actual, Days Late)
  7. Other metrics supporting the Project position e.g. Test Execution and Defect status if in an Test Phase
  8. Finances - position against budget and forecast to complete
  9. Issues, Risks and Dependencies which I believe should be highlighted to the Board
  10. Slides specific to any Decisions required as necessary
  11. Any other information I decide will be of use to the meeting depending on where the Project is e.g. up and coming phase detailed planning
Project Reporting - Key Milestones
Key Milestone Tracking Example

Project Reporting - Key Products
Key Products Tracking Example

Issuing the Pack

Issue the Pack in advance of the meeting, my target is 24 hours although sometimes I do miss this, I will strive to issue out the evening before the meeting come what may. Each Board member will have individual preferences, some like to print the pack and review in advance, some will just scan electronically, some won't look at all. 

As in many organisations, some Board members may join the meeting by phone, having the pack issued a few hours in advance is important.

Running the Meeting

Although the Sponsor is the chair of the meeting, most Sponsors are happy for the Project Manager to run through the material which makes sense as effectively it is the PM report into the Board. I aim to use a projector to show the presentation rather than have mountains of paper. The individual Board members can print the pack if they wish (see Issuing).

Move through the meeting using your slides, keep an eye on the time and be prepared to skip sections to get to your "must have" material to ensure the Board discuss the points you want discussed and you achieve the decisions required (if not, establish a firm timetable soon after the meeting to achieve the decision and note any risks or assumptions you will take pending the decision). Be honest in your responses to Board questions and if you don't know the answer don't waffle, take an action on yourself to come back promptly by email.

After the Meeting

Minute the meeting with actions as appropriate, check with your Sponsor if requested and then issue out to Board members with a target of 3 days from the meeting so things are fresh in people's memory. 

Conclusion

Project Board meetings are important checkpoints with the Owner of the Project and should be used by the Project Manager to honestly report on progress, request assistance (e.g. escalated issue discussion) or make decisions. As such the Project Manager should take the appropriate care and attention in preparing for such meetings. 

Remember, ultimately the Project Manager will be judged by the success or failure of the project execution but you can build at lot of credibility through your performance in these meetings.

Friday, 5 June 2015

You plan the Project execution, do the same for Benefits Realisation

There are two dimensions to Project success, the delivery of the Project objectives to the agreed success criteria in the Project Definition, often related to Time, Cost and Quality (Project Manager responsibility on behalf of Project Team) and the delivery of the Project Benefits (Project Sponsor responsibility). A lot of Planning goes into achieving the first dimension but often very little Planning goes into the second dimension. So help your Sponsor and the Organisation by creating a Benefits Realisation Plan during the Project execution phase. If a viable plan for achieving the benefits (as stated in the Business Case) can't be agreed, the viability of that Business Case needs to be questioned during the Project execution rather than saying "oh dear" once the whole Project budget has been spent!
Plan Benefit Realisation just like Project Delivery

It all starts with the Business Case

Before starting the Project a high level Business Case should have been drafted with a statement of the expected benefit case and a stab at the project costs. This allows the Organisation to choose between potentially competing initiatives before kicking off Project Initiation for the initiative with the best Business Case. This process can encourage overly creative Business Cases as per the cartoon in my previous post

If for any reason the Project has been initiated with any thought to the Business Case, I would look to produce something during the this phase. Of course, you may need to find a Sponsor first remembering that the Sponsor should own the Business Case not the Project Manager.

A Business Case may start high level and be refined in the early part of the Project

You may start with a high level business case and flush out some more detail as you proceed through Analysis and Design. So ensure you plan these activities. Sometimes a good way of driving to a detailed Business Case is through the use of Project Stages so that an agreed deliverable for the first Project execution Stage, is a firm detailed Business Case (as a minimum) and potentially a Benefit Realisation Plan as well.

The Business Case should be kept under review during Project Execution

A common mistake is to forget the Business Case during execution. At whatever level it is produced, it should be kept under review. I recommend a strategy for ensuring this happens remembering that the Sponsor really owns this. A good way of ensuring that this happens is the concept of Gated Reviews at various points in execution, say at the end of a formal Stage or maybe even just at the end of a phase of the plan.

What is the content of a Benefits Realisation Plan?

The Benefits Realisation Plan should answer the following questions:
  1. What is the benefit that will be captured including the target level? (if there is a range of levels over time, this should be described)
  2. Who is accountable for securing the benefit?
  3. How will it be measured? (processes, tools, techniques and resources involved in undertaking the measurement)
  4. When it will be measured?
Even with a financial benefit, the process to calculate this may be non trivial. For non financial benefits, a proxy measure is likely to have to be devised. For example, "Improved customer satisfaction" might be via a survey before and after the Project has been implemented. The exact process should be documented and agreed.

Monitoring and Control of the Benefits Realisation Plan or should I say policing?

This is a problem faced by most organisations as the Project team has typically been disbanded by the time that the benefits start to be properly realised. The Sponsor may not be motivated to ensure the measurements get made especially if the benefits were "over-egged".

An ideal solution is for a PMO to take ownership of monitoring & control of the Benefit Realisation Plans. An alternative / additional approach I have seen in one organisation is to have a Projects Approval Board (PAB) which sits above individual Project Boards. The PAB has to authorise new Project Stages based on submissions of a revised Business Case by the Sponsor (sometimes accompanied by the Project Manager). A special review was timetabled post Project completion (at an appropriate time in line with the Benefit Realisation Plan) where the Sponsor had to attend the PAB and present on Benefit Realisation measurements against the agreed Plan. In addition, the achievement of the benefits was often written into the Sponsor's personal objectives for the year. This is probably the best example I have seen of policing the Benefit Realisation Plan and keeping Sponsors "honest"

Conclusion

A plan to deliver the Project objectives is considered common place but this isn't always the case for the Project Benefits. As ultimately the benefits of the Project should be the reason for undertaking the Project this makes little sense. So start with a Business Case, drill down into more detail as more information is known during Project execution and when agreed move onto agreeing a Benefit Realisation Plan which will determine the what, who, when and how with regard to assessing whether the expected benefits have been realised. The organisation also needs a method of policing the process post Project completion. With these elements in place, benefits stated in Business Cases are more likely to be realistic, all efforts within Project execution should be focused on achieving the stated benefits as should some post delivery actions to correctly exploit what has been introduced by the Project.

Twitter Delicious Facebook Digg Stumbleupon Favorites More