M02-6 Identifying and Engaging Stakeholders

02.0 - MANAGING PEOPLE

02.1 - Module 02-1 - Introduction to Managing People

02.2 - Module 02-2 -Develop Project Controls Career Path Development Plan

02.3 - Module 02-3 - Develop Individual Competencies

02.4 - Module 02-4 - Develop Management Competencies

02.5 - Module 02-5 - Develop Organisational Competencies

02.6 - MODULE 02-6 - IDENTIFYING AND ENGAGING STAKEHOLDERS

Figure 1 - Identifying and Engaging Stakeholders Process Map

Source: Source: Guild of Project Controls

02.6.1 INTRODUCTION

Stakeholder management is becoming recognized as one of the major reasons projects succeed or fail and as project control professionals play such a key role in the collection, analysis and communication of project information, it becomes imperative that we know and understand the different perspectives to identify and engage stakeholders.

Stakeholders fall into 6 generic categories-

1. Beneficiaries- Usually the customer client or end user of the product the project was undertaken to deliver. Those entities who will benefit from the product of the project
2. Negative Beneficiaries- Those stakeholders who will either be negatively impacted TEMPORARILY while the project is executed (e.g. people who have to detour while new water pipes are being installed in their neighborhood) or PERMANENTLY. (e.g. Someone who lost their home to a new roadway being built)
3. Implementers- Those leading or serving on the project team. This includes owner’s staff, contractor’s staff along with subcontractor and vendors. Anyone who provides support to the execution of the project.
4. Decision makers- The most obvious are the Asset Managers who act as SPONSORS for CAPEX funded project or Operations Managers who act as SPONSORS for OPEX funded projects. Other examples of decision makers would be the local building or electrical inspectors.
5. Financiers- This includes the banks, shareholders, bond holders or those in the finance or accounting department.
6. Regulators- These are any one of a number of Governmental or quasi-governmental agencies, including NGO’s. The prime examples are the Environmental Protection Agencies or the Board of Health. Any governmental agency which publishes rules or regulations which the project must comply with.

The dictionary definition of “stakeholder” to be: “Any party that has an interest in an enterprise or project. The primary stakeholders in a typical corporation are its investors, employees, customers, contractors and suppliers. However, modern theory goes beyond this conventional notion to embrace additional stakeholders such as the community, government and trade associations.”

Identifying stakeholder needs, wants and expectations has become one of the most under stated yet arguably one of the more important functions that “project controls” or “project management offices” is responsible to facilitate. There is no shortage of research pointing to the number of “failed” projects and the vast majority of those “failures” involve the project manager and project team’s ability to establish realistic expectations in terms of time and cost budgets, resource availability and productivity an perhaps most importantly, an understanding of the risks inherent in project work. The Investopedia definition of “stakeholder” does the best job of explaining the quandary project control professionals find themselves in, whether working for an owner or contractor organization. 

What this means is the practice of project control is in the position of having to negotiate between stakeholders who want the project cheap, those who want it fast and those who want high quality and safety. Because clients today want the projects “faster, cheaper, better” the planner/scheduler and the cost manager in particular have to facilitate negotiations between stakeholders with mutually exclusive needs wants and expectations. Explained another way, you can have your projects fast and cheap, good and fast or good and cheap but you CANNOT have them fast and good and cheap.

Figure 2 - Broard vs the Narrow View of What a Stakeholder is

Source: Stakeholder Theory (2013)

02.6.2 INPUTS

• Business Case
  • Owner
  • Contractor
• Performance Measurement Baseline

02.6.3 TOOLS & TECHNIQUES

02.6.3.1 Stakeholders Identified Defining “Success”

Given that projects seem to “fail” with alarming regularity, one of the great challenges in project management is trying to define what “success” looks like, understanding that what might look like “success” to one stakeholder may well be “failure” for another. One of the major outputs from Module 2.4 - Identifying and Engaging Stakeholders is to get all stakeholders to agree on what “success” looks like. The reason for this is given project controls has access to such a wealth of project historic data, whether you are an owner or contractor’s project control professional, you are probably well positioned to track and report on this Key Performance Indicator (KPI).

So how can project controls practitioners help in identifying and engaging stakeholders and facilitating them to define what “success” looks like?  There are two elements to “success”.  One is the success or failure of the PROJECT which is where project control professionals who are assigned to the execution phase of the project play a role and the other is the “success” or “failure” of whatever product, service, asset, change or business result the project was undertaken to achieve.  This is more often the responsibility of the project control professional working for an owner during the early phases of the project when the business case is established.

For the PRODUCT of the project to succeed it must substantially deliver the value or fulfill the needs for which the project was undertaken to accomplish in the first place.   While for the PROJECT to succeed, the business case is often ignored and the focus is on the “Tetrad Trade Off” of scope, cost, time and quality. Which is why project control professionals need to be looking not only whether the project was a success, but was the PRODUCT the project was undertaken to create was a success.   For a CONTRACTOR, as the project is a PROFIT CENTER, this means did the project deliver the profit margin or whatever other benefit chosen as to why the contractor bid on the project.  However, for an OWNER’S project control team, they not only have to look at whether the project was successful but also need to conduct a FORENSIC ANALYSIS to measure whether or not the project achieved the STRATEGIC OBJECTIVES for which it was undertaken.

Because we are exploring the definition of “success”, in the context of the explanation above, this is an ideal point to explain the difference between PROJECT success and PRODUCT success.

Figure 3 - Project Success v Failure

Source: Giammalvo, Paul D (2015) Course Materials. Contributed Under Creative Commons License BY v 4.0

This simple matrix shown in Figure 3 illustrates an important concept that project control practitioners need to understand and appreciate and that is, the difference between a PROJECT being successful and whatever product (asset), service or business outcome the project was undertaken to achieve or produce being successful.

Unfortunately, as we have come to find out, there is no correlation between a PROJECT being “successful” or “failing” and the product of the project “succeeding” or “failing”.  

In the worst case scenario, the Project “fails” and whatever product or service or result the project created fails as well. The classic example of this scenario, is the European Channel Tunnel project; not only was it late and over budget, but the payback period on the investment is longer than the useful life of the product the project created. At least from an investment perspective, it was unsuccessful.  

The classic example of a project which FAILED but the PRODUCT was a success, is the Sydney Opera house. The project itself was late, over budget, and experienced all kinds of quality problems, but the product the project created has become the iconic image of Sydney with untold tangible and intangible value added.

In the third scenario, the project was a “success” (i.e. finished on time, within budget, in substantial conformance to the technical requirements with no lost time injuries or major environmental violations) but the product of the project failed to deliver the return on investment. We find this scenario playing out frequently in the oil and gas sector, where the drilling contractor does a great job and walks away happy, but the well fails to produce the amount of oil or gas that the business case was predicated on.

You can fill in your own examples of your favourite scenario where both the project and the product of the project was a “success”, but unfortunately, based on the research by KMG, Glenn Butts and many others, examples of these kinds of projects are relatively low and the larger and more complex the project the less likely we are to find scenarios where both the project and the product were successes. 

As a follow on, one of the most fundamental tenets or beliefs in management theory is that a person cannot be held accountable for that over which he/she has no reasonable control and/or the authority to act. What this means is we need to be able to identify different categories of risk and opportunity events, determine who is best able to manage that risk or opportunity, and then empower or authorize the person responsible with sufficient and appropriate authority to act to address that potential risk or opportunity event.

Surprisingly enough, while there is plenty of research showing consistency in the root causes of project failure there is not a lot of consistency in defining project “success” criteria.

What is clear is that there is are certain LEGAL OBLIGATION of the managers in any organization be it owner or contractor, is their obligation to maximize shareholder value. Which means that the top priority for a CONTRACTOR is to generate a favorable return on investment, which, given for a contractor a project is usually a PROFIT CENTER that the first or top priority is for the project to be PROFITABLE. However because for an OWNER a project is NOT a profit center, but a cost or investment center, for the OWNER’s project manager, the primary responsibility is to increase shareholder value by doing their part to ensure that the PRODUCT of the project meets or fulfills the business objective.

Figure 4 - Top 10 Success Criteria for Owner’s and Contractor’s

Source: Compiled and edited by Giammalvo, Paul D. (2015) from research by Korbijn, Gert (2014) "Success criteria and critical success factors for contractors of urgent and unexpected projects" plus Livengood, John (2014) "Managing Claims from A to Z, AACE Bangkok Symposium"

The other two LEGAL obligations of both Owner and Contractor are that they must adhere to the various safety, health and environmental laws as well as being legally obligated to fulfill whatever has been agreed to in the contract. For this reason, these legal obligations were ranked as being the top 3 (Green highlight). 

Given that no manager, be they contractor or owner, can be held accountable for that over which they have little or no control or authority, those items in yellow highlight are those items over which the owners and contractors project managers should have “reasonable” control over AND sufficient authority to influence the outcomes. Applying this criteria, the research indicates that those items in yellow appeared consistently throughout all of the research, although the relative rank order changed considerably.

Given the uniqueness of each project it should be up to the project manager, supported by the project control team, as a part of their stakeholder analysis to capture, record and track progress against those elements the stakeholders used to define “success”.

02.6.3.2 Stakeholder Theory

Stakeholder Theory is a specific approach to recognising and dealing with stakeholders, based on the concept of stakeholder developed by Ed Freeman in his books Strategic Management: a Stakeholder Approach (1984), and Stakeholder Theory: The State of the Art (2010).

The way in which organisations approach stakeholder management, the tools and techniques used to engage stakeholders and at a philosophical level, the purpose of the organisation are all built on which view of stakeholders is accepted by the organisation’s governing body.

The traditionalist / Friedman view of stakeholders focused on the ‘owners’ of the organisation (in the commercial world shareholders) with the simple purpose of maximising profits. A range of public relations and physical disasters highlight the short term, self-defeating outcomes of this approach.

R Edward (Ed) Freeman’s stakeholder theory poses the deeper philosophical question: ‘can business leaders make decisions about the conduct of the business without considering the impact of these decisions on (all) those who will be affected by the decisions?’ Is it possible to separate ‘business’ decisions from the ethical considerations of their impact?

The evidence suggests it is impossible to build a sustainable organisation of any type, including a profitable business, if that organisation fails to meet the needs of most (if not all) of its stakeholders, most of the time. Freeman is considered to be one of the early proponents of this wider view of organisational stakeholders, writing that they could be defined as “any group or individual who can affect or is affected by the achievement of the organisation’s objectives”.

Adopting this approach to stakeholder engagement is supported by organisations such as the Project Management Institute (PMI) and would appear to offer the greatest opportunity for project success. Stakeholder affect project controls in two ways:

• Project controllers can be actively engaged in managing the technical aspects of the project stakeholder engagement; eg, by compiling and maintaining the stakeholder register.
• Controls information is a key element in the overall information exchange with stakeholders and contributes to managing the stakeholder’s expectations.

02.6.3.2.1. Stakeholders and Governance

Over the last decade or two, governance has been an emerging area of interest, growing in importance and the focus of increasing legislative interest; as a consequence, governance is becoming an increasingly important part of the overall management of projects and requires effective controls data. The objectives of governance were defined in 2002 by Sir Adrian Cadbury and in 2004 by the OECD.

The objective of ‘good governance’ adapted from the definition by Sir Adrian Cadbury (2002) is generally accepted as: “…… holding the balance between economic and social goals and between individual and communal goals. The governance framework is there to encourage the efficient use of resources and equally to require accountability for the stewardship of those resources. The aim is to align as nearly as possible the interests of individuals, the organisation and society”.

Making governance decisions requires controls data! However, project controls cannot operate effectively without the protection of senior management. Frank and fearless reporting of status and issues cannot be assumed if the middle levels of management have the capability to restrict negative information. Conversely, executive management decisions depend on accurate and realistic assessments of risk, schedule and cost. Creating a culture where this type of information is not only available but accepted and used properly is the key governance issue within the project, program and portfolio domain. The functions of governance are:

• To determine the objectives of the organisation
• To determine the ethics of the organisation
• To create the culture of the organisation
• To design & implement the governance framework
• To ensure accountability by management
• To ensure compliance by the organisation

These functions ‘set the rules’ by which management operate to achieve the objectives of the organisation. The functions of management were developed by Henri Fayol (1841 – 1925) and described in his 1916 book Administration Industrielle et Generale , as:

• To forecast and plan,
• To organise
• To command or direct (lead)
• To coordinate
• To control (French: contrôller: in the sense that a manager must receive feedback about a process in order to make necessary adjustments and must analyse the deviations.).

Management undertakes these functions through management structures and committees such as project control boards. The role of controls is to make sure accurate, timely and relevant information is available to all levels of governance and management.

02.6.3.2.2. Stakeholder Mapping Techniques and Tools

There are a wide range of tools and methodologies for categorising and listing stakeholders in an appropriate form of stakeholder register. The role of the project controllers is to assist project management in this process, using the defined tools and templates.

Most categorisation tools in use at present are simple 2x2 matrices; the world loves 2×2 matrices because they help make complex issues appear simple. Unfortunately though, some complex issues are complex and need far more information to support effective decision making and action. The apparent elegance of a 2×2 view or the world quickly moves from simple to simplistic.

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

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

Figure 5 - Power-Interest Grid

Source: Power-Interest grid for stakeholder prioritization (Thompson 2006)

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

The problem is you may have a stakeholder assessed as high power, low interest who opposes your work, who you need to be actively engaged and supportive – ‘keep satisfied’ is a completely inappropriate management strategy. The Salience Model developed by Mitchell, Agle, and Wood. (1997) introduces the concepts of urgency and legitimacy.

Figure 6 - Salience

Source: Salience Model, Puneet Kuthiala, 2009

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

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

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

Figure 7 - Three Dimensional Stakeholder Cube

Source: Murray-Webster and Simon, 2008

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

02.6.3.2.3. Information Needed for a Full Assessment

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

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

• Firstly the power the stakeholder has to affect the work of the project. This aspect tends to remain stable over time.
• Secondly the degree of ‘urgency’ associated with the stakeholder – how intense are the actions of the stakeholder to protect of support its stake? This aspect can change quickly depending on the interactions that have occurred between the project team and the stakeholder.
• A third element, included in the Stakeholder Circle® methodology, is how close is the stakeholder to the work of the project (proximity) – stakeholders actively engaged in the work (eg, team members) tend to be need more management attention than those relatively remote from the work.

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

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

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

If this all sounds like hard work it is! But it’s far less work then struggling to revive a failed project. You generally only get one chance to create a first impression with your stakeholders – it helps to make it a good one.

02.6.3.2.4. Stakeholder Register

The stakeholder register lists the stakeholders affecting the work of the project and/or who are being actively managed. The information recorded in a stakeholder register varies, but should include:

• Identification information. Name, organisation, position, location and contact details, and where appropriate, role in the project, their stake in the project.
• Assessment information. What the project needs or requires from the stakeholder, the stakeholder’s expectations or requirements from the project, potential for influencing project outcomes, and the phase of the project life cycle where the stakeholder has the most influence or impact.
• Stakeholder classification. Internal/external, impact/influence/power/interest, upwards/downwards/outwards/sidewards, or any other classification model chosen by the project manager and team to assist in building relationships and developing the appropriate communication strategies.

The stakeholder register should be consulted and updated on a regular basis, when the membership of the stakeholder community changes, as the project moves into another phase, and if there are changes within the organization or the project environment.

02.6.3.2.5. Controls Support for Stakeholder Engagement

Stakeholder engagement is primarily the function of the project manager and the project management team; however, all contact between project personnel and others is in part a stakeholder engagement activity and has the potential to alienate stakeholders. Therefore all communication and other contacts with stakeholders should be seen as part of the stakeholder engagement processes.

In addition to this general involvement, controls data can be an important element within all three types of project communication. Therefore controls professionals should be alert to the information needs of stakeholders and ensure the information they provide is structured to meet the needs of most people.

02.6.3.2.6. The Three Types of Stakeholder Communication

Projects use three basic types of communication, project controls information can contribute to all three provided the project controllers are aware of the opportunities and make the information available to the project management team in a useful and timely way.

There are three general classes of communication that are needed in an effective stakeholder engagement:

1. Traditional reporting;
2. Project relations (PR - marketing); and
3. Directed communication.

Reporting fulfils two useful purposes. Firstly it demonstrates you are running your project properly, project managers are expected to produce reports and have schedules, etc., issuing reports shows that you are conforming to expectations. Secondly, copying a report to a person keeps you in touch with them for when more significant communications are needed. Compiling reports is a core function of project controls.

Project relations (PR) similar to normal PR but focused on your project and stakeholders. PR or marketing is probably the most underrated and under used communication process. It includes all of the broadcast communications needed to provide information about your project to the wider stakeholder community, both to market the value of the project and to prevent information ‘black holes’ developing that breed misinformation and rumour.

Project controllers should be aware of the PR schedule and make sure significant highlights from within the controls information are made available to the people managing the PR function. Newsworthy highlights may be 1 million accident free hours, milestones achieved, or any other vignette of information that is interesting to a ‘wider audience’.

Directed communication is hard work and needs to be focused on the important stakeholders (both positive and negative) with whom the project management team need to cause a specific effect. This includes providing direction to team members and suppliers and influencing the attitude or expectations of other key stakeholders. Directed communication needs to be planned, which means the project management team need to know precisely what effect they are seeking and then work out how to achieve the effect.

The role of project controllers is to support this effort with information as requested or needed.

02.6.3.2.7. Targeted Information

One size simply does not ‘fit all’. All project communication needs to be designed to meet the needs of the recipient, to make it as easy as possible for the recipient to make use of the information and act in a way that best meets the needs of the project. There is absolutely no point in sending information to someone in a format that makes it hard for them to use; they will simply ignore the information.

As discussed in the communication section above:

• There is no point in communicating with someone unless you want them to do, or change, something.
• To have an effect, the information communicated has to be understood by the receiver.

Achieving this requires the ‘right information’ in the ‘right format’ to be available to the stakeholder at the ‘right time’.

Right information = relevant to the stakeholder at the right level of detail or summarisation. As a general rule, if the information being communicated exceeds half of one page in length no one will bother reading it which means they will not understand what they have to do. Achieving this heuristic requires focusing on the information that matters, at the appropriate level of detail, within an appropriate timeframe. Team leaders only need information about their team’s work over the next 2 to 4 weeks maximum. Senior executives do not need 100s of lines of detail. More general information can be made available via ‘pull communication’ options.

Right format = easily read and understood.

Most people do not understand project controls diagrams and charts, and most people will not tell you this. Make sure the information you are communicating is in a format that can be understood by the receiver. Just because you have been trained to read a bar chart and believe the information is concise and easily understood does not mean everyone has had your training. Active listening skills are needed to make sure the information is understood (particularly by senior executives).

02.6.3.3 Six Types or Categories of Stakeholder

The reason it is important to categorize stakeholders is because in many instances, they have competing, conflicting or in some cases, mutually exclusive needs, wants and expectations. When this happens, which it inevitably does, it becomes the project manager’s responsibility, with the help and support from the project controls team as subject matter experts, to assist in negotiating with the stakeholders to come up with realistic expectations. This is especially true when it comes to time (planning and scheduling) and costs (resources) As an example, the sales and marketing people say they need the project done in 6 months in order to beat the competition and be first in the marketplace with the new product or service. But then the finance people come along and say that the additional costs to crash the project bring into question whether or not the business case will remain valid.

Ideally, these negotiations should have happened in Phases 1, 2 or 3 and not when we get into Phases 4 or 5 and execution actually starts, but unfortunately, that is what happens and is something we as project control professionals should be facilitating in those early phases. Figure 7 below under the ethical obligations of the project control professional illustrates this quandary and also explains what our role and responsibility is to all stakeholders, to that they can reach agreement before the project starts.

1. Beneficiaries- Usually the customer client or end user of the product the project was undertaken to deliver. Those entities who will benefit from the product of the project
2. Negative Beneficiaries- Those stakeholders who will either be negatively impacted TEMPORARILY while the project is executed (e.g. people who have to detour while new water pipes are being installed in their neigborhood) or PERMANENTLY. (e.g. Someone who lost their home to a new roadway being built)
3. Implementers- Those leading or serving on the project team. This includes owner’s staff, contractor’s staff along with subcontractor and vendors. Anyone who provides support to the execution of the project.
4. Decision makers- The most obvious are the Asset Managers who act as SPONSORS for CAPEX funded project or Operations Managers who act as SPONSORS for OPEX funded projects. Other examples of decision makers would be the local building or electrical inpectors.
5. Financiers- This includes the banks, shareholders, bond holders or those in the finance or accounting department.
6. Regulators- These are any one of a number of Governmental or quasi-governmental agencies, including NGO’s. The prime examples are the Environmental Protection Agencies or the Board of Health. Any governmental agency which publishes rules or regulations which the project must comply with.

02.6.3.3.1. Five Questions To Identify Stakeholders

1. Does the stakeholder have a fundamental impact on your organization’s performance? (Required response: yes.)
2. Can you clearly identify what you want from the stakeholder? (Required response: yes.)
3. Is the relationship dynamic — that is, do you want it to grow? (Required response: yes.)
4. Can you exist without or easily replace the stakeholder? (Required response: no.)
5. Has the stakeholder already been identified through another relationship? (Required response: no.)

02.6.3.3.2. Tips for Facilitating Stakeholder Analysis Meetings

1. Stakeholder analysis may comprise a series of focus-group meetings and workshops.
2. Define group categories narrowly or broadly, depending on the situation.
3. Make sure to have all fundamental information of the key stakeholders.
4. Perform detailed analysis of the key stakeholders.
5. Keep stakeholder analyses updated during project implementation because this is a vital source of information.

This process can be integrated into regular project review missions.

02.6.3.4 Ethics for Project Control Professionals

As the Guild has invested thousands of person-hours researching global “best tested and proven” practices, we have adopted and urge other organizations to consider adopting or adapting the Society of Corporate Compliance and Ethics (SCCE) Code of Professional Ethics.   As the SCCE literally has “written the book” on ethics for all major corporations and many government agencies, the Guild has adopted this approach and adapted it to apply to professional project control practitioners as well.  

More specifically, the key ethical obligation affecting project controllers include (in no particular order):

• Only accepting assignments that are consistent with our capabilities.
• Protecting proprietary or confidential information.
• Upholding the policies, rules, regulations and laws that govern our work.
• Actively seeking to understand the truth.
• Providing complete and accurate information in a timely manner.
• Being truthful in our communications and in our conduct.

This means as professional project control practitioners, we do not engage in or condone behaviour that is designed to deceive others, including but not limited to, making misleading or false statements, stating half-truths, providing information out of context or withholding information that, if known, would render our statements as misleading or incomplete.

One of the issues facing project control professionals is when and how to tell project stakeholders that their expectations are unrealistic if not impossible.  The classic example of this is our PROFESSIONAL OBLIGATION to make know to the key stakeholders the trade-offs between time and costs, understanding that the contractors normal or optimum duration is unlikely to be the owners optimum or desired duration, and that there are cost impacts that owners have to be willing to recognize or accept if they want a project done faster than is “normal”.  Examples of this can be found in everyday life where you take your suits into the dry cleaner and you can have one hour service, same day service or 3 day service, with a cost premium placed on the faster delivery time.

Ethics is concerned with distinguishing between good and evil in the world, between right and wrong human actions, and between virtuous and nonvirtuous characteristics of people. Ethical behaviour is a key underpinning of leadership and is built upon several layers of understanding.

02.6.3.4.1. Values, Morals and Ethics

Values are the fundamental beliefs of a person or social group in which they have an emotional investment. They are the principles we use to define that which is right, good and just. They are our standards which provide guidance as we make decisions about right and wrong, should and shouldn't, good and bad. They also help us decide which are more or less important, which is valuable when we have to trade off meeting one value over another. Typical values include honesty, integrity, compassion, courage, honour, responsibility, respect and fairness. Morals are values which we attribute to a system of beliefs, typically a religious system and are based on ideas of right and wrong. These values get their authority from something outside the individual - a higher being or higher authority (e.g. society).

Morals have a greater social element compared to values and tend to have a very broad acceptance. Many of our values are strongly influenced by our sense of morality - what is right as defined by a higher authority. Most of the values listed above (honesty, integrity, compassion …) can be categorised as ‘moral values’ - values derived from a higher authority. Which is a convenient way to differentiate them from what are often called utilitarian or business values, such as excellence, quality, safety, service, which define some elements of right and good in a business context.

Ethics is about our actions and decisions. They are the rules or standards governing the conduct of a person or the members of a profession. When one acts in ways which are consistent with our beliefs (whether secular or derived from a moral authority) we characterise those actions as ‘acting ethically’. However defining what is ethical is not an individual exercise; ethics are defined societally, not individually, and tend to be codified into a formal system or set of rules which are explicitly adopted by a group of people.

02.6.3.4.2. The Ethical Obligations of a Project Controls Professional

The key ethical obligation affecting project controllers include (in no particular order):

• Only accepting assignments that are consistent with our capabilities.
• Protecting proprietary or confidential information.
• Upholding the policies, rules, regulations and laws that govern our work.
• Actively seeking to understand the truth.
• Providing complete and accurate information in a timely manner.
• Being truthful in our communications and in our conduct.

This means we do not engage in or condone behaviour that is designed to deceive others, including but not limited to, making misleading or false statements, stating half-truths, providing information out of context or withholding information that, if known, would render our statements as misleading or incomplete.

One of the issues facing project control professionals is when and how to tell project stakeholders that their expectations are unrealistic if not impossible. While these are shown under the heading of ethical obligations, under the various shareholder protection laws such as Sarbanes Oxley (SoX) in the USA or the British or EU equivalent legislation what is today considered to be an ethical issue may well become a legal one as well, assuming that project managers and project controls people have access to information that may well lead to a loss in shareholder value.

The classic example of this is what happened to Lucent Technologies and the OneTel project during 199 to 2001 in Australia. Basically, OneTel selected Lucent Technologies to design, install and commission a 1.3 billion dollar GSM communications system. Despite the fact that no banks would provide financing to OneTel for the project, Lucent decided to provide MORE than 100% financing. During the design and rollout those on the project knew the project was a disaster waiting to happen yet no one on the project team would speak out against it.

In several legal actions which are still on-going, the question of how much the project team knew and what their ethical if not legal obligations were to “blow the whistle” when they realized the project was doomed has yet to be resolved. While all professionals are or should adhere to a professional code of ethics/code of conduct, not all codes of ethics/codes of conduct are created equally.

The Guild of Project Controls has researched what are defined to be “best in class” codes of ethics and we have agreed that the best benchmark comes to us from the Society of Corporate Compliance and Ethics organization (SCCE) on the basis that these are the people who research and write our corporate and organizational codes of ethics. Here is the link to the SCCE Code of Ethics understanding that the Guild is in the process of benchmarking our organization code of ethics against this standard and we are urging our members to do the same.

Given the propensity of owners in particular to be overly optimistic in terms of how long it takes to do a project and how much the project will cost, one of the responsibilities of the project control professional is to conduct an analysis of the optimum duration of a project by adding the construction costs and the engineering and “road user” or “opportunity” costs to find what the optimum duration and project budget should be. This is known in some sectors as the “should cost” vs “will cost” analysis. While management tends not to like to see this information, as professionals, we have the obligation to conduct this analysis and make our stakeholders aware of the results. The reasoning behind this is so many projects are failing because of unrealistic cost and/or time estimates on the part of project sponsors.

As noted by several researchers, most notably Glenn Butts (NASA), Prof Bent Flyvbjerg, Ed Merrow and others, there are serious problems with owner organization’s in particular intentionally underestimating costs and/or time in order to make the business case more attractive. If this does not stop, sooner or later under Sarbanes Oxley or BASIL 3, project managers and project control managers are likely to be held legally accountable for intentionally under estimating costs, risks or durations, as part of our ethical obligations not only to the shareholders of our organizations, but to all stakeholders in the broadest sense, we need to be producing an analysis showing what the “will cost” estimates are vs the “should cost” estimates, And this concept applies to both costs and durations as well.

Figure 8 - Cost vs Time Analysis to determine the OPTIMUM duration

Source: Work Zone Road User Costs Concepts and Applications (2011) Figure 15 Page 116

02.6.3.5 Use of the Logical Framework Approach

To close out this module the Guild of Project Controls researched to find any model or approach which enables us to develop realistic expectations given diverse and mutually exclusive stakeholder needs, wants and expectations, while still achieving or realizing an organizations strategic goals and objectives, given limited or scarce resources?

Historically, project control professionals, in particularly those working for owner organizations have not been effective in connecting projects to achieving strategic objectives.  Based on the Guilds research a “best tested and proven” practice is known as the “Logical Framework Approach” (LFA) and while it was developed back in the 1970’s for international development projects and is still in use today,  it has not yet become commonplace for use by the private sector.   As the emphasis is increasingly being on “sustainability”, the logical framework approach is being advocated by the Guild for use wherever appropriate by professional project control practitioners.  

What we have at the completion of implementing the Logical Framework Approach processes is a single one or two page document which summarizes the requirements for a project, which shows how allocating scarce or limited resources through the project management processes, will achieve organizational objectives.  This document is known as the “LogFrame Document” or simply “LogFrame”.   As we begin to understand how this project development tool/technique can be used not only to measure and assess the relative success or failure of the PROJECT but also the relative long term success or failure of how well the project achieved whatever strategic objectives it was undertaken to achieve, either as a single project or part of a portfolio of projects in support of a program.

One of the major problems in many of our organizations is trying to accomplish too many projects with too few resources. Depending on the “PMO” or “Project Controls” model being used in your organization, part of the roles and responsibilities may include portfolio management, which up until recently, was treated as a separate responsibility. With AACE’s Total Cost Management Framework (TCMF), PMI’s PMBOK Guide 2016 and Axelos PRINCE2 moving towards full integration of asset, portfolio, program (operations) and project management processes into a holistic approach, the Guild of Project Controls is urging Project Controls professionals to expand our knowledge beyond merely planning and scheduling, cost estimating and claims analysis into the broad field of “project support services”.

Those organizations responsible for international development projects have created a tool or technique to allocate scarce or limited resources to use project management as the delivery method to achieve strategic objectives. This is known as the “Logical Framework Approach” (LFA) and is a tested and proven “best practice” which has been in use since the 1970’s. The Guild believes this method should be known by all GPC members, not only because so many projects are being funded by bi-lateral organizations such as the World Bank, International Monetary Fund, Asian Development Bank, and the new Chinese led Asian Infrastructure Investment Bank, but also Government Agencies such as AusAid, USAID, UN Projects Office (UNOPS) or Non-Governmental Agencies such as World Wildlife Fund (WWF) OxFam, Save the Children etc, all require project control professionals. For this reason, knowledge and understanding of the Logical Framework Approach (LFA) and how to create the LogFrame document are essential skills to master for the professional practitioner.

The 6 step process map for using the Logical Framework Approach (LFA) to create the LogFrame document can be see here:

Figure 9 - 6 Step Process Map to Create the LogFrame Document

Source: Using the Logical Framework for Sector Analysis and Project Design: A User's Guide (2008)

Following this process, we can fully integrate the allocation of scarce or limited resources to realizing organzatonal strategic objectives using project management as the “means to achieve the end”.

This is what a LogFrame document looks like when completed.

Figure 10 - LogFrame Document

Source: Using the Logical Framework for Sector Analysis and Project Design: A User's Guide (2008)

Using the Logical Framework approach we produce a one or two page document which summarizes the entire project into a format senior managers love as it not only identifies the level 2 WBS and Activities, but produces a Class 3 or Class 4 cost estimate but it shows on one or two pages what the key deliverables are from the project, what the business case for the project is and most importantly, what strategic objects the project is designed to support or deliver. It also provides KPI’s for each of the above, what metrics we will use to measure how successful both the project and the product of the project was, but also summarizes the project risks, business risks and strategic risks should the project not do what it was undertaken to achieve.

02.6.3.6 Negotiation

Negotiating is, or should be, a process designed to achieve a mutually acceptable outcome. Great negotiated outcomes are when both parties feel they have ‘won’; acceptable outcomes are when the parties can ‘live with’ the results.

02.6.3.6.1. Negotiation - opening stages

Preparation is the key to every successful negotiation. The more you know about your negotiating team, the project and the product being procured, PLUS the other side’s negotiating team, their offer, their business and the general market the better the likely outcome.

Establish protocols and introductions. Protocols depend on culture and tradition. Introductions and establishing appropriate protocols sets the atmosphere and framework for the negotiation.

Opening statements simply outline the starting position for each of the parties. All relevant documents should have been disclosed and copies provided to all of the negotiators.

02.6.3.6.2. Negotiation - negotiating stages

Probing is when each of the parties seek to understand their position in relation to the other:

• What points are already agreed and what is the difference between the parties on each of the other points;
• What are your, and the other party’s strengths and weaknesses;
• What is important to you (and the other side) and what can be traded to achieve an ultimate agreement?

Through building rapport and engaging in active listening it may be possible to understand the hidden thoughts and agendas of the other party.

Scratch (hard) bargaining is the process of trading concessions for benefits. Ideally to trade something of low value, but important to the other side, for some concession - “If we agree to pay your progress claims in 7 days, can you increase your workforce and reduce the development time?”. All concessions are made “subject to us reaching a final agreement then…”. Most of the negotiating tactics and ploys are used during this stage of negotiating.

02.6.3.6.3. Negotiations - closing stages

Ratification confirm what has been agreed.

Closure is when the overall position is summed up.

Agreement as soon as the final gap has been closed, fully document the agreement immediately (and sign off on the document) before anyone leaves the room. A reaction known as buyers remorse often sets in after a negotiation: “We should have done better / it was too easy.” The agreement can be lost if it is not clearly documented. More formal agreement, contracts, etc. are drafted after the closure of the negotiation (usually by lawyers).

Implementing the agreement. One key factor to build into every negotiation is remembering that any negotiated agreement has to be implemented. This requires the compliance of both parties.

02.6.3.6.4. Negotiation Rules

• REMEMBER 
  • Present and maintain a professional attitude.
  • Control stress and tension.
  • Avoid politics and egos.
  • Take time to gather all facts and requirements beforehand.
  • Meet with the proper hotel or site people who have the authority to make decisions.
  • Know all the following Do’s and Don’ts. 
• DO
  • Define the purpose and objectives of the meeting.
  • Know the event.
  • Have printed copies of meeting plans available.
  • Make key contacts in all services and sites.
  • Follow up frequently.
  • Obtain peer referrals.
  • Contact union stewards before an event at a union venue.
  • Communicate with clarity and outline everything in writing.
  • Make all agreements part of the written contract.
  • Possess the authority to make a decision (or sign a contract).
  • Be ethical.
  • Ask questions.
  • Listen and pay attention. 
  • Minimize all distractions. 
  • Verify all legal clauses of the contract with an attorney.
  • Know the budget.
• DON’T
  • Sacrifice quality for cost.
  • Make unreasonable demands.
  • Insist on being the final authority.
  • Be inconsiderate of a supplier’s profit margin and business needs.
  • Escalate and overestimate needs.
  • Hesitate to ask questions.
  • Be apprehensive about negotiating for everything required.
  • Promise what cannot be delivered.
  • Lie or misrepresent.
  • Jump at the first offer.
  • Pass up a good deal based on a personality conflict.
  • Be intimidated.
  • Hesitate to advise the facility of changes

02.6.4 OUTPUTS

• List Of Validated Stakeholders By Type Or Interest
• Logframe Document
• Negotiated Expectations
• Definition Of “Success”
  • Business Success
  • Project Success
  • Contractor Success
  • Owner Success

02.6.5 REFERENCES & TEMPLATES

• UK Templates- http://www.gdrc.org/ngo/logical-fa.pdf
• Https://Www.Prince2.Com/Blog/How-Identify-Stakeholders
• https://hbr.org/2014/03/five-questions-to-identify-key-stakeholders
• Freeman, R Edward (N.D.) Http://Stakeholdertheory.Org/Team/R-Ed-Freeman/
• Government Of Serbia (2011) Guide To The Logical Framework Approach 2nd Edition Http://Www.Evropa.Gov.Rs/Evropa/Showdocument.Aspx?Type=Home&Id=525
• World Bank (N.D.) Logframe Handbook http://documents.worldbank.org/curated/en/783001468134383368/The-logfra…
• Http://Www.Bakermckenzie.Com/Files/Uploads/Documents/Supporting%20your%20business/Featured%20services/Bk_Internationalnegotiations_Negotiationtechniques6.Pdf
• Bourne L.M., Stakeholder Theory. https://www.academia.edu/17233261/Project_Stakeholder_Management_and_St…
• White Paper: The Functions Of Governance: https://mosaicprojects.com.au/WhitePapers/WP1096_Six_Functions_Governan…
• Bourne L.M. Making Projects Work: Effective Stakeholder And Communication Management, Crc Press, Taylor And Francis Group, Boca Raton, Fl, Usa Bourne L.M. The Three Types Of Stakeholder Communication. https://mosaicprojects.com.au/Mag_Articles/SA1020_Three_types_stakehold…

GPCCAR Module M02-6, Revision 1.02