Sunday, 1 May 2016

How do you measure Project Success?

Projects are everywhere in business and life and we have a myriad of books, professional bodies to help build skills and knowledge needed to manage a project. We are training and certifying project managers for their knowledge and understanding to ensure we have a professional to manage the project. But the consensus seems to be that we are still doing projects badly with 30% failing (depending on which figures you look at this could be as high as 70%). 

In these austere times we cannot afford to waste resources $ and peoples time on failures. We need to pick the right projects and we need them to be successful.

So if projects are still failing how can we (project management professionals) significantly improve the chances of success beyond the definitions and guidance written in the BoK's and Best Practices?  

I believe one thing we can do is create a common understanding of what is meat of project success and how we can significantly improve the project outcome to enable it to be successful.

Hence the subject for May will be to explore "Project Success" and how do we demonstrate it to the project stakeholders (which group care about what measures). 

The sources for this months posts are:
Reinventing Project Management: The Diamond Approach to successful growth and innovation - published by Harvard Business Review - Authors Shenhar and Dvir 
Project Planning and Project Success—The 25% Solution: - published by CRC  - Author Pedro Serrador, PHD
Both books are available from Amazon and Project Planning and Project Success is available on Books 24x7 if you have access.

Over the next four weeks we will be exploring the definitions of success, the how the different PM processes and tools contribute to success with the intention of identifying the attributes of project management that greatly increases the chances for success. 

I will be publishing weekly and at the end of the month I will create a summary of the findings and comments. 

The first question is, what is project success?

  • Is it delivering the project to satisfy the iron triangle (Cost, Time, Scope/Quality) ? 
  • or is it meeting or exceeding stakeholder expectations and if so which stakeholders are the most important?

In legal terms, on-time, within budget and delivered what was specified is classed as success. The Body's of knowledge used this as a mantra for years, however gradually they are moving to include some additional attributes of success. Such as "Customer Satisfaction", "Achieving the business outcome in the business case". 

We often hear the project supplier use the words "the product was delivered on-time, within the cost and to your specifications". This may be true, but from the customer perspective still the project is seen as a failure because it doesn't really meet their needs.

Dimensions of Success Beyond the Iron Triangle

In "Reinventing Project Management" Chapter 2 Shenhar and Dvir identify five main dimensions of project success:

  1. Project Efficiency (on-time, within budget and to specification)...
  2. Impact on the Customer
  3. Impact on the Team
  4. Business and direct success
  5. Preparation for the future
Serrador refers to similar dimensions of project success:
  1. Project efficiency: Meeting cost, time, and scope goals; and 
  2. Project success: Meeting wider business and enterprise goals.
He collected data on over 1,300 projects from 60 countries and conducted detailed statistical analysis and came to the conclusion that the 2 aspects of success are interlinked and the project shouldn't disregard either dimension of success. He states that Project Managers should consider building broader success criteria into their project definitions at the beginning.

Shenhar and Dvir highlight the broader success dimensions over the longer time period than the normal project timescale.

In my own observations I see that for projects to be successful they generally depend on two intertwined aspects of the project. 

  1. Developing the solution of the problem or opportunity the organization has set as an objective.
  2. Preparing the organization to adopt the solution so that it can take advantage of the new capabilities the solution provides.

Failure to prepare the organization for the new solution often creates challenges of adoption and therefore the longer term success. 

Over the next four weeks I will explore how the two books identify how to improve the chances of success for the projects and what practical steps project managers can take to enhance the chances for success in their projects.

Saturday, 23 April 2016

Operation Revitalise!

It has been a while since my last entry 
(sounds like the start of a confession). 

Well I am back in the saddle and ready to start blogging and helping improve the Project Management Competency of whomever wishes to read my musings.

Over the next 8 months (the rest of this year) I will be focusing on set subject themes for each month with the occasional drift into where-ever the conversation goes.

These are the themes (but I am open to requests/suggestions).

  • May: Project Success
  • June: Portfolio Management
  • July: Transformation Projects
  • August: Stakeholder Engagement
  • September: Issue Management (revisited)
  • October: Risk Management (the sister of Issue Management)
  • November: Governance in all it's forms 
  • December: Estimating and Planning - A refresher of a core skill
These new blogs will include books to review/read. At the beginning of the month I will publish details (titles etc...) of the book or books that I am going to be reading to study the subject.

I'm looking forward to revitalising this blog with some lively relevant content!

Suggestions for potential postings within each month welcomed.

If you want to know more about me then you can view my profile on linkedIn 

Wednesday, 11 June 2008

Project / Program / Programme Governance

Definition of Governance

In the previous blog entry I defined Project Governance as:

Project Governance is the process of developing, communicating, implementing, monitoring, and assuring the policies, procedures, organizational structures, and practices associated with a given project.

The combination of these policies, procedures etc make a governance framework to facilitate efficient and effective decision making. Efficiency meaning economically in terms of time and effective being the right decisions for the right problems.

Governance or Project Control is all about decision making and is central to project / programme management. The purpose of control is to ensure that the project or program is producing the required products that meet the defined quality criteria, is being carried out on schedule and as agreed with the resource and cost plans. This also applies equally to programs but adding the requirement to deliver the benefits to meet the program objectives.

The framework could be broken down into its constituent parts such as:

Policies:The policies that help guide the behaviour of the project staff within policy areas.

  • Tolerance for a stage overrun within which the PM can accept changes to scope without having to refer to the project board. i.e. the current stage can overrun by 10% of time and 5% of budget without the PM having to raise a exception report to the Steering Committee Executive (Project Board). I will review the concept of tolerance in another post.
  • Releasable product: The definition of what constitutes a releasable product i.e. definition of the severity of incidents and the acceptable number at each level for a releasable product.
  • Quality Policy
  • Expense Policy (could be taken from the corporate policy)
  • ....
Procedures: This would be a set of Standard Operating Procedures (SOP's) that would ensure consistency of managing different areas of the project control.

  • Scope Management procedure
  • Change Management procedure (scope change management)
  • Risk Management procedure
  • Issue Management procedure
  • Work Authorisation procedure
  • ....

Practices: These are the techniques, processes and methodologies used in the governance of the program / project.

  • The use of Stage Gates for program and project control
  • Breaking projects into stages to facilitate control
  • Using Quality Review Technique for approval of products
  • Conducting Project Audits to ensure compliance to procedures
  • Conducting weekly project team meetings where progress, issues, risks and work are discussed
  • Conducting weekly or as required Change Control Board meetings to discuss the change requests and those that are acceptable are assigned for impact assignment and the impact assessments for those in the pipeline are reviewed and accepted, rejected or escalated for Steering Committee Executive authorisation (with an exception plan showing how the change will effect the project)
  • ....
The organization's management may include the program governance into the organizations overall governance model. This will ensure that the program and its related projects will comply to the wider organization governance. Typically these include regulatory and financial governance frameworks around privacy, security and investment appraisal.

Now we have defined the framework from a policy, procedure and practices point of view we need to include an organization structure that provides authorizations, decisions and guidance to the program / project.

PRINCE2 provides a well documented separation of the management of the project from the work needed to produce the products. The fundamental principle is that the project organization has four layers:

  1. Corporate or Program management
  2. Direction of the project
  3. Day-to-day management of the project
  4. Team management
The first layer initiates a project and defines the overall constraints. The project management team perform the next three layers.

The next few paragraphs are taken directly from the PRINCE2 manual.

PRINCE2 provides a structure for a project management team that supports

  • Roles for decision makers
  • Management by exception for the decision makers
  • Full time or part time project management
  • Controlled delegation of some day-to-day management responsibilities, where required to team managers.
  • Roles for independent inspection of all aspects of project performance
  • Administrative support, as required to the project manager and team managers
  • Agreement by all concerned on what the various roles and responsibilities are
  • Lines of communication between the project management team members
The organization structure has many names; project board, steering committee, project control board, Steering Committee Executive etc...

The structure is a temporary one designed to manage the project / program to its successful conclusion to meet the requirements of its charter. The structure allows for channels of communication to decision making forums and should be backed up by role descriptions that specify the responsibilities, goals, limits of authority, relationships, skills, knowledge and experience required for all the roles in the project/program organization.

The Project Board is the group responsible for ensuring project/program goals are achieved and providing support for addressing escalated risks and issues.

The three project interests must be represented on the project board at all times.

  1. Business
  2. User
  3. Supplier

The project executive / executive sponsor is ultimately responsible for the project supported in the Project Board by the Senior User and Senior Supplier. He or She owns the Business Case and balances the demands of the User, Supplier and Business . Their responsibilities include:

  • approve Project Board
  • ensuring tolerance is set in the Project Brief
  • approving End Project Report and Lessons Learned Report
  • organising and chairing Project Board meetings
  • acts as communication channel to the Program
  • ensuring business assurance is met - i.e. that the project is delivered in time and on budget, meeting the Business Case
  • informing the project of any Program influences

The senior supplier is a member of the Project Board along with Project Executive and Senior User. The Senior Supplier represents the interests of those designing, developing, facilitating, implementing and possibly operating theprojects products. They are responsible for:

  • agreeing the objectives for the supplier activities
  • needs to ensure the project achieves the results required by the Senior User
  • ensures that the designs and proposals are realistic within the cost and time parameters for which the Project Executive is accountable
  • represents the interests of those designing, developing, procuring, implementing and possibly those maintaining and operating the supplier products
  • if there is more than one supplier there may need to be more than one Senior Supplier

The Senior User Represents the Users needs and expectations, ensuring these are meet within the constraints of the Business Case; They are responsible for:

  • Promoting and maintaining focus on the desired project outcome
  • should re-evaluate the priority of a Project Issue after impact analysis
  • can be asked by the Project Manager to canvas the Project Board for agreement to implement a Project Issue
  • is accountable for any products supplied by the Users (i.e. defined requirements)
  • providing User resources and ensuring that the solution will meet User needs within the constraints of the Business Case
  • ensuring the products and outcomes provide the expected User benefits
  • Project Assurance from a User perspective
  • May be represented in some cases by more than one person

A Program Board can have a slightly different composition depending on what type of program it is. However the basic responsibilities are the same as the project board with each perspective being taken into account on program decisions.

Primary responsibilities of the Program Board / Steering Committee Executive are:

  • Appoints and defines delegated authority of: the Program Manager, Program Executive, Program Director and Program Assurance (if delegated by the Program Sponsor)
  • Approves budgets and sets financial tolerances
  • Monitors overall Program progress and ensures corrective action is taken as required
  • Monitors overall financial status and ensures action is taken as required
  • Owns overall Program changes, risks, issues, dependencies and constraints and ensures appropriate action is taken
  • Ensures the Program is aligned with the needs of both the Client’s and the Supplier’s Businesses (win:win) and will achieve the objectives that have been set
  • Sets and monitors priorities for the Program
  • Approves proposed changes to the Program scope and subsequent Program plans and time-scales

The Program Manager reports to the Steering Committee Executive and Executive Sponsor. The role manages overall program delivery and carries out day-to-day management of the Program. It is the key link betwee projects and the Program.

Primary responsibilities are:

  • Provides the program team with direction and ensures effective communication of that direction (leadership).
  • Ensures that the program management environment is put in place (e.g. relevant evelopment processes are implemented effectively across the program).
  • Ensures adequate resourcing of the Program and constituent Projects
  • Secures Contractor/Supplier resources for the Program
  • Monitors changes in the Program component projects.
  • Monitors risks, focussing on dependencies and constraints between projects.
  • Ensures that the constituent projects interface successfully with each other and with the wider business environment (i.e. that dependencies and interfaces between them are managed at a program level).
  • Addresses cross-project issues including resourcing conflicts (e.g. staff, business time, release slots) and declared or actual slippage against dependencies and program level deliverables.
  • Authorises and monitors expenditure of the Program budget (in line with the agreed delegated financial authority)
  • Agrees appropriate program level deliverables (e.g. technical and quality strategies)
  • Liaises with Program Assurance as appropriate.
  • Reports program status to the Program Board and Program Executive

The Program Office Manager reports to the Program Manager, with overall responsibility for the Program Office which is a key function providing a ‘centre of excellence’ for the program and its delivery objectives. Integration and consistency of information is vital for informing management decisions, The Program Office is responsible for all aspects of information and knowledge management across the program.It is possible for this role to be extended to cover the wider aspects of Program Control.

Primary responsibilities are:

  • Manages the following functions at Program level
    o Program Plan
    o Program Budget
  • Provides the Program with specific Programme/Project Management processes, procedures and standards for the production of:
    o Program Plans
    o Project Plans
    o Work Packages (Projects)
    o Highlight Reports
    o Program Board status reports
  • Maintains an accurate and timely record of Program status in terms of:
    o Plans
    o Changes
    o Budget
    o Costs
    o Work Packages
    o Products Delivered
    o Risks and Issues
    o Resources (timesheets)
  • Ensures that the Product Review process for the Program is managed efficiently and effectively
  • Manages the Program Document Library and ensures that it is available at the point of use

The Business Change Manager provides valuable user-side input and assurance to the projects within the program. The business change manager may even fulfill the senior user role for some programs. The role of the business change manager often call the Change Agent has responsibility for benefits definition and management throughout the program.

The typical responsibilities of a Business Change Manager are:

  • Ensure Program meets sponsoring group’s requirements
  • Work with Program director and Project Managers to deliver and sustain the defined benefits for the areas they are responsible for
  • Work with the Program Manager to identify how the benefits will be realised and sustained
  • Work with the program manager to ensure that the portfolio of projects, initiatives or work packages that the program contains will provide the ability to deliver the required program benefits
  • Assist the program manager to identify benefits that may be common to more than one program / project
  • Assist the Program Manager in identifying any duplicated activities that may exist in the portfolio in respect of realising benefits
  • Plan and implement any preparatory work needed to ensure the areas that they are responsible for are prepared to deal with any revised business processes or ways of working that are required to achieve the defined benefits
  • Establish the way that the benefits will be delivered and how the impact of these benefits can be assessed.
  • Ensure that as the projects, initiatives or work packages are delivered the business areas achieve the planned improvements in new or existing business processes
  • Lead all the activities needed to achieve the benefits and ensure that activities are in place to ensure sustainability

Business change managers should also have the change management skills amd enough experience to be able to bring order to complex situations and maintain focus on the programs objectives.

Establishing the optimum organization for a program means defining the roles and responsibilities and governance structures. The organization, structures and roles discussed in this blog provide the basis for effective project / program management. They are not intended to be used as is but with some tailoring to suit the project and program. This can be done as part of the project / program initiation stages.

Thursday, 29 May 2008

What is the Difference between Projects and Programs?

When I talk to Project and Business Managers about program management they often ask questions like:

  • "Are programs just big projects and shouldn't we manage them like that?" or
  • "What is the difference between projects and programs?"

The PMI definitions of a Project and a Program are:

  • A project is a temporary endeavour undertaken to create a unique product, service or result such as implementation of a solution, infrastructure etc.
  • A Program is a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually. Programs may include elements of related work outside the scope of the discrete projects in the program (such as transition to operations and then ongoing until the benefits are realised).

The PMI definitions for Project and Program Management are:

  • Project Management is the application of knowledge skills, tools and techniques to project activities to meet the project requirements.
  • Program Management is the centralised coordinated management of a program to achieve the programs strategic objectives and expected benefits.
Below is a diagram to show the context of Programs and consequently program management.

Another key difference between program's and projects is the focus of the management.

Program and project managers differ in their perspective, the lists below highlight the differences.

  • Projects have a narrow scope with specific deliverables. Programs have a wide scope that may have to change to meet the benefit expectations of the organization.
  • The project manager tries to keep change to a minimum. Program managers have to expect even embrace change.
  • Project success is measured by budget, on time, and products delivered to specification. Progam success is measured in terms of Return On Investment (ROI), new capabilities, benefit delivery
  • Project leadership style focuses on task delivery and directive in order to meet the success criteria. Program leadership style focuses on managing relationships, conflict resolution. Program manager’s need to facilitate and manage the political aspects of the stakeholder management.
  • Project managers manage technicians, specialists etc... Program managers manage project managers
  • Project managers are a team player motivating by knowledge and skills. Program managers are leaders providing vision and leadership
  • Project managers conduct detailed planning to manage the delivery the products of the project. Program managers create high level plans providing guidance to projects where detailed plans are created.
  • Project managers monitor and controls tasks and the work of producing the projects products. Program managers monitor projects and ongoing work through governance structures.

The basic difference is that programs are responsible for delivering outcomes (benefits, new capabilities) whereas projects are primarily responsible for delivering solutions or products that enable the outcsomes to be achieved.

Programs are a means of achieving organizational goals and objectives, often in the context of a strategic plan. Projects are a means of achieving tactical goals and objectives.

These fundamental differences mean that managing a program is not just BIG PROJECT MANAGEMENT.

Wednesday, 14 May 2008

Project Early Warning System

I have written several PM articles for and early this year the editor emailed me and asked if I could contribute something in January to help them through the slow month. I agreed and wrote an article on issue management.

Unfortunately they get the copyright of articles on the web, so rather than duplicating the article I thought a link would help. Also it saves me having to write a entry :~)

The title on this entry is linked to the article in the January edition of
Click on the title to go to the article.

Monday, 5 May 2008

Foundation for Project Success

Successful project delivery seems to elude many project managers both professional and amatuer. This post hopes to promote some discussion on how the success of a project is shaped during its initiation.

PRINCE2 (UK Project Management Standard) starts by defining Projects as:

  • 'management environment that is created for the purpose of delivering one or more business products according to a specified business case'

Another definition provided in the PRINCE2 manual defines a project as:

  • 'a temporary organization that is needed to produce a unique and predefined outcome or result at a pre-specified time using predetermined resourcs'

PMI(Project Management Institute) defines a project as:

  • 'A temporary endeavour undertaken to create a unique product, service or result'

Either of these standards provide definitions that focus on the temporary nature and the unique product or outcome. This temporary nature and uniqueness often requires people who are going to come together temporarily and collaborate to build or achive the unique result.

Instantly we are thinking (well those who are PM minded); how do we identify the people/resources needed, how do I communicate the need to collaborate and ensure they all understand the objectives, scope of the products/results/outcome, the constraints we have to work within such as time, cost and quality?

The simple answer is you need to conduct some sort of pre-project planning and project initiation in order to answer those questions and establish the temporary infrastructure for the team to operate within. What should be included in the pre-project pleanning and project initiation? Rather than re-inventing the wheel lets turn to an establish Project Management Frameworks such as PRINCE2 to provide us with process definitions , inputs, outputs and the guiding principles already.

The Project Management Framework(PMF) should not cover the specialist techniques used to create the technical products or outcomes as this is the job of other methods. The PMF should focus on the management of the project and its resources being involved in carrying out the project tasks and activities.

PRINCE2 is a useful framework because it has been developed to be a PMF within a contract context and many projects are run within contracting context.

PRINCE is an abbreviation of PRojects IN a Controlled Environment. The controlled environment within PRINCE2 extendeds to include a controlled start, controlled progress and controlled closure. This project control is supplemented by the well defined governance structure that provides a controlled project assurance. (The number 2 on PRINCE2 came about when it released version two. This practice was stopped at Version 2.)

Starting Up a Project (SU)

Prince2 has a process called 'Starting Up a Project' to help start build the foundations for the project. The process produces six key elements:

  • Designing and appointing the project management team
  • Assembling the project brief
  • Establishing the project approach
  • Establishing the customers quality expectations
  • Setting up the project risk log
  • and creating the Plan for the Initiation Stage

There are several tips for scaling the process depending on the possible initiation point:

  1. In a standalone project then all the steps of the process can be applied.

  2. If the project is part of a program they program can pass down the documentation either as a complete project brief or even a project initiation document (project plan in PMI terms). The program management may have already decided the project approach and the risk log could be included in the program risk log. In this case this process can just be a check to whether any more work needs to be done on the start up products.

  3. The 3rd possibility is that the project is very small. In such cases the process can be usually be handled in an informal manner, possibly just taking a few minutes. A project manager should avoid the templates and bypass the process going straight to the Initiating a Project (IP) process.

Initiating a Project

This process aims at laying the foundations for the delivery of the project products/outcomes. It follows the Starting Up a project (SU) process within the framework. Its purpose is to draw up the contract between the project board and the project manager and the organization receiving the products so there is a common understanding of:

  • The reasons for doing the project
  • What key products the project will produce
  • How and when these will be delivered and at what cost
  • The scope of what is to be done
  • Any constraints that apply to the product/outcome
  • Any constraints that apply to the project
  • Who is involved in project decision making
  • How the quality required by the customers will be achieved
  • What risks the project will be facing
  • How is the project to be controlled through governance structures
  • Who will receive what communications
  • The production of plans in detail for next stage and in outline for the rest of the project

The PRINCE2 manual provides advice on scalability similar to Starting Up a Project (SU) the advice depends on the trigger and size of the project.

The processes within IP are:

  • IP1 - Planning Quality
  • IP2 - Planning a Project
  • IP3 - Refining the Business Case
  • IP4 - Setting up Project Controls
  • IP5 - Setting up Project Files
  • IP6- Assembling a Project Initiation Document (PID)

Project Governance

Project Governance is the process of developing, communicating, implementing, monitoring, and assuring the policies, procedures, organizational structures, and practices associated with a given project. The result is a framework for efficient and effective decision-making and delivery management focused on achieving project goals in a consistent manner, addressing appropriate risks and stakeholder requirements.

The Project Board is the group responsible for ensuring project goals are achieved and providing support for addressing project risks and issues.

Click on the image to enlarge

Within PRINCE2 there is a process group that the Project Board is responsible for. This process is called Directing a Project (DP) and this process will be discussed in another posting.


Project initiation provides a firm foundation for a project's success and research by NASA on project planning has shown that project success depends on sound planning during project initiation.

A controlled start depends on establishing the core structures and products that will be used to manage the delivery of the project's products / outcomes. The project initiation is an essential process for all projects however scalability can reduce the tasks from production of documents to review and update when Project Initiation Documents and the associated plans are provided for the project manager to use.

The key to a project's success largely depends on a successful project initiation and the establishment of the project organisation and documents and plans.