Tuesday, 24 May 2016

Project Success - "Projects are like Chalk and Cheese"

This is the third part in my thoughts on Project Success:
The key points from the first two parts are:
  • Project Success cannot be judged by the triple constraint.
  • The triple constraint of time cost and scope only address the project efficiency dimension of success.x
  • Different projects have different success measures depending on your point of view as a stakeholder
  • Shenhar and Dvir identified five dimensions of success which could be used as a model to identify the success criteria for a project
  • Success criteria has to be built into the project from the first step and then reflected in its plan, demonstrating how the project will deliver the outcome
I believe this evidence also points to the need for an organisation to develop its PM reward system to be based on more than just the traditional triple constraint. 

Sunday, 8 May 2016

Wish for Serendipity, take advantage of the fluke, and never trust to dumb luck!

Graph Cartoon 7231: Serendipity is up, fluke is doing well, but I’m a little concerned about our dumb luck.
Of course we all want Serendipity to visit us on our projects, we welcome help from any source. A Project Manager can increase the chances of our friend Serendipity visiting the project by:

  • Being alert, 
  • noticing what others do not see, 
  • putting together the project jigsaw as the new pieces emerge in the form of issues, ideas etc...

How does this all relate to project success?  

Successful projects do not just happen. A Project Managers career is going to be a short and painful one if they do not understand how to set up their projects to be successful. 

Before we get into how to make the conditions right for project success let's look at project success from the traditional project perspective.

Success from the Project Perspective

Traditionally project success was measured against delivering against the Iron Triangle - basically project management efficiency. 

We often hear the mantra "delivered on-time, within budget and what was specified" as the project manager doing what is necessary to be successful. The whole PM industry has been focused on driving for this performance. 

To help us meet these three key performance indicators we have developed more PM processes and best practices than you can shake a stick at, but we seem to continually struggle in our search for success. Despite all this effort project statistics still show that many projects are recorded as unsuccessful. 

Success from Business Perspective

This published whitepaper at PMI Research is rethinking the triple constraint, it  clearly shows the profession is changing its perspective on what constitutes a successful project, moving away from the project outputs based on the Iron Triangle, towards Business outcomes.

The opening paragraph from PMI research on project success also provides more context on why the delivery of a project to the triple constraint is not sufficient for it to be deemed successful.

"Projects are the vehicles of change. Projects are provided funding and resources not so they can simply be delivered on time, within budget and according to scope; but because they help drive the necessary changes, both individually and organizationally, that create value for the organization."

I agree with this thought, and I believe that organizations require project to be successful beyond meeting the basic iron triangle. I also believe that PMO's should be striving to establish the environment and conditions to ensure every project is successful, before the project is even launched.

Why are Projects Unsuccessful?

We have known for years what factors contribute to making project unsuccessful. The National Audit Office and the OGC in the UK published a paper identifying the top reasons why project fail (see box three extracted from British Computer Society Report).


None of these reasons are new, and the sad fact is they are as valid today as when they were published over 12 years ago. The main problem I see is that despite knowing these factors to be true, somehow executive leaders do not believe that they apply to their projects....

So what can be done about this? 

As PM Professionals we have a duty to help shine a light on what project success is, and we should be promoting how to help our organizations improve the success of their projects.

In Chapter 12 of "Project Planning and Project Success: The 25% Solution" (P Serrador) brings together an impressive collection of literature review and research on the linking of project planning to project success. His conclusion  

"From this table, we can see that the preponderance of the literature has found that planning and the level of completeness of planning are important for project success.From the literature review alone we can answer the question: Is planning important for project successThe answer is yes.".

This would appear to also bear out the influence of point 7, and partially point 4 from the OGC table above.

In "Reinventing Project Management" Shenhar and Dvir point to integrating the project success dimensions (see previous post) in to project planning (p.33). They include a view that project managers are responsible for achieving success in all dimensions. On page  35 they identify Key Points and action items for developing the environment for success.

I have included links in this post to white papers / reports and other sources of information to help you understand the conditions and factors for enabling the successful environment for your projects. I hope you find them useful to back up your arguments / actions by demonstrating they are based on solid evidence.  

Look Forward
In the next post I will explore the project success factors, and how they fit with different types of projects.

Additional Sources / Research
The Relationship Between Project Success And Project Efficiency  (you can get this well researched paper for free if PMI Member it is a paper in the Project Management Journal)
Conditions for Project Success
Factors in Project Success
Interesting Paper on Serendipity in Product Development
Complete collection of Project Management Statistics

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 AllPM.com 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 Allpm.com.
Click on the title to go to the article.