What are the Benefits from doing project work?  Does anyone review the Benefits?

Project work should be all about benefits.  A project without clear benefits should not be undertaken and while these benefits may be intangible we would hope that some of the benefits are tangible (can be financially quantified).  Ideally for commercial organisations there should be some level of financial justification present (these kinds of things keep shareholders happy).  Documenting the benefits in the business case at the beginning of the project is standard practice for mature organisations. 

Benefits realisation is the measurement of the benefits achieved through the new capabilities created by the project team.  This may be as a result of introducing a new computer system, building a bridge to connect 2 sides of a river or renovating a house so the family can grow.  In order to conduct benefits realisation, you need to have those baseline measures in place at the beginning of the project.  For example, if you are undertaking a project because you want to increase your market share by 8%, it is important that you understand what your current market share is before you begin the project.

Once you have established your benefits, then you need to plan for when they will be realised.  It is possible to realise benefits during a project (think Agile teams or teams that conduct Pilots) but typically the realisation of benefits will come post project.  The project manager should prepare a Benefits Realisation Plan (known as a Benefits Review Plan under the PRINCE2 Methodology).  This plan will outline who should conduct the benefits review, when it should be done and how.  The PMBOK makes no mention of Benefits Realisation and focuses more on the handover of the project product to the operational area.

Interestingly enough there is significant research around to suggest that many companies do not conduct benefits realisation (typically more than 50%) or have trouble realising the benefits even if they do go to the trouble of measuring the benefits after a project.

Points to remember:

1.     Identify benefits at the beginning

2.     Include financially quantifiable benefits for a stronger business case

3.     Create a plan for when and how benefits will be realised

4.     Execute the plan so you can demonstrate the value the project has brought to your organisation

5.     Celebrate the success!

If you would like further information on the topic above please contact us or consider one of our project management training courses to improve your knowledge.

The Project Manager's Body of Knowledge (PMBOK) defines an estimate as "A quantitative assessment of the likely amount or outcome"¹ . Estimating is applied to a number of project parameters including effort, resources, cost etc.  

When estimates are provided they should include a descriptor so that the person being advised of the estimate understands how firm the estimates are.  Typical descriptors include "preliminary estimate, order of magnitude and definitive".

Some people view project estimating as black magic more than science.  In reality, estimating for a project is often a combination of experience, metrics and measurements.  There are a number of ways to prepare estimates including parametric, analogous, top down and bottom up to name a few approaches. 

One of the more successful estimating techniques (particularly for IT projects) is the Delphi technique.  Over time it has been shown to be a successful method for developing more accurate estimating.

If you would like more information on estimating contact us.

And finally, remember to always start your estimates with effort (not duration).  Good luck with it!

1  A Guide to the Project Management Body of Knowledge - Fourth Edition © Project Management Institute.

This is a question we get asked all the time from people looking to improve their project management knowledge.  People want to know - which is better?  The Project Management Body of Knowledge (PMBOK) or the PRINCE2 Project Management Methodology.  First lets look at some background information on these two items.

The PMBOK (formally known as the A Guide to the Project Management Body of Knowledge) is a recognised standard for the project management profession.  It is based on good practice in the project management community and covers those practices which are considered applicable to most projects most of the time.  The publication clearly states that it is a guide and not a methodology.  

People wishing to attain accreditation with the PMBOK can either sit the Certified Associate in Project Management (CAPM) exam or the Project Management Professional (PMP) exam.

Unlike the PMBOK, PRINCE2 is a methodology.  It is one of the most widely accepted methods in the world for managing projects.  The PRINCE2 method is based around a series of underlying Principles along with seven Processes which show the project manager how to manage a project under the PRINCE2 method.  There are also a series of project management Themes.

People wishing to attain accreditation under the PRINCE2 method can choose to progress only to the Foundation level or can go on to a Practitioner level (recommended for project managers).

So which is better?  Well it depends.  The two are not mutually exclusive and we usually recommend to professional project managers that they are across both. 

PRINCE2 dominates in the government sector and is also very popular with organisations that prefer a structured approach to their projects (i.e. it is commonly used in the pharmaceutical sector).  With a background in IT projects, it is also very popular for IT project teams.  To use PRINCE2 successully it needs to be embraced by the organisation or at least at the department/divisional level.

The PMBOK is very popular in the construction, engineering and mining sectors.  The PMBOK covers topics such as different types of contracts and earned value calculations.  These are not covered in any detail in the PRINCE2 method.  It provides a project manager with a toolkit to go on and manage projects in a professional manner.  As the PMBOK is a guide, a project manager can apply the concepts contained within even if the organisation is not a "PMBOK shop".

If you would like further information on PRINCE2 or PMBOK feel free to get in touch.

So what tool should we be using to avoid this?  It is known in the industry as lessons learned logs and lesson learned reports.  So lets start with a definition.

Lessons learned: Items that went well or badly on a project that should be recorded so the organisation can benefit from the knowledge in the future. 

You may choose to record lessons at any time.  Traditionally PMs do it at the end of the project but if you work on long engagements then it makes more sense to record lessons at the end of every stage or phase.  The chances of you remembering in detail something that happened in the first month of a 18 month project at the end are slim (unless you are alot smarter than your average PM).  So jot them down as you go and then the end project report summarising the lessons will write itself.

The next trick??  Trying to find those Lesson Learned reports from other PMs.  That is a whole other post.

This week I want to look at the roles in an Agile project and how they interact with a more traditional project management method such as PRINCE2 (and the concepts laid out in the PMBoK for PMPs and CAPMs). 

What is Agile? 
Lets have a look at what the Agile Manifesto (www.agilemanifesto.org) says.  It outlines 4 ideals.
1.     Individuals and interactions over processes and tools.
2.     Working software over comprehensive documentation.
3.     Customer collaboration over contract negotiation.
4.     Responding to change over following a plan.
 
Below is an extract from a white paper being presented at the upcoming APMG Best Practice Showcase http://www.bestpracticeshowcase.com.au/ .  The full paper will be posted after the conference takes place this Friday.

Both PRINCE2 and Agile approaches describe specific roles and responsibilities.  The question is how do we move some of the Agile roles such as product owner, Scrum Master etc into the structure.

Agile Roles - Possible mappings
Product Owner
Most of the literature places the Product Owner as either the Senior User or the Project Manager (proxy for the Project Board).  The Project Manager will only work well as a Product Owner if they have a user/customer focus.  If the Senior User is going to take the role they need to be committed to the time investment that is required in the role of Product Owner.  It is generally more time intensive than the traditional PRINCE2 Senior User role.

Scrum Master
The Scrum Master for small projects can be the Project Manager.  This assumes the PM can move away from a command and control approach to a more facilitating approach. 
 In projects where there may be multiple teams, multiple sprints etc then it may be wise to have a Scrum Master for each sprint team.  The Scrum Master essentially takes the Team Manager/Team Lead role under the PRINCE2 model.  In this latter approach we would leave the Project Manager role in place with the overall view of the project.

Team
The Team in an Agile structure will resemble the PRINCE2 Team Members.  Typically agile teams are small (5-9) and self organizing.  There is no need for a team manager in the traditional sense.

If you want to read more on the whitepaper this was extracted from visit our online resources area for the complete paper.

If you are interested in learning more about PRINCE2 or PMP/CAPM please check our online schedule http://www.bluemaple.com.au/training/

The spin off from this whole saga is that anyone running large projects or working in the program space on Queensland Government contracts are about to find governance takes on a whole new meaning going forward.  And I pity any PM who has a SAP payroll rollout planned later this year in a government department in the Sunshine State.  Suffice to say they will be receiving more than their fair share of attention from our friends in project assurance.

This week we are going to look at project business cases.  First of all we are going to start with a definition of a business case.  There are lots of variations with respect to the exact definition but the intent is usually the same.  Let's look  at the PRINCE2® manual and the PMBoK® Guide (the PMP® and CAPM® reference text) as a guide for our definition. 

PRINCE2 says the business case is something that can be used to justify a project and can also test the ongoing viability of a project.

The PMBoK says that the business case is used to determine whether the investment is worthwhile.

So I think we can agree that a business case will provide the justification we need to determine whether someone's idea for a project should actually become a project (i.e. there is value to the business).

Now that we know what a business case is, we can look at the kinds of things we normally include in one. 

Let's include some background information so those reading the business case can understand the context.   We can also note the reasons for undertaking the project.  This will help those reading the business case to understand why the project is being considered.   This should include a statement directly linking the project to the direction of the company.  We do this by strategically aligning the business case to one or more of the corporate objectives. 

Business cases are all about demonstrating the value of a project so one of the key elements to a business case will be the relationship between costs and benefits. Ideally you can demonstrate some financial benefit to your project and thus provide a clear comparison between costs and benefits.  However in certain situations (regulatory/compliance projects) there may be overriding factors that mean an in-depth financial analysis is unnecessary.

Other information to include?  You should include an estimate of the timeframe over which the project will run.  You might also mention key risks that may affect the project

 And finally how should you present it?  For a small project or an informal organisation the business case might be a presentation with the information summarised on a series of presentation slides.  For most projects in most companies, the business case will be a document that can be distributed for approval.  In the more complex situations, the business case may be supported by many pages of financial calculations demonstrating the financial value of the project to the organisation.

Want to learn more about Business Cases?  Contact us at info@bluemaple.com.au or join one of our classes.  All our courses (including Project Management Fundamentals, PRINCE2 and the PMP/CAPM) touch on Business cases.

Next week?  Agile and PRINCE2 - can they co-exist happily?

Each post we are going to offer a definition and explanation for some area of project management.  Today we are going to look at Project Mandates.

The term Project Mandate refers to information that will be used to start preliminary investigations into whether a project should be pursued.  The Mandate may be verbal or may be a documented request. 

The term Project Mandate is used in methods such as PRINCE2®.

Information that is often found in a Mandate may include:

• Background to the idea
• Customers who will benefit from the project
• Responsible authority
• Project Objectives
• Scope
• Constraints, interfaces and assumptions
• Ballpark figures on project size and duration

The content may vary from project to project but the purpose is always the same - provide sufficient information so further investigations can be undertaken to determine the viability of the project.

Next post....we will look at project Business Cases.