Seeking a definition of a project.

August 11, 2016

Good definitions are short and unambiguous and are essential for almost every aspect of life. Even something as simple as ordering a snack requires a clear understanding of what’ required – this understanding is the basis of a definition. For example, doughnuts and bagels have a lot in common, they are both round and have a hole (a torus), and are made from dough but they are ‘definitely’ very different commodities! If you need a bagel for breakfast or a doughnut for you coffee everyone involved in the transaction needs to understand your requirements if your expectations are to be fulfilled.

bagel

donut

 

 

 

 

 

 

 

 

Definitions serve two interlinked purposes, they describe the subject of the definition in sufficient detail to allow the concept to be recognised and understood and they exclude similar ‘concepts’ that do not fit the definition. Definitions do not explain the subject, merely define it.The simple fact is if you cannot define something precisely, you have real problems explaining what it is, what it does and the value it offers, and this lack of definition/understanding seems to be a key challenge facing the project management community (by the way, the bagel is on the left…… the other picture is a Krispy Kreme donut).

Way back in 2002 we suggested the definition of ‘a project’ was flawed. Almost any temporary work organised to achieve an objective could fit into almost all of the definitions currently in use – unfortunately not much has changed since. PMI’s definition of a ‘project’ is a: temporary endeavour undertaken to create a unique product, service or result. This definition is imprecise, for example, a football team engaged in a match is involved in:

  • A temporary endeavour – the match lasts a defined time.
  • Undertaken to create a unique result – the papers are full of results on the weekend and each match is unique.
  • Undertaken to create a unique product or service – the value is in the entertainment provided to fans, either as a ‘product’ (using a marketing perspective) or as a service to the team’s fans.

Add in elements from other definitions of a project such as a ‘defined start and end’, ‘planned sequence of activities’, etcetera and you still fail to clearly differentiate a team engaged in a project from a football team engaged in a match; but no-one considers a game of football a project. Football captains may be team leaders, but they are not ‘project managers’.

The definition we proposed in 2002 looked at the social and stakeholder aspects of a project and arrived at an augmented description: A project is a temporary endeavour undertaken to create a unique product, service or result which the relevant stakeholders agree shall be managed as a project. This definition would clearly exclude the football team engaged in a match unless everyone of significance decided to treat the match as a project but still suffers from a number of weaknesses. To see how this definition works download the 2002 paper from, www.mosaicprojects.com.au/PDF_Papers/P007_Project_Fact.pdf

 

Updating the definition

Since 2002 there has been a significant amount of academic work undertaken that looks at how projects really function which may provide the basis for a better definition of a project.  The key area of research has been focused on describing projects as temporary organisations that need governing and managing; either as a standalone organisation involving actors from many different ‘permanent organisations’ such as the group of people assembled on a construction site, or as a temporary organisation within a larger organisation such a an internal project team (particularly cross-functional project teams). The research suggests that all projects are undertaken by temporary teams that are assembled to undertake the work and then dissipate at the end of the project.

My feeling is recognising the concept of a project as a particular type of temporary organisation provides the basis for a precise and unambiguous definition of ‘a project’. But on its own this is insufficient – whilst every project involves a temporary organisation, many temporary organisations are not involved in projects.

Another fundamental problem with the basic PMBOK definition is the concept of an ‘endeavour’.  The definition of endeavour used as a noun is: an attempt to achieve a goal; as a verb it is: try hard to do or achieve something.  But, ‘making an effort to do something’ is completely intangible; projects involve people! Hitting a nail with a hammer is an endeavour to drive it into a piece of wood but this information is not a lot of use on its own; you need to know who is endeavouring to drive the nail and for what purpose?

Nail-Quote-Abraham-Maslow

Another issue is the focus on outputs – a product service or result; the output is not the project, the project is the work needed to create the output. Once the output is finished, the project ceases to exist!  A building project is the work involved in creating the building, once the building is finished it is a building, not a project. But confronted with the need to create a new building different people will create different projects to achieve similar results:

  • One organisation may choose to create two projects, one to design the building, another to construct it;
  • A different organisation may choose to create a single ‘design and construct’ project;
  • Another organisation may simply treat the work as ‘business as usual’.

The scope of the work involved in any particular project is determined by its stakeholders – projects are a construct created by people for their mutual convenience, not by some immutable fact of nature.

 

A concise definition of a project

Unpacking the elements involved in a project we find:

  • A temporary organisation is always involved, but not all temporary organisations are project teams.
  • The requirements and scope of work included in a project have to be defined and agreed by the relevant stakeholders – there are no pre-set parameters.
  • The stakeholders have to agree that the work to accomplish the scope will be managed as ‘a project’ for the project to exist; the alternative is ‘business as usual’ or some other form of activity.

Modifying our 2002 definition to incorporate these factors suggests a definition along these lines:

A project is a temporary organisation established to deliver a defined set of requirements and scope of work, which the relevant stakeholders agree shall be managed as a project.

This definition overcomes many of the fundamental problems with the existing options:

  • It recognises projects are done by people for people, they are not amorphous expenditures of ‘energy’.
  • It allows for the fact that projects do not exist in nature, they are ‘artificial constructs’ created by people for their mutual convenience, and different people confronting similar objectives can create very different arrangements to accomplish the work.
  • It recognises that projects are only projects if the people doing the work and the people overseeing the work decide to treat the work as a project.

What do you think a good project definition may be that is concise and unambiguous?

The challenge is to craft a technically correct definition, and then apply the Socratic method of thinking outlined in our 2002 paper at:  hwww.mosaicprojects.com.au/PDF_Papers/P007_Project_Fact.pdf.

I look forward to your thoughts!


Stakeholder Management Maturity

August 14, 2013

Recognition of the importance of stakeholder management has taken a huge leap forward since the release of the PMBOK® Guide 5th Edition.   The next challenge, addressed in this blog, is for organisations to be able to map their maturity with a view to improving their stakeholder management capabilities.

The PMBOK® Guide lays out the fundamental framework for effective stakeholder management and aligns fairly closely with the structure of the Stakeholder Circle® methodology we have been developing for the last decade. Within the PMBOK:

  • Process 13.1 deals with the identification of stakeholders and the creation of a stakeholder register.   This is directly supported by the Identify and Prioritise steps in the Stakeholder Circle® methodology. The key difference is the PMBOK tends to classify stakeholders based on simple 2×2 matrices, the Stakeholder Circle uses a more sophisticated analysis that prioritises stakeholders based on their importance to the project rather than just their attitude (positive or negative).
  • Process 13.2 Plan Stakeholder Management, links the stakeholder management section of the PMBOK to the Communication  section and focuses on defining the current  attitude of each stakeholder, the realistically desirable attitude we would like the stakeholder to have, and the communication strategy needed to maintain satisfactory attitudes and beneficially change  attitudes that need improving.  These concepts directly align with the Visualise and Engage stages in the Stakeholder Circle methodology.
  • Then the hard work of effectively engaging and communicating with the important stakeholders begins (without ignoring the less important ones).  The planning, managing and controlling of communications (from Chapter 10) link to process 13.3 Manage Stakeholder Engagement. Issues identification and management is a key element in this process and a core element in our Stakeholder Circle database tool.  The next upgrade of the Stakeholder Circle database tool will add a contact management module to facilitate the rest of this process.
  • The final process in the PMBOK® Guide, 13.4 is the standard PMBOK controlling process that actively encourages the regular review of the overall stakeholder management process and aligns exactly with Stage 5, Monitor changes in the Stakeholder Circle® methodology.  As with effective risk management, the environment needs to be continually scanned for emerging stakeholders, and if the current engagement strategies are not working with identified stakeholders, new ones need to be tried.

The good news is the framework we developed in the Stakeholder Circle® methodology nearly 10 years ago and the framework adopted by PMI in the PMBOK® Guide and most other competent stakeholder management methodologies all lay out the same basic steps.  And, as PMI claims for the PMBOK in general, these processes have become generally accepted good practice.

The challenge now is to build these good practices into the culture of organisations so they become simply ‘the way we do business’.  Maturity models such as P3M3, CMMI and OPM3 look at the stages of developing and implementing good practices in organisations.  The SRMM® Maturity Model has been designed to provide a similar framework for organisations seeking to develop an enhanced stakeholder management capability.

The five levels of the Stakeholder Relationship Management Maturity (SRMM®) Model are:

  1. Ad hoc:  some use of processes
  2. Procedural:  focus on processes and tools
  3. Relational:  focus on the Stakeholders and mutual benefits
  4. Integrated:  methodology is repeatable and integrated across all programs and projects
  5. Predictive:  used for health checks and predictive risk assessment and management.

And for each level of maturity, the SRMM Model defines the key features, the good practice components, and the expected tools and reporting process expected at that level of maturity, together with some general guidance.

SRMM is designed to be an open system that would support any effective stakeholder management methodology (not just the Stakeholder Circle), which means SRMM is a useful tool for implementing a stakeholder management methodology based on the PMBOK’s processes as effectively as one using the more sophisticated capabilities of the  Stakeholder Circle.

The SRMM® Model is available for downloading and use by any organisation planning to implement effective stakeholder management under a free Creative Commons licence. Download you copy of the SRMM® Model.


How useful are BOKs?

April 21, 2013

We have the PMBOK® Guide, the APM BoK and many other BoKs and standards ranging from ISO 21500 to the PMI Practice standards.

We personally think they are useful and commit a significant amount of volunteer time to developing standards through PMI and ISO; as are the certifications to demonstrate a person has a good understanding of the relevant BoK (and we make money out of running our training courses).

However, we are fully aware that passing a knowledge based credential does not demonstrate competency (and that passing a competency based assessment does not demonstrate transferable knowledge – both are needed see: Developing Competency).

We are also aware that too many organisations place too much emphasis on ‘ticking boxes’ rather then taking time to assess people or optimise solutions. The easy tick in the box may avoid ownership of a problem but also tends to avoid the solution itself……

For these reasons we commend the Association for Project Management (APM – UK, publisher of the APM BoK) for publishing a short video, based on a talk given by our friend and colleague, Dr. Jon Whitty to the APM in Reading UK in Nov last year. I hope it starts you thinking.

See the video: http://www.apm.org.uk/news/courageous-conversation#.UXE_pLXfCSp


PMI Standards Round-Up

April 15, 2013

PMI StandardsThe three standards released by PMI at the beginning of this year were the:
PMBOK® Guide Fifth Edition
Standard for Portfolio Management Third Edition
Standard for Program Management Third Edition

As a consequence, the global PM community now has a set of basic standards that will remain stable for the next four years through to the next cyclical update scheduled for late 2016. The tight integration between all three standards means minimal duplication of ideas and best practices.

Whilst each of the PMI Credentials tends to focus on one of these three standards, the key thing from an organisational perspective is they are integrated, and after this round of upgrades better integrated than ever!

The Portfolio Management standard focuses on the investment decisions needed to select the best projects and programs to start and maintain to achieve the organisations strategy within its resource constraints. Selecting the ‘right projects and programs to do’.

For guidance on ‘doing them right’, the Program Management standard focuses on the business outcome and integration aspects of program management and the PMBOK® Guide covers off the basic skills and capabilities needed to deliver the project outputs efficiently.

Each standard can be used in isolation; however, the real power lays in using all three as a framework for organisational improvement – Creating an effective Project Delivery Capability (download the PDC White Paper). The final missing link, PMI’s updated OPM3 standard will be released later this year.

This means that organisations interested in developing a best practice capability across the ‘enterprise’ aimed at achieving the maximum sustainable value from its investment in projects and programs now have an ideal opportunity to buy into current thinking via these standards and time to develop improved processes.

We have enjoyed working through the standards and writing this series of posts on the improvements (for previous posts click here) – but 4 months down the track we now consider these ‘new’ standards business as usual, have consigned the ‘old’ standards to history, and will make this our last post on the updates. Our very last PMP and CAPM course based on the ‘old’ standards will be run at the end of May (view course details) and then we will be 100% aligned to the new and improved versions. We encourage everyone else to do the same.


PMBOK 5 – Some final thoughts

April 1, 2013

We are now well into the process of updating materials and writing new questions based on the PMBOK® Guide 5th Edition – From being something new, the book is now becoming increasingly familiar:

  • Our daily question has had a 5th Edition for the last 3 months: you can follow the questions on Twitter: see today’s question
  • Updates to our CAPM, PMP and PMI-SP courses are planned and under development – our new Mentored Email™ courses will start in late April.
  • Our last classroom course based on the 4th Edition will be at the end of May
  • The PMI examination change dates are:
    – CAPM 1st July
    – PMP 1st August
    – PMI-SP 1st September
  • The initial rush of people interested in buying the 5th Edition has subsided and we are effectively out of stock of the 4th Edition.

Overall as we become more familiar with the 5th Edition we are finding it to be a significant improvement. There are certainly a few issues and problems highlighted in earlier posts in this series (view the full series) but the enhancements significantly outweigh the odd regression.

One of the minor but important improvements is he ranges for cost estimates are back to the industry standards of -25% to +75% for ROM and -5% to +10% for detailed estimates. This pessimistic shift in the ranges more accurately reflects reality.

The rearrangement of the first three chapters is also significant and is aligned with the standards for Program and Portfolio management:

  • Chapter 1 sets the scene with:
    – definitions of a project and project management,
    – discussion of the relationships between project, program and portfolio management, in the context of organizational project management,
    – Discussions of the relationship between project management, operations management, strategy and business value
    – the role of the project manager.
  • Chapter 2 focuses on organisational influences including the influence of project stakeholders and governance on the project team and the overall project lifecycle.
  • Chapter 3 looks at project management processes and the structure of the rest of the PMBOK.

The reorganisation of this front section, facilitated in part by the move of the ANSI standard to Annex A1 is probably the quiet achievement in the standard. The section flows far more sensibly and logically than in previous editions.

In conclusion – the quality of the PMBOK® Guide 5th Edition has been enhanced by hundreds of small changes that make the work of transitioning our course materials hard work and will certainly require some hard work from anyone who has to update their exam preparation.

So a word of warning: If you are trained for the current exam make sure you sit before the change over dates – PMI do not have any flexibility in the timing of the system changes!! This includes re-sits. After the change over date, all new exams are based on the new standards.

But once through these changes we certainly have a better book for the next 4 years and the development team deserve congratulations for a job well done.


The Standard for Program Management—Third Edition

March 21, 2013

The most noticeable thing about the new Standard for Program Management—Third Edition is that is has gone on a major diet! The 2nd Edition was 271 page long (plus appendix), the 3rd Edition is less than half the size at 106 pages plus appendix. Unfortunately the price has not moved in the same direction.

The Standard still provides a detailed understanding of program management and promotes efficient and effective communication and coordination among various project management groups. The major updates include:

  • Program Life Cycle has been assigned its own chapter for the third edition to provide the details of the unique set of elements that makes up the program management phase.
  • The third edition highlights the full scope of program management and clarifies the supporting processes that complete the delivery of programs in the organizational setting.
  • A more detailed definition of program management within an organization is provided, including the fundamental differences between project management and program management.

The major focus of the revision seems to be removing a lot of the ‘project management’ information that is found in the PMBOK® Guide and focusing on the role of program management in organisations, the unique characteristics of program management work and the role of the program manager. A shift from process to principle, that is aligned with the Program Management Role Delineation Study that forms the basis for the PgMP examination.

The framework in the Third Edition is:

  • Introduction
  • Program Management Performance Domains
  • Program Strategy Alignment
  • Program Benefits Management
  • Program Stakeholder Engagement
  • Program Governance
  • Program Life Cycle Management
  • Program Management Supporting Processes

The relationship between the Program Management Performance Domains that makes up the bulk of the standard is illustrated below.

Program_Domains

In addition to the core standard, Appendix X4 on Program Management Competencies, and X5 on Program Management Artefacts are very succinct and useful.

A couple of shortcomings in this version of the standard are firstly the limited recognition of the different type of program that organisations run. The PMI standard is very much centred on the ‘strategic program’ defined in the GAPPS typology discussed in our White Paper Defining Program Types. In particular the GAPPS ‘Operational Program’ typology has been largely ignored in the PMI standard.

The other is the classic confusion between the Enterprise level executive management responsibilities that are critical for the support and oversight of the work of the Program Manager and Organisational Governance typical of documentation produced by working managers. What the standard describes as ‘governance’ is the critical management responsibilities of senior executives to adequately support oversight and manage the process of ‘program management’. Governance is the process of oversighting the whole management system, that is performed by the ‘governing body’ which is the Board of Directors in most commercial organisations and their equivalent in other types of organisation – governors govern, managers manage! For more on this critical distinction see: WP1084 Governance Systems & Management Systems. The contents of the ‘governance’ section are good, just miss-labelled.

Summary
Overall this is a significantly improved standard – a lot of duplication and redundancy has been removed, and the key functions and processes of program management and what organisations need to do at the enterprise level to support programs are well though through and laid out. This new standard is available in Australia from: http://www.mosaicprojects.com.au/Books.html#PMI


PMBOK® Guide 5th Edition – Some Technical Differences

March 15, 2013

We are busily working through the PMBOK® Guide 5th Edition updating Mosaic’s PMI training courses  ready for the scheduled examination changes. Three of the more technical changes (out of many) are:

The Good:
Quality management has been tidied up. The seven basic tools of quality management are now dealt with in on place, once, in 8.1.2.3 and referenced through the rest of the chapter. The ‘magnificent 7’ are: Cause and Effect Diagrams, Flow charts, Checksheets (checklist), Pareto Diagrams, histograms, control charts and scatter diagrams. Other specific techniques are discussed in the appropriate process. There is also an attempt to relate the different project/quality cycles including the basic process groups, the ‘Plan-Do-Check-Act cycle, the cost of quality and quality assurance and control.

The Bad:
Monte Carlo is missing from Time Management and Cost Management! One area that needs a major update in the 6th Edition are the aspects of time and cost management focused on three point estimates and variability. Monte Carlo has been moved out of the section into the Risk chapter, and is defined as the source of ‘contingencies’ and as a means of ‘simulating’ schedule outcomes. Very little is included about the ways simulation through Monte Carlo are developed or used. In particular, there is no discussion of how different distributions should be chosen based on the available data. Understanding the range of potential outcomes is a critical time and cost management process as is the interactions between time and cost. The treatment in the Risk chapter is not bad, just in the wrong place, hopefully in the 6th Edition the consideration of modelling outcomes will move back into the Time and Cost chapters. Or there will be far clearer links drawn between the development of the raw data and its use in cost and time management.

The Ugly:
For some reason PMI keeps bringing PERT back into consideration, ensuring the unfortunate confusion around PERT will persist for another 4 years at least! The completely inaccurate reference to ‘PERT Cost’ that crept into the 4th Edition has been killed off but the concept has reappeared in Duration Estimating (6.5.2.4), Quality Assurance (8.2.2.1) and the glossary.

There is nothing wrong with PERT being in the PMBOK if the technique is defined properly. PERT is a simplistic technique that applies a single modified beta distribution and an approximation of the calculation for Standard Deviation (a polite term for inaccurate), to the activities on the critical path in a single calculation to determine the the mean (p50) completion date and the effect of adding 1 Standard Deviation to approximate the p80 completion (ie, the date with an 80% probability of being achieved or bettered). PERT is prone to errors including the ‘PERT Merge Bias’ which describes the effect of a nominally sub-critical path finishing later than the critical path.

However, PERT is not synonymous with three point estimating and despite a number of software vendors making the same mistake and using a ‘cute name’ to make their uncertainty calculations sound sexy any computation that involves simulation, different distribution options or calculating the whole network is not PERT.

PERT has an important place in history and is a useful teaching tool because you can do the calculations manually. But confusing this venerable technique with simulation and three point estimating helps no one. This creates a significant communication problem – when a planner says he has done a PERT analysis you have no idea if this means a full Monte Carlo simulation, a manual PERT calculation described above or something in between. As a professional body PMI has let everyone down perpetuating this confusion.

The End:
Overall the PMBOK® Guide 5th Edition is still a significant improvement; our earlier posts have highlighted many of these changes:

To read our earlier comments: https://stakeholdermanagement.wordpress.com/category/pmbok-5th-edition/

To see more on the book:
– In Australia: http://www.mosaicprojects.com.au/Books.html#PMI
– Other places: http://marketplace.pmi.org/Pages/Default.aspx


PMI’s Standard for Portfolio Management

March 7, 2013

The publication of the third edition of PMIs Standard for Portfolio Management represents a significant step forward in linking the performance of project and programs to the achievement of the organisations vision, mission and strategy.

One of the key additions is the introduction of the ‘Portfolio Strategic Management’ process group. The standard’s fundamental proposition is that efficient portfolio management is integral to the implementation of the organization’s overall strategic plan. While project and program management focus on doing the work right, the purpose of portfolio management is to ensure the organisation is investing its limited resources in doing the right work.

As with any portfolio the optimum return is achieved through an appropriate diversification of risk. Short term, low risk, low return projects will not build the organisation of the future, investments to maintain and expand current capabilities need to be off-set by some future focused, high risk high reward projects to develop new capabilities, products or services. The challenge is developing a balanced portfolio that maximises stakeholder value overall, and this needs a practical strategic plan as the basis for developing the portfolio strategy.

The challenge facing most organisations is developing systems to efficiently link innovation, strategy, portfolio management, project execution, organisational change management and the realisation of value. Any weak point in this ‘value chain’ will reduce the return on its investment in projects and programs achieved by the organisation. Establishing systems to achieve this linkage is a key management challenge, ensuring they are in place is a key governance responsibility. We have posted on this topic several times:

Linking Innovation to Value

The failure of strategic planning

Who Manages Benefits?

Benefits and Value (White Paper)

The updated Standard for Portfolio Management provides an authoritative resource to assist organisations in the overall development of an effective value delivery capability.

One of the elements we really like if that PMI have separated the management of the portfolio (effectively investment decisions and oversight) from the need for organisations to manage their project delivery capability. The ‘enterprise project management’ system that develops and nurtures project delivery capability (see: PCD White Paper) should be quite separate from the portfolio investment decision making process. There is a fundamental conflict of interest created if the same management body is responsible for decisions to ‘kill’ projects that are no longer viable whilst at the same time supporting and nurturing the project team to help them remain viable. PMI have not fallen into this trap!!

Stocks of the PMI Standard for Portfolio Management Third Edition are available world-wide. Australian readers can buy from: http://www.mosaicprojects.com.au/shop/shopexd.asp?id=37&bc=no

For other PMI standards see: http://www.mosaicprojects.com.au/Books.html#PMI


PMBOK #5 standardises its approach to planning

February 17, 2013

The PMBOK® Guide has always been designed for large projects, and assumes intelligent project teams will scale back the processes appropriately for smaller projects. The 5th Edition keeps this focus and introduces a standard process to ‘plan the planning’ at the start of each knowledge area. This concept has been embedded in earlier editions of the PMBOK, it’s made explicit in the 5th Edition.

Why plan the planning?

As a starting point, on larger projects there will be a significant team of experts involved in developing various aspects of the project plan, on $ multi-billion project frequently more than 100 people so their work needs planning and controlling the same as any other aspect of the project. With a budget of several $ millions and the success of the rest of the project dependent on the quality of the project planning this is important work.

But planning the planning and developing an effective strategy for the accomplishment of the project’s objectives is critically important on every project. If you simply do what you’ve always done there is very little likelihood of improvement. Spend a little time overtly thinking about what needs to be done to first develop the best project plan and then to manage the project effectively can pay huge dividends.

The overriding consideration in developing the plan is Juran’s quality principle of ‘fit for purpose’ you need a plan that is useful and usable that has been developed for the lowest expenditure of time and effort.

CoQ3

To facilitate this, the PMBOK now has process to ‘plan the management’ of: Scope, Time, Cost, Quality, HR, Communication, Risk, Procurement and Stakeholders. These planning processes develop outputs that are integrated within the overall project management plan and describe how each of the specialist areas will be managed. The management plans include the policies, procedures and documentation required for the planning, developing, managing and controlling of each discipline.

Less well developed are two key aspects that can contribute significantly to project success:

  • Within the ‘PMBOK’ there is a real need to coordinate and integrate different aspects of the planning. Decisions in one area frequently impose constraints on other disciplines and managing these constraints across multiple sub-teams is vital if the objective of a coordinated and integrated project plan is to be achieved. The project core team need to set parameters for the specialists to work within, possibly at a ‘planning kick-off meeting’ and then manage issues as they arise.
  • On a more general level, and applicable to projects of all sizes, there is a need to formulate the project delivery strategy before any realistic planning is possible. Answering the question ‘what’s the best way to achieve our objectives?’ frames the project planning and later the delivery. In software development choosing ‘agile’ over ‘waterfall’ as the delivery strategy changes everything else (for more on managing Agile see: Thoughts on Agile). The project objective of functioning software can be achieved either way, which strategy is best depends on the specific circumstances of the project (See our earlier post on project delivery strategy)

Certainly asking the team to think about what is needed to optimally plan, develop and deliver each knowledge area, will contribute to project success. Maybe the 6th Edition will take the integration of these processes forward.

See our other posts on the PMBOK® Guide 5th Edition.

To buy a copy in Australia see: http://www.mosaicprojects.com.au/Book_Sales.html#PMI


PMBOK #5 Boosts Stakeholder Management

January 16, 2013

PMI_PMBOK5The publication of the PMBOK® Guide 5th Edition is a major boost for stakeholder management. The introduction of Chapter 13, Project Stakeholder Management as a distinct knowledge area raises the importance of engaging stakeholders to the same level as all other PM ‘knowledge areas’. Ideally the new section would have been placed next to the closely aligned process of communication management but this is not to be – the PMBOK is expanded by adding new chapters to the end.

The four processes follow the familiar PMBOK pattern with a few differences. They are:

  • 13.1 Identify Stakeholders – identifying everyone affected by the work or its outcomes.
  • 13.2 Plan Stakeholder Management – deciding how you will engage with the stakeholders.
  • 13.3 Manage Stakeholder Engagement – communicating with stakeholders and fostering appropriate stakeholder engagement
  • 13.4 Control Stakeholder Engagement – monitoring the overall relationships and adjusting your strategies and plans as needed.

The 5 stages of our Stakeholder Circle’ methodology are embedded within these processes; the key steps in theStakeholder Circle’ are:

  1. Identify – the primary purpose of 13.1 with very similar objectives.
  2. Prioritize – This is mentioned in 13.1 (Identification) without any real assistance on an effective approach to this important task. The PMBOK recognises most projects are going to be resource constrained and should focus its engagement activities on the important stakeholders but that’s all – options to calculate a meaningful prioritisation is missing. See more on prioritisation.
  3. Visualize – This is also included in 13.1 (Identification) based on a simple 2 x 2 matrix. A number of options are listed including power/interest, power/influence, and the influence/impact grids. The Salience model developed by Mitchell, Agle, and Wood 1997 is also mentioned without attribution.In reality to properly understand your stakeholders you need to understand significantly more than two simple aspects of a relationship. The Stakeholder Circle’ diagram was adapted from the Salience model to help teams really appreciate who matters and why. This will be the subject of another post in a couple of day’s time.
  4. Engage – the primary purpose of 13.2 (Plan engagement) and 13.3 (Implementing the communication plan). Separating planning and implementation is a good idea. The planning process uses an engagement matrix similar to the tool built into the Stakeholder Circle’ – However, whilst the PMBOK looks at the attitude of each stakeholder (both current and desired) it omits the key consideration of how receptive the stakeholder is likely to be to project communication. If the stakeholder does not want to communicate with you the challenge of changing his/her attitude is a whole lot harder and the missing priority level lets you know how important this is.
  5. Monitor and Review – whilst this is the focus of 13.4, the assumption of review and adjustment is a statusing process. Our experience suggests the dynamic nature of a stakeholder community requires the whole cycle starting with the identification of new and changed stakeholders to be repeated at regular intervals of 3 or 6 months (or at major phase changes).

Conclusion.

As mentioned at the beginning, the introduction of a separate knowledge area for stakeholder management is a huge advance and should contribute to improving the successful delivery of projects – PMI are to be congratulated on taking this step!

However, unlike most other areas of the PMBOK, the processes outlined in this 5th Edition are likely to be less than adequate for major projects. As soon as there are more than 20 or 30 stakeholders to assess and manage, the tools described in this version will be shown to be inadequate and more sophisticated methodologies will be needed.

Note:
Stocks of the PMBOK® Guide 5th Edition are now in the shops:
Internationally: http://marketplace.pmi.org/Pages/Default.aspx
Australia: http://www.mosaicprojects.com.au/PMP-Pack-LP.html

For other posts on the new PMBOK 5th Edition see: https://stakeholdermanagement.wordpress.com/category/pmbok-5th-edition/