The Handbook of Integrated Business and Project Management, Volume 1. Fundamental Concepts, Structure and Methodologies

By Ali Jaafari

Hundreds of billions of dollars are lost globally each year due to project and program failures in virtually all fields. Continued project failures, setbacks and losses have prompted me to question the adequacy of the current concepts, models and practices of project and program management, and to explore opportunities for change. In my view the contemporary approaches do not adequately address the real challenges of planning and delivery of projects and programs of significant size. Evidence from numerous field studies shows that projects and programs continue to underperform, or fail with massive losses and disillusioned clients and sponsors. Clearly, a fresh perspective and approach is needed to ensure that projects will deliver the outcomes that the stakeholders aspire to. For this to realise, it is imperative that client and sponsor organisations adopt a new mindset, and a vastly different approach to management of projects and programs. It is incumbent upon all client bodies to exercise a hands-on proactive approach, ensure that they understand complexities, and invest in creating the requisite capabilities for planning and management of their projects and programs.

I have written this book, together with Volume 2, in a style that can assist both scholars and practitioners to adopt and tailor the contents to suit their needs. My main motivation is to promote a more strategic and integrative approach to planning and delivery of projects and programs of significant size. I have attempted to bring together the key elements of knowledge related to project business and project management, and present these in a consistent and coherent framework, coupled with the relevant processes needed for their practical application. The integrated business and project management (IBPM) approach embodies a fresh perspective, frameworks, processes and tools for strategic planning, development and management of projects and programs of significant size.

• Language: English
• Publisher: Lulu.com
• Release date: Jan 5, 2023
• ISBN: 9781471734069

Book preview

CHAPTER 1. DEFINITIONS AND BASIC CONCEPTS

Introduction

Despite more than 65 years of development, project management is still poorly understood and applied (Abbasi & Jaafari, 2018; Wideman, 2004). Recent studies of projects across the globe demonstrate many instances of project failure, particularly in terms of project outcomes (Berssaneti & Carvalho, 2015; Robertson & Williams, 2006; Sage, Dainty, & Brookes, 2014; Shenhar & Dvir, 2007; Terrill, Emslie, & Moran, 2020). Repeated project failures indicate that the current concepts of project management do not represent project management realities on the ground. It is easy to blame the actors, be it designers or contractors or vendors, but the root cause lies elsewhere (Al-Ahmad, et al., 2009; Pinto & Mantel, 1990). Projects by nature are dynamic systems subject to uncertainty and change, yet most theories of project management assume projects as defined and organised endeavours, and see the execution phase as the main challenge (Artto, Kulvik, Poskela, & Turkulainen, 2011; Hensman, Valenta, & Jaafari, 2004; Ingason & Jónasson, 2009; Jaafari, 2004). Such theories have formed the foundation concepts of project management, and are embedded in the education and training of practitioners (Crawford, Morris, Thomas, & Winter, 2006; PMI, 2017).

Ideally, a study of project failures should guide the formation of the theories and concepts that can improve future cycles of project undertakings. However, the majority of studies tend to focus on the effects experienced during the implementation phase, rather than seek to uncover the root causes of failure (Hughes, Dwivedi, Simintiras, & Rana, 2016; Pinto & Mantel, 1990; Al-Ahmad, et al., 2009). The following observations provide some insight into the common causes of project failures:

Projects often start with good intentions but end up with less than desirable outcomes.

Many projects are created to achieve internal efficiencies, or expand capacity to respond to a dynamic market, but most end up missing the target date, allowing competitors to move in and seize the opportunity (Simonsson, Johnson, & Ekstedt, 2010).

Many projects suffer conflict, and need lengthy and often difficult negotiations to rescue. One plausible reason is insufficient strategic planning and rushed implementation.

Generally speaking, unresolved design and technical issues tend to surface during the execution phase and cause substantial disruption to the project implementation process, leading to cost and time overrun and disappointed clients (Al-Ahmad, et al., 2009; Hughes, Dwivedi, Simintiras, & Rana, 2016).

On many projects the linkage to original strategic goals or needs and requirements is gradually lost, as the management’s efforts have to be spent on sorting out the immediate delivery issues (Hughes, Dwivedi, Simintiras, & Rana, 2016).

In large complex projects market dynamics change, or champions move on before the project completion, creating conditions for conflicts among stakeholders.

Many projects are expressions of faith with a less than clear business case (Pan, Hackney, & Pan, 2008; Standing, Guilfoyle, Lin, & Love, 2006).

As noted from the above, there is an urgent need for changing the foundation concepts of project management. In particular, the project management profession needs to own, integrate and manage both downstream and upstream phases of projects, and deliver solutions that are fit for purpose and meet the stated objectives. This book is intended to provide a framework and a body of knowledge to facilitate a shift to a more holistic planning and management of projects of significant size (Jaafari, 2010).

There is a vast amount of literature on project management, and most recently program and portfolio management. The intention is not to add another textbook to the already rich collection of scholarly papers, textbooks, standards and other sources of knowledge. Rather, this book seeks to present a unique framework and a fresh perspective for project and program management that is integrative and strategy-focused. It encapsulates the author’s 40 years of research, experience and insights in this field.

For too long project management has been commonly interpreted as a set of activities, executed by a contractor to deliver a defined scope of work to a defined schedule and quality requirements, in a rather stable and predictable environment. While this understanding may assist a contractor to fulfil their contractual obligations in small to medium-sized undertakings, it does not necessarily focus on business or social needs, or the broader strategic objectives that prompt sponsor organisations to invest in projects in the first instance; nor does it reflect adequately the impacts that a project may have on its environment.

Despite the plethora of publications in this field, the author sees a need for redefining project management in order to shift the focus from the traditional delivery objectives to the higher level objectives of financial, performance and environment. Emphasis on the environmental and ecological footprint has assumed a new urgency given the climate change risks, and the global efforts to reduce emissions (Das, K., & Emuze, 2015; Kaatz, Root, & Bowen, 2005). The author’s adopted framework comprises the following components:

A set of objectives that represent the project’s end value and its fitness for purpose, used to guide the decision-making and optimisation efforts, and acting as criteria for performance assessment over the project life;

An integrated project lifecycle architecture, embodying both the front-end business and strategic phases, and the downstream delivery phases; and

A set of functions (enablers) to plan and deliver projects from creation to definition, design, procurement, execution, commissioning and start-up, in a holistic manner.

While elements of the above approach are covered in the literature, or applied in isolated cases, there does not exist a coherent model, underpinned by a body of knowledge, to assist both scholars and industry practitioners to anchor their approaches without limiting their freedom.

Portfolio, Program and Projects

Projects of significant size are often planned and managed as stand-alone endeavours with direct linkage to the sponsor organisation’s strategy (Figure 1-1). Typically, such projects are found in the construction and infrastructure, mining, energy, defence, IT/IS and aerospace fields. Aside from the sponsor organisation’s strategy and aspirations, these projects must ultimately satisfy the greater business and/or social needs and stakeholders’ requirements.

Small to medium size projects can be undertaken as individual endeavours, particularly in cases where the sponsor organisation does not undertake projects regularly, or projects are non-homogeneous and unrelated to one another. Small to medium size projects are frequently subsets of programs or portfolios, particularly in service organisations. Management of such projects is dependent on the parent program and portfolio goals and constraints. The relationships to the parent program and or portfolio imply that key decisions related to the project must be made at a higher level. Figure 1-2 shows simplified examples of projects constituting part of a portfolio or a program.

Many projects are conceptualised and initiated within fairly mature organisations for specific objectives, such as capacity building, or development of new product lines, or responding to technological or other innovations, or for regulatory compliance. In such organisations, projects must be conceptualised considering the entire business unit architecture, including mapping of the interrelationship to other departments or business functions within the organisation, particularly the operating arm. In contrast, major projects exhibit characteristics similar to programs, and often need to be approached individually. Project-based organisations fulfil their mission via projects.  An organisation may have a number of product/service lines that are designed and delivered to fulfil its mission/strategic goals, and it may comprise several portfolios (see Figure 1-3).

Fig. 1-1: A Simplified Example of a Project Managed as a Stand-alone Endeavour

A product portfolio is a major line of products designed to serve a segment of the market or a customer group. A project portfolio is a collection of related projects. Portfolio management’s chief function is to broadly define the goals of a particular line of products/projects, and use these to plan, stage and coordinate the respective programs or projects. In short, portfolio management aims to address the following questions: Which class of customers or market segment are we focused on? And how can we fulfil the organisation’s strategic objectives with respect to the said market/customers?

Fig. 1-2: Simplified Examples of Projects Managed as Part of a Program or Portfolio

Normally a portfolio relates to serving a particular market segment. A telecommunication company can define the mobile telephony services in a particular State or region as a single portfolio. The company can adopt a target for market share in that State or region. Capturing the market share may require higher standards of service, which in turn may necessitate fresh investment in upgrading or replacing the company’s mobile telephony assets. In order to achieve the target market, the company needs to define and differentiate the standard and features of their service to win or maintain their market share. It is imperative that the project succeeds in delivery the target features and services or the company may not succeed in capturing the target market share.

In the example shown in Figure 1-3, there are 3 portfolios, designated as A, B and C. Portfolio A has 2 programs, A1 and A2. Program A1 has 2 projects, A1.1 and A1.2. Program A2 has 2 projects, A2.1 and A2.2. Typically, portfolio management offices spend an insignificant amount of resources but have a critical influence on the business success. Their chief role is high level coordination of the constituent projects, programs and activities. In other words, portfolio management performs a strategic coordination role, and is thus part of the organisation’s strategic management function.

Fig. 1-3: Typical Relationship Between Portfolios, Programs and Projects in a Business Unit

A program is defined as a unit of organisation set up to manage the production and delivery of a definable part of one, or a number of portfolios of goods and services to customers, or end user groups. In the case of project-based programs, it is defined as a unit of organisation set up to manage the planning and realisation of a number of interrelated projects, with or without non-project activities. Programs may be unrelated to portfolios; they may be defined to include a number of projects and/or contain operations and activities in a functional form. The role of program management is to define the goals, mission, strategy, and the broad scope for coordination and integration of the related projects and activities. Thus, programs are units of organisations with defined goals and mission. An example is a regional transit program, set up to manage a number of interrelated projects, such as stations, tunnels, viaducts, rail and rolling stocks. Each project has a defined scope, and can only be of use when it is fully completed. The transit network may have a goal of providing fast transit for the residents in a region at an affordable cost, while also reducing traffic congestion on the road network, reducing carbon emissions and delivering other benefits. The goals can be wholly or partially satisfied. For example, a partially-completed transit network may be operated while the rest of the program is under construction.

A project is a temporary organisation set up to deliver a single large or a collection of interrelated products/services to satisfy specific needs, while also meeting the thresholds set for project objectives. Typically, a project delivers a unique set of outcomes (business case).  For example, constructing a major underground station in an urban area can be considered a project within the transit network. It will serve the local population to access the transit network. It cannot connect to the network unless it is fully completed, tested and commissioned.

A project is normally divided into a number of parts, and each part divided into a number of components. Each component has a defined scope and requires a number of work packages (WPs) to be realised. In an ideal situation, a team may be formed to deliver a specific part, with members drawn from different entities with complementary skills. In practice, this is not normally the case; the extent of cooperation among the entities contracted to deliver a project depends on the contractual arrangements entered into. In project-based approaches a contracted entity may deliver a single or a collection of deliverables.

A product/service is a defined deliverable from the family of products/services an organisation delivers to its customers. It aims to meet specific stakeholders’ needs and requirements. A cell tower, including electric communications equipment and antennae in a mobile telephony system, can be considered a product, as its function is to allow the surrounding area to use wireless communication devices, such as telephones and radios. As seen from Figure 1-3, projects within a portfolio or program are undertaken by an organisation either on behalf of its operating business units, or for external client organisations. Large projects, such as those in infrastructure, mining, aerospace and industrial sectors, are often complex, involving a coalition of organisations working over long periods to plan and promote in order to secure their finance and approval to implement. Planning and management of large complex projects transcend management of small to medium-sized projects, and require an integrated business and strategic project management framework. Typically, in such cases it is necessary to design and apply a unique governance and administrative framework within which the project can be crafted and delivered.

Basic Roles in Capital Projects

The key roles commonly referred to in projects are defined below:

A sponsor/owner is an individual or a business unit that sponsors and often funds the project. A department in a large organisation or a government agency may sponsor a project.

An investor is an individual or an organisation that provides equity capital to finance the project’s development and execution in the expectation of receiving capital growth and dividends from the project once it goes into operation. There are 2 types of investors: active and passive investors. Active investors participate in the planning, development and execution of the project in some form (e.g. as the sponsor). Passive investors provide equity capital but do not participate in the project planning and execution, though they may occupy a seat in the corporate board of the company that owns the project.

A client is an individual or an organisation unit that represents the sponsor/owner. It may be a different arm of the owner organisation or a hired company or a special entity set up to act as the client on multiple projects. Note that ‘client’ is a contractual and legal role. It is referred to as ‘Principal’ in some contracts.

A customer is an individual or an organisation who will often buy the project’s product. For example, consider a developer who builds a new hospital facility in a particular district. The customer can be a regional health authority or a private health provider who will occupy and operate the hospital once commissioned. The authority may secure the use of the asset under a leaseback deal or outright purchase or other arrangements. On some projects, the sponsor, client and customer are one and the same. In such cases the roles may conflict in the implementation phase.

A project manager is a person or a firm who manages the project on behalf of the client (or assists the client). Reference to project manager also includes the project management team. Individual entities participating in a project, have their own project managers to manage their side of the project. Reference to project manager in this book is to the entity that is assigned the responsibility for management of the project on behalf of the client. The project manager may be appointed to act as a client’s agent under a professional services agreement.

The project team is a group of professionals and/or entities contracted to deliver specific services to the project and/or take on the responsibility for the delivery of parts or the whole of the project scope. The project team works under the oversight of the client/PM team.

A contractor is an organisation who is engaged by the client to perform certain services or deliver all or a portion of the project scope. Contractors may be referred to as ‘performing organisations’. A subcontractor is an individual or an organisation that is engaged by a general contractor to perform a portion of the project under the administrative system set up by the contractor. A nominated subcontractor is an entity that is selected by the client to perform a specific task or deliver a part of the project under the administrative system set up by the contractor. Vendors and suppliers can be classed as contractors too if they engage with the project through a procurement and contracting mechanism.

A designer is a professional firm (or an individual) that enters into a professional services contract with the client, or the prime contractor to prepare one, or all of the following design deliverables: conceptual design, basic design, final design, specifications and supporting documents for tendering and/or execution of a project. Normally a multitude of designers are involved with different stages of the design, each specialising in a specific area, or discipline, such as architectural, civil, mechanical, electrical, hydraulic, fire, and so on.

Varying Perspectives

As noted from the review of basic roles, typically there are 5 groups of entities involved in the synthesis, planning and delivery of projects: (1) sponsor/owner/operator; (2) client/PM team; (3) designers, consultants and advisors; (4) contractors and subcontractors; and (5) suppliers/vendors. Each entity has its own perspective. For example, a sponsor/owner/ operator is interested in an asset that can respond to their strategy, business needs or mandates. A client body is interested in correct interpretation of the business and strategic requirements so that they can oversee the development and delivery of an optimum solution to satisfy the requirements. Designers aim to create a design that meets the design brief and creates a facility/asset that is fit for purpose. Contractors are generally interested in executing a scope assigned to them to the required standards and specifications. Suppliers and vendors are also interested in supplying the goods and materials to meet the design and specification requirements.

This book addresses project and program management primarily from the perspective of sponsors and clients. As a unique undertaking, staged in an environment of complexity and change, and subject to a multitude of disruptive forces, a project is exposed to numerous risks. Not all of these risks are explicitly recognised and managed by client bodies or their agents. Decades ago there was an expectation that there would be an order of magnitude improvement in project planning and delivery because of the adoption of QA standards by designers and contractors. This was not a realistic view. Although the adoption of QA standards helped contractors to improve quality of their services, the QA standards have had a limited effect in improving the overall picture, as designers and contractors come into the picture rather late, and when the die has already been cast. As stated, the front-end phases are critical. Projects are conceptualised, defined and strategically planned well before reaching the design and procurement stage. It is imperative that the sponsor and client organisations preside over the whole process to achieve the desired results. To perform their role optimally, they need to possess an array of managerial and technical capabilities to lead the project processes and shape the project outcomes.

The realisation that the sponsor, as the investor and promoter of a major project, has the highest stake in the project, and needs to put in place a system for its effective governance and leadership to guide the entire process, has come of late. Some government agencies and major corporations around the world have started to question overreliance on designers and contractors to achieve success in their projects. For example, the UK government established the Infrastructure and Projects Authority (IPA) on 1 January 2016 to ensure government agencies and public corporations have the necessary capabilities, and take the right approach to undertaking major infrastructure projects. IPA has been actively promoting agency capability acquisition and enhancement, as well as adoption of optimum project leadership and management practices as the key drivers to improving project outcomes.

Progressive Elaboration Process

As seen from Figure 1-4, projects are progressively defined and detailed through the project life cycle phases by applying capabilities tailored to the needs of each phase. Forward arrows linking phases indicate progressive elaboration of the project, as it moves across the project phases. Back arrows imply the recursive nature of project planning and decision-making, i.e. changes at lower levels have to be fed upwards, and be reflected in the original decisions and plans. Assessment of performance at each level is based on the respective goals or objectives. Goals and objectives are interrelated, as noted below:

Customers/end-users’ needs and requirements inform the business unit’s strategic goals and mission

That in turn shapes the portfolio goals and mission

The portfolio goals and mission influence the program goals

Where programs are not part of a portfolio, the program goals are derived from the sponsor organisation’s policy or strategy statement and aspirations 

The program goals influence the business case of each of its constituent projects

Project objectives can represent the sponsor organisation’s policies, standards and aspirations. For example, the sponsor organisation may require all its investments and projects to meet a minimum attractive rate of return.

Program goals and project objectives can be defined in terms of financial KPIs, performance KPIs and environmental KPIs.

Fig. 1-4: Schematic Representation of the Progressive Elaboration Process

Project Life Cycle

The project life cycle architecture adopted in this book comprises both upstream and downstream phases (Figure 1-5).

Fig. 1-5: Project Life Cycle Phases

Note that the policy phase and the operation phase are also included in Figure 1-5. While this diagram may convey a linear process, in practice project phases are often conducted in a dynamic and recursive manner (Figure 1-4). Project deliverables in upstream phases may need revision to reflect the final solutions adopted subsequently, or changes made during the design and execution phases. In some cases, project upstream phases (i.e. project creation and project definition) are conducted as part of the related portfolio and or program management functions, performed at the host or sponsor organisation, while downstream phases are performed via outsourcing or contracting. In the case of major projects, the project life cycle normally includes all upstream stages. Regardless of where the upstream phases are conducted, it is imperative to recognise the linkages and the interdependency of upstream and downstream phases, and to specifically take on board the cross impacts when making decisions or evaluating changes to the project under consideration.

It is of critical importance to have the business and strategic goals articulated and agreed upon at the outset, as all subsequent decisions will inevitably seek to maximise the chances of their attainment. Strategic goals are either derived from policy changes or from the goals of the parent portfolio or program. The needs and requirements can be distilled from the policy document or the parent program or portfolio. The deliverable of the project creation phase is a Project Brief that articulates the needs and requirements, threshold values set for project objectives, policies, governance and administrative framework and other key information. The main deliverable of the project definition/ development phase is the project business case/plan or project business solution. The outcome of the project implementation masterplanning phase is a high level implementation plan. In turn, the implementation masterplan is used to conduct the design and procurement phase, followed by the execution and commissioning phases.

Given the interdependencies of the project phases, conduct of each phase is critically dependent on the preceding phase’s deliverables. Should there be shortcuts or ambiguities or unresolved issues in terms of project deliverables or the interrelationships shown in Figure 1-5, there is a risk that these will surface during the execution phase, potentially causing major disruptions, and/or cost and time overruns.

It is critical that the project follows a structured process and does not skip any of the front-end phases. The project brief must spell out the needs and requirements that the project is supposed to satisfy, as well as the thresholds to meet and the policy and governance framework under which the project must be planned, orchestrated and executed. Based on a clearly defined project brief, the project must follow the sequence of phases shown in Figure 1-5 to ensure that the final facility/system delivered by the project, will be fit for purpose and can meet the respective thresholds set for financial, performance and environmental objectives.

There has been a tendency in the past to skip or shortcut project definition/development or implementation masterplanning phases, and to jump from the project brief to design and procurement phase, then proceed to the execution phase. This process is often advocated by some clients who wish to fast track the delivery of their projects. They normally issue a client brief to kick-start the design. More often than not, a client’s brief is no more than a wish list; it may also confuse the real ‘needs’ with ‘wants’. It is absolutely essential that projects undergo the necessary planning, appraisal and optimisation processes before proceeding to the design and implementation activities. Project life cycle phases will be further discussed in Chapter 2.

Project Success and Project Objectives

The author considers a project to be successful if the following criteria can be met (Jaafari, 2004):

The solution delivered by the project is fit for purpose (business case has been delivered);

The threshold values set for project objectives are met;

The project is set to deliver the target benefits to the broader stakeholders; and

The constraints faced in achieving the above outcomes have been overcome in a satisfactory manner.

Project objectives must reflect the business and strategic goals (Jaafari, 2004; Baccarini, 1999; ISO 21500, 2012) and include:

Financial objectives relate to the underlying value of the project to the sponsor organisation or investors, using the familiar quantitative measures, such as the project’s net present value (NPV) or equity internal rate of return (EIRR).

Performance objectives relate to operability, functionality, sustainability, competitiveness and capacity to meet the regulatory requirements (generally the capacity to meet the KPIs set for performance requirements in the operation and repurposing phases).

Environmental objectives relate to the project’s impacts on the environment over its life cycle, including ecological effects, economic impacts, social costs and social benefits, and so on.   

An organisation will normally specify a number of key performance indicators (KPIs) and the associated thresholds, to assess the attractiveness of potential investment ventures. Financial objectives set for a project must exceed the threshold values for the organisation to invest in that project. Financial objectives can also be derived from the parent program/portfolio’s financial KPIs. In the case of public sector projects, the treasury normally specifies the hurdle (minimum acceptable) rate of return, or the minimum benefit/cost ratio that all project proposals must meet for finance consideration.

Performance objectives and their thresholds are derived from the operational and regulatory requirements. Environmental objectives are extracted from organisational policies, as well as the respective planning and environmental laws, considering ecological, socio-economic, political and other factors. Typically, major sponsor organisations have a set of environmental standards that must be met by all projects.

Project objectives must have targets (thresholds) to enable performance assessment. They must sit high above the usual execution control parameters in order to represent the project value. All project downstream and execution decisions must be evaluated in terms of their impacts on project objectives and the project’s capacity to deliver the business case.  Project management processes should facilitate the delivery of the business case and achievement of the aforementioned objectives.

Project Objectives vs. Contractor’s Objectives

From a project or client perspective, time and cost are considered constraints, not objectives. Generally speaking, traditional project objectives, such as scope, time, cost and quality, are relevant to the scope of a contract undertaken by a contractor. These may not represent the project’s end value directly. A project may enter into multiple contracts, each with a defined scope and requirements and differing priorities. The delivery process should be orchestrated in a manner that maximises the project’s end value. In the post-war reconstruction era, the focus in project management tended to be on the fast completion of projects in an effort to meet the reconstruction priorities. Under such constrained conditions perhaps it was appropriate to consider time and cost as the main objectives. Times and projects’ raison d'être have changed since then. Scope, time, cost, quality and stakeholder management are functions that will assist in the realisation of the business case and attainment of the project objectives. Thus, these functions can be viewed as tools or enablers, rather than constituting an objective function by themselves. Other things being equal, a project needs to manage its stakeholders to the extent needed to achieve a successful outcome.

Project Success vs. Project Management Success

The published literature has references to project success separately from project management success. Baccarini (1999) states: "project success consists of two components-product success and project management success. Product success deals with goal and purpose; project management success deals with outputs and inputs" (Baccarini, 1999).  This implies that it is possible to have an unsuccessful project while judging that its management has been successful. The author considers such a separation unhelpful and somewhat contradictory. This is because the success of management of a project must relate to the business case it delivers. Project management excellence for its own sake is not a valid concept.

An argument often advanced is that a project may actually be planned and executed well (project management excellence) while the original project solution or business case may have been poorly formulated, and hence despite excellence of its management, it may lead to project product failure, i.e. the project may fail to deliver its business case (PMI, 2017). The author argues that it is a false premise to call this a project management success.

The main function of project management is to deliver a solution that is fit for purpose while meeting or exceeding the thresholds values set for project objectives. As stated, the author considers project management success in terms of the project business case and the respective high level project objectives. In short, project success requires not only selecting the right opportunity, but also focusing the project efforts on the front-end (strategic) phases to define and lock in value, and to optimise and integrate project decisions. These will provide a solid basis for the success of the project execution too. Other things being equal, a well-defined project has a much higher chance of execution success than the one rushed to execution. Note that the front end phases include project implementation masterplanning, which aims to structure and guide the execution process.

As outlined by De Wit (1988): "good project management can contribute towards project success but is unlikely to be able to prevent failure. The most appropriate criteria for success are the project objectives. The degree to which these objectives have been met determines the success or failure of a project. The criteria for success of the project management effort tends to be restricted to cost, time and quality performance. When measuring project success, one must consider the objectives of all stakeholders throughout the project life cycle and at all levels in the management hierarchy. Therefore, to believe that, with such a multitude of objectives, one can objectively measure the success of a project is somewhat an illusion" (De Wit, 1988).

While there has been a gradual realisation that project success criteria transcend the traditional scope, time, cost and quality, the literature is still unclear on what criteria should be used for project success. "Project success is a multidimensional construct that includes both the short-term project management success efficiency and the longer-term achievement of desired results from the project, that is, effectiveness and impact (Judgev et al., 2001; Shenhar et al., 1997)" (Joslin & Müller, 2015).

The Enablers and Performance Targets

Project success is influenced by numerous factors, both individually and in combination. Generally speaking, many of these factors are beyond the project team’s control (Al-Ahmad, et al., 2009; Liu, Wang, & Chua, 2015). Availability of materials and other resources, legal, commercial, cultural and physical context/environments are among the factors that cannot be controlled by the client/PM team, or the wider project team. However, the client/PM team can establish or acquire the required capabilities and influence the state of practice, which can contribute to the project success.

It is self-evident that large complex projects require substantial quantities of input resources, whose availability is not always guaranteed. In particular, the project may require a large number of skilled workers and technical experts, that may be difficult to source in certain localities. Thus, and unless the provision of resources can be guaranteed, the client/PM team needs to consider the key resource constraints early, and put in place measures to ensure that the required resources will be available down the track. For example, timely completion of a large process plant is critically dependent on the availability of a large number of qualified and certified welders, which might not be readily available in a remote location.

As stated, project teams do not have the power to control the host country’s legal, commercial, cultural and physical environments. However, the client/PM team is able to factor in all such influences in the respective project decisions and plans. This narrative explains why projects are unique, and why there is no one best way of defining, documenting and delivering projects. Each project needs careful crafting to be in alignment with its environment, and to deliver a fit for purpose solution, while meeting the threshold values set for the respective project objectives (Aviram-Unger, Zwikael, & Restubog, 2013; Pellegrinelli, Partington, Hemingway, Mohdzain, & Shah, 2007; Jaafari, 2004).

Generally speaking, the enabling factors are within the client/PM team’s control, though constrained by the specified governance or administrative framework. In the case of public sector projects, the administrative and regulatory framework may limit the client/PM team’s ability to build an optimum level of capability, or select a delivery method that matches the perceived challenges and complexities. As it is known, public sector projects are subject to mandated procurement and contracting processes. Decision-making on such projects may be slow due to the complex administrative and regulatory processes.

The client/PM team must ensure that the required capability to manage a given function or project area is in place, and that it is applied effectively in a timely manner. On most projects a number of functions are critical and need to be resourced well. Such functions are assigned higher performance targets compared to the less critical functions. The higher the performance target set for management of a function, the more resources will be needed to plan and manage that function. Performance targets set for management of project functions should not be confused with project objectives. Since managerial and technical resources are limited, setting a high target for one function may divert the resources away from other significant functions. Setting performance targets requires experience and insights to figure out which function is the most critical and what level of performance is needed to achieve a successful outcome (Koutsikouri, Austin, & Dainty, 2008; Jaafari, 2007).

Project Planning and Delivery Framework

Figure I-2 shows the project planning and management framework developed by the author. In generic terms, it consists of 17 core functions, comprising 69 variables, that need to be planned and managed over the 6 phases of the project life cycle in order to define, develop and deliver a viable outcome, and achieve the project objectives.

The approach to management of a function can vary from project to project, depending on the project characteristics and context. This is fine so long as the approach applied reflects managerial principles or key success factors. Examples of managerial principles include customer focus, leadership, people engagement, process approach, continuous improvement, evidence-based decision-making and relationship management (ISO 9000, 2015). It is important to note that these principles or key success factors are generally effective in the Western cultures. They need intelligent adjustment to be suitable for application in other cultures.  Additional key success factors, cognisant of the local cultures, may be necessary in certain circumstances. Professional judgement plays a key role in determining what constitutes an effective set of principles or KSFs in each case.

As stated, experience and intuition are applied initially to determine the capability level required to manage a given function. The client/PM team must make a decision in each case as to the criticality of a given function to the project success, assign a performance target to it, and then establish or hire the required resources. As an illustration, if a project is being executed in a remote area, far from the nearest population centres, the capability to manage interactions with the local populations is not a critical function. The decision as to which functions or project areas require a higher capability level compared to the rest, is critical to the project success. Functional criticality may also change with time, depending on the actual project dynamics on the ground, as well as external influences. A feedback loop can be established to review functional criticality in each review cycle, and reorientate the resources as necessary. This needs to be done on a continuous basis.

Activities related to the planning and management of all significant functions need to be planned, coordinated and executed concurrently. In addition, project management activities should be aligned with the main project design and execution activities over the project lifespan. To achieve a high degree of integration one needs to apply appropriate tools. For example, a product breakdown structure (PBS) can be used as the core structure for the integration of deliverables that form the project solution. A corresponding work breakdown structure (WBS) can be used to define and integrate the work packages (or efforts) needed to deliver the project. A web-enabled database can be deployed to store the project information in a format that supports both the product breakdown and the associated work efforts at individual component or element level, and so on.

Project Planning and Delivery Process

Figure 1-6 illustrates the project planning and delivery process schematically. Project capabilities (enablers) are applied to create the project artefacts, and use these as reference documents to progressively implement the project over its life cycle phases, and deliver the planned outcomes (Davies & Brady, 2000; Zerjav, Edkins, & Davies, 2018). The client/PM team sits at the apex of project governance, and presides over the whole process. They are guided by the project brief. As part of their first action, they need to engage a task force (project team) to undertake project definition studies and recommend a preferred solution, and a suggested project planning and delivery architecture, considering the client or sponsor’s specific administrative/governance policies and framework (Paolillo, Olson, & Straub, 2016).

The project definition studies may highlight the perceived critical functions, and the range of capabilities required to plan and deliver the project successfully. Based on the project business case/plan, the client/PM team plans and progressively establishes the required project capabilities (enablers). Such capabilities, which are normally secured through outsourcing, are mobilised to orchestrate the implementation of the solution, encompassing detailed design and documentation, procurement, execution, commissioning, hand-over and close-out. Other things being equal, the stronger the project capabilities (enablers), the higher are the chances of the project success. However, the relationship between the enablers and the outcomes is not linear. What is an optimum capability to define and deliver a given project function? No hard and fast rule exists to guide the decision maker as to what constitutes an optimum capability other than experience and intuition, supplemented by feedback obtained from regular performance reviews and adjustments over the project life.

Fig. 1-6: Schematic Representation of Project Planning and Delivery Process

The traditional approaches to performance assessment use scope, time, cost and quality as means of performance assessment. As stated, project scope, time, cost and quality are not absolute measures of project value or success. Note that a project may be brought online in time and within budget, but it may fail in terms of meeting the respective business and strategic requirements. Also, the capital invested in a project is intended to generate returns and deliver benefits. As an illustration, consider a project that with an extra investment of 5% can generate an additional 20% net return. Whether the additional outlay is a good investment depends on the value of the additional net return compared to the additional investment. If the additional investment in this case meets the minimum required EIRR value, and other things being equal, it is justified to go ahead and make the additional investment, unless faced with financial constraints.

Project Performance Assessment

As noted from Figure 1-6, project performance assessment should address 3 areas: (a) project worth/outcomes performance; (b) project management performance; and (c) project execution performance. It is self-evident that all 3 assessment areas are interrelated.

Project Worth/Outcomes Performance Assessment

Assessing the project worth (actual or projected value) must relate to the utility and optimality of the delivered facility or system in meeting the sponsor’s strategy, business goals and requirements, considering the delivery constraints. Project objectives are the ultimate criteria for assessing the outcomes or worth of a project. Figure 1-7 is a schematic representation of the decision process, showing the framework, variable type and information sources, as well as transformation functions.

Fig. 1-7: Holistic Project Outcomes Evaluation and Optimisation Framework

It is important to ensure that the threshold values set for objectives are realistic and achievable. Notwithstanding that, there is merit in setting stretched targets to encourage project teams to search for breakthrough solutions. The art of project/program management is the application of creativity to derive solutions that can meet multiple criteria, and produce exceptional outcomes. Though past achievements are a good starting point, the aim should be to push back the boundaries, and achieve enhanced results with new ideas, cutting edge technologies, smart strategies and innovative solutions.

Financial targets include minimum values for the project net present value or equity internal rate of return or benefit-cost ratio, and so on. Typically, project planning and delivery is subject to meeting a number of constraints, particularly schedule and budgetary constraints. So financial targets must be set accordingly, and the project decisions and options evaluated against these throughout its life. Figure 1-7 is a schematic representation of the decision process, showing the framework, variable type and information sources, as well as transformation functions.

Operational and environmental performance targets are reflected in two measures: Overall Satisfaction (an index from 0 to 5); and Benefit Points (expressed as % points of the project NPV). Overall satisfaction is a function representing stakeholders’ satisfaction (excluding project financial participants), quality, operability, functionality, sustainability, and capacity to meet the regulatory requirements (generally the capacity to meet the KPIs set for performance requirements in the operation and repurposing phases). Environmental variables embrace impacts on the natural environment, i.e. impacts on the flora and fauna, emissions, carbon footprint, effluent discharge and waste generation, and so on. Each variable is evaluated via a set of indicators using an index from 0 (the lowest satisfaction) to 5 (the highest satisfaction).

Then, all variables are combined, applying preference weightings to estimate the overall satisfaction (OS). The OS is a composite index that measures how well a given solution will deliver a commercially successful result while it satisfies the end users, external stakeholders and the host community needs, and meets legal and statutory requirements. Many parameters in this set are fuzzy variables, which are assessed using a qualitative approach, and an appropriate set of descriptors. 

Benefit points capture those benefits that the project will deliver to the end users and stakeholders, excluding the projected cash flow of the project, which is the domain of project financial assessment. Social and environmental costs (other than sponsor’s outlays) offset social benefits. Not all benefits or social costs are amenable to quantification in monetary terms. Nevertheless, one must attempt to include all those which can be expressed in terms of % of the project NPV. For example, a new road link brings benefits to motorists and the wider community, while also imposes social cost on some. It is possible to assign monetary value to the road users’ trip times saved due to faster connection, as well as reduction in accidents and wear and tear to vehicles. It is harder to measure the civic benefits of a new road link. Figure 1-7 shows the process for the evaluation of project worth. As noted, it uses the triple objectives as the criteria for evaluation and comparison of alternative options.

Fig 1-8. Schematic Representation of a System to Compute Project Worth

To measure the value of a decision or option, it is ideal to have a single decision measure to characterise the project worth. It will require applying a multi-criteria and preference modelling technique. The optimum state corresponds to the highest project worth (not necessarily the highest EIRR financially). Balanced Scorecard (BSC), developed by Kaplan and Norton, can be used within a multi-criteria decision-making framework for this purpose (Kaplan & Norton, 2007).

The process starts by assigning threshold values for financial KPIs, overall satisfaction (OS) and benefit points (BP). The worth of any solution is then progressively evaluated using the triple criteria approach. To apply the holistic approach and estimate the project worth, one needs to set up a computing system for the project under consideration (Figure 1-8). The system is then run to evaluate the worth of each alternative. Design changes, or substitute parts or components, can also be evaluated by estimating and comparting the project worth against each alternative.

To highlight the importance of holistic evaluation of changes, consider the scenario that a contractor in a large project comes forward with a design variation that has the potential to cut the delivery timescale by 30%, but requires an additional 10% capital investment. Shall the client accept such a proposal?  This is a major variation. It should be evaluated by applying the above triple criteria. Assume that the revised design has the same OS and BP values, then it comes down to the financials alone to decide whether to accept or reject the proposal. Saving 30% of the delivery time has the potential for the project to earn revenue, or perform the required service much earlier.

In addition, finance costs will be reduced due to the shortened duration. These, and other potential savings and benefits are estimated and entered into the above system. Cost increases are also estimated and entered into the same system. The revised project worth will show if the contractor’s proposal should be accepted. If it is a public project, and other things being equal, the net savings from the changes must be equal to, or exceed the extra costs for it to be an attractive proposal.

Project Management Performance Assessment

Project management performance assessment (project health check) seeks to establish: (a) whether the capabilities assigned and mobilised to manage project functions meet the respective performance targets; and (b) whether the method applied to perform the individual project functions is optimum. A project health check can be conducted at any point during the implementation phases to see how each function performs.

There are 17 core functions to assess (Figure I-2). As stated, it is important to allocate resources to those functions that have the highest impact on the project delivery performance and outcomes. Performance in each function can be compared to the assigned target, and action taken to address the underperforming areas. It is a continuous process. The conduct of each cycle of assessment will provide fresh insights and clues in terms of how the project is behaving as a dynamic system, and which of the functions (enablers) have the most influence on the project management performance (Jaafari, 2007; Crawford, 2006; Davies & Brady, 2016).

Performance can be plotted against time to observe trends, and to check if past interventions to improve performance have been effective. The results can also be correlated with the project execution performance. Naturally, there should be a cause and effect relationship, i.e. an additional investment in capabilities and improvement in the state of practice should lead to a corresponding improvement in the execution performance. However, there is a lag between the intervention time, and the time the corresponding effect is observed. Chapter 18 (Volume 2) covers project health check in more detail, see also Jaafari (2007) for the fundamentals underpinning project health check.

Project Execution Performance Assessment

Project execution performance assessment seeks to track the actual work completed against the plan. This type of performance assessment has historically used the CPM and PERT methods to check the activities completed up to the data date and those in progress, and compare these to the schedule. The PM team can update the schedule to estimate the projected completion date, and determine delays. Project progress monitoring is not sufficient as the