Levels of Stakeholder Engagement

August 21, 2017

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’ in 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 for 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.


Good Governance, Good Outcomes!

July 20, 2017

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 2016 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 ongoing 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: https://mosaicprojects.wordpress.com/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/


Defining Project Success using Project Success Criteria

July 4, 2017

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?

Was the Sydney Opera House a success

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



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:

How the chair can make a meeting ineffective

March 7, 2017

The chair of any meeting has a unique ability to destroy the value of the meeting!

Eight of the key ways to reduce the meeting’s value are:

  1. Playing favourites. Bad chairs tend to shut down some attendees whilst allowing others they see as politically important to occupy most of the speaking time. The outcome from this behaviour tends to be poor decision-making; bad chairs don’t care. Their interest is to stay the good books of the people they see as politically important.
  2. Changing the rules. Bad chairs keep the rules to themselves and change the rules when it suits them. They don’t give advice on what preparation attendees need to make or advise how the meeting will be conducted. While this trait may appear to appear to be a gambit to leave the chair in control, in reality it means the meeting is likely to be less than useful.
  3. Showing bias. When there is a vigorous debate between various groups in the meeting a bad chair will obviously be supporting one side.  Good chairs remain neutral whilst they may feel strongly about subject their primary function is to ensure the meeting reaches a consensus, not that the meeting reaches a decision that they predetermine as being optimum (although they need to be part of the consensus).
  4. Failing to define its purpose. Bad chairs do not define a clear objective for the meeting, fail to set priorities, and don’t circulate an agreed agenda. Good chairs define the purpose of every meeting with crystal clarity so attendees can come prepared and stay focused.
  5. Losing control. The hallmarks of a bad chair during the meeting include running over time, getting off track, get rattled, and allowing discussion to descend into personal arguments. Good facilitators keep their hands firmly on the reins consistently and politely guiding discussion back to the purpose of the meeting.
  6. Failing to communicate. Bad chairs tend to display no sense of appreciation for the points made by contributors to the discussion and tend to ignore many of the attendees. Good chairs are great communicators remember everybody’s name, include newcomers, and are excellent at active listening and summarising points to ensure everybody has a clear understanding of the current state discussion[1].
  7. Failing to make decisions. Deadlocks happen in most meetings, bad chairs cannot solve them. A good chair will either take a vote, extend discussion for a set (limited) period, set up a working party, or call an extraordinary meeting to deal with the item later; any of these options are better than allowing the meeting to waffle on allowing tension and confusion to grow.
  8. Failing to engage with meeting participants outside of the meeting. Bad chairs are missing in action, too busy to be involved with the delegates other than during the meeting. Good chairs recognise the meeting is part of a continuing process that requires responsive input and support between meetings.

Meetings are an expensive resource often costing thousands of dollars an hour to run. If you are the chair of the meeting, or are responsible for calling a meeting, you need to ensure the meeting is managed effectively to maximise the opportunity for success.  This is important for every type of meeting from a short team ‘stand-up’ through to company board meetings – the further up the hierarchy the greater the cost of ineffective meetings. Unfortunately ‘bad chairs’ seem to be common at all levels; the idea for this post came from an article by Kath Walters in the AICD March 2017 magazine focused on the behaviour of dysfunctional boards of directors.

Recognising poor performance is one thing, doing something about it is another; for more on managing effective meetings see: http://www.mosaicprojects.com.au/WhitePapers/WP1075_Meetings.pdf


[1] For more on active listening see: http://www.mosaicprojects.com.au/WhitePapers/WP1012_Active_Listening.pdf

The Yin and Yang of Integrated Data Systems

December 13, 2016

Integrated project management information systems (PMIS) are becoming more common and more sophisticated ranging from ‘web portals’ that hold project data through to the potential for fully integrated design and construction management using BIM[1].  The benefits from using these systems can be as much as 20% on complex construction projects using BIM.

pmisThe advantages of this type of information storage and retrieval system include:

  • Ready access to data when needed via PDAs and ‘tablets’ significantly reducing the need for ‘push’ communication and the existence of ‘redundant data’[2].
  • One place to look for information with indexing and cross-referencing to minimise the potential for missed information.
  • Audit trails and systems to ensure only the latest version of any document is available.
  • Cross-linking of data in different documents and formats to assist with configuration management, requirements traceability and change control.
  • Controls on who can ‘see’ the data, access the data and edit the data.
  • Workflow functions to remind people of their next job, list open actions, record actual progress, etc[3].
  • A range of built-in functions to validate data and avoid ‘clashes’, including locking or ‘freezing’ parts of the data set when that information has been moved into ‘work’.

These benefits are significant and a well-designed system reduces errors and enhances productivity leading to reduced costs, but the ‘yin’ of well-designed PMIS comes with a ‘yang’!

People increasingly tend to believe information produced from a computer system, this is true of ‘Facebook’, Wikipedia and flows through to more sophisticated systems. There also seems to be a steady reduction in the ability of younger people in particular to critically analyse information; in short if it comes from the computer many people will assume it is correct. Add to this the ability of many of the more sophisticated PMIS tools to transpose and transfer information between different parts of the systems automatically or semiautomatically and there is a potential for many of the benefits outlined above to be undermined by poor data. This issue has been identified for decades and has the acronym GIGO – garbage in, garbage out.

The question posed in this blog is how many projects and project support organisations (PMOs, etc.) consider or actively implement effective data traceability.  Failed audits, overruns from scope oversights, and uninformed or ill-informed decision-making are just a few of the consequences project teams suffer from if they do not have full traceability of their project management data. This issue exists in any information processing system from basic schedule updating, through monthly reporting to the most sophisticated, integrated PMIS. If you cannot rely on the source data, no amount of processing will improve the situation! And to be able to rely on data, you need to be able to trace it back to its source.

tracabilityTraceability is defined as ‘the ability to trace the location, history and use of each data element’. This sounds simple but in reality can be very challenging, and the results of poor visibility can be devastating to a project. Some of the key questions to ask are:

  • Where did this data or these actuals come from?
  • What is the authorizing document and when did it get signed/approved?
  • Has everyone approved the change request or action item?

Traceability does not happen by accident! Project management information systems have to be designed with traceability as a key element in each of its aspects.  As information comes into the system the author or the origin of the information has to be recorded (preferably automatically). Depending on the nature of the information it may need to be quarantined until appropriate checks have been carried out and/or approvals have been obtained and then there needs to be traceability of any subsequent changes. The foundation of traceability is the combination of processes (people) and data management.

Therefore, the ‘yang’ of a sophisticated integrated project management information systems is that as the systems become more integrated and sophisticated people will come to rely on the information provided and ‘trust it’ whilst the source and veracity of the data used becomes less obvious.

Resolving this is partly process and partly people. The Chartered Institute of Building (CIOB) has produced the Time and Cost Management Contract Suite 2015 focused on complex construction projects using BIM.  This contract defines a number of key support roles (largely independent of the parties) focused on managing the information flows into and out of the system to ensure its accuracy and validity. Similar roles and responsibilities are essential in any effective PMIS.

My latest post on the PMI ‘Voices blog’, From Data to Wisdom: Creating & Managing Knowledge highlights the importance of data as the underpinning of all reporting and communication.  So the question is, how much focus does your project team or PMO put on ensuring the data it is using is timely, complete, accurate and traceable?


[1] BIM = Building Information Modelling, see: http://www.mosaicprojects.com.au/WhitePapers/WP1082_BIM_Levels.pdf

[2] For more on planning project communication see: http://www.mosaicprojects.com.au/Mag_Articles/ESEI-09-communication-planning.pdf

[3] A discussion on how these capabilities can enhance project controls is at: https://mosaicprojects.wordpress.com/2016/11/26/the-future-of-project-controls/

Are you a workshop leader or facilitator?

November 17, 2016

workshopWorkshops are a routine feature in many projects. They are typically used either to find a solution to a problem or to develop and integrate knowledge needed for the work (eg, requirements gathering and prioritisation).

Effective project managers know that every workshop is a meeting and many of the rules for running effective meetings need to be applied including:

They also know that unlike normal meetings workshops are a creative process that needs the active contribution of the attendees to craft the best answer to the problem or question being posed…..  This means time is needed to ‘break the ice’ so that the people in the workshop feel comfortable working together and the facilitator needs to act as a host welcoming and engaging people as they arrive.

The job of the facilitator is to ensure the workshop ‘works’ and produces the required outcomes. The facilitator (or workshop leader) only needs sufficient knowledge of the subject under discussion to allow them to ask pertinent questions and summarise discussion – the core skills of facilitation lay in ensuring everyone is engaged and participates, all points of view are heard, the group works towards a consensus or conclusion efficiently and the outputs are agreed.  For more on facilitation see: http://www.mosaicprojects.com.au/WhitePapers/WP1067_Facilitation.pdf

Facilitation is a very useful skill for a project manager to acquire and use, however, to organise and run a successful workshop there are a two key questions that need to be asked very early in the planning stage – unfortunately both of these are frequently overlooked!

Question 1 – Will I be a key contributor to the process of developing the workshop’s output? If the answer to this question is ‘yes’ the project manager should consider engaging someone else to act as the facilitator for the workshop.  The role of the facilitator is to make sure everyone contributes, all of the ideas are brought into discussion and the best solution is reached; it is nearly impossible to do this if you are also contributing significant input to the discussion.

Question 2 – Do I want to lead the workshop towards a predetermined conclusion or do I want the workshop to have free reign to explore and develop its own solutions?  While a degree of flexibility is needed in both situations, if the workshop is focused on getting buy-in to a concept that is already in mind (quite common in problem solving mode) the approach to managing the workshop will be quite different to an open discussion looking at all of the options.

Based on your answers to these questions there are four quite different types of workshop that require different approaches to deliver successful outcomes:


The best way to approach the planning and running each of these workshop types varies significantly.

You facilitate. In situations where you have no particular input to contribute and no predetermined outcome in mind (beyond the fact you need an outcome) facilitating the work of the group participating in the workshop can be a good way to build credibility and enhance your leadership position. Provided you are comfortable in the role, facilitating the workshop to achieve a useful outcome is a valid role for the project manager.  If you are not comfortable in the role, there is nothing wrong with using an experienced facilitator, your objective is simply to get a useful outcome from the process (for example a prioritised list of requirements).

Others facilitate. Where you are going to be a key participant in the workshop process and have significant input to contribute as a subject matter expert, but do not want to drive to a predetermined conclusion, the use of a neutral facilitator is essential.  The job of the facilitator is to ensure all of the viewpoints in the room are heard and the outcomes from the workshop incorporate the views of the participants, either based on a consensus or by applying an impartial selection / decision making process. It is virtually impossible to simultaneously be a participating expert and an impartial facilitator.

Briefing sessions. Have a very different focus, the purpose of the workshop is to explore and understand a predetermined proposition.  The role of the facilitator shifts towards making sure everyone’s questions are heard and answered, and there is a full understanding of the proposition being put. The outcome from the workshop is focused on creating understanding and buy-in from the participants rather than crafting a free-form solution – depending on the nature of the proposition being discussed, there may, or may not, be opportunities to adjust or fine-tune the concepts. However, provided someone else is the primary source of the concepts being discussed, the project manager can usefully take the role of facilitator.

Sales sessions. Have a similar focus to briefing sessions but the concept being ‘sold’ is primarily ‘owned’ by the project manager.  In this situation if you want genuine buy-in from the workshop participants it is essential that the workshop is facilitated by someone else!  The facilitator’s job is to make sure everyone is heard and to help lead the group towards a common understanding and consensus. Your job is to answer the questions and ‘sell’ the proposition (and where appropriate adapt your proposition based on the feedback received).

Understanding the objectives of the workshop and the best way for you to participate in delivering a successful outcome lays the foundation for success.  Then the hard work starts……..

Seeking a definition of a project.

August 11, 2016

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











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

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

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

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

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


Updating the definition

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

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

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


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

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

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


A concise definition of a project

Unpacking the elements involved in a project we find:

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

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

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

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

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

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

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

I look forward to your thoughts!