The Olympics and Earned Value Management

Part of the 2012 London Olympics project was a learning legacy project, the learning legacy project captured and shared the knowledge and lessons learned from delivering an Olympic games. The learning legacy project can be viewed here:

http://learninglegacy.london2012.com/

The project information is captured in 10 learning legacy themes:
• Archaeology
• Design and engineering innovation
• Equality and inclusion
• Health and safety
• Master-planning and town planning
• Procurement
• Project and Programme management
• Sustainability
• Systems and technology
• Transport
The project and programme management theme contains a series of micro reports, champion products, case studies, research summaries and videos.
One of the micro reports of particular interest is how earned value was used by the Olympic Delivery Authority (ODA) to measure project performance across the programme. The recent EVM series on this blog outlined the basic EVM techniques. For those interested in seeing how this can be applied in live the micro report here:
http://learninglegacy.london2012.com/publications/using-earned-value-stable-baselines-with-nec-contract-pr.php

shows how combining scope, schedule and cost measurement into a single reporting system allowed the ODA to manage progress and get early warning of potential programme issues.
The EV system implemented used:

Budget Cost of Work Schedules (BCWS) – To provide the baseline
Budget Cost of Work Performed (BCWP) – To provide earned value
Actual Cost of Work Performed (ACWP) – To give the actual cost

Further detail can be found in the micro report which in conjunction with the 4 part EVM series on this blog provides a theoretical and practical introduction to EVM.

Advertisements

The Project Life Cycle

Today’s blog post looks at project lifecycles, why do we have them and the two common project lifecycles.
Most project management books contain references to the project lifecycle. A project lifecycle is typically an analogy used to describe the idea for, creation of and subsequent demise of a product or outcome. A lifecycle is a model of the phases or stages a project can go through. It’s useful to delineate stages so we can see where activities take place and the relationships between activities. No single life cycle model is applicable to all projects although certain types of projects such as a construction project for a sports event such as the Olympics may be associated with a particular life cycle.
The two main life cycles are the basic and extended project life cycles.

Lifecycle

The basic and extended project life cycles

Concept

During this phase the business problem to be solved or opportunity is identified or established. Proposals are prepared and feasibility studies undertaken. A stop/go gate can be added via approval or otherwise of a project business case

Definition

The outline business case generated in the concept phase is used as input into further planning. Potential solutions are identified and evaluated and a preferred solution identified. Following this the project manager can derive the scope, time, cost and quality plans for the project.

Implementation

The project plan produced in the definition stage is execute in this stage. The design of the deliverables is completed and the products built. The project manager is actively engaged in managing stakeholders, monitoring time and costs, ensuring quality objectives are met and controlling the scope. This is the busiest stage of the basic life cycle.

Handover

Once all the deliverables have been built they are handed over, in a controlled fashion, to the business. Once formal acceptance has taken place the ownership of the products transfers from the project team to the receiving authority. The basic life cycle project should be closed in a controlled manner at this point.

The above 4 stages describe the basic project life cycle, an example of a basic life cycle project is a software development project. The end product may be in use for many years hence no requirement to plan for the two extra stages found in the extended life cycle, these are:

Operation

The period during which the deliverable is used and maintained in service for its intended purpose

Termination

The tear down and disposal of the project deliverables including any remedial action to return the receiving authority to an agreed state.

The recent London Olympics are an example of the extended life cycle. Once the games (Operation) were complete many venues were (or will be) transformed (Termination) to their final states. Examples of how each venue was transformed can be seen here http://www.guardian.co.uk/sport/2012/aug/11/olympic-venues-stadium-velodrome-regeneration

I hope this helps describe two of the most common project life cycles – what are your views, how applicable are the models above to your projects?

EVM Part 1

Earned Value Management (EVM) – Part 1
As a project manager that has worked in various organisations I am often asked to complete project reports to show the current status of my projects. Often these report templates ask to me to report spend against budget. This has some value but does not always paint the full picture of what is actual happening and, crucially, what might happen in the future. Therefore the value of that report from a management decision making perspective is questionable.
Ideally we need a system that allows us to report against a baseline of cost, schedule and performance.
One of the most common systems for monitoring and controlling project cost is the earned value system also known as earned value management (EVM).
The earned value management system will show the planned cost of the work and the actual cost of the work along with a measure of the value earned by the work.
An earned value management systems consists of 4 key data pillars, these are:
1. The budgeted cost of work scheduled (BCWS), also known as planned value (PV)
2. The budgeted cost of work performed (BCWP), also known as earned value (EV)
3. The actual cost of work performed (ACWP), also known as actual cost (AC)
4. The estimate at completion (EAC)

If these 4 key data pillars are in place the earned value management then the EVM systems will provide:
1. Accurate status reports
2. Visibility of schedule and cost impacts to the project

What are the benefits of EVM?

The graph below shows the traditional actual cost versus budget graph

fug 5 Budget v Actual

Fig 1 A graph of budget vs actual cost
What this type of graph does not show is whether the project is on schedule, to cost or delivering value for money.

Budgeted Cost of Work Scheduled (BCWS)
To analyse progress against the plan we need to create the baseline cost expenditure profile. This is called the budgeted cost of work scheduled (BCWS) or planned value (PV). Once estimating and scheduling activity is completed during project initiation the BCWS graph can be produced. This is done by adding together the weekly or monthly costs of each activity and allows the rate of expenditure to be predicted. The BCWS can be calculated if we know the budgeted cost of each activity, when it occurs and the spend profile of each activity.
The table below shows the cost and duration of a series of activities for a project to create a SAP BI solution. Each activity is described along with the budgeted cost and duration.

Fig 1 Scheduled Expenditure on project
Table 1 Scheduled expenditure in project

The table below shows how we use this to create our expenditure baseline or BCWS. The spend of each activity is predicted in the relevant time slot as the project progresses. Each row represents a 4 week time slice in the project. Each row is added up to give a total spend in that period. The BCWS is calculated by adding up each row.

fig 3 Calculations of BCWS for SAP BI Project
Table 2 BCWS baseline

Therefore it can be seen that if we know the budgeted cost of each activity, when it occurs and the spend profile of each activity we can calculate the BCWS.
This is then represented graphically below:

fig 4 graph of bcws for SAP BI project
Fig 2 BCWS for SAP BI Project

This graph also provides two further pieces of information, namely:
1. The scheduled completion (SC) date – in this example week 55
2. The project budget (PB) – in this example $300,000

Budgeted Cost of Work Performed (BCWP)
The earned value (EV) of the project to date is the cost assigned to the work during the estimation phase. The APM define earned value (EV) as:
“The value of completed work expressed in terms of the budget assigned to that work”
This is also known as the budgeted cost of the work performed (BCWP).
The APM define the budgeted cost of the work performed (BCWP) as:
“The sum of the budgets for completed work packages and completed portions of open work packages, plus the applicable portion of the budgets for level of effort and apportioned effort”
I will use BCWP for this article but the term is interchangeable with EV.
The BCWP is found by adding the cost of work either wholly or partially completed at the time of the measurement.
As an example let’s have a look at the BCWP at week 26 of our SAP BI project, this is created by taking the scheduled expenditure in project and showing the cost of work performed.

fig 6 bcwp at wk 26

Table 3 BCWP for SAP BI project at week 26

As can be seen completed activity, such as activity 1 Design Infrastructure, is reported as 100% complete and 100% of the cost is represented in the BCWP calculation. Activity 2 is 50% complete therefore 50% of the budgeted cost is represented in the BCWP calculation.
So we now have 2 of our pillars in place, namely:
1. Budgeted Cost of Work Scheduled (BCWS) which is the accumulation of scheduled work
2. Budgeted Cost of Work Performed (BCWP) which is the accumulation of performed work
However, these are only views of planned cost and not views of actual costs. Next we shall look at how we introduce actual costs into the EVM system and how we can use that information to manage our SAP BI project.

Real life stakeholder management – go live in 3 days and key stakeholder voices concerns

Following on from my recent posts on stakeholder managament https://theprojectlens.wordpress.com/2013/03/25/311/ I found an interesting real life example today.

In the UK the government is about to launch a new non emergency telephone advice line. However a key stakeholder, the British Medical Association, has today gone public today voicing concerns about the project http://www.bbc.co.uk/news/health-21963297. In their view the system is unable to cope with call volumes and has suffered severe IT failures.

I am reminded of the 1992 London Ambulance Service computer aided despatch system project failure http://erichmusick.com/writings/06/las_failure.html. Lessons learned?

If you were the project or programme manager how would you manage the situation….?

Choose the subject of my first ebook

I’m about to write an ebook for this blog but I want your help to choose the subject. Please vote now!

The Art of Negotiation

Today we have a look at art of negotiation and what we, as project managers, need to consider when involved with negotiations during project delivery.
On this blog we have previously looked at aspects of risk and stakeholder management and I have presented tools and processes for creating a risk and stakeholder management baseline. The on-going management of risk and stakeholders will depend, to a degree, on your ability to negotiate with people to achieve desirable outcomes. A key distinction should be made at this point; a desirable outcome may not necessarily be the best case outcome but lies within a tolerance we have set ourselves in advance of the negotiation.

As project managers we are used to dealing with the management of constraints but also dealing with conflicting views, agendas and interests. To resolve these conflicts we are often call upon to negotiate.

In advance of a negotiation take time to understand your role, is it:
• As an observer
• An active participant seeking to negotiate for a personal outcome
• An active participant trying to bring two or more parties to an agreed position

There are many views on how to approach negotiation but personally I recommend that you try, wherever possible, to maintain relationships with those you have to negotiate with. Unless the situation is particularly extreme then be conscious of the fact that you may need to work together in the future. The literature often refers to this as win-win negotiation, it means arriving at a point where both parties are comfortable with the outcome, it may be less than ideal but is mutually agreeable.

To find the point of mutual agreement spend time understanding the different views held by the interested parties. Also consider the authority, power and influence of these groups. Spend time speaking to or meeting those directly involved or on the periphery to understand their perspectives. The more intelligence you can gather the better as this will help you formulate your position and understand the likely responses to this position.
Also take time to understand what upper and lower limits of tolerance exist around the negotiated position. Be aware of your level of authority and understand where you may have to seek further approval if the potential agreed position is outside these tolerances.
Equally, consider the impact and consequences of a failure to achieve a desired outcome. This is likely to impact on time, cost and quality and may require sponsor intervention to either approve or resolve.

Negotiation is often an iterative process and will cycle through planning, discussing, pitching, bargaining and finally agreeing. Always formally communicate an agreement in case this is challenged later in the project. Be ethical in your negotiation and be aware of any cultural influences that you may need to consider.
This is a personal view on negotiation based on my personal experiences, please share your experiences and views on negotiation and lets learn from each other in the PM community…….

Project news from around the world

Today’s post is a look at some large projects making the news in America, Australia, Italy and China

Stakeholder management will be important in Kentucky as the State authorities push plans to build a bridge at a cost of $1.1 billion

Woodside Petroleum’s $40 billion Browse gas project looks less likely to go ahead despite the re-election of its biggest supporter, West Australian Premier Colin Barnett.

In Italy a £90million project to restore Pompeii is overshadowed by controversy

In the UK an article on the APM websites covers what lessons can be learned from Hurricane Sandy

A massive project to divert water from China‘s south to its drought-prone north — which has seen hundreds of thousands of people relocated — will become partly operational next year

5 steps to effective Stakeholder Management

A key aspect of project management is effective stakeholder management. Stakeholders can influence projects in many ways, both positively and negatively, and need to be actively managed. Risk management and subsequent mitigation is to some degree reliant on effective stakeholder management. Over the years I have evolved my own 5 step model for managing stakeholders which I am going to share in today’s post.
Below is the 5 step model I use on my projects.

Step 1 – Create the Organisational Breakdown Structure (OBS)

An OBS is a diagram, usually in the form of a tree structure, of the stakeholder organisation created in excel. Where projects span multiple departments and organisations I generate an OBS for each group. Each stakeholder is added along with their job title in the correct part of the hierarchical structure (see below). I sometimes will colour code users if they are on project boards or part of the day to day delivery or are significant in some other way. One of the benefits of this approach is that it often uncovers stakeholders I may have not considered. If I am aware of the position in the organisation of my stakeholders I can then consider the most appropriate management mechanism to deal with them.

OBS

Step 2 – Categorise your stakeholders

Once I have found my stakeholders I categorise them into one of three groups: immediate circle (direct involvement), observational circle (indirect involvement) and the community circle (interest/regulatory). The second tab of my stakeholder spread sheet is this list of stakeholders.

stake 1

Step 3 – Understand Power and Impact of Stakeholders

Step 3 and tab 3 of the stakeholder spread sheet is an assessment of the power and interest of those stakeholders I identified in step 1. I try not to over complicate this stage as categorisation is often subjective (and sometimes sensitive). I categorise the users as either having High or Low Power and High or Low Interest.

Step 4 – Complete Power Interest Grid

stake2

Once I have considered the power and interest of my stakeholders I can place them in the one of the quadrants in the power interest grid above. A high interest high power user would be placed in the top right hand quadrant and managed closely as they have the potential to significantly impact the project. A low power and low interest user would fit in the bottom left hand quadrant and monitored. One thing I am always conscious of is that stakeholder’s power and interest may change as you move through the project. With this in mind I will, on a weekly basis, review the power and interest of identified stakeholders and make my management decisions based on the current project context.

Step 5 – Complete Stakeholder management and communication plan

Once steps 1-4 are complete I then complete the fifth and final tab of the stakeholder analysis, the stakeholder plan.

stake3

The first column contains the stakeholder name and job title. The second column “communications approach” is taken from the PI quadrant and will be Manage Closely, Keep Satisfied, Keep Informed or Monitor. Key interests and issues allows me to record specific information about the stakeholder. Current status is either: advocate, supporter, neutral or blocker. These are terms I use but you could use anything that suited your way of working. Desired support uses the same statuses of advocate, supporter, neutral or blocker but detail where you want the stakeholder to be. Desired project role is a column I use to record how I want to involve me stakeholders. This often works well with those stakeholders that are neutral or a blocker; if I involve them in the project I have better visibility any problems. It’s better to have critics involved rather than sitting them on the side line outside the project potentially impacting the project by their actions. Actions desired is a column I use to record any stakeholder\risk management activity I have set e.g. I may need the sponsor to call his equivalent in the supplier organisation or get a business lead to communicate to the business teams.

Messages needed is a column where I can record what information I, as project manager, need to communicate to my stakeholders to manage them. This could be around key financial information, deadlines, impact on business teams or any other project related event. I also consider events external to my project that could impact my stakeholders and communicate about them accordingly.

Finally action and communication records how and when I am going to communicate with my stakeholders to support my desired management strategy. It may be a weekly update, weekly call, an article on the portal or any other type of communication that is deemed appropriate to deliver the required message. I also like to rely to a degree on informal communication and not fall into the trap of making this an open loop process. Where possible elicit feedback by personally contacting key stakeholders , I have found that this lets you test how you have categorised a stakeholder and that you are not managing based on incorrect assumptions.

I hope you have found this useful, please let me know how you manage your stakeholders. What do you think are the strengths and weaknesses of my approach – would it work in the contexts you deliver your projects?

My 5 favourite Project Management Blogs

 

Whilst eating my breakfast this morning I quickly scanned my favourite blog sites. I do this every morning and its an established part of my daily routine. In today’s post I thought I would share with you this mornings sites:

For a wide variety of interesting articles check out PM Hut here http://www.pmhut.com/, it also now includes a couple of posts from this blog which was great from a personal perspective

Another blog with great content is How to manage a Camel from Arras people here http://www.arraspeople.co.uk/camel-blog/ 

One of the first blogs ever read was A girls guide to Project Management by Elizabeth Harrin http://www.pm4girls.elizabeth-harrin.com/ 

We then have the blog of the PMI here http://blogs.pmi.org/blog/voices_on_project_management

And on a similar theme I always check out the news page of the APM here http://www.apm.org.uk/

Finally I found a great resource this week from Arras People, namely their PPM Community which is a portal for blogs http://ppmcommunity.com/ 

What are your favourite blog sites, if you have an interesting blog site let me know and next time i’m eating breakfast I’ll check it out….

 

Book review – Secrets to mastering the WBS in real world projects

secrets-mastering-wbs-in-real-world-projects-most-liliana-buchtik-paperback-cover-art

Secrets to mastering the WBS in real world projects is by Liliana Buchtik PMP and was published by the Project Management Institute (PMI) in 2010. Liliana Buchtik is president of Buchtik Global, a consulting and training firm specialising in project management.
The book is written in a simple question and answer format and each chapter heading is phrased as a question. There are 12 chapters covering all aspects of the construction and use of the Work Breakdown Structure (WBS) in this 202 page paperback book.

Chapter 1 sets the scene by providing a definition of the WBS as “a structure used to breakdown or divide the project work” to show what the project has to deliver to achieve the desired outcome.

Chapter 2 advances 20 potential benefits that can be obtained by implementing a WBS. These range from understanding the work through to inspiring confidence and gaining credibility.

Chapter 3 explains 4 areas of confusion about the WBS. These being confusing the WBS with a sequence of work, confusing the WBS with a schedule, confusing the WBS with the organisational breakdown structure (OBS) and not using the modern working definition of the WBS. The author takes time on the final point to explain the difference between a task and deliverable based structure.

Chapter 4 asks what questions need to be asked to understand the capability of a well structured WBS. The chapter asks the what, when, why, who and how questions that relate to the creation of the WBS.

Chapter 5 covers the theoretical requirements of creating a WBS. This includes how many levels the WBS should go to and identification and numbering of the individual elements. One of the key aspects of this chapter is answering the question of how many levels are needed in the WBS. The author suggests that you should “decompose the WBS to the level where you are able to manage the work and able to assign and estimate resources, costs and time”.

Chapter 6 covers the practical steps needed to create a WBS that aids project delivery. The author walks the reader through a 20 step model to create the WBS. This begins with understanding the required inputs and closes with baselining the identified project scope.

Chapter 7 discusses software tools that can be utilised to visually represent the WBS. Visual WBS’s are considered as either being a tree structure , text based outline or a spreadsheet based tabular format. Software such as Microsoft Word, Excel and Visio are covered as is MindManager and others.

Chapter 8 explains how the WBS can be integrated with the management of scope. The author argues that “it’s almost all about scope and how to better manage it. The scope is the basis for planning.” The chapter advances the sensible concept that we must, as project managers, understand the scope of the project and that the WBS is a key pillar in this strategy.

Chapter 9 shows how the WBS can be used to derive resource and cost schedules including why this should be done and offering practical advice on how to do it.

Chapter 10 demonstrates how the project manager can integrate the WBS with stakeholder and risk management. The central thesis of the chapter being that the WBS can be exploited for uses beyond pure scope management.

Chapter 11 and 12 close the book by exploring its use in virtual, multicultural and agile environments.
The book closes with a conclusion and 2 appendices encompassing 2 generic WBS templates.

The book provides an interesting view on the WBS. The author conveys an obvious passion for the subject which draws the reader in. The practical advice is relevant and every project manager should be able to take something from this book and apply it to their project management practice. I recommend this book to any project manager looking to broaden their understanding of this powerful project management process.