Stakeholder's manage or engage?

:-) Steak-Holder

In my previous blog entries I have shown how the success of a project is measured, and that success is clearly related to the level of adoption of the project solution.  Therefore happy stakeholders are key to successful projects. 

In 1998 a UK National Audit Office report identified lack of effective engagement as one of the common causes of project failure. Again in 2009 this reason was cited as a common cause of project failure.

This is 2016, hopefully we have learnt enough about the impact of poor change management that we do not want to spear our stakeholders and force them into yielding to an imposition of a solution. If we follow this approach to implementing solutions then we are treating our stakeholders to divide and conqueror approach to implementation. 

The purpose of this post is to explore the differences between Stakeholder engagement and stakeholder management. Providing a discussion, thoughts and steps you can take to improve your stakeholders participation in your next project.

Back to the Future for tips on stakeholders and other puzzling influences!

In 1985 I left the British Army to start a new civilian career in a recession hit UK (I am known for taking a risk). I managed to get re-trained as a computer programmer (COBOL) and so began my second career in the IT world.  I moved quickly through up to leading teams and then to Project Management. I was fortunate enough to be introduced to the Open University (OU) to gain a civilian education (I joined the Army aged 16). 

In 1991 I enrolled on one of the best OU courses I ever undertook. It was titled "PT621 Introducing New Technology", it introduced me to the concept of change management and stakeholders / Influences on the project / programme of change.

In this blog entry I want to look to back to remind myself, and present to you of some of those ideas around identifying stakeholders and other influences on the project environment that are still relevant in this the future.

Portfolio Management - Review 2 (PMI's The Standard for Portfolio Management)

In previous posts I considered:

• What is Portfolio Management
• Management of Portfolios(MoP) – OGC (now Axelos)

This is the final post in this series on Portfolio Management. It will contain the review of the Project Management Institute's(PMI) Portfolio Management Standard, and I will provide some links to references and research papers I have found useful in developing my understanding.

I have an admission (if it is really that), I was a member on the PPMS core team that developed the first PMI Portfolio Management Standard 2005-2006. You will find my name on page 167 Section X2.9.1 in Appendix 2. The same core team also worked on the 1st edition of the Program Management Standard.

The third edition of the Standard for Portfolio Management has developed considerably from those early days. The first edition had three chapters 

If you care to look at Appendix X2 you will find some of the reviewers for this edition were involved in building the first edition so there is continuity of thought and ideas.

This post will examine the PMI Standard for Portfolio Management and how it can aid organizations in adopting Portfolio Management as part of their strategic delivery process.

Note all figures and images in this post are copyright of the Project Management Institute. 

Portfolio Management – Review 1 (MoP)

The three reference books identified on the previous post have their own process models

• Management of Portfolios(MoP) – OGC (now Axelos)
• Portfolio Management Standard (PMI)
• The Wiley Guide to Project, Program and Portfolio Management

Over the next two posts I will review parts of the two main publications and include thoughts from the Wiley Guide.

We can explore the models for similarities and differences, not to chose one model as the only path to Portfolio Nirvana, but rather to look at the practices and processes that will fit within our own organizations and business environments.

I am not seeking to cause process chaos by proposing a cut and paste from different models, but simply to help people understand that they do not need to become a slave to one model.  

They can legitimately choose a core model to adopt as a guiding philosophy for their portfolio management approach and then utilize concepts / processes from other models to tuning to suit the business environment, creating their ideal for their organization.

This post will explore the Management of Portfolios (MoP) Manual from Axelos, originally developed with the Office of Government Commerce in the UK.

"MoP® is a (registered) Trade Mark of AXELOS Limited. All rights reserved"All figures and images in this post are copyright of AXELOS Limited

What is this thing called Portfolio Management?

In May's blog we explored the meaning of project success and it was clear that project management is focused on doing the project right, with a wider view of success identifying the need to deliver on more than the key constraints of time, budget and scope.

Over the next few weeks I will explore Portfolio Management which is predominately about choosing the right projects that are aligned to the organization's strategy.

For those who wish to research deeper the sources for this series are:

• The Wiley Guide to Project, Program and Portfolio Management
• Management of Portfolios - Published by Axelos in the UK
• The Standard of Portfolio Management (Third edition) - published by PMI

Project Success - Part 4 - Reasons to be Cheerful

IMPROVING THE LIKELIHOOD OF SUCCESS

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.

Project Success - "Projects are like Chalk and Cheese"

This is the third part in my thoughts on Project Success:

• In part 1, I posed the question "How do you measure Project Success?"
• In Part 2, I explored Project Success from different perspectives and provided some links to sources that explored factors in project success and to improve the chance of success beyond serendipity.

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. 

Wish for Serendipity, take advantage of the fluke, and never trust to 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. 

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

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 

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.

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.

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.

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.

Summary

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.