Monday

Tag Archives: Benefits Realization

Benefits Management

Posted on January 8, 2024 by | 2 comments

The publication of BS 202002:2023 – Applying benefits management on portfolios, programmes and projects, last year has prompted an update to our Value and Benefits Realization page, including a link to the new Standard’s home page.

As we know, organizations invest resources in projects to derive benefits and create value.  But those benefits don’t happen by themselves, they need to be managed. BS 202002:2023 is a new British standard on how to deliver the planned benefits of projects, programmes and portfolios to create value for the organization and its customers.

While the Standard is quite expensive to buy, all of the publications on the Mosaic ‘Value and Benefits’ page are free to download and use and cover:
– Value and Benefits Overview,
   – Defining project success,
– Benefits Management,
– Value Management and Value Engineering, and
– Useful External Web-links & Resources.  

See more at: https://mosaicprojects.com.au/PMKI-ORG-055.php  

2 Comments

Posted in General Project Management, Governance

Tagged , , ,

Levels of Stakeholder Engagement

Posted on August 21, 2017 by | 1 comment

How engaged should your stakeholders be? Or how engaged do you want them to be? In an ideal world the answer to both questions should be the same, but to even deliver a meaningful answer to these questions needs a frame of measurement.  This post uses ideas from 1969 to propose this framework!

In July 1969, Sherry R. Arnstein published ‘A Ladder of Citizen Participation’ the A.I.P Journal[1] looking at citizen participation and the consequential citizen power over a range of USA government initiatives designed to enhance the lives of disadvantaged people in US cities. The typology of participation proposed by Arnstein can be transposed to the modern era to offer a framework for discussing how engaged in your project, or program, your stakeholders should be in actively contributing to the management and governance of the work they are supposed to benefit from.

Modern paradigms such as ‘the wisdom of crowds’, ‘user participation in Agile teams’ and ‘stakeholder theory’ all lean strongly towards stakeholder ownership of the initiative designed to benefit them. These views are contrasted by concepts such as technical competence, intellectual property rights, confidentiality and the ‘iron triangle’ of commercial reality (often backed up by contractual constraints).

The debate about how much control your stakeholders should have over the work, and how engaged they should be in the work, is for another place and time – there is probably no ‘universally correct’ answer to these questions. But it is difficult to even start discussing these questions if you don’t have a meaningful measure to compare options against.

Arnstein’s paper is founded on the proposition that meaningful ‘citizen participation’ is ‘citizen power’ but also recognises there is a critical difference between going through empty rituals of participation and having real power to affect the outcome of a process. This poster was from the May 1968 student uprising in Paris, for those of us who can’t remember French verbs, translated it says:  I participate; you participate; he participates; we participate; you (plural) participate; …… they profit.   The difference between citizen participation in matters of community improvement and stakeholder participation in a project is that whilst civil participation probably should mean civil control,  this same clear delineation does not apply to stakeholder engagement in projects.  The decision to involve stakeholders in a project or program is very much open to interpretation as to the best level of involvement or engagement.  However, the ladder of engagement proposed by Arnstein can easily be adapted to the requirement of providing a framework to use when discussing what is an appropriate degree of involvement of stakeholders in your project or program.

There are eight rungs in Arnstein’s ladder; starting from the bottom:

  1. Manipulation: stakeholders are placed on rubberstamp advisory committees or invited to participate in surveys, provide feedback, or are given other activities to perform which create an illusion of engagement but nobody takes very much notice of the information provided.   The purpose of this type of engagement is primarily focused on making the stakeholders feel engaged rather than using the engagement to influence decisions and outcomes. The benefits can be reduced stakeholder opposition, at least in the short term, but there is very little real value created to enhance the overall outcomes of the project.
  2. Therapy: this level of stakeholder engagement involves engaging stakeholders in extensive activities related to the project but with a view to changing the stakeholder’s view of the work whilst minimising their actual ability to create change. Helping the stakeholders adjust to the values of the project may not be the best solution in the longer term but every organisational change management guideline (including our White Paper) advocates this type of engagement to sell the benefits the project or program has been created to deliver.
  3. Informing: informing stakeholders of their rights, responsibilities, and/or options, can be the first step towards effective stakeholder participation in the project and its outcomes. However too frequently the emphasis is placed on a one-way flow of information from the project to the stakeholders. Particularly when this information is provided at a late stage, stakeholders have little opportunity to contribute to the project that is supposed to be delivering benefits for them. Distributing information is a key stakeholder engagement activity (see the Three Types of Stakeholder Communication) but there have to be mechanisms for effective feedback for this process to maximise its potential value.
  4. Consultation: inviting stakeholder’s opinions, like informing them, can be a legitimate step towards their full participation. But if the consultation is not combined with other modes of participation this rung of the ladder is still a sham, it offers no assurance that the stakeholder concerns and ideas will be taken into account. Effective participation includes providing stakeholders with a degree of control over the consultation processes as well as full insight as to how their inputs are considered and used. In the long run window dressing participation helps no one.
  5. Placation: at this level stakeholders have some degree of influence although tokenism is still potentially involved. Simply including stakeholders in processes such as focus groups or oversight committees where they do not have power, or are trained not to exercise power, gives the appearance of stakeholder engagement without any of the benefits.
  6. Partnership: at this level power is genuinely redistributed and the stakeholders work with the project team to achieve an outcome that is beneficial to all. Power-sharing may seem risky all but if the right stakeholders with a genuine interest in the outcome are encouraged to work with the technical delivery team to constructively enhance the project’s outcomes (which is implicit in a partnership) everyone potentially benefits.
  7. Delegated power: In many aspects of projects and programs, particularly those associated with implementation, rollout, and/or organisational change, delegating management authority to key stakeholder groups has the potential to significantly improve outcomes. These groups do need support, training, and governance, but concepts such as self-managed work teams demonstrate the value of the model.
  8. Stakeholder control: In one respect stakeholders do control projects and programs but this group tends to be a small management elite fulfilling roles such as sponsors, steering committees, etc. Genuine stakeholder control expands this narrow group to include many more affected stakeholders. Particularly social projects, where the purpose of the project is to benefit stakeholders, can demonstratively be improved by involving the people project disposed to help. But even technical projects can benefit from the wisdom of crowds[2].

In summary, the framework looks like this:

The biggest difference between the scenario discussed in the original paper and stakeholder engagement around projects and programs is the fact that different stakeholders very often need quite different engagement approaches to optimise project outcomes. Arnstein’s 1969 paper argued in favour of citizen participation as a single entity and the benefits progressing up the ladder towards its control. In a project situation, it is probably more sensible to look at different groups of stakeholders and then assess where on the ladder you would like to see that group functioning. Some groups may only need relatively low levels of information to be adequately managed. Others may well contribute best in positions of control or at least where their advice is actively sought and used.

Do you think this framework is helpful in advancing conversations around stakeholder engagement in your project?

____________________

[1] Arnstein, S.R.  AIP Journal July 1969 pp:216 – 223.  A Ladder of Citizen Participation.

[2] The Wisdom of Crowds: Why the Many Are Smarter Than the Few and How Collective Wisdom Shapes Business, Economies, Societies and Nations, published in 2004, is a book written by James Surowiecki about the aggregation of information in groups, resulting in decisions that, he argues, are often better than could have been made by any single member of the group.

1 Comment

Posted in Stakeholder Management

Tagged , , , , , ,

Good Governance, Good Outcomes!

Posted on July 20, 2017 by | 1 comment

Good governance is focused on setting the ‘right’ rules and objectives for an organisation, management is about working within those rules to achieve the objectives. Prudent governors also require assurance that the rules are being followed and the objectives achieved (for more see the six functions of governance)

Within this governance framework, getting the ethics and culture of an organisation right comes before anything else – it has far more to do with people, and culture than it does with process and policing! But crafting or changing culture and the resultant behaviours is far from easy and requires a carefully crafted long term strategy supported from the very top of the organisation. The journey is difficult, but achievable, and can pay major dividends to the organisation concerned. One interesting example of this approach in practice is the implementation of effective major project management by the UK government.

The problems with megaprojects[1]

The challenges and issues associated with megaprojects are well known, we recently posted on one aspect of this in the reference case for management reserves. The source materials used in this post clearly show that UK government has been acutely aware of the issues for many years as does any review of the UK National Audit Office’s reports into failed government projects.  At the 2022 PGCS symposium in Canberra, Geraldine Barker, from the UK NAO offered an independent and authoritative overview of the UK perspective and experience from her review of the Major Projects Authority, on the approaches, challenges, and lessons to be learned in improving the performance of major projects at individual and portfolio levels. While there were still major issues, there had also been a number of welcome developments to address the issues including:

  • Improvements to accountability with greater clarity about the roles of senior responsible owners;
  • Investment by the Authority and departments to improve the capability of staff to deliver major projects, with departments reporting to us that they are seeing benefits from these initiatives;
  • Increased assurance and recognition of the role that assurance plays in improving project delivery; and
  • Initiatives to prevent departments from getting locked into solutions too early.

Amyas Morse, head of the National Audit Office, said in a report to the UK Parliament on 6 January 2016, “I acknowledge that a number of positive steps have been taken by the Authority and client departments. At the same time, I am concerned that a third of projects monitored by the Authority are red or amber-red and the overall picture of progress on project performance is opaque. More effort is needed if the success rate of project delivery is to improve”[2].

The major challenges identified in that report were to:

  • Prevent departments making firm commitments on cost and timescales for delivery before their plans have been properly tested;
  • Develop an effective mechanism whereby all major projects are prioritised according to strategic importance and capability is deployed to priority areas; and
  • Put in place the systems and data which allow proper performance measurement.

The latest report from the Infrastructure and Projects Authority – IPA (formally the Major Projects Authority) has allowed the UK government to claim an improvement in its delivery of major projects, with the number of those at risk reducing from 44 to 38 in the past year.

The report says that there are 143 major projects on the Government Major Projects Portfolio (GMPP), worth £455.5bn and spread across 17 government departments.

The data shows a steady improvement in the way that government is delivering major projects:

  • More than 60% of projects by whole-life cost are likely to be successfully delivered;
  • Since last year’s report, the number of at risk projects has reduced from 44 to 38, which continues to be an improvement from 48 the previous year;

The data shows signs of steady improvement in the way government is delivering major projects. The question is how was this achieved?

The answer is ‘slowly’ looking from the outside there seem to be three parallel processes working together to change the culture of the UK civil service:

  • The first is making project management ‘attractive’ to senior executives. Since 2000 the government has been working to develop the internal skills needed to allow the deployment of capable ‘Senior Responsible Owners’ (SRO) on all of its major projects including establishing a well-respected course for SROs. The Major Projects Leadership Academy was developed in 2012 (first graduates 2013) and is run in partnership with the Saïd Oxford Business School and Deloitte. The academy builds the skills of senior project leaders across government, making it easier to carry out complex projects effectively. In the future, no one will be able to lead a major government project without completing the academy programme.
  • The second has been making the performance of its major projects public. This includes an on-going challenge to acquire realistic and meaningful data on performance (still a challenge) and is most obvious in the annual report from the Major Projects Authority. Their fifth report is now available for downloading.
  • Finally skills development and robust challenges are put to departments to ensure adequate front end planning is completed before government funds are committed to a project.

This process is not quick and given the risky nature of major projects will never deliver a 100% success rate, but the steady change in attitudes and performance in the UK clearly show that ‘good governance’ backed by a sound multi-faceted strategy focused on the stakeholders engaged in the work will pay dividends. Proponents advocating for this type of improvement have many challenges to deal with, not the least of which is the fact that as data quality improves, the number of problems that will be visible increase – add the glare of publicity and this can be politically embarrassing!  However, as the UK reports show, persistence pays off.

____________________

[1] For a definition of megaprojects see: /2017/06/09/differentiating-normal-complex-and-megaprojects/

[2] See: https://www.nao.org.uk/report/delivering-major-projects-in-government-a-briefing-for-the-committee-of-public-accounts/

 

1 Comment

Posted in Governance

Tagged , , , ,

Defining Project Success using Project Success Criteria

Posted on July 4, 2017 by | 4 comments

Everyone likes a successful project but the big question is what makes a project successful??  A good example is the Sydney Opera House; was the Sydney Opera House successful or not?

The project ran significantly over budget finished very late and was technically less than perfect; $millions are currently being spent rectifying many of the technical deficiencies in the building. But can anyone say Sydney Opera House is not one of the most recognised and therefore successful buildings in the world?[1]

Success is an ephemeral concept! Different people will have different perspectives and judge the success or failure project differently. Neither a project nor a program manager can control many of the factors that have made the Sydney Opera House worldwide icon but they can address the concept of success with their stakeholders and then work to deliver a successful outcome based on these discussions.

So what is success? There are probably three key elements, but these frequently create a paradox that requires a balanced approach to success. The three fundamental elements are:

  • The Iron Triangle (Scope + Cost + Time)
  • Benefits realised (or maximised)
  • Satisfied stakeholders (but, when??)

One of the key paradox is a myopic focus on the Iron Triangle particularly time and cost can frequently destroy benefits and leave the stakeholders unhappy, but focusing on keeping stakeholders happy can frequently have detrimental effects on the Iron Triangle. There are no easy solutions to this problem[2].

In my view, the successful delivery of a project or program requires:

  • Achieving the overall goal for the project;
  • Delivering its objectives; and
  • Meeting its success criteria.

But, to achieve success you need to define and agree the project goal, the project objectives, and the project success criteria with your key stakeholders with a view to achieving a combination of stakeholder satisfaction and value created. The goal and objectives frame the project’s work and direction. The success criteria frame how the objectives are achieved.

 

The Project Goal

Goals are high-level statements that provide the overall context defining what the project is trying to achieve. One project should have one goal (if there are multiple goals you are most likely looking at a program of work[3])!  For example:  Within 180 days, reduce the pollution in the rainwater runoff from a council tip by 98%.

The goal is a key statement in the Project Charter[4] and if the project is to be successful, all key stakeholders need to agree the goal.  The goal needs to be specific and should define the project in a way that focuses attention on the key outcomes required for overall success from a technical and strategic business perspective[5].

 

Project Objectives

The objectives are lower level statements that describe the specific, tangible products and deliverables that the project will create; each objective (and the overall goal) should be SMART[6]. For the runoff project the objectives may include:

  • Develop wetlands to trap 99.8% of sediment
  • Install channels to collect and direct the runoff
  • Install screens remove floating debris
  • Etc….. There will be a number of objectives……

Each objective requires defining and specifying with clear performance criteria so you know when it has been achieved. This may be done by the client or by the project team during the scope definition process. The performance criteria may be defined by a set of precise specifications that are specific and measurable or may be defined as a performance requirement with either:

  • The external contractor to provide the specific details of how the objective will be achieved, or
  • The internal project team to develop the details in consultation with the client

The defined objectives are the building blocks that facilitate the achievement of the goal and the creation of the benefits the organisation is expecting from the project[7]. The benefits need to be realised to create value.

 

Success criteria

Success criteria are different they measure what’s important to your stakeholders. Consequently, they are the standards by which the project will be judged at the end to decide whether or not it has been successful in the eyes of its stakeholders. As far as possible the stakeholders need to be satisfied; this includes having their expectations fulfilled and in general terms being pleased with both the journey and the outcome (in this respect scope, cost and/or time may be important).

Success criteria can be expressed in many different ways some examples include:

  • Zero accidents / no environmental issues;
  • No ‘bad press’ / good publicity received;
  • Finalist in the project achievement awards;
  • Plus the goal and all of the objectives achieved (yes – you still need to do the work).

For any project, the success criteria should be split between project management success criteria which of related to the professional aspects of running the project; plus project deliverable success criteria which are related to the performance and function of the deliverable.

Documenting the success criteria is important, it means you can get project stakeholders to sign up to them, and having them clearly recorded removes ambiguity about what you are setting out to do. The four basic steps to create useful success criteria are

  1. Document and agree the criteria; each criteria should include:
    1. The name of success criteria,
    2. How it is going to be measured,
    3. How often it is going to be measured, and
    4. Who is responsible for the measurement.
  2. Use continuous measurements where possible. For example, rather than ‘finish the project on time’ measure progress continually ‘no activity completes more than 5 days after its late finish date’.
  3. Baseline today’s performance.
  4. Track and report on your progress.

As with any performance indicators, the art is to select a few key measures that represent the wider picture if there are too many success criteria defined the impact will be severely reduced. For example, the effectiveness of meetings, communication and stakeholder attitude could be measured scientifically using the ‘Index Value’ in the Stakeholder Circle[8] or pragmatically by measuring the number of open issues against a target (eg, no more than 5 high priority open issues).

 

Summary

Goals and objectives are the building blocks required to allow the realisation value from the project’s outputs; they are essential ingredients in a successful project but are insufficient on their own.  The role of success criteria is to direct the way work at the project is accomplished so as to meet stakeholder expectations, and to craft a perception of success in the stakeholder’s minds.

Project success is an amalgam of value created for the organisation and your stakeholders being satisfied with the journey and the outcome.  This concept of success may seem subjective, but it does not have to be. Successful organisations work to take the guesswork out of this process by defining what success looks like and agreeing these definitions with the key stakeholders, so they all know when the project has achieved it.

This means the key to stakeholders perceiving your project as successful lays in understanding the criteria they will measure success by, incorporating those measures into your project success criteria, and then working to achieve the criteria. But even this is not enough, to engage your stakeholders you need to communicate the criteria, communicate your progress and communicate your success at the end. For more on effective communication see: http://www.mosaicprojects.com.au/PM-Knowledge_Index.html#PPM07

________________

 

[1] For more on the success or failure of the Sydney Opera House see Avoiding the Successful Failure!:  http://www.mosaicprojects.com.au/Resources_Papers_046.html

[2] For more on paradox see: https://www.projectmanagement.com/blog-post/30669/The-Problem-With-Paradox

[3] For more on differentiating projects and programs see: http://www.mosaicprojects.com.au/WhitePapers/WP1002_Programs.pdf

[4] For more on the project charter see: http://www.mosaicprojects.com.au/WhitePapers/WP1019_Charter.pdf

[5] For more on project success see: http://www.mosaicprojects.com.au/Mag_Articles/N001_Achieving_Real_Project_Success.pdf

[6] SMART = Specific, Measurable, Attainable, Relevant and Time-framed.

[7] For more on linking objectives and benefits see: http://www.mosaicprojects.com.au/WhitePapers/WP1042_Outputs_Outcomes_Benefits.pdf

[8] The Stakeholder Circle® index value see: http://202.146.213.160/help-files/stakeholder-engagement-profile/#engagement-index

4 Comments

Posted in Communication, General Project Management, Project Controls, Scope Management, Stakeholder Management, Value

Tagged , , , , , , , ,

Differentiating normal, complex and megaprojects

Posted on June 9, 2017 by | 7 comments

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)

7 Comments

Posted in Agile Ideas, Complexity, General Project Management, PMBOK6, Project Typology, Stakeholder Management

Tagged , , , , , , , ,

The reference case for management reserves

Posted on May 23, 2017 by | 5 comments

Risk management and Earned Value practitioners, and a range of standards, advocate the inclusion of contingencies in the project baseline to compensate for defined risk events. The contingency may (should) include an appropriate allowance for variability in the estimates modelled using Monte Carlo or similar; these are the ‘known unknowns’.  They also advocate creating a management reserve that should be held outside of the project baseline, but within the overall budget to protect the performing organisation from the effects of ‘unknown unknowns’.  Following these guidelines, the components of a typical project budget are shown below.

PMBOK® Guide Figure 7-8

The calculations of contingency reserves should be incorporated into an effective estimating process to determine an appropriate cost estimate for the project[1]. The application of appropriate tools and techniques supported by skilled judgement can arrive at a predictable cost estimate which in turn becomes the cost baseline once the project is approved. The included contingencies are held within the project and are accessed by the project management team through normal risk management processes. In summary, good cost estimating[2] is a well understood (if not always well executed) practice, that combines art and science, and includes the calculation of appropriate contingencies. Setting an appropriate management reserve is an altogether different problem.

 

Setting a realistic management reserve

Management reserves are an amount of money held outside of the project baseline to ‘protect the performing organisation’ against unexpected cost overruns. The reserves should be designed to compensate for two primary factors.  The first are genuine ‘black swans’ the other is estimating errors (including underestimating the levels of contingency needed).

The definition of a ‘black swan’ event is a significant unpredicted and unpredictable event[3].  In his book of the same name, N.N. Taleb defines ‘Black Swans’ as having three distinct characteristics: they are unexpected and unpredictable outliers, they have extreme impacts, and they appear obvious after they have happened. The primary defence against ‘black swans’ is organisational resilience rather than budget allowances but there is nothing wrong with including an allowance for these impacts.

Estimating errors leading to a low-cost baseline, on the other hand, are both normal and predictable; there are several different drivers for this phenomenon most innate to the human condition. The factors leading to the routine underestimating of costs and delivery times, and the over estimating of benefits to be realised, can be explained in terms of optimism bias and strategic misrepresentation.  The resulting inaccurate estimates of project costs, benefits, and other impacts are major source of uncertainty in project management – the occurrence is predictable and normal, the degree of error is the unknown variable leading to risk.

The way to manage this component of the management reserves is through the application of reference class forecasting which enhances the accuracy of the budget estimates by basing forecasts on actual performance in a reference class of comparable projects. This approach bypasses both optimism bias and strategic misrepresentation.

Reference class forecasting is based on theories of decision-making in situations of uncertainty and promises more accuracy in forecasts by taking an ‘outside view’ of the projects being estimated. Conventional estimating takes an ‘inside view’ based on the elements of the project being estimated – the project team assesses the elements that make up the project and determine a cost. This ‘inside’ process is essential, but on its own insufficient to achieve a realistic budget. The ‘outside’ view adds to the base estimate based on knowledge about the actual performance of a reference class of comparable projects and resolves to a percentage markup to be added to the estimated price to arrive at a realistic budget.  This addition should be used to assess the value of the project (with a corresponding discounting of benefits) during the selection/investment decision making processes[4], and logically should be held in management reserves.

Overcoming bias by simply hoping for an improvement in the estimating practice is not an effective strategy!  Prof. Bent Flyvbjerg’s 2006 paper ‘From Nobel Prize to Project Management: Getting Risks Right[5]’ looked at 70 years of data.  He found: Forecasts of cost, demand, and other impacts of planned projects have remained constantly and remarkably inaccurate for decades. No improvement in forecasting accuracy seems to have taken place, despite all claims of improved forecasting models, better data, etc.  For transportation infrastructure projects, inaccuracy in cost forecasts in constant prices is on average 44.7% for rail, 33.8% for bridges and tunnels, and 20.4% for roads.

The consistency of the error and the bias towards significant underestimating of costs (and a corresponding overestimate of benefits) suggest the root causes of the inaccuracies are psychological and political rather than technical – technical errors should average towards ‘zero’ (plusses balancing out minuses) and should improve over time as industry becomes more capable, whereas there is no imperative for psychological or political factors to change:

  • Psychological explanations can account for inaccuracy in terms of optimism bias; that is, a cognitive predisposition found with most people to judge future events in a more positive light than is warranted by actual experience[6].
  • Political factors can explain inaccuracy in terms of strategic misrepresentation. When forecasting the outcomes of projects, managers deliberately and strategically overestimate benefits and underestimate costs in order to increase the likelihood that their project will gain approval and funding either ahead of competitors in a portfolio assessment process or by avoiding being perceived as ‘too expensive’ in a public forum – this tendency particularly affects mega-projects such as bids for hosting Olympic Games.

 

Optimism Bias

Reference class forecasting was originally developed to compensate for the type of cognitive bias that Kahneman and Tversky found in their work on decision-making under uncertainty, which won Kahneman the 2002 Nobel Prize in economics[7]. They demonstrated that:

  • Errors of judgment are often systematic and predictable rather than random.
  • Many errors of judgment are shared by experts and laypeople alike.
  • The errors remain compelling even when one is fully aware of their nature.

Because awareness of a perceptual or cognitive bias does not by itself produce a more accurate perception of reality, any corrective process needs to allow for this.

 

Strategic Misrepresentation

When strategic misrepresentation is the main cause of inaccuracy, differences between estimated and actual costs and benefits are created by political and organisational pressures, typically to have a business case approved, or a project accepted, or to get on top of issues in the 24-hour news cycle.  The Grattan Institute (Australia) has reported that in the last 15 years Australian governments had spent $28 billion more than taxpayers had been led to expect. A key ‘political driver’ for these cost overruns was announcing the project (to feed the 24-hour news cycle) before the project team had properly assessed its costs.  While ‘only’ 32% of the projects were announced early, these accounted for 74% of the value of the cost overruns.

The Grattan Institute (Australia) has reported that in the last 15 years Australian governments had spent $28 billion more than taxpayers had been led to expect on transport infrastructure projects. One of the key ‘political drivers’ for these cost overruns was announcing the project (to feed the 24-hour news cycle) before the project team had properly assessed its costs.  While ‘only’ 32% of the projects were announced early, these projects accounted for 74% of the value of the cost overruns.

Reference class forecasting will still improve accuracy in these circumstances, but the managers and estimators may not be interested in this outcome because the inaccuracy is deliberate. Biased forecasts serve their strategic purpose and overrides their commitment to accuracy and truth; consequently the application of reference class forecasting needs strong support from the organisation’s overall governance functions.

 

Applying Reference Class Forecasting

Reference class forecasting does not try to forecast specific uncertain events that will affect a particular project, but instead places the project in a statistical distribution of outcomes from the class of reference projects.  For any particular project it requires the following three steps:

  1. Identification of a relevant reference class of past, similar projects. The reference class must be broad enough to be statistically meaningful, but narrow enough to be truly comparable with the specific project – good data is essential.
  2. Establishing a probability distribution for the selected reference class. This requires access to credible, empirical data for a sufficient number of projects within the reference class to make statistically meaningful conclusions.
  3. Comparing the specific project with the reference class distribution, in order to establish the most likely outcome for the specific project.

The UK government (Dept. of Treasury) were early users of reference class forecasting and continue its practice.  A study in 2002 by Mott MacDonald for Treasury found over the previous 20 years on government projects the average works duration was underestimated by 17%, CAPEX was underestimated by 47%, and OPEX was underestimated by 41%.  There was also a small shortfall in benefits realised.

 

This study fed into the updating of the Treasury’s ‘Green Book’ in 2003, which is still the standard reference in this area. The Treasury’s Supplementary Green Book Guidance: Optimism Bias[8] provides the recommended range of markups with a requirement for the ‘upper bound’ to be used in the first instance by project or program assessors.

These are very large markups to shift from an estimate to a likely cost and are related to the UK government’s estimating (ie, the client’s view), not the final contractors’ estimates – errors of this size would bankrupt most contractors.  However, Gartner and most other authorities routinely state project and programs overrun costs and time estimates (particularly internal projects and programs) and the reported ‘failure rates’ and overruns have remained relatively stable over extended periods.

 

Conclusion

Organisations can choose to treat each of their project failures as a ‘unique one-off’ occurrence (another manifestation of optimism bias) or learn from the past and develop their own framework for reference class forecasting. The markups don’t need to be included in the cost baseline (the project’s estimates are their estimates and they should attempt to deliver as promised); but they should be included in assessment process for approving projects and the management reserves held outside of the baseline to protect the organisation from the effects of both optimism bias and strategic misrepresentation.  As systems, and particularly business cases, improve the reference class adjustments should reduce but they are never likely to reduce to zero, optimism is an innate characteristic of most people and political pressures are a normal part of business.

If this post has sparked your interest, I recommend exploring the UK information to develop a process that works in your organisation: http://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-governent

______________________

[1] For more on risk assessment see: http://www.mosaicprojects.com.au/WhitePapers/WP1015_Risk_Assessment.pdf

[2] For more on cost estimating see: http://www.mosaicprojects.com.au/WhitePapers/WP1051_Cost_Estimating.pdf

[3] For more on ‘black swans’ see: /2011/02/11/black-swan-risks/

[4] For more on portfolio management see: http://www.mosaicprojects.com.au/WhitePapers/WP1017_Portfolios.pdf

[5] Project Management Journal, August 2006.

[6] For more on the effects of bias see: http://www.mosaicprojects.com.au/WhitePapers/WP1069_Bias.pdf

[7] Kahneman, D. (1994). New challenges to the rationality assumption. Journal of Institutional and Theoretical
Economics, 150, 18–36.

[8] Green Book documents can be downloaded from: http://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-governent

5 Comments

Posted in Risk

Tagged , , , , , , ,

The maturing or ‘agile’

Posted on May 8, 2016 by | 1 comment

A deliberately provocative article on Linked-In asks the question is ‘Agile Dead?’; a discussion on how various aspects ‘agile’ invented by different individuals and groups are fading from prominence follows.  Agile is not my area of expertise but the article seems designed to generate attention without really saying anything new.

What the article did prompt in my thinking was the question ‘What is agile?’. Concepts vary from:

  • The Agile Manifesto (which is basically 101 common sense) created to overcome the failures of rigid IT development that required a 100% complete fully detailed plan before people really knew what the problem was (often referred to as ‘waterfall’ development but nothing like the original ideas in the waterfall concept).
  • Through to the agile anarchist community who’s mantra seems to be ‘trust us all of our teams are above average’ and we will make you really nice software without any discipline (a concept that ignores the mathematical fact that 50% of any group have to be below average….).
  • Then there are all of the various ‘agile’ methods from ‘Scrum’ to ‘XP’.

Ergo ‘Agile’ or ‘agile’ can mean virtually anything to anyone.  In contrast to all of these specific variants, I would suggest at its root ‘agile’ is a concept or philosophy rather than a methodology or process; useful philosophies rarely ‘die’.

What is emerging I believe is a gradual understanding that the false concepts of ‘command and control[1]’ and ‘certainty, based on a fully detailed plan[2]’ are slowly disappearing from management thinking (although there are still plenty of recalcitrant ‘fossils’ embedded in far too many management structures) – detailed planning months or years in advance of the work, done at a time where the work is imprecisely understood cannot control an uncertain future regardless of contract conditions and the exhortation of management. These ideas are slowly being replaced by an adaptive approach to projects that engages stakeholders and focuses on actually achieving the stakeholder’s objectives and realising benefits, ie, an ‘agile’ approach.

Every project and every project management system can benefit from some elements of ‘agile’ (which overlaps with many other concepts such as ‘light’, ‘lean’, and ‘last planner’. The key tenets seem to be:

  • involve your stakeholders,
  • trust your team,
  • don’t waste time planning in detail things you don’t have detailed knowledge of[3],
  • adapt to changing circumstances, and
  • wherever possible avoid a ‘big bang’ approach – iterative and incremental developments mitigate the risk of catastrophic failure.

The agile manifesto certainly highlighted these important concepts but it did not invent them. These elements of fundamental common sense are ignored in far too many situations. What the agile manifesto and the subsequent changes in attitude have done is refocus on the importance of people and relationships in any project.

On the ‘Agile front’, many of the ridiculous excesses promoted by consultants and experts are certainly fading into obscurity. Executives are learning that ‘agile’ is not a cure all ‘silver bullet’ it needs pragmatic management and proper planning the same as everything else, it just the way planning and managing is done that differs; for more on this see: http://www.mosaicprojects.com.au/PDF_Papers/P109_Thoughts_on_Agile.pdf

Certainly there has been a realisation that the agile anarchist’s concept of ‘trust us’ (and their abandonment of any pretence of strategic planning and documentation) really does not work. An appropriate degree of planning, coordination and documentation are essential to achieve success, particularly on larger projects and in the longer term when the inevitable updates and maintenance cut in.

In summary, if ‘agile’ is a philosophy that prioritises people over rigid process, and it will change and adapt over time; it’s not ‘dead’ but it is evolving into a pragmatic management process. Certainly some of the narrowly defined concepts and methodologies branded as ‘agile’ are failing and being abandoned as ‘passing fads’ and new adaptations are emerging, but that’s normal. The core underpinnings of the original Agile Manifesto are still alive and well.

___________________

[1] In the 1950’s Peter Drucker identified the need for a new way of managing ‘knowledge work’, see: http://www.mosaicprojects.com.au/PDF_Papers/P070_A_Simple_View_of_Complexity.pdf

[2] “All models are wrong, but some are useful” (Prof. George E.P. Box), and every estimate used in the plan is wrong to a greater or lesser degree, see: http://www.mosaicprojects.com.au/WhitePapers/WP1051_Cost_Estimating.pdf

[3] For more on ‘rolling wave’ planning see: http://www.mosaicprojects.com.au/WhitePapers/WP1060_Rolling_Wave.pdf

1 Comment

Posted in Agile Ideas

Tagged , , , ,

The Shergold Report calls for better governance and better project controls!

Posted on February 20, 2016 by | 2 comments

The recently released report by Professor Peter Shergold, ‘Learning from Failure: Why large government policy initiatives have gone so badly wrong in the past and how the chances of success in the future can be improved’ (the Shergold Report), sets out a framework designed to improve the delivery of major Australian Government programs.  But the framework is not limited to government; the concepts can be usefully applied by any organisation seeking to initiate a major program of works.

The report focuses on making practical recommendations to enhance the capacity of the Australian Government to:

  1. Design and implement large public programmes and projects;
  2. Develop robust and effective governance and accountability arrangements for such programmes and projects;
  3. Understand the broader environment in which programmes and policies are designed and implemented;
  4. Identify, understand and manage risks; and
  5. Provide accurate, timely, clear and robust advice to ministers and within the APS.

Substitute ‘organisation’ for ‘Australian Government’ and ‘senior stakeholders and governors’ for ‘ministers and within the APS’ and the value of the document to the wider community becomes apparent.

The Shergold Report does not make specific recommendations to the government; rather it reaches a series of immutable conclusions based on the narrative in each section and is intended to spark public comment and discussion from a wide spectrum of people both within and outside of the Australian Public Service.

The Shergold Report contains 28 proposals for improvement; the key conclusions are reproduced below are reformatted as recommended good practices for any organisation planning to undertake a major program of works:

Ensuring Robust Advice: Good governance is founded on good policy, and good policy depends on good advice. To this end, executives and managers should be held accountable for the quality of advice they provide. Significant advice should be provided in writing and records maintained.

Decision Making: The importance of decision-making, and the circumstances under which it occurs, underscore the need to have well-functioning support systems in place.

Creating a Positive Risk Culture: Moving the organisation from reactive, defensive risk management; to proactive, performance-focused risk engagement. The major challenge is to embed the new approaches within a strong risk culture. This requires: understanding appetites for risk on individual programs and across the portfolio, appointing a Chief Risk Officer, at a senior executive level, proposals should be supported by an endorsed Risk Management Plan, and preparing a bi-annual whole-of-organisation Risk Assessment for the governing body, analysing the system-wide impact of operational, financial, strategic, legislative and procurement risks faced by the organisation.

Enhancing Program Management: Program and project management are too often seen as control activities; they are actually creative processes!  They require discipline and professional expertise to maintaining single point accountability while being open and flexible to the opportunities of networked governance structures. To achieve this requires:

  • Defined standards of proficiency for project and program managers, with active support through career development opportunities, continued education and participation in professional communities of practice such as the upcoming Project Governance and Controls Symposium.
  • For each project or programs[1], a clear understanding of who accepts end-to-end responsibility for managing implementation (typically the Sponsor[2]), wields delegated authority and where accountability resides.

Opening up to diversity: A diversity of perspectives in the workplace and the boardroom improves performance. Diversity increases critical analysis of information, results in better decision-making and challenges ‘groupthink’. Program advisory groups should be established that include representation drawn from outside the organisation in order to capture a broader diversity of perspectives and knowledge.

Embracing adaptive governance: Organisations that thrive are flexible. They seize opportunities, learn rapidly and recognise that partners will be needed to deliver long-term goals. When they enter uncharted territory they respond fast, start small, test new approaches, watch market responses, learn from doing, scale-up their activity or, if necessary, try again.

Most importantly, they are honest about failure. They recognise that mistakes happen, interrogate why they occurred and set in place remedial measures to ensure that they perform better next time. Failure and its lessons are an inevitable part of entrepreneurial life but are also central to maintaining organisational competitiveness. This means (where possible) new proposals should include a trial or demonstration stage, allowing new approaches to be developed fast and evaluated early. Large projects should incorporate staged decision-making[3].

Conclusions

Good governance is focused on creating good outcomes, not developing a straightjacket of impenetrable and restrictive procedures – the person or organisation that has never made a mistake has never made anything! The art of effectively using project and programs to create a new and desirable future is effective governance, backed by prudent risk management and effective, adaptive delivery and change management processes. The Shergold Report concludes that:

  1. Policy is only as good as the manner in which it is implemented
  2. Policy advice can only be frank and fearless if it is supported by written argument.
  3. Deliberations, oral and in writing, need to be protected.
  4. Deliberative documents need to be preserved, whether written on paper or delivered by digital means.
  5. It is up to ministers (the governing body), not officials (management), to make policy decisions.
  6. The effective management of risk is just as important in the public sector as in the private – perhaps more so.
  7. As the public service fully commits itself to measuring results by outcomes, program management needs to be accorded far greater professional status.
  8. Good governance increasingly depends on collaboration across sectors.
  9. The APS needs to be further opened up. Diversity and external inputs to the organisation.
  10. An adaptive government (organisation) can respond rapidly to changing circumstances without taking unnecessary (and unforeseen) risks.

The one area missing from the Shergold Report is recognition of the importance and difficulty of implementing organisational change (and the disciplines of change management and benefits realisation). The concepts are implicit in many aspects of the report but would have benefitted from direct discussion.

These limitations aside, the Shergold Report is a very deep and well considered document, well worth the effort of reading by both private and public sector mangers and governors. It highlights failures and the learning that can be taken from the experiences to improve future outcomes. To quote Confucius “By three methods we may learn wisdom: First, by reflection, which is noblest; Second, by imitation, which is easiest; and third by experience, which is the bitterest”. Learning from other’s experience may not be the ‘noblest’ option but is far preferable to repeating avoidable mistakes.

We will be commenting further on this report in future posts and I’m sure it will feature prominently in discussions at the upcoming Project Governance and Controls Symposium that is being held in Canberra in May.

The full report can be downloaded from: http://www.apsc.gov.au/publications-and-media/current-publications/learning-from-failure

From a completely different source, the Australian Infrastructure Plan Priorities and reforms for our nation’s future (Feb. 2016), recommendations under Chapter 9 – Governance calls for very similar processes to the Shergold Report.  These reports, and many previous, have consistently promulgated the same message.  We know what needs to be done, understanding why its not being done is the real challenge.

 

[1] To understand the difference between a project and a program see: http://www.mosaicprojects.com.au/WhitePapers/WP1002_Programs.pdf

[2] For more on the role of the Sponsor see: http://www.mosaicprojects.com.au/WhitePapers/WP1031_Project_Sponsorship.pdf

[3] For more on ‘gateway reviews see: http://www.mosaicprojects.com.au/WhitePapers/WP1092_Gateways-Scorecards.pdf

2 Comments

Posted in General Project Management, Governance

Tagged , , , , ,

Some ideas for making project management effective and efficient in 2016

Posted on January 22, 2016 by | 3 comments

It’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.

Almost 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

3 Comments

Posted in General Project Management

Tagged , , , , ,

Is your steering committee costing $5000 per hour?

Posted on December 13, 2015 by | 1 comment

The loaded cost of running a committee of senior managers can easily exceed $5000 per hour once the opportunity costs are included.  Productive committees offset this by creating value, hopefully significantly greater than their running costs.  Project and program steering committees should be no different!

However, if the steering committee is simply focused on ‘governance’ it is highly unlikely to be generating any significant value.  At the management level where most steering committees operate there is very little governance decision making needed and conformance and assurance usually needs specialists.

The first four functions of governance defined in The Functions of Governance are:

  • Determining the objectives of the organisation: this is done by the organisation’s governing body and implemented through the strategic plan. The project should have been selected because it contributes to achieving the strategic plan, a function of portfolio management, but once the project has started it is rather too late.
  • Determining the ethics of the organisation: this is done by the organisation’s governing body; it is a duty of every manager to support the organisation’s ethical standards and ensure the people they are managing conform. But you do not need a committee to ensure this occurs, just the project manager’s line manager (usually the Sponsor).
  • Creating the culture of the organisation: again this is done by the organisation’s governing body; it is a duty of every manager to support the organisation’s cultural standards and ensure the people they are managing conform. But you do not need a committee to ensure this occurs, just the project manager’s line manager (usually the Sponsor).
  • Designing and implementing the governance framework for the organisation: this should be done before the project is started and include delegations of authority for expenditure and decision making and escalation paths. If it has not been done, one half hour meeting of the sponsor and a few key managers can set the delegations.

In summary, the aspects of governance that determine the way the organisation operates and how the project or program will fit into the overall governance framework does not need a monthly meeting of any type.  There are management responsibilities but these are vested in the responsible line manager, typically the Sponsor (see more on the role of a Sponsor).

The final two functions of governance are ensuring accountability by management and conformance by the organisation.  A steering committee can certainly focus on these aspects of governance but if they do, they are largely wasting their time and most of the $5000 per hour.  There are two fundamental reasons for this:

  1. It is extremely poor governance for a managing entity to seek to provide assurance that the people it is managing are conforming. Assurance oversight should be provided by an independent body.
  2. Most aspects of project surveillance and assurance require high levels of technical skill. It is highly unlikely any of the managers on a steering committee posses these skills (see more on project surveillance).

The organisational entity best suited for the work of surveillance and assurance is a PMO with appropriate support from management. If there is an effective PMO structure in place with the ability to identify shortcomings, backed up by responsible line management there is no need for another committee to second guess the process a few weeks later (see more on PMOs).

Some of the completely unproductive ‘governance’ functions undertaken by ‘steering committees’ include:

  • Validating correct procedures have been followed (properly resourced PMOs are a better and cheaper option).
  • Discussing negative variances and allocating blame (management action is needed not committee discussions).
  • Second guessing management decisions after the event and interfering in the day-to-day running of the project (project professionals are not helped by interference from amateurs – even if they are senior managers).
  • Listening to lengthy reports on what has happened during the last month (effective reporting is all that is needed).

Being involved in this type of activity may make the steering committee members feel important but contributes little or nothing of value in a well governed and structured organisation; if the organisation is not well governed and structured the committee members would be far better off focusing on fixing the real problems.

 

Steering Committees can be highly valuable!

The constitution of most steering committees creates a real opportunity to add value to the overall management of a project or program, but only if the committee focuses on helping craft success. Steering committees typically include members from a range of areas within the organisational affected by the project and its deliverables. Therefore as a group its members are uniquely placed to assist the project manager and sponsor deliver a successful project by helping them steer a path through the organisational politics and stakeholder issues that confront any project or program.

This objective can be achieved by making the members of the steering committee personally responsible for the realisation of value from the organisation’s investment in project, and in particular for dealing with the organisational change and stakeholder issues that are outside of the project manager’s responsibilities. Some of the key responsibilities allocated to the steering committee may include:

  • Responsibility for preparing the organisation for the changes needed to make use of the project’s deliverables and the realisation of value.
  • Managing the interface between the project and the organisational change management work
  • Being available to assist in the management of stakeholder issues escalated from the project and/or identified in areas outside of the direct influence of the project.
  • Ensuring effective benefits management is in place for the life of the initiative (ie, it continues after the project is closed).
  • Dealing with any other aspect of organisational politics that may affect the work of the project or the on-going change initiative.
  • Making value based decisions on complex change proposals, including contributing positively to the resolution of intractable problems, to optimise the value outcome for the organisation.

Obviously the steering committee also needs to take an interest in the project its steering to success. The problem is these are all management activities, not governance activities (for more on this see Does organisational governance exist?).

Effective steering committees work with the project manager and sponsor to identify the external influences causing problems and help the project successfully navigate the organisational stakeholder environment. They also resist the urge to interfere in the actual running of the project or program. There is a world of difference between a collaborative and supportive approach focused on success and the negative approach adopted by so many steering committees that seems to translate ‘governance’ into giving the project manager a ‘hard time’ to ensure compliance with ‘due process’ even if this adds to the existing problems.

Are your organisation’s steering committees worth their hourly running costs?

1 Comment

Posted in Governance, Stakeholder Management

Tagged , , , , , , ,