Tag Archives: Project success

Differentiating normal, complex and megaprojects

The days when projects were simply projects and project success was defined by the ‘iron triangle’ are long gone.  The intention of this post is to try and bring together four aspects of current thinking and their embedded concepts into an overall model of project management in the 21st century.  The starting point is traditional project management as defined in the soon to be published 6th Edition of the PMBOK® Guide; the major change (incorporated in the 6th Ed.) is ‘Agile Project Management’.  The two significant extensions to traditional project management that go beyond the PMBOK® Guide are ‘Complex Project Management’ and ‘Megaproject Management’. The focus of this paper is on the skills and competencies needed by the ‘managers’ of these different classifications of ‘projects’ rather than the scope of the different concepts (more on this later).

As a starting point, there seems to be a generally accepted view that the competencies needed to be a successful project manager underpin all of the other concepts. There are some distinctly different techniques used in Agile, only some of which flow into traditional project management, but in other respects ‘agile’ and ‘good project management’ are very closely aligned.  Managing complexity requires a significant additional set of competencies that build onto the traditional requirements.  Then, whilst many complex projects do not meet the definition of a ‘megaproject’, every megaproject is by definition a complex project with an additional layer of management capabilities needed to deal with its impact on society.  This basic framework is outlined below:

Stakeholders

All forms of project management recognise the importance of the project stakeholders. Projects are done by people for people and the ultimate success or failure of a project is defined by people – all ‘stakeholders’.  My work on the PMBOK® Guide 6th Edition core team was very much focused on enhancing the sections on stakeholder engagement and communication (which is the primary tool for engaging stakeholders). And as the scale of projects increase, the number of stakeholders and the intensity of public focus increases dramatically.

A heuristic suggested by Prof. Bent Flyvbjerg is as a general rule of thumb: ‘megaprojects’ are measured in billions of dollars, ‘major projects’ in hundreds of millions, and ‘projects’ in tens of millions or less. To quote the late Spike Milligan, ‘Money can’t buy you friends but you do get a better class of enemy’ – and while many stakeholders may not be ‘enemies’, the ability of stakeholders to organise around a megaproject tends to be far greater than around a small internal project. Consequently, the focus on stakeholders should increase significantly in excess of the increment in cost as you flow from small to megaprojects.

However, regardless of size, the need to identify, engage, manage, and deliver value to stakeholders, through the realisation of beneficial change, is consistent through all of the concepts discussed below. This and the temporariness of each ‘project organisation (ie, team)’ are the two consistent factors that underpin the concept of project management; and ‘temporariness’ is the key factor that separates projects and programs from other forms of management and ‘business as usual’.

 

Traditional Project Management.

The recognised guide for traditional project management is the PMBOK® Guide augmented to a degree by ISO 21500. The publicly released information on the 6th Edition highlights the need for flexibility in applying its processes, including the requirement to actively consider ‘tailoring processes’ to meet project requirements, and the value agile thinking can bring to the overall management of projects (see below).

The frame of traditional project management starts once the project is defined and finishes once the project has delivered is objectives. While this scope is somewhat limited and there may be a need to expand the scope of project management to include project definition at the ‘front end’, and benefits realisation and value creation after the outputs have been delivered (this will be the subject of another post), the knowledge, skills and competencies required to manage this type of project management are well understood.

Each project has four basic dimensions, size (usually measured in $), technical difficulty, uncertainty and complexity (these are discussed in detail in: Project Size and Categorisation). In the right circumstances, Agile can be an effective approach to resolving uncertainty. However, at an undefined point, the increase in complexity reaches a point where the concept of ‘complex project management’ becomes significant and really large projects are the realm of ‘megaproject management’. But the underpinning capabilities required to manage all of these extensions remains the conventional project management skills.

 

Agile Project Management

Agile has many facets. The concepts contained in the Agile Manifesto basically reflect a shift away for a ridged focus on process towards a focus on people (stakeholders) and adapting to change to achieve a successful outcome.  These concepts are now firmly embedded in the PMBOK® Guide 6th Edition and apply to every project. Where agile projects separate from traditional projects is recognising that in a range of soft projects, including software development, taking an iterative and adaptive approach to understanding the scope can often achieve a better outcome. Understanding what is actually helpful to the client develops based on learned experience from earlier iterations and these needs are incorporated into the next iteration of the development allowing a better outcome to be delivered to the client. This is not significantly different to much older concepts such as ‘rolling wave planning’ and progressive elaboration – there really is little point in making detailed plans for work you don’t know much about. The difference is Agile actively expects the scope to be adapted to the emerging requirements of the client, the other approaches seek to add detail to the plans at an appropriate point in time whilst the overall scope remains fundamentally unchanged.

Agile does not even need a project to be useful. Many of the Agile techniques work in any situation where there is a backlog of work to get through and can be effectively used outside of the concept of a ‘project’, this particularly applies to routine maintenance work of almost any kind.  A discussion on the value of Agile, and its limitations, are contained in our paper Thoughts on Agile.

However, for the purposes of this post, the key aspects Agile brings to the discussion, that are essential for effectively managing most types of project, are contained in the Manifesto – a preference for:

  • Individuals and interactions over processes and tools.
  • Customer collaboration over contract negotiation.
  • Responding to change over following a plan.

The Manifesto recognises there is value in the items on the right, but values the items on the left more.

 

Complex Project Management

Complexity is a facet of every project and program. Complex project management skills become important at the point where complexity becomes a significant inhibitor affecting the delivery of a successful outcome from the project (or program). This point may occur well before ‘complexity’ becomes the defining feature of the project.

Complexity is a very different concept to a complicated project, technically complicated work can be predicted and managed; launching a new communication satellite is ‘rocket science’, but there are highly skilled rocket scientists available that undertake this type of work on a routine basis. As with any traditional project, the costs, resources and time required can be predicted reasonably accurately.

The dominant feature of complexity is the non-predictability of outcomes. Non-linearity, ‘the tipping point’, and emergence describe different ways outcomes from a slightly different starting point can vary significantly compared to previous experience or expectations (for more on the concepts of complexity see: Complexity Theory).  Complexity arises from various forms of complex system, these may be organic (eg, a river’s eco-system), man-made (eg, an overly complicated system-of-systems such as too many interconnected software applications automatically interacting with each other), or interpersonal (eg, the web of relationships within and between a project team and its surrounding stakeholder community).  In all of these situations, the ‘system’ behaves relatively predictably, dealing with the effects of stresses and stimuli up to a point (and normal management approaches work satisfactorily); but after that point adding or changing the situation by a small increment creates completely unexpected consequences.

Interestingly, from the perspective of managing a project, these three areas of complexity are closely interlinked, the complex behaviour of the environment and/or man-made systems-of-systems feeds back into the perceptions of stakeholders and the activity of stakeholders can impact on both the environment, and the way complex systems function. Similarly, dealing with emerging anomalies in the environment or in a complex system needs the active cooperation of at least some of the project’s stakeholders. Consequently, the focus of complex project management is dealing with the consequences of the inherently unpredictable and complex behaviours and attitudes of stakeholders, both within the team and within the surrounding stakeholder community.

Some projects and programs, particularly large ones, are obviously complex from the outset and can be set up to make effective use of the ideas embedded in complex project management. Others may be perceived as non-complex ‘business-as-usual’ and tip into complexity as a result of some unforeseen factor such as a ‘normal accident[1]’ occurring or simply because the perception of ‘straightforward’ was ill-founded. Underestimating complexity is a significant risk.

Where the project is perceived to be complex from the outset, a management team with the competencies required to deal with the nuances of managing a ‘complex project’ can be appointed from day one (and if appropriately skilled people are not available, support and training can be provided to overcome the deficiencies) – this maximises the probability of a successful outcome.  When a project unexpectedly falls into a state of complexity the situation is far more difficult to manage primarily because the people managing the work are unlikely to be skilled in complex project management, will try to use normal management techniques and most organisations lack the resources needed to help rectify the situation – skilled complex project managers are in short supply globally.

One initiative designed to overcome this shortage of ‘complex project managers’ and build an understanding of ‘complex project management’ is the International Centre for Complex Project Management (ICCPM).  ICCPM’s approach to complex project management is to see this capability as an extension of traditional project management (as inferred in the diagram above). The ICCPM view is that while traditional approaches are insufficient to effectively manage a complex project on their own, you cannot manage a complex project without a strong foundation based on these traditional skills and processes. The relationship is described by the ICCPM as:

What changes is in part the way the traditional capabilities such as scheduling and budgeting are used, overlaid with the expectation these artifacts will need to adjust and change as the situation around the project changes, augmented with a range of ‘special attributes’ particular to the process of managing a complex project. These ‘special attributes’ are valuable in the management of any project but become essential in the management of complex projects.  These capabilities and competencies are defined in the ICCPM’s Complex Project Manager Competency Standard available from: https://iccpm.com/.

Complex projects can vary in size from relatively small undertakings involving factors such as updating a complex systems-of-systems, or a high level of political sensitivity, through to the megaprojects discussed below. A complex project may not be a megaproject or even a major project, but every megaproject and many major projects will also be a complex project requiring complex project management capabilities for a successful outcome.

 

Megaproject Management

Megaprojects are defined as temporary endeavours (i.e. projects or programs) characterised by:

  • A large investment commitment;
  • Vast complexity (especially in organizational terms); and
  • A long-lasting impact on the economy (of a country or region), the environment, and society.

They are initiatives that are physical, very expensive, and public. By definition, megaprojects are complex endeavours requiring a high degree of capability in the management of complex projects.  In addition megaprojects typically involve a number of other facets:

  • Megaprojects are by definition a program of work (see: Defining Program Types).
  • Many are implemented under government legislation, requiring skills and knowledge of government processes and the ability to operate within the ambit of ‘government’. This is a very different space in terms of accountability and transparency compared to private enterprise.
  • Most interact with a range of government agencies at all levels of government from local to national. These stakeholders often have a very different set of agendas and success criteria compared to the organisation running the megaproject.
  • The size of a typical megaproject involves large amounts of money and therefore increases the risk of corruption and other malfeasance – governance and controls need to be robust[2] to maintain high ethical standards.
  • The ‘political attractiveness’ of doing a megaproject (eg, hosting the Olympics) distorts decision making; care in the megaproject development process is required to reduce the effect of optimism bias and strategic misrepresentation (see: The reference case for management reserves).
  • Megaprojects are financially fragile[3] and fragility is typically irreversible. Once broken the fragile entity cannot be readily restored to its original function. Financial (or investment) fragility is defined as the vulnerability of a financial investment to becoming non-viable, i.e., losing its ability to create net economic value. For example, the cost risks for big dams are significant; the actual costs more than doubles the original estimate for 2 out of 10 dams; triples for 1 out of every 10 big dams. But managers do not seem to learn; forecasts today are likely to be as wrong as they were between 1934 and 2007.

Recognising the scope and complexity of managing a megaproject and training people appropriately can mitigate the risks, the UK experience around Terminal 5 and Cross Rail (both £4 billion projects) suggest that achieving a good outcome is viable provided the organisation commissioning the megaproject is prepared to invest in its management. It’s probably no coincidence the management of megaprojects and their associated risk has been the focus of the Saïd Business School, University of Oxford for many years.

 

Summary

The competencies needed to manage projects grows in line with the increase in complexity and the increase in size. There are definitely additional elements of competency needed at each step in the framework outlined above.  What is far less clear is how to demarcate between normal, complex and megaprojects! Every project has a degree of complexity and a degree of size.  The values suggested above to separate normal, major and mega projects are arbitrary and there is even less clarity as to the transition between normal and complex projects.

I suspect the domain map demarcating the different disciplines will end up looking something like this but there’s a lot of research needed to define the boundaries and assign values to the axis (especially in terms of measuring the degree of complexity).  Hopefully, this blog will serve to start the discussion.

______________________

 

[1] Normal accidents are system accidents that are inevitable in extremely complex systems. The three
conditions that make a system likely to be susceptible to Normal Accidents are:
–  The system is complex
–  The system is tightly coupled
–  The system has catastrophic potential
The characteristic of the system leads to multiple failures which interact with each other, despite efforts to avoid them.

[2] For more on governance and ethics see: http://www.mosaicprojects.com.au/PM-Knowledge_Index.html#OrgGov1

[3] From: Big Is Fragile: An Attempt at Theorizing Scale, in Bent Flyvbjerg, ed., The Oxford Handbook of Megaproject Management (Oxford: Oxford University Press)

Setting up a project controls system for success

A couple of hour’s hard thinking can make the difference between project success and failure!  Far too many projects are simply started without any real thought as to the best strategy for delivery and what control systems are really needed to support the management of that delivery – one size does not ‘fit-all’ and simply repeating past failures creates more failures.  Similarly, far too many control systems are implemented that simply generate useless paperwork (frequently to meet contractual requirements) when what’s needed is effective controls information.

Remembering that all project controls documents have to be used and maintained to be useful; the three key thinking processes needed to help build project success are:

  • First the big question – how are we going to do the work to maximise the opportunity of success and optimise risk??  This is a strategic question and affects procurement as much as anything – off-site assembly needs a very different approach to on-site assembly. This does not need a complicated document but the strategy does need to be agreed; see: www.mosaicprojects.com.au/WhitePapers/WP1038_Strategy.pdf
  • From the strategy, the project management team structure can be designed to best manage the work as it will be accomplished and these people (or at least the key people) can then contribute to the planning process. Pictures are as useful as anything to define the overall flow of the work; see: www.mosaicprojects.com.au/WhitePapers/WP1039_Project_Planning.pdf.
  • Once you know the way the work will be accomplished and the overall flow/sequence of the work you are now in a position to plan the project controls function aiming to apply the minimum amount of ‘controls’ necessary to be effective.  Excessive controls simply waste money and management time. My approach is always to do a bit less then I think may be needed because you can always add some additional features if the need eventuates – it Is nearly impossible to remove controls once they have been implemented.
  • Then you can develop the schedule and other control tools needed for effective management working within the framework outlined above.

This area is what PMI call Schedule strategy and Schedule planning and development. Getting this ‘front-end’ stuff right is the best foundation for a successful completion of a project; this is the reason these elements of project controls have a strong emphasis in the PMI-SP exam.

Conversely, stuffing up the strategy in particular, means the project is set up to fail and implementing control systems that do not support the management structures within the project simply mean the controls people are wasting their time and the time of everyone they engage with.

However, creating a project that is based on a sound strategy supported by a useful project controls system will require some cultural changes:

  • The project manager and project executive will need to take some time to look at strategic options and develop an effective delivery strategy.
  • The organisation and client will need to allow the project controls professionals to work through the challenges of developing a ‘light-but-effective’ controls system and then review/approve the system – this is more difficult than simply requiring every project to comply with some bloated standard controls process that no one uses (except for claims) but should deliver massive benefits.
  • The organisation will need skilled project controls professionals……….
  • And the project management team will need to be willing to work with and use the project controls.

The problem is easy to outline – fixing it to enhance the project success rate is a major challenge.

Some ideas for making project management effective and efficient in 2016

SuccessIt’s a New Year and by now most of us will have failed to keep our first set of New Year resolutions! But it’s not too late to re-focus on doing our projects better (particularly in my part of the world where summer holidays are coming to an end and business life is starting to pick up). Nothing in the list below is new or revolutionary; they are just good practices that help make projects successful.

Most projects that fail are set up to fail by the organization and senior management (see:  Project or Management Failures?).  80% of projects that fail don’t have a committed and trained project sponsor. An effective project sponsor will:

  1. Give clear project objectives.
  2. Help craft a well‐defined project scope.
  3. Remove obstacles that affect project success.
  4. Mediate disagreements with other senior stakeholders.
  5. Support the project manager.

The role of the project or program sponsor is outlined in: WP1031 Project & Program Sponsorship.

Customers or end‐users are critically important to the success of ‘their project’. Unfortunately there is an extreme shortage of ‘intelligent customers’.  A ‘good customer’ will:

  1. Help refine the project scope – no one gets it 100% correct first time.
  2. Convey requirements fully and clearly
    (see: WP 1071 Defining Requirements).
  3. Avoid changing their minds frequently.
  4. Adhere to the change management process.

Every project team needs expertise – this is frequently provided by external experts. Subject‐matter experts should:

  1. Highlight common pitfalls.
  2. Help rather than hinder decision making.

The work of the project is done by ‘the team’. A committed and motivated project team will:

  1. Buy into the project’s objectives.
  2. Identify all of the required tasks and ensure the schedule is complete and accurate.
  3. Provide accurate estimates.
  4. Report progress and issues truthfully.
  5. Deliver their commitments.
  6. Focus on achieving the intended benefits
    (see: WP 1023 Benefits and Value).

Finally, the project manager

  1. Recognises that there is no “I” in project and works with the team and stakeholder community to create a successful outcome
  2. Resolves issues and risks that may arise from the 18 items above quickly, efficiently and effectively.

Making Projects WorkAlmost all of the items listed require action by people other than the project manager – this highlights the fact that projects are done by people for people and the key skill required by every project manager is the ability to influence, motivate and lead stakeholders both in the project team and in the wider stakeholder community.

For more on Making Projects Work see: http://www.mosaicprojects.com.au/Book_Sales.html#MPW

How to succeed as a PM in 2016

On-the-busProjects are done by people for people and through the medium of social media, people power is growing.  Successful project managers know this and use it to their advantage; they create a team culture focused on working with other stakeholders to create success.

Project managers know when they get this right because their project team will challenge, follow and support them, and each other, in order to get the job done. Not only that, but word spreads and other people inside the organisation will want to join the team or be associated with its success. When a PM achieves this, they know they have created something special and paradoxically are under less pressure, can get a good night’s sleep, and as a consequence are fully refreshed each day to keep building the success. This is good for the people and great for the organisation!!

Developing the skills and personal characteristics needed to develop and lead a committed team needs more then technical training. Experience, reflection, coaching and mentoring all help the project manager grow and develop (and it’s a process that never stops). Five signs that they are on the path to becoming a great team leader are:

  1. They’re well liked. Great leaders make people feel good about themselves; they speak to people in a way that they like to be spoken to, are clear about what needs to be achieved[1], and are also interested in their lives outside work and display a little vulnerability every now and again to demonstrate that they are human. They’ll always start the day with a ‘good morning’, the evening with a ‘good night’ and every question or interaction will be met with courtesy. When the team picks up on this the project area will be filled with good humour and great productivity.
  2. They put effort into building and maintaining teams. Designing great teams takes lots of thought and time – you need the right people ‘on the bus[2]’ and you need to get the wrong people ‘off the bus’. A great project manager doesn’t accept the people who are ‘free’ or ‘on the bench’ unless they’re the right people and they’ll negotiate intensely for the people that they really need, going to great lengths to recruit people into the vision that they have. Once the team is in place, they never stop leading it, building it, encouraging it, performance managing it and celebrating it.
  3. They involve everyone in planning. Or at least everyone that matters! The PM identifies the team members and other stakeholders that need to be involved; creates a productive, enjoyable environment, and leads the process. They want to ensure that they get the most out of the time and at the end have a plan that the team has built and believe in.
  4. They take the blame and share the credit. Great project managers are like umbrellas. When the criticism is pouring down they ensure that the team is protected from it. They then ensure that the message passed down is presented as an opportunity to improve not a problem to be fixed. Similarly, when the sun is out and the praise is beaming down, they ensure that the people who do the real work bask in it and are rewarded for it. When they talk about how successful a project has been, they talk about the strengths of the team and the qualities they have shown, never about themselves.
  5. They manage up well. Stakeholder engagement, particularly senior stakeholder engagement is the key to project success[3]. Great project mangers know they need senior executive support to help clear roadblocks and deliver resources and know how to tap into the organisation’s powerlines for the support they need.

Great project mangers are also good technical managers; they have an adequate understand the technology of the project and they know how the organisation’s management systems and methodologies work. But they also know they can delegate much of this aspect of their work to technologists and administrative experts within their team. And if the team is fully committed to achieving project success, these experts will probably do a better job than the project manager anyway.

Projects are done by people for people and the great project managers know how to lead and motivate[4] ‘their people’ to create a successful team that in turn will work with their stakeholders to create a successful project outcome.
[1] For more on delegation see:  http://www.mosaicprojects.com.au/WhitePapers/WP1091_Delegation.pdf

[2] In the classic book Good to Great, Jim Collins says, “…to build a successful organization and team you must get the right people on the bus.”

[3] This is the focus of my book Advising Upwards: A Framework for Understanding and Engaging Senior Management Stakeholders, see http://www.mosaicprojects.com.au/Book_Sales.html#Adv_Up

[4] For more on leadership see: http://www.mosaicprojects.com.au/WhitePapers/WP1014_Leadership.pdf

For Stakeholders, 2×2 Is Not Enough!

The world loves 2×2 matrices – they help make complex issues appear simple.  Unfortunately though, some complex issues are complex and need far more information to support effective decision making and action.  The apparent elegance of a 2×2 view or the world quickly moves from simple to simplistic.

One such situation is managing project and program stakeholders and convincing the stakeholders affected by the resulting organisational change that change is necessary and potentially beneficial.  As a starting point, some stakeholders will be unique to either the project, the overarching program or the organisational change; others will be stakeholders in all three aspects, and their attitude towards one will be influenced by their experiences in another (or what others in their network tell them about ‘the other’).

The problem with a simple 2×2 view of this complex world is the assumption that everyone falls neatly into one of the four options and everyone categorised as belonging in a quadrant can be managed the same way.  A typical example is:

power-interest

Power tends to be one dimension, and can usually be assessed effectively, the second dimension can include Interest, Influence, or Impact none of which are particularly easy to classify.  A third dimension can be included for very small numbers of stakeholders by colouring the ‘dots’ typically to show either importance or attitude.

The problem is you may have a stakeholder assessed as high power, low interest who opposes your work, who you need to be actively engaged and supportive – ‘keep satisfied’ is a completely inappropriate management strategy.

The Salience Model developed by Mitchell, Agle, and Wood. (1997) introduces the concepts of urgency and legitimacy.

Salience

Urgency refers to the degree of effort the stakeholder is expected to expend in creating or defending its ‘stake’ in the project, this is an important concept!  However the concepts of ‘legitimate stakeholders’ and non-stakeholders are inconsistent with stakeholder theory[1] and PMI’s definition of a stakeholder – anyone who believes your project will affect their interests can make themselves a stakeholder (even if their perception is incorrect) and will need managing.  This model also ignores the key dimension of supportive / antagonistic.

The three dimensional Stakeholder Cube is a more sophisticated development of the simple 2×2 chart. The methodology supports the mapping of stakeholders’:

  • Interest (active or passive);
  • Power (influential or insignificant); and
  • Attitude (backer or blocker).

Ruth_MW

This approach facilitates the development of eight typologies with suggestions on the optimum approach to managing each class of stakeholder (Murray-Webster and Simon, 2008[2]). However, the nature of the chart makes it difficult to draw specific stakeholders in the grid, or show any relationships between stakeholders and the activity. However, as with any of the other approached discussed so far, the classifications can be used to categorise the stakeholders in a spreadsheet or database and most of the key dimensions needed for effective management are present in this model. The two missing elements are any form of prioritisation (to focus effort where it is most needed) and the key question ‘Is the stakeholder in the right place?’ is not answered.

Information needed for a full assessment

The factors needed for effective stakeholder management fall into two general categories, firstly the information you need to prioritise your stakeholder engagement actions; second the information you need to plan your prioritised engagement activities.

The two basic elements needed to identify the important stakeholders at ‘this point in time’ are:

  • Firstly the power the stakeholder has to affect the work of the project. This aspect tends to remain stable over time)
  • Secondly the degree of ‘urgency’ associated with the stakeholder – how intense are the actions of the stakeholder to protect of support its stake? This aspect can change quickly depending on the interactions that have occurred between the project team and the stakeholder.

I include a third element in the Stakeholder Circle® methodology[3], how close is the stakeholder to the work of the project (proximity) – stakeholders actively engaged in the work (eg, team members) tend to be need more management attention than those relatively remote from the work.

The next step is to assess the attitude of the important stakeholders towards the work of the project.  Two assessments are needed, firstly what is the stakeholder’s current attitude towards the project and secondly what is a realistically desirable attitude to expect of the stakeholder that will optimise the chance of project success?

Attitudes can range from actively supportive of the work through to active opposition to the work. The stakeholder may also be willing to engage in communication with you or refuse to communicate[4].  If you need to change the stakeholder’s attitude, you need to be able to communicate!

From this information you can start to plan your communication. Important stakeholders whose attitude is less supportive than needed require carefully directed communication. Others may simply require routine engagement or simple reporting[5].

If this all sounds like hard work it is! But it’s far less work then struggling to revive a failed project. This theme is central to my new book, Making Projects Work, Effective stakeholder and communication management[6]. You generally only get one chance to create a first impression with your stakeholders – it helps to make it a good one.

Making Projects Work

[1] For more on ‘stakeholder theory’ see:
https://mosaicprojects.wordpress.com/2014/07/11/understanding-stakeholder-theory/

[2] For more information see www.lucidusconsulting.com

[3] For more on stakeholder prioritisation see: http://www.stakeholder-management.com/shopcontent.asp?type=help-4

[4] For more on assessing stakeholder attitudes see: http://www.stakeholder-management.com/shopcontent.asp?type=help-6

[5] For more on the ‘three types of stakeholder communication’ see: http://www.mosaicprojects.com.au/Mag_Articles/SA1020_Three_types_stakeholder_communication.pdf

[6] For more on the book see: http://www.mosaicprojects.com.au/Book_Sales.html#MPW

Project failure revisited

Project-FailOver the holiday period there has been a couple of interesting discussion on project success and failure. The consensus of the many commentators was that the simplistic measures of time, cost and scope are inadequate but there was little consensus on the solution.  This post poses some of the questions that need a considered answer:

Firstly, the APM website posed the question which of the following projects was successful?

Two organisations decided to undertake identical projects with a normalised value of  $1million.
–  Organisation A assessed their project and set the project budget at $800,000
–  Organisation B assessed their project and set the project budget at $1,200,000
Organisation A’s team did their best to ‘meet the challenge’ and achieved an outcome of $900,000 – a cost overrun of $100,000 nominally a project failure.
Organisation B’s team did ‘a good job’ and achieved an outcome of $1,100,000 – a profit of $100,000 nominally a project success.

But which project is really successful??  The one that cost $900,000 or the one that cost $1,100,000 to produce the same output.  This example is simplistic, the numbers are given and the problem is demonstrated, but nowhere will you ever have two identical projects run against different baselines.  How can you assess the ‘project risk’ caused by soft or hard targets??

Similar issues arise when allocating the blame for ‘failure’ to different parts of the ‘performing organisation’.  Many so-called project management and project leadership failures are likely to be either unavoidable consequences or symptoms of far more significant underlying issues (for more on this see: Project or Management Failures?).  Focusing on the superficial (and blaming the project manager) prevents a more thorough ‘root cause analysis’  of the real issues and problems in organizations.  I will take 2 examples and borrowing from Toyota’s ‘Five Whys’ ask ‘why’ a few times:

  1. Failure of PM leadership. The project manager failed to lead, relate or communicate, with stakeholders. But the project manager did not appoint him/her self , some of the unanswered questions are:
    1. Why did the organisation appoint a PM lacking the requisite skills?
    2. Why did the organisation fail to support/train the PM?
    3. Why were the failings not picked up and resolved during routine project surveillance?
  2. Failing to use recognised techniques such as risk management. Some of the unanswered questions are:
    1. Why does the organisation allow sub-standard practices to exist?
    2. Does the organisation have proper templates, processes and support in place to support the practice?
    3. Does the organisation provide adequate time, training and resources to implement the practice?
    4. Why were the failings not picked up and resolved during routine project surveillance?

The answer to these questions may go back to organisational culture, the overall organisational ability to effectively manage and support its projects (the strategic management of projects)  and/or ultimately the governance of the organisation.

Certainly some projects will fail for project related reasons; projects and programs are innately risky and this means project related failures are to be expected – minimising this cause of failure will be valuable. But, simply measuring performance against cost and time targets is influenced by the way the initial target was set in the first place.

project-failure-2The problem is compounded by the lack of ‘root cause’ assessments. I expect a proper study of the root causes of many so-called ‘project failures’ will show many projects are effectively set up to fail by the organisation.  Allowing executive management to continue with these types of practices is ultimately a governance failure. Addressing the ‘root causes’ of failure hidden in executive management practise, culture and governance are likely to generate significantly greater benefits than simply trying to ‘fix project management’; but you cannot see the failures without proper data.

One initiative aimed at working towards a standardised assessment of project failures is a series of articles being published by Proff. Alan Stretton in PM World Journal, see: http://pmworldjournal.net/article/series-project-success-failure-deficiencies-published-causes-project-failures/  (registration is free).

Given the general management mantra of ‘you cannot manage what you cannot measure’, developing a measure of project failure that is valuable and consistent would be a good start in developing the data needed to allow management improvement across the board.

As Alan concluded the referenced article:

The above deficiencies in current data all point to an urgent and obvious need to develop comprehensive data on causes of project failures – preferably validated by appropriate and agreed criteria as to what constitutes success / failure, and covering the widest possible range of project types and project management application areas.

A suggestion (or challenge) here is for global project management organisations (IPMA, PMI, apfpm, etc) to jointly create a framework to develop and share project success / failure data, covering the widest possible range of project management types and application areas. This would include

  • Developing and agreeing common criteria for project success / failure;
  • Collecting and sharing validated data on success/ failure rates;
  • Researching and sharing validated data on success drivers / failure causes.

If you agree support Alan and start lobbying your PM association of choice. Defining the problem is easy, solving it elegantly is not!

Opportunity Lost

RICSThe first edition of the RICS / APM guidance note on Stakeholder Engagement is a missed opportunity. Hopefully the second edition will plug many of the glaring gaps.

The guide is built around ten principles:

  • Principle 1: Communicate
  • Principle 2: Consult early and often
  • Principle 3: Remember they’re only human
  • Principle 4: Plan it
  • Principle 5: Relationships are key
  • Principle 6: Simple, but not easy
  • Principle 7: Just part of managing risk
  • Principle 8: Compromise
  • Principle 9: Understand what success is
  • Principle 10: Take responsibility

All sound principles but in a strange order

Any complex endeavour needs a clear understanding of its objectives and then a plan to achieve the objectives before starting work, but ‘Understand what success is’, is at #9 and ‘Plan it’ at #4.  Surly the whole point of engaging stakeholder is to enhance the probability of success. Which means #1 understand what success is, #2 plan how to achieve success and then move into implementation.

But implementation needs focus, completely missing from the guide is any practical guidance on ways to understand the stakeholder community, prioritising the stakeholders so the communication effort is focused where needed and then managing the overall engagement effort for maximum effect. The best the guide can offer is a simplistic 2×2 matrix. My methodology, the Stakeholder Circle® is one of several that recognise the multiplicity of dimensions needed to understand a stakeholder, the outline is available free of charge from http://www.stakeholdermapping.com/stakeholder-circle-methodology/

The last omission is considering the path to stakeholder management maturity. The path to maturity is mapped at: http://www.stakeholdermapping.com/srmm-maturity-model/

I had hoped stakeholder engagement was moving beyond the soft ‘fluffy’ platitudes of the past into a pragmatic management process, allied to risk management, focused on maximising the aggregate benefit from a project to all of its stakeholders.  These ideas are in the RICS Stakeholder Engagement guide but unfortunately the guide lacks any guidance on how to achieve these objectives, with the exception of the CASE model in Appendix 3.

Hopefully the 2nd Edition will not be too far away.

The 1st Edition is available from http://www.rics.org/shop