Monday

Tag Archives: Stakeholder Analysis

The Central Role of Stakeholder Management

Posted on April 24, 2010 by | 1 comment

20 years ago, stakeholder management and shareholder/owner management were almost synonymous. In the intervening period, much has changed.

Most enlightened thinkers now place stakeholder management at the centre of effective business operations. The business needs to support, empower and satisfy the people working within the organisation, the general public and customers (now classes as Corporate Social Responsibility or CSR) and the owners of the business. All of these people are stakeholders.

Since the passing of the Sarbanes Oxley Act, organisational governance has become an important focus. For all types of organisation this is directly linked to governing the work of the people engaged in the work of the business; ie, stakeholders.

Since the GFC effective risk management has also become of increasing concern. Risk management is not the foolish attempt to avoid all risk – this is impossible, rather the effective management of risk within the risk tolerance thresholds of key stakeholders including the organisations owners and managers; ie, stakeholders.

Stakeholder Management

As summarised by the diagram above, business operations are intrinsically linked to, and require, effective governance, to meet the expectation of the organisations owners, within acceptable risk parameters to deliver value to society and the organisations clients or customers.

However, whilst stakeholder management is central to all of these processes, effective stakeholder management requires the allocation of scarce management resources to focus on the relationships between the work and the most important stakeholders. At the most fundamental level, the purpose of the Stakeholder Circle® methodology is understand ‘who’s who, and who’s important’ in the stakeholder community surrounding your work.

Once you understand this the effective management of stakeholders becomes possible. However, without the clarity of insight created by the careful analysis of the stakeholder community to determine who is really important the potential for wasted effort is enormous. As with most planning process, the payback from effort expended in analysis, is the reduced incidence of issues and problems as the work proceeds.

Can you afford not to focus some effort on effective stakeholder management?

1 Comment

Posted in Stakeholder Management

Tagged , , , , , , , , , , , , , , ,

The upside of Risk

Posted on April 22, 2010 by | 8 comments

I am amazed by the number of project management commentators who flatly refuse to recognise that  risk = uncertainty that matters and that uncertainty can be positive or negative (ie, it’s uncertain).

The latest commentator in a long line of negative thinkers is Michael Hatfield in PMI’s Voices on Project Management blog. His approach to risk suggested in ‘PMBOK® Guide for the Trenches, Part 4: Risk’ is simplistic and assumes all uncertainties are negative…..

There are numerous problems with this simplistic view of the world:

  • Firstly the same risk – a future uncertainty – can have both an upside and a downside. Failing to manage the upside equates to guaranteeing failure (or at least missing opportunities).
    • Future weather conditions are a risk; they could be good or bad. A major motorway near my home town was finished months early and under budget because they were lucky enough to build the project at the tail end of a 10 year drought. The last few months have had above average rain. If the people building the road only worried about the ‘downside’ risk the road would only just be finishing now.
    • A similar example is the management actions taken to accelerate work on the Panama Canal through the GFC to take advantage of then upside risk of lower construction costs.
  • Second, the environment around projects does not stop changing just because someone has signed off a cost performance baseline. Ongoing risk assessments are critical to avoid surprises; good or bad! The more warning of changed circumstances the project team have the more likely they are to manage the situation effectively.

One of our key areas of expertises is stakeholder management – each stakeholder can be a threat to the project if badly managed and a supporter if well managed. The Stakeholder Circle® methodology has been explicitly developed to first prioritise stakeholders then focus on the important high priority stakeholders to achieve an optimal level of support to allow the project to succeed (for more see http://www.stakeholder-management.com/)

Where we do agree with Michael is on the mumbo jumbo of statistical paralysis many so called risk management systems bog down in. The purpose of risk management is to identify opportunities and threats and then actually do something about them. Recording risks in a risk register and then qualitatively and quantitatively analysing them is a complete and total waste of time unless someone actually takes action. This is the focus of our ‘How To’ build a Risk Management Plan workshop – yes we have a cute Excel risk register but the purpose is action not documentation.

The biggest weakness in the current version of the PMBOK® Guide is the total omission of a process for treating risks. The idea of risk treatment is implied, but not overtly set out as a process, which allows people to think identification and analysis is the end game. Unfortunately managers need to make decisions based on the risk assessment and then take actions if risk management is going to deliver any benefits at all. Hopefully the 5th Edition will fix this.

8 Comments

Posted in Risk, Stakeholder Management

Tagged , , , , , , , , , , , , , ,

Stakeholders and Change Management

Posted on January 10, 2010 by | 2 comments

When considering stakeholders, there are very few one-to-one relationships. Most stakeholders are, and have been, influenced by a range of relationships in and around your project, program and your organisation.

Change Management and Stakeholder Management

Stakeholder management is a key facet of organisational management where stakeholder management is often aligned with marketing, branding and corporate social responsibility (CSR) initiatives.

Similarly, stakeholder management central to change management and the ability to realise the benefits the change was initiated to deliver. The benefits will not be realised unless the key stakeholder communities accept and embrace the changes.

Project and program management also has a focus on effective stakeholder management. In a change initiative, the project and/or program undertakes the work to deliver the elements needed to facilitate the change but are only ever part of the journey from concept to realised value.

A typical evolution of a change initiative would flow along these lines:

  • The organisation decides on a major organisational restructure and as a consequence initiates a change management process and appointed a change manager.
  • The change manager develops the business case for the program of work and the executives responsible for the organisations portfolio management approve the business case and agree to fund and resource the program.
  • The program manager sets up the program management team, established the program management office (PgMO) and charters a series of projects to develop the various deliverables needed to implement the change.
  • The projects deliver their outputs.
  • The program integrates the outputs with the operational aspects of the organisation.
  • The organisation’s management make effective use of the new systems and processes.
  • Value is created for the organisation and its owners.

The change manager is the sponsor and primary client for the program but the people who need to be convinced of the value of changing are the operational managers and their staff. If the organisation does not accept and use the new systems and processes very little value is generated.

Within this scenario, stakeholders in the operational part of the organisation, and particularly the managers will be key stakeholders for a range of different entities:

  • They are stakeholders in the organisation itself and part of the organisational hierarchy.
  • They are stakeholders in the change process being managed by the change manager.
  • As end users of the new systems and processes they are also stakeholders of the program.
  • As subject matter experts (SMEs) they are likely to be stakeholders in at least some of the projects.

In one respect change management is stakeholder management. Therefore, in a change management initiative, stakeholder management should be an integrated process coordinated at the change manager’s level. All of the organisational elements working on the change need to coordinate their stakeholder management efforts to support the overall outcome. Confusing and mixed messages don’t help anyone.

But this is just one typical business scenario. When considering stakeholders, there are very few one-to-one relationships. Most stakeholders are, and have been, influenced by a range of relationships in and around your organisation. Consequently, focusing on a simple one-to-one view is unlikely to provide the best outcome for anyone.

Effective stakeholder management requires a mature organisational approach. One approach to developing this capability is the SRMM (Stakeholder Relationship Management Maturity) model described in my book. Stakeholder Relationship Management: A Maturity Model for Organisational Implementation. I will outline the SRMM model in a later post.

2 Comments

Posted in Change Management, Governance, Stakeholder Management

Tagged , , , , , , , , , , ,

Construction Stakeholder Management

Posted on December 29, 2009 by | 1 comment

Wiley-Blackwell has published a new book on stakeholder management in the construction industry, edited by Ezekiel Chinyio from the University of Wolverhampton and Paul Olomolaiye from the University of the West of England. This book is designed to map the current state of stakeholder management in the construction industry with input from a range of well known academics and researchers.

Our chapter on Mapping Stakeholders can be previewed on our Interesting Book’s page with links through to the publisher’s web site.

1 Comment

Posted in Stakeholder Management

Tagged , , , , , , , , , , ,

The Cultural Dimension of Stakeholder Management

Posted on December 28, 2009 by | 2 comments

The importance of understanding culture in designing successful communications to influence and inform stakeholders cannot be understated. But as discussed in previous posts, culture is multi-dimensional. Some of the facets include:

  • corporate culture – how the organisation works
  • industry/professional culture – the way people in a profession work and relate
  • age – baby boomers, Gen X, Y and Z (at least in the western world)
  • national/ethnic cultures

The last of these facets tends to be over simplified in many texts. There is not just an east/west divide! Robert J House in Culture, Leadership and Organizations (2004 – Sage Publishing) reported on the Global Leadership and Organizational Behaviour Effectiveness (GLOBE) program that is undertaking a long term study of 62 societies.

The GLOBE study identifies ten national culture clusters that have distinctive leadership and management behaviours:

  1. Asian:
    a.  South Asia – Philippines to Iran, including ASEAN countries and India
    b.  Confucian Asia – China, Japan and Korea plus Singapore, Hong Kong and Tiwan
  2. European:
    a.  Anglo – North America, UK, Australia /NZ and ‘white’ South Africa.
    b.  Germanic – Germany, Austria and Netherlands
    c.  Latin – Portugal, Spain, France, Italy, Israel.
    d.  Eastern – Poland and Greece to Russia.
    e.  Nordic – Denmark to Finland, Iceland.
  3. Arab – Qatar and Iraq to Morocco
  4. Sub-Sahara Africa including ‘black’ South Africa.
  5. Latin America – Mexico to Argentina.

The GLOBE study focused on the interrelationship between societal culture, organisational culture and organisational leadership. Attributes such as uncertainty avoidance, power distance and performance -v- human orientation were considered.

Yoshitaka Yamazaki in Learning Styles and Typologies of Cultural Differences (2005 – Science Direct) identifies six dimensions:
  Cultural typologies in anthropology
    1. High-context vs. low-context cultures
    2. Shame vs. guilt cultures
  Cross-cultural management literature
    3. Strong vs. weak uncertainty avoidance
    4. M-type organizations vs. O-type organizations
  Cross-cultural psychology
    5. Interdependent-self vs. independent-self
    6. Field-dependent and field-independent

High context societies place great importance on ambience, decorum, the relative status of the participants in a communication and the manner of the message’s delivery. Effective communication depend on developing a relationship first, because most of the information is either in the physical context or in the context of the relationship, therefore relatively little needs to be in the coded, explicit, transmitted part of the message. Communication in low context societies tends to have the majority of the information vested in the explicit code transferred by the message. People from high context societies (eg, France or China) may think people from a low context society (eg, Germany or USA) think they are stupid because the low context people include all of the information in a message. Similarly, people from high context societies are unlikely to express their disagreement or reservations in an open meeting, circumstances and relationships are as important as work so they would comment in a more private or appropriate occasion but only if the opportunity is provided.

Shame or guilt considers whether a person has an outwards orientation based on the judgement of others or an inward orientation focused on their core ethical values to encourage high performance and moderate poor performance.

O-Type organisations are where the employees see themselves as a permanent part of the group; they are part of a social collective. M-Type organisations are more focused on individual achievement.

Field-dependent societies adhere to structures and perceive or experience communication in a global fashion. Field-independent societies and people are analytical; they can self-structure situations and have self-defined goals and reinforcements.

These differences in approach were one of the reasons I posed the question ‘do we need cultural extensions to the PMBOK?’ (see: PMI’s Voices on Project Management). But while understanding cultural stereotypes may be a helpful starting point, no grouping or stereotyping will provide the necessary subtleties needed for important communication.

Firstly, everyone’s experience is unique and the person you wish to communicate with will have been moulded by a range of influences including the corporate and professional cultures they have worked within. Second, no study I am aware of has focused on the effect of the global communication network on national cultural behaviours. The concept of baby boomers, X, Y and Z Gen, is very much a western phenomena, there are certainly likely to be age groupings in other cultures but where the divides lie and how technology interacts with the national characteristics is largely unknown (at least to me). Thirdly, people travel widely for both education and work, even after returning home they will have absorbed some of the influences of the other cultures they have lived in.

So how should you approach the planning of an important communication? As a start, try to define the normal communication mode of the person you are seeking to influence or inform. Understanding national characteristics helps, but is not enough; you need to seek information from a wide range of sources. Err on the side of caution if there is any doubt about the optimum mode for communication. Then carefully observe the effect of your initial communication on the receiver and adjust the mode until you achieve a satisfactory result.

My paper for the PMI Asia Pacific Congress, Beyond Reporting – The Communication Strategy,  is also focused on the topic of effective communication, as is my next book, Advising upwards: A Framework for Understanding and Engaging Senior Management Stakeholders due for publication in 2011. So expect more on this subject in the New Year.

2 Comments

Posted in Stakeholder Management

Tagged , , , , , , , , , , , , ,

Project Management 2.0

Posted on September 27, 2009 by | 5 comments

Project Management 2.0 (PM 2.0) seems to be going the same way some Agile anarchists are trying to take software development which is essentially not to do project management and hope a group of people with good will and good luck will create something useful.

Not doing ‘project management’ is a really good idea if you and your client have no idea what’s needed, when its required, or how much budget is available. Journeys of exploration can be fun and can be highly creative but are nothing to do with managing projects.

Wikipedia (retrieved 27/9/2009 from: http://en.wikipedia.org/wiki/Project_management_2.0) lists the following differences between PM 2.0 and ‘traditional’ project management.

PM 2.0 -v- Traditional PM

Whoever wrote this has absolutely no idea what good traditional project management looks like and has probably never worked on a successful major project. Good traditional project management differs from this highly subjective and biased list in many ways:

  • Control is not centralised, authority and responsibility are devolved to the appropriate management levels.
  • All good project management is based on collaboration.
  • All good project management requires open access to the plan both as an input to its creation and to know what needs doing during delivery.
  • Access to information is vial when and where needed.
  • Open and effective communication is critical.
  • Project are,  by definition, separate management entities – a holistic approach (ie, not doing projects) is called general management.
  • Tools, see: A fool with a tool is still a fool, and you need the right tools for the right job. Amateurs try to do jobs with inappropriate tools. Easy to use and flexible are fine if you know exactly what you are doing, it is a recipe for wrong information and wrong decisions if you don’t.

The table is correct in so much as project management involves a degree of top down planning. Project management is about delivering a required output to the specifications requested by the client. The product or service is a failure if it does not meet the quality requirements set by the customer; which may include time, cost and scope parameters.

It is also correct in respect of the implied structure – projects work because there is an implied structure that sets a framework for collaboration. If you don’t know who is doing what it is nearly impossible to collaborate. Even Wikipedia and Linux have structure in their collaborative frameworks.

I have emphasised good project management throughout this post. Bad project management involves excessive attempts to ‘control the future’, lack of stakeholder involvement, excessive bureaucracy, and many other problems. These traits are bad management full stop.

One comment on the Wikipedia article is important though: PM 2.0 is good for small jobs. This is consistent with a survey of construction projects in the UK undertaken by the Chartered Institute of Building, focused on time management, which found that on ‘simple projects’ there was no difference in performance between those projects with a properly developed and managed schedule and those without. The same proportions finished early, on time and late.

However, as soon as the projects became ‘complex’; there was a marked difference in performance. Projects with effective schedule control performed significantly better than those without, and the bigger/more complex the project, the more significant the difference. ( I will put up a post on the CIOB’s work and its new practice standard for scheduling in a few days).

The CIOB’s findings and a closer look at many of the blogs and comments on both PM 2.0 and Agile seem to fit this trend. I would suggest two conclusions could be drawn:

  1. If the work is small, simple and easy to understand there is no need for much in the way of traditional project controls. Knowledgeable people know what needs to be done and can just get on with the work.
  2. If the required output is not capable of being determined by the client and the objective is to ‘create something wonderful’ it is very difficult to apply too many project management techniques – basically you don’t know what needs to be planned, costed and scheduled, etc. Time and cost are secondary to creativity and the exploration of problems.

In both of these circumstances traditional project management may not be appropriate. In fact I would question if either circumstance is actually a project given the definition of a project is to produce a defined product, service or result that meets the needs of a customer.

The challenge for senior organisational management is recognising the threshold where PM 2.0 and ‘free form Agile’ cease to be appropriate and more traditional forms of project management are needed. Traditional project management does not mean ridged control, the type of project influences what’s needed (see: Projects aren’t projects – Typology) but appropriate systems do help optimize cost, time and quality to deliver client satisfaction.

This does not mean dumping the new ideas, rather melding them into an improved project management process. Agile software development fits in nicely to ‘rolling wave’ planning. Similarly some aspects of PM 2.0 can really help enhance team communication and collaboration. Used wisely, these ideas and technologies simply help improve the way projects work to deliver quality outputs to their clients. This change is really no different to the shift from faxes and carbon copy paper to emails. Good project management has always adapted to use improvements in processes and technology to improve the quality of service provided to the project’s clients. This next wave of improved technologies should be no different.

However, be wary of the zealots suggesting the ‘old ways’ don’t work and should be abandoned and use examples of really bad project management to prove their point. This is even more important if the zealots also advocate employing them to solve all of your problems for a fee. Management fads come and go – modern project management has been generally successful in achieving positive outcomes for well over 50 years now and continues to evolve and improve. For further comment see Glen’s post on: Herding Cats

5 Comments

Posted in Agile Ideas, General Project Management, IT Project Management, Project Typology, Stakeholder Management, Value

Tagged , , , , , , , , , , , , , , , , , , , , , ,

Stakeholder Management with apologies to Dr. Seuss

Posted on September 25, 2009 by | Leave a comment

When beetles battle beetles in a puddle paddle battle and the beetle battle puddle is a puddle in a bottle…
…they call this a tweetle beetle bottle puddle paddle battle muddle.
Excerpted from: Tweetle Beetles, ‘The Fox in Socks’, by Dr Seuss

The connection between a book written to be read to under 5s and business stakeholder management is the ‘puddle muddle’ otherwise known as the stakeholder pool. The challenge of managing stakeholders is a factor of the disturbance caused by dozens if not hundreds of battles most of which, the person attempting to efficiently manage his or her stakeholders has no control over whatsoever.

Most stakeholder management methodologies start by assessing the stakeholder from the perspective of the work. This is not unreasonable but can easily miss many important factors.

Figure 1: The Stakeholder Pool

Figure 1 shows ‘the stakeholder’ in the overall stakeholder pool being influenced by the ripples created by your battle in your part of the pool (your puddle). Unfortunately the stakeholder pool is a much bigger, more turbulent place.

Figure 2: the Stakeholder Pool with turbulence

Show some of the other disturbances in the pool and you start to see the stakeholder buffeted by waves and impacts from all directions, in Figure 2. ‘The stakeholder’ is continually being buffeted by waves from other projects, the organisation and many other influences. These other waves are one of the prime reasons stakeholder responses to your perfectly reasonable needs or suggestions are frequently so unpredictable. All of these influences, both current and past have helped shape the stakeholders perceptions and attitudes towards your industry, your organisation and ultimately, you.

Consequently, a single view point is really not sufficient! Effective stakeholder management needs an organisational approach. Successful stakeholder management requires all of the influences perceived by the stakeholder to be coordinated and authentic. And this can only be achieved by the organisation as a whole adopting mature, ethical stakeholder management as a core discipline.

Very little has been written about mature organisational stakeholder management until recently. To date, the focus of most papers have been one dimensional focusing on CRM and the ‘customer experience’ or one dimensional focusing on the relationship between the stakeholder and a project (or other organisational activity).

A new book, Stakeholder Relationship Management: A Maturity Model for Organisational Implementation, by Dr. Lynda Bourne takes this next step to define the interaction between the organisation as a whole and its stakeholders using the Stakeholder Relationship Management Maturity (SRMM®) model.

Effective and ethical stakeholder management cannot happen overnight and cannot happen in isolation. The preconceived perceptions of stakeholders towards your work are based on multiple experiences over an extended period of time, and the stakeholder-to-stakeholder conversations that occur outside of your hearing or control. To actively improve these conversations and create a positive and supportive stakeholder environment needs a long term consistent effort, organisation wide.

Bourne’s SRMM model offers a practical framework that can be used by organisations to build from ad hoc, single project attempts to manage stakeholders to a situation where stakeholder management is a core skill used by the organisation as a whole to maintain a competitive advantage. As with any culture change, this cannot happen overnight but at least Dr. Bourne’s new book provides a road map organisations can use to improve their management of stakeholder relationships to the benefit of both the stakeholders and the organisation.

Stakeholder Relationship Management: A Maturity Model for Organisational Implementation is published by Gower, ISBN: 978-0-566-08864-3

Leave a comment

Posted in Stakeholder Management

Tagged , , , , , , , , , ,

Thoughts on Agile

Posted on September 20, 2009 by | Leave a comment

Following on from a rather lengthy on-line discussion covering various aspects of the interface between the Agile software development methodologies and project management, we have developed a discussion paper that looks at how the two processes can be integrated.

The paper is a ‘work in progress’ aimed at business managers who are new to the concepts of Agile (ie, it is not intended as an Agile manual for IT professionals). Any comments will be appreciated.

The paper can be downloaded from: http://www.mosaicprojects.com.au/PDF_Papers/P109_Thoughts_on_Agile.pdf

Leave a comment

Posted in Agile Ideas, IT Project Management

Tagged , , , , , , , , , , , , , , ,

Agitating Agile

Posted on August 19, 2009 by | 10 comments

I have been involved in a series of posts on both my SRMM Blog (see post) and the PMI Voices on Project Management blog (see post) that have stirred up sections of the agile software development community.

Despite the Agile Manifesto focusing on providing excellence to stakeholders, many Agilists seem intent on advocating their rather extreme view of agile including no documentation, little planning or architectural design and less control. The mantra is ‘give the software developers free reign and you will get better software’. Whilst this may be true (although I somehow doubt it in anything but the smallest and simplest projects) it ignores the needs of the project’s key stakeholders.

Most IT projects exist to enhance the capability of the organisation. Consequently the software development is only one part of an overall project to change the organisation, deliver new capabilities or similar. In these typical circumstances, the IT component needs to meet predetermined requirements; any change in the IT capability delivered requires changes in other parts of the project. In fact the best IT solution may turn out to be an unacceptable business solution.

Meeting the needs of the businesses key stakeholders demands discipline and communication not just within the ‘scrum’ or XP team but to the customer’s managers. This needs at the very least a minimum of documentation to prove the IT team and its immediate customers understand their scope of work and other constraints and know how they will achieve the outcomes needed to support the business. Adequate documentation and effective communication are essential.

This post is not suggesting a return to Waterfall or other heavily documented software development process (they don’t work very well anyway – refer the Standish reports) but rather for an appropriate level of documentation to meet the genuine needs of senior management stakeholders. Saying ‘trust me’ is not enough and is not good stakeholder management.

Identifying the key stakeholders, assessing their requirements and expectations and then managing these key relationships so the stakeholders realistic expectations can be realised definitely involves up-front planning and effort, needs tools and methodologies such as the Stakeholder Circle® and involves on-going monitoring and control but is, I would suggest, worth the effort. Your project is unlikely to be seen as successful if the stakeholders expectations are not realised!

In most aspects of life the long term enjoyment of real freedom required a significant measure of self discipline. The agile extremists may do well to consider this and focus on meeting the needs and expectations of all of the stakeholders involved in their work.

10 Comments

Posted in Agile Ideas, IT Project Management, Stakeholder Management

Tagged , , , , , , , , , , , , , ,

Key Stakeholders

Posted on January 19, 2009 by | 2 comments

I was recently asked by a colleague for the definition of key stakeholder. Everyone writing about stakeholders uses the term probably synonymously with ‘important stakeholder’ but what is the actual definition?

One definition is from Cornell University, Information Technologies. Their definition is: ‘Key Stakeholders are a subset of Stakeholders who, if their support were to be withdrawn, would cause the project to fail’.

This definition is probably true of IT and internal projects but ignores important stakeholder groups such as the ‘environmentalists’ opposed to a major engineering project. Some important stakeholders will never support the project and are focused on preventing it proceeding (or in the example above, at least minimising its impact on the environment). They may never see the project’s output as good or desirable – for these, effective stakeholder management is about finding an effective, ethical way of neutralising the threat they pose.

We use the term key stakeholder to identify members of the sub-group of stakeholders who have the power to substantially damage the project and may potentially cause it to fail. This group are both important and influential/powerful; they may be individuals such as an important manager or entities such as a regulatory authority. This concept of key stakeholder is used extensively in my book Stakeholder Relationship Management: A Maturity Model for Organisational Implementation (due for publication, September 2009).

Key stakeholders must be both important and influential

Our definition is:
Key stakeholders are a subset of stakeholders who have power to prevent the project from achieving its full set of objectives and potentially may cause the project to fail.

This is the flip side of success. Before you can win a game, you have to not lose it. (Chuck Noll, ex-Pittsburgh Steelers Coach). If you fail to manage your project’s key stakeholder community, your project is almost certain to fail: not failing however, does not mean succeeding.

A large proportion of the project’s key stakeholders will also have the power to influence the determination/perception of the project’s eventual success. But in most circumstances, if the project is to be deemed successful, a large numbers of additional stakeholders will have to want to make use the project’s output to realise the value/benefits the project was initiated to create.

For the project to be deemed successful, most stakeholders must perceive it as a success

Achieving success involves significantly more than just completing the project on-time and on-budget. For more on this see my earlier post Success and Stakeholders.

Definitions:

  • Organisation’s Stakeholder: Stakeholders are individuals or groups who will be impacted by, or can influence the success or failure of an organisation’s activities.
  • Project’s Stakeholder: Stakeholders are individuals or groups who will be impacted by, or can influence the success or failure of the project’s work and/or its deliverables.
  • Important Stakeholder: A stakeholder who has been identified as important, using an appropriate prioritisation methodology (such as the Stakeholder Circle®), for the purpose of allocating scarce resources to ensure effective communication and to focus other stakeholder management initiatives.
  • Key Stakeholder: A stakeholder who has to power to prevent the project from achieving its full set of objectives and potentially may cause the project to fail.

Note: By these definitions, key stakeholders are always a potential risk to the project (opportunity and/or threat) but may not be particularly important ‘at this point in time’ if the relationship is working well (ie, they may not need high priority communication at this point in time). This will be the subject of a future blog.

Are you aware of any better definitions of key stakeholder?  Your comments are welcome.

2 Comments

Posted in Stakeholder Management

Tagged , , , , ,