Saturday, 4 June 2016

Project Success - Part 4 - Reasons to be Cheerful


Wrapping up this series on Project Success I want to revisit some of the earlier themes and identify what you as the Project Manager or Project Owner can do to enhance the likelihood your project being judged a success.

We have already identified in previous entries that a key theme of success is to understand what type of project the organization is initiating or selecting.  

Organizations tend to opt for simplistic assessments of project type. They often equate difficulty of their projects based on size
  • how big the scope is
  • how large a budget will be required
  • estimated time / duration for the project
  • team, etc... 
They use $ and estimated counts to categorize their projects and it is true that bigger projects have a higher risk of failure. However, while size of project brings its own set of unique challenges, the real issues that drive the difficulty of projects are:
  • complexity in the solution, and the stakeholder relationships
  • uncertainty of requirements, or in the project environment
  • urgency of delivery
These issues bring an order of magnitude increase in the difficulty of a project, well above the challenges of a large big project.

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. 

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). 

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.

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.
The diagram below illustrates the context of Programs as a vehicle for delivering strategy 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.