Understanding Project Management: Skills and Insights For Successful Project Delivery

Projects in an Ideal World

01 An Introduction to Projects and Project Management

• Learning Outcomes

  • Gain insights into characterizing projects and project management.

  • Reflect on initial considerations of the project manager's role.

  • Explain the relationship between project management and risk management.

  • Evaluate and reflect upon risk in project management.

  • Explain project processes and lifecycles.

  • Reflect on inherent complexity and the fundamental role of stakeholders.

• Introduction

  • This book addresses both clearly identifiable projects and equivocal scenarios that could benefit from a project management approach.

  • Clarity of definition is less crucial than meeting objectives and delivering successfully.

  • The terms "managing projects" and "project managers" are widely used in business and society.

  • The word "project" is used universally, sometimes with misplaced confidence (e.g., in reality entertainment shows).

  • Examples span from organizing a marketing promotion (reality show) to constructing a hydro-electric power station.

  • All these activities are considered projects, and those involved are either project managers or involved in project management.

• Projects – Initial Perspectives

  • Defining a Project:

    • Maylor (2003, quoting BS6079: 2000): "A unique set of co-ordinated activities, with definite starting and finishing points, undertaken by an individual or organization to meet specific performance objectives within defined schedule, cost and performance parameters."

    • Association for Project Management (APM) (2012): "A unique, transient endeavour undertaken to achieve planned objectives."

    • Project Management Institute (PMI) (2013): "… it’s a temporary group activity designed to produce a unique product, service or result," noting that "a project team often includes people who don’t usually work together – sometimes from different organizations and across multiple geographies."

  • Evolution of Definitions: Recent definitions emphasize a more holistic understanding, moving beyond detailed formulations.

  • Scenarios as Projects (Table 1.1):

    • A language training company introducing an e-learning platform.

    • A company improving material handling efficiency.

    • A proposed partnership between two media production companies.

    • A hotel introducing a new customer loyalty programme.

    • The construction of a new healthcare facility.

  • All listed examples are considered projects due to their "new-ness" or non-routine nature, sometimes involving cross-organizational teams.

  • Maylor's (2003, 2010) Model of Project Characterization (Figure 1.1): Projects are characterized by relationships between volume and variety.

    • Low Variety, High Volume: e.g., preparation of fast-food meals (few fillings, high sales).

    • Extremely Low Volume, High Variety: e.g., exploration of planet Mars.

    • Middle Ground: e.g., "paint-by-numbers" housing construction, or event management (regular but with variations).

    • Between these: Activities delivered once, needing similar but different execution (e.g., multi-venue entertainment tour).

  • Terminology for Project Types: Throughout the book, projects are characterized as "Paint-by-numbers", "As… but", and "First-timer".

    • "Paint-by-numbers": higher commonality in process and outcome.

    • "As… but": similar but different from previous projects.

    • "First-timers": done for the first time.

  • Language Challenge: The term "paint-by-numbers" can be challenging for non-native English speakers, highlighting a broader issue in this vocational area.

• The Project Manager and Project Management

  • Ambiguity in Project Manager Definition: What is a "project manager" can be ambiguous, as a project considered "first-timer" by one individual may not be by another.

  • Some businesses organize their activities with a project management philosophy by default.

  • Classifying the Project Manager: An individual responsible for an activity fitting one of the project definitions.

    • May have an official "project manager" title and role definition.

    • May be an "accidental project manager" – undertaking a task unaware of its underlying project nature.

  • Definition of Project Management: The set of activities associated with the fulfillment of a project.

    • PMI (2013): "application of knowledge, skills and techniques to execute projects effectively and efficiently."

• Project Management is Risk Management

  • Risk and Uncertainty:

    • Risk often provokes negative reactions (danger, possibility of loss or injury).

    • Uncertainty relates to doubt.

    • Both can have positive or negative connotations.

  • Prevalence of Risk Management: Applied extensively in various fields (e.g., educational visits, travel, power generation, food production) due to safety concerns and reputation threat.

  • Societal Expectation: Increasing expectation that all experiences should be incident-free, sometimes attributing blame when problems occur.

  • Relationship between Certainty and Risk (Figure 1.2):

    • Certainty can range from $0\%$ to $100\%$.

    • Lower certainty correlates with higher risk likelihood.

    • Higher certainty correlates with lower risk likelihood.

  • Projects and Risk: Projects inherently involve a degree of "new-ness," leading to uncertainty and thus risk.

  • Learning Point: Risk is ever-present in projects, so project management is equivalent to risk management.

  • Therefore, managing projects involves managing risks, and this perspective must be maintained throughout the project lifecycle and beyond, where associated risk considerations are carried forward (e.g., knowledge from a visitor attraction project informs safe operation).

  • Risk should be an "as normal" part of project management, not an isolated concept, to anticipate problems rather than react.

  • To manage risks, thinking needs to extend beyond initial definitions to identification, assessment, and consequence analysis.

  • Risk Identification:

    • Sources of Risk: Internal and external.

    • Framing: From stakeholder landscape or other relevant perspectives.

    • Example Risk Areas (for small-scale energy-generating project): Environmental, Legislative, Technology, Contractual, Financial.

    • Means of Identification: Varies based on experience and analytical techniques (e.g., encouraging the team to "worry").

    • Assessing Level of Risk: Consider likelihood and impact.

      • Often difficult to determine with accuracy, especially for subjective risks (e.g., poor team performance).

      • Assign numbers from a scale (e.g., 1 to 5) when numerical probability is lacking.

      • Consequence Calculation: $\text{Consequence} = \text{Impact} \times \text{Likelihood}$ (Table 1.3 provides an example).

      • This analysis can also prioritize risks.

    • Learning Point: It may be difficult to identify all project risks, especially at early stages. Regularly revisit risk identification.

  • Response to Risk:

    • Options (Table 1.4): Transfer, avoid, reduce, include a contingency, accept.

      • Transfer the risk: Insure against it, utilize subcontractors.

      • Avoid the risk: Do it a different way.

      • Reduce the risk: Change one or more aspects.

      • Include a contingency: Add a buffer (time or money).

      • Accept it: Do nothing.

    • Dynamic Management: The process should be dynamic, intelligently interpreting information to understand reputational risk.

    • Reputational risk is a key consideration for any organization.

• Project Processes

  • Visualization: A new project can be likened to "uncharted waters" – a journey to an unknown place (Figure 1.3).

  • ICOM Model (Input–Constraint–Output–Mechanism) (Gardiner, 2005; Maylor, 2010): Helps characterize projects.

    • Mechanisms:

      • People: bring capability, knowledge, experience, motivation, character.

      • Techniques/Tools: important, but may not be available initially or transferred from previous projects.

      • Equipment: requirement depends on project type.

      • Organization: means of organizing varies with context (private-sector vs. public-sector multi-party).

    • Constraints: Focus on key project management components, setting emphasis and priority (Figure 1.4).

      • Time, Cost, Quality: often called "triple constraints," are immediate focus areas.

      • Legal, Ethical, Environmental Factors: may not be fully known at the outset (e.g., contract type, environmental impact).

      • Logic, Activation Sequence, Indirect Effects: understood better during planning or delivery.

  • Case Study: Hafod Eryri (Snowdon Summit Building)

    • Context: Building on Snowdon, highest mountain in Wales; bilingual society (Welsh and English).

    • Challenges: Engineering, environment, climate (-20°C to +30°C, up to 240km/h winds, 508cm annual rainfall).

    • Protracted Process: Involved stakeholders, risk, financing, vision, creativity, perseverance, ingenuity, and extensive planning.

    • Funding: £8.3m from SNPA, Welsh Assembly, EU structural funds, Snowdon Mountain Railway.

    • Logistics: All materials/labour transported by narrow-gauge Snowdon Mountain Railway (commercial conflict as train couldn't carry fee-paying customers).

    • Construction: Limited working area at summit, requiring innovation (e.g., twice-assembled steel framework – rehearsed off-site).

    • Delays: Heavy snowfall in April 2008 delayed completion to September 2008.

    • Stakeholders: SNPA (Snowdonia National Park Authority) concerned about balancing conservation (a) and public enjoyment (b) statutory purposes.

    • Extensive consultation took place; critics became advocates (e.g., media involvement in naming contest: Hafod Eryri).

    • Completion: Handover on 12 June 2009, seen as a "triumph of vision, perseverance and effective project management."

    • Case Reflection: Evaluate characterization in terms of stakeholders, management style, risk profile, key stages/phases, construction complexities, and "feel-good" aspects.

• Projects and Lifecycles

  • Project Boundaries: Every project has a start and an end point (fulfilment of objectives, resource depletion, time-event related, or abandonment).

  • Lifecycle Models: Projects typically go through phases (e.g., four phases: conceptual, planning, execution, termination).

    • Hybrid models may be needed to adapt to diverse circumstances.

    • Example (Figure 1.5, Town and Country Planning Association): Guide for community energy projects in the UK, showing 10 distinct phases (Stage 1: Objective setting, to Stage 10: Delivery).

    • This also demonstrates that risk profile changes over the lifecycle, with increasing investment leading to decreasing risk.

  • Ideal vs. Real World:

    • Ideal: Pre-ordained sequence of activities (e.g., feasibility early on) for new, similar projects. Unambiguous multi-stage approach.

    • Reality: Projects encountered in varied circumstances (e.g., unexpected events like natural disasters).

      • Entry point may not be the "start" (e.g., reviewing an almost completed project, given a project to execute, evaluating an initial idea, or recommending a project stops).

      • Roles vary even if all are called "project managers."

    • Problem: Project concept not universally understood, project not well-defined, project manager lacking full control.

    • Difficulty: Many projects "do not come in a box" – undefined, ambiguous, no clear instructions or stages.

• Projects and Gates

  • Gated Processes: Projects may not follow a full lifecycle; they must pass through sequence of "gates." (e.g., funding approval after feasibility study, redesign after initial analysis).

  • Example (Figure 1.6: Drug Development and Approval Gates): Illustrates fall in potential pharmaceutical products at each stage, highlighting considerable effort/expenditure before market.

    • Project lifespan can be elongated compared to other sectors.

  • Gate Outcomes: "proceed", "stop", "redesign", "recycle."

  • Management Implications: Need to manage "stop/go/maybe" nature of feasibility/business case processes carefully.

• Projects: Ingredients and Early Insights

  • Ingredients: Empirical components of a project process, which become "building blocks." (e.g., for conceptual stage, then context-specific challenges).

  • **"Algebra of Project Management": ** (Input, Constraints, Mechanisms) become building blocks for complex projects.

  • Successful Project Outcome: Successful project outcome = function (Input, Constraints, Mechanisms)

    • Emphasizes dependence on ingredients (input, constraints, mechanisms), but precise composition/emphasis is unknown.

    • Analogy: novice chef visualizing final dish without knowing precise ingredients, quantities, timing.

  • Experience helps determine input aspects and management of constraints/mechanisms.

  • Early Insights:

    • Bodies of Knowledge (BoK): Complete set of concepts, terms, activities in a professional domain (APM, 2012).

      • International organizations (e.g., PMI) support understanding, provide standards, credentials, professional development.

    • Project vs. Programme: At this stage, programme is a collection of one or more formally/informally connected projects, or projects plus other organizational/project-like activities. Definition will be refined later.

• Projects are Complex; Stakeholders; Change

  • Complexity: Projects are inherently complex activities.

    • Definitions of "complex" (Oxford English Dictionary, 6th edn, 2007, Table 1.5):

      • "Consisting of many different and connected parts; not easy to analyse or understand."

      • Mathematics: "denoting or involving numbers or quantities containing both a real and an imaginary part" (apt for projects exceeding budget).

    • Understanding Complexity: Helps adopt appropriate management approach for the scale of the challenge (e.g., public-sector multi-partner projects with ambiguity).

    • No universal model to derive complexity; often expressed as a component of technical risk (Nicholas and Steyn, 2012), or through technical-organization-environment framework (Bosch-Rekveldt et al, 2011).

    • Project complexity is a key variable affecting risk management (Thamhain, 2013).

    • Research lacks consensus on project complexity (Chronéer and Bergquist, 2012).

    • Importance: Complexity is inherent, justifying sufficient analysis, formality where appropriate, and understanding budget "real and imaginary parts."

  • Stakeholders: Fundamental component of any project.

    • No stakeholders, no project (they request, finance, benefit from, are annoyed by, or deliver it).

    • Many stakeholder groups are outside direct project management control, often underestimated.

    • Stakeholder Envelope (Figure 1.7): Project sits within a stakeholder envelope; "who’s in charge here?"

    • Definition: Groups or individuals who affect or are affected by the project (Freeman, Harrison and Wicks, 2007).

    • Managing stakeholders is crucial to project success, even if seen as "non-business activities."

    • Classification: "internal" or "external" (Freeman, 2010), "primary" or "secondary" (Cleland and Ireland, 2002), "organizational" (Mullins, 2010), "economic, socio-political and technological" (Johnson, Scholes and Whittington, 2008).

    • Importance: Vital to undertake analysis and implement mechanisms throughout the project life.

    • Stakeholder perspective may extend well beyond initial project timeframe (e.g., nuclear reactor decommissioning, long-term health impact of products).

    • Revised Success Formula: Successful project = function (Stakeholder, Successful project outcome)

  • Change:

    • Projects often originate from a desire to change something (improve processes, penetrate markets).

    • Change is a key theme, impossible to undertake a project without causing it.

    • Relationship with project management is similar to risk management (unwelcome change can stop a project).

    • Change needs to be managed within the project (Chapter 4), can be unexpected (Chapter 6), and is a focus of leadership (Chapter 12).

• Summary

  • Introduced projects, project management, and the project manager role.

  • Explored underlying models: project lifecycle, process, complexity.

  • Discussed risk and stakeholders as persistently important aspects, with approaches for management.

  • Encouraged reflection on the gap between ideal and real project management, and anticipating the unexpected.

  • Provided an introduction to the world of projects.

02 Projects at the Conceptual Phase

• Learning Outcomes

  • Explain the notion of the conceptual phase of a project.

  • Explore the role of feasibility and business case.

  • Reflect on initial drivers of project requirements.

  • Evaluate and reflect upon the role of stakeholders during this phase.

  • Approach this phase by asking fundamental questions.

  • Reflect upon the inherent assumptions and constraints.

• Introduction

  • Chapter 1 introduced general project concepts and project management, including the project lifecycle, which, despite imperfections, is a useful basis for understanding.

  • The conceptual phase is the first pre-delivery phase.

  • Reflective and Critical Approach: Acknowledge that while ideal projects start at the conceptual phase, one's entry point to a project may be later in the lifecycle (e.g., inheriting a difficult situation, reapplying conceptual work).

  • This chapter will explore how projects originate, using terminology from project management literature and guides.

  • Artificial Segmentation: "Conceptual" phase is isolated for discussion, followed by "planning." In practice, phases often overlap.

• Conceptual Phase

  • Project Origin: Projects emerge from opportunities, problems, aspirations, or "my boss's idea."

  • All projects have a reason or rationale, sometimes from strategic planning processes requiring significant expenditure.

  • All projects are likely to cause some form of change.

  • Examples of Project Sources (Table 2.1):

    • New opportunity: new product/market development, response to political/technological change.

    • Need to overcome a problem: obsolete building, inefficient system.

    • Response to change: government changes, recession, environmental standards, public perception, natural disasters.

    • New idea: combines characteristics of above, completely novel concept.

  • Ideal Project Stages (Figure 2.1): Idea, Feasibility, Business Case are early-stage activities within the Conceptual phase.

  • Variable Entry Points: Individuals may "join," "manage," or "lead" a project at Planning, Implementation, or Review stages. Sometimes, responsibility is taken in response to existing problems.

  • This challenges an ideal approach to learning about projects, as reality is often different.

• Entry Points

  • Entry Point: Idea

    • Developing and delivering the entire project from an initial idea (e.g., an entrepreneur).

    • Creativity: Some projects require high levels of creativity initially, which formal management processes might inhibit (Chapter 7 discusses this).

    • Output of creative phase often leads to the generation of ideas for feasibility/business case development.

    • Example (Higher Education Commercialization): Goal is successful business venture, offering project management support for business planning.

      • Problem: Brilliance of creative academic conflicts with rigidity required for formal financial analysis (P&L, cash-flow, balance sheet forecasts).

      • Requires particular behavioral style from project manager.

    • Strategic Coherence: Is strategy driving the project, or vice versa? Or both?

    • The "project parent" (organization, multi-organization, department, individual) provides vital support for the activity (Figure 2.2).

      • Learning Point: Without parent support, problems and potential project failure are likely.

  • Entry Point: Feasibility Evaluation

    • Formal management processes require feasibility analysis and business case.

    • Undertaking Feasibility: Organizations use various methods (e.g., analysis of possibility, practicality, viability; focus on problems, alternatives, costs/benefits).

    • Engenders confidence and assurance for the project parent/sponsor.

    • Gardiner's (2005) Framework for Feasibility Study:

      • Determine the problem.

      • Evaluate alternatives, potential, cost-effectiveness, feasibility.

      • Analyze technology requirements.

      • Assess capabilities.

      • Evaluate risk.

      • Undertake analysis of trade-off constraints.

      • Identify success factors.

      • Generate preliminary time/cost estimates.

    • Example (Severn Tidal Power Feasibility Study - BERR, 2008): Terms of reference focused on cost/benefit/impact, preferred project, regulatory requirements, and support basis.

      • Incorporated work in environmental, engineering/technical, economic, regional, planning/consents, stakeholder engagement areas.

    • Questions: Feasibility questions can lead to "STOP", "GO", or "MAYBE" outcomes, requiring further information or indicating unviability.

      • Sequence of questions may be sequential, parallel, or heuristic depending on emerging information.

  • Entry Point: Business Case Development

    • Often developed alongside feasibility analysis; precise form depends on context.

    • APM (2012) Definition: "a justification for undertaking a project or programme; it evaluates the benefit, cost and risk of alternative options and the rationale for the preferred solution."

    • Typical Content: Strategic case/fit/objectives, options appraisal, expected benefits/consequences, commercial aspects (costs/affordability/achievability), uncertainty and risk appraisal.

    • Used at key "gates" throughout the project (Chapter 1).

    • PMI (2013) Focus: Stronger link to feasibility study and subsequent project management authorization.

    • Continuous Questioning: "Is there a business case?" "Are benefits greater than costs?" (Benefits are often hard to predict/quantify, costs hard to quantify/predict).

    • Analytical Methods:

      • Example (Ice-cream retail business, Figures 2.3 & 2.4): Payback analysis and rate of return for three options.

        • Scenario 3 had shortest payback/highest return but highest start-up capital.

        • Limitation: Does not account for "time value of money."

      • Net Present Value (NPV): Used to factor in cost of capital, delaying breakeven point (Figure 2.4 shows scenario 2).

        • Effect varies with inflation/borrowing costs.

      • Learning Point Project managers should be familiar with terminology/principles, but specialist support may be needed.

      • Estimating costs/benefits can be very difficult (e.g., system implementation projects, mega-events).

    • Case Study: Changbin and Taichung Wind Project

      • Context: Two sites in Taiwan (62 wind turbines), providing 500 GWh electricity to Taipower. Taiwan imports 98% of fuel.

      • Key Driver: Renewable energy necessary for energy security.

      • Business Case: Developed with Voluntary Emission Reduction (VER) opportunities (carbon credits) as crucial for viability.

      • "Project Design Form" (Southpolecarbon.com) Areas: General description, baseline methodology, duration, monitoring, GHG emissions, environmental impacts, stakeholder comments.

      • Economic Viability: Without VER revenues, project was not attractive.

      • Alternatives: Doing nothing, doing without VERs, using alternative fuels (hydro, PV, biomass, fossil fuel).

      • Environmental Assessment: Covered physical, chemical, ecological, sociological, economic, tourism, culture aspects.

      • Public Hearings: Raised concerns about noise, sight (grid connection), "windbreak forest" trees, independent power provider, typhoon turbine stops. Responses were provided.

      • Timeline: Started 2000 (office in Taipei), bank finance Sep 2006 (project start date), construction Dec 2006/2007, production June/July 2007/2008.

      • Success Factors: Right geographic location (windy west coast), dedicated industrial park location (few residents), effective project development (e.g., working with carbon consultants).

      • Paradox: Need electricity but dislike generation (leading to stakeholder discontent for wind energy projects).

      • Case Reflection: Evaluate feasibility issues, business case aspects, stakeholder strategy, and the paradox of needing electricity but disliking its generation.

    • Iteration: Business cases/feasibility can be undertaken multiple times (e.g., HS2 rail project) due to revealed aspects (modifications, additional funding, flawed assumptions, changing technology).

    • Stakeholder Impact: Early-stage feasibility affected by stakeholder interaction, leading to lengthy consultation processes.

    • Universal Challenge: Stakeholder concerns are global.

    • Gated Processes (Chapter 1): No certainty of anticipated course; project might stop due to funding refusal or other evaluation outcomes.

    • Some projects start without formalized feasibility/business cases (e.g., due to individual personality, default management style), which can be problematic if weak project management, flawed concepts, or unconsidered stakeholders.

• Some Important Questions

  • Learning Point: "Prompts, not prescriptions" – these questions are a starting point.

  • Questions to Inform Framework Development:

    1. Who is asking for it? (client, customer, user, internal, external, parent)

    2. What do they want? (specification, scope, product, service, result)

    3. Why do they want it? (rationale, motivation, problems, strategic alignment)

    4. How much will it cost? (budget, upper limit, unknown)

    5. When do they want it? (deadline, agreed timeframe, open-ended)

  • Answering these informs framework development (e.g., "Project Charter" (PMI) or "Project Initiation Document" (PID)).

  • These documents are valuable for clarifying project scope, helping resolve emergent problems, and keeping stakeholders informed.

  • Four of five questions involve "who" or "they", emphasizing stakeholders.

  • The list is not exhaustive; active thinking is crucial. "Using your brain – the most important tool of a potentially successful project manager."

  • Who is asking for it?

    • Clarifies external/internal focus, commitment, motivation.

    • Breakdown: "whose expectation?" "who will have influence?"

    • Understanding Needed: Stakeholder identity, needs, expectations, interests, position, importance, predicted behavior.

    • This area is increasingly important in project management.

    • Stakeholder Oven (Figure 2.5): Project going through critical scrutiny.

    • Approach to Stakeholder Management: Identify, analyze, conclude, strategize, act, review.

      • Identify: Use classifications (internal/external, primary/secondary, organizational, economic/socio-political/technological).

      • Importance of knowing stakeholders.

      • Analyze: Understand impact (needs, wants, expectations, risks: uncertainty, likelihood, impact, consequence, response).

        • Power–Interest Grid (Figure 2.6, adapted from Ackermann and Eden, 2011): Plot stakeholders by power and interest.

          • "Crowd" (lowest priority, low power/interest).

          • "Subjects" (moderate priority, low power/high interest).

          • "Context setters" (moderate priority, high power/low interest).

          • "Players" (highest priority, high power/interest).

        • Movement of stakeholders within grid is as important as initial snapshot.

        • Example (UKIP rise): Political movements changing stakeholder positions and project environments.

        • Example (US tobacco industry): Smokers' power-interest position changed over decades.

      • Conclude: Draw together analysis; be prepared to repeat the process.

      • Stakeholder Strategy (Cleland and Ireland, 2002): Optimal, efficient, proportionate for value to project process and opportunity cost.

        • Collect information on capabilities/options.

        • Identify probable strategies.

        • Determine effects on project interests.

        • Continuously monitor and provide info.

        • Organize info for project team.

        • Learning Point: "Travelling to Ystradgynlais" – accidental bridge-building (informal relationship building) is invaluable for later project delivery.

      • Act: Implement strategy at a high level initially, with more detail later.

      • Review: Premature for conceptual phase, but forward-thinking helps; stakeholder groups' positions can change. Reputational risk is a key consideration.

  • Why do they want it?

    • Understand rationale and motivation, which can reveal problems.

    • "Why?" followed by "Why?" again to deepen understanding.

    • Opportunity for diagnostic support.

  • What do they want?

    • Crucial for initial project framing.

    • Ambiguity difficult for systems development, creative projects.

    • Scope: Identifying "what" requires defining scope (APM, 2012: "totality of the outputs, outcomes and benefits, and the work required to produce them"; Oxford English Dictionary: "extent of the area or subject matter that something deals with or to which it is relevant").

    • Establishing boundaries ensures delivery of requirements and avoids "grilling by the media" or "making a profit." `

    • Examples of "Out of Scope" Issues:

      • Academic researcher delivering D and E, not C (client wanted A, B, C).

      • Project manager working on X and Y, when document indicated X, Y, Z (Z was operational phase).

    • Experience/training sharpens focus on scope; contracts help mitigate ambiguity.

  • When do they want it?

    • Easy for events with known dates; others agreed with stakeholders, or depend on equipment availability.

    • For some, time is less emphasized or open-ended.

    • Project manager may provide input on feasible delivery time, which can be difficult.

  • How much will it cost?

    • May be unknown, with an upper limit given, or pre-agreed budget.

    • Project manager may need to work out costs and resources.

  • What assumptions will be needed? What constraints will there be?

    • Assumptions are inherent; specific constraints should be identified.

    • Risk Profile: Build early for the activity.

    • Example (Consultant responding to ITT): Brief/ambiguous ITT for 10–15 days' work makes effort estimation difficult, impacting profitability.

    • Consultant responds by evaluating risk, highlighting assumptions/constraints/scope in "small print."

• Summary

  • Examined activities in project conceptual phases: idea, feasibility, business case.

  • Identified fundamental questions (why, who, what, when, how).

  • Discussed important but challenging concepts like scope.

  • Stakeholders are a strong theme.

  • Acknowledged uncertainty in early phases, to be explored further in the planning phase.

  • Answers to questions form basis for project planning (e.g., project charter/initiation document).

  • Recognized that projects may start in different styles and early-stage instinctive aspects of project managers.

  • Next: planning aspects.

03 Planning Within Projects

• Learning Outcomes

  • Gain insights into planning within projects.

  • Explain the incorporation of stakeholder and risk themes in project planning.

  • Reflect on achieving clarity in detail and logic.

  • Discuss the value of breaking things down to manageable size.

  • Explain time, resource, cost, and quality planning in project environments.

  • Explore how to approach project management organization development.

• Introduction

  • Moving from conceptual to planning phase, assuming successful feasibility and business case work.

  • One's entry point into a project might be at this planning phase.

  • Planning is a beneficial activity where the project is "rehearsed in some detail."

  • However, planning can be superfluous or too rigid.

  • "Failing to plan is planning to fail" is a common adage, but experience informs optimal planning style and depth.

  • Approach may be determined by organizational setting (e.g., pro-forma templates).

  • Familiar tools: time-planning bar chart (Gantt chart), critical path, work breakdown structure (WBS).

  • Start by considering "who" (stakeholders) to develop planning and understand "project domain."

  • Each section builds on previous themes, incorporating risk and stakeholder as crucial for project success.

  • Reputational risk is highlighted for its strategic implications.

• Stakeholder Aspects

  • Challenge for Project Managers: Role and position of stakeholders, especially in multi-organizational projects where reporting structures might weaken the project manager's position.

  • Coordination is high even within single-organization projects.

  • Working with external parties (beyond organizational boundaries) significantly increases management challenge.

  • Planning Focus: Building on Chapter 2's stakeholder work, specifically on actualizing the stakeholder strategy.

    • Focus on understanding group behavior and its impact on the project.

    • Stakeholder Planning Focus (Table 3.1, adapted from Ackermann and Eden, 2011): Approaches based on stakeholder power/interest.

      • "Players" (high power, high interest): sustained management attention.

      • "Context setters" (high power, low interest): raise awareness, develop.

      • "Subjects" (low power, high interest): keep informed, sustain interest.

      • "Crowd" (low power, low interest): consider if management effort is worthwhile.

  • Continuous Monitoring: Factor in actions to continuously monitor changes in stakeholder position.

  • Proportionate effort is key; justified by risk from inappropriate engagement strategy.

• Specification – Being Clear About What is Required

  • If the "what" (scope) is unclear from the conceptual phase, definition work is needed.

  • Some projects primarily aim to develop "what" is required.

  • Examples (from Chapter 2):

    • Academic researcher: delivering C, D, E when client expected A, B, C. Highlights importance of agreed scope.

    • Construction project: clarification of scope (deliver X and Y, not Z) enabled accurate planning and avoided project manager accountability beyond control.

  • Learning Point: Project managers' instinctive character traits can create problems.

  • Recognizing scope as a risk during the planning phase is helpful.

  • Visualize the process: What needs to happen to deliver the final product?

• Breaking Things Down

  • Work Breakdown Structure (WBS): Breaking the "what" into smaller stages is crucial for planning.

    • If it can be broken down, do it. If not, understand why.

    • Helps visualize timing, resourcing, logic, and inconsistencies.

  • Method: Use whiteboards, sticky notes, digital tools.

  • Challenges: Some parts may be beyond current understanding, or prone to initial errors.

  • Outputs: Leads to milestone/bar charts and identification of required people/capabilities, informing project management organization (PMO).

  • Different people approach this differently (e.g., some start with time-planning, others with resourcing).

  • Key Questions: How long will it take? How much will it cost? Who will do what?

  • Example (Figure 3.1): Hierarchical diagram of activities, events, or milestones.

  • This is a starting point for further analysis of sequence and time.

• Time Planning

  • Task: Estimate project duration, or work backward from a deadline.

  • Challenge: Getting the logic right from the outset.

  • Time Estimation:

    • Prior Information: Use "analogous estimates" from similar projects (Table 3.2).

      • Problem: Past experience is not a guarantee for new activities.

      • Estimates are optimistic or pessimistic; aim for balance.

    • "First-timer" Projects: More onerous estimation process.

      • Options: ask colleagues, research, look for comparators, rehearse analytically.

      • Generate pessimistic/optimistic scenarios and calculate an unweighted average.

    • Personal Examples: Car-body trim replacement (optimistic estimate: 10 mins, actual: 50 mins); guitar repair (pessimistic estimate: "a while," actual: <5 mins). Both affected by lack of prior direct knowledge.

    • Distractions: Business environments often lead to flawed estimates.

    • Recipient's Perspective: Information becomes "reality stick" to "beat the project."

    • Table 3.3 shows estimation based on pessimistic/optimistic times.

    • Adding optimistic/pessimistic times provides a projected project duration range.

    • Problem: Initial analysis often assumes sequential activities, while some can be concurrent.

  • Diagrammatic Representation:

    • Network Diagram: Simplified representation of techniques like PERT (program evaluation review technique) and CPM (critical path analysis) (Morris, 1994).

    • Activity Box (Figure 3.2): Includes earliest start time (EST), latest start time (LST), event label.

    • Calculation (Figure 3.3):

      • Work left-to-right to determine earliest start/finish times.

      • Work right-to-left to determine latest start/finish times.

      • Critical Path: The sequence of activities with no "slack" (delay in an activity directly delays the project).

    • Discovery: Critical path might be hidden without formal analysis, especially with multiple activities.

    • Learning Point: "Critical path" and "slack" provide useful vocabulary.

    • Limitations: Relies on known activities, dependencies, sequence, and accurate duration estimates.

      • Estimates are likely to be wrong, invalidating analysis.

      • Use judgment for tool deployment.

  • Time-Planning Bar Chart (Gantt Chart):

    • Intuitive tool, once considered the entirety of project management.

    • Represents activities, expected durations, sequence (Figure 3.4).

    • Conventions: Milestones as diamonds.

    • Effectiveness: Good for communicating project shape, especially with limited activities and neat page layouts.

    • Drawbacks: Manual drawing/redrawing cumbersome; likely "wrong the moment it is drawn and presented" (things change).

    • Does not explicitly show critical path or resource requirements.

    • Example: Used to explain forthcoming activities to an academic commercialization team, improving informed perspective.

    • Software Tools (e.g., Microsoft Project™): Facilitate creation of Gantt charts, scheduling, resourcing, costing.

      • Powerful for modeling, but a tool, not an end in itself. Can be counterproductive if misused.

      • Learning Point: Skillful project managers integrate such tools with other activities to influence positive outcomes.

• Resource Planning

  • "Resource": Something needed to deliver a component or the whole project (person, equipment, expertise).

  • Identification: Identify as many resources as possible to estimate overall requirement and cost.

    • Unplanned key resources can emerge, especially in "first-timer" projects or with new technologies, creating significant cost and risk.

  • Examples:

    • Market research project (Figures 3.1-3.4): Market research organization (bought-in resource with associated cost).

    • Market research organization itself: Deploying staff, recruiting external resources, with associated staff/hire costs.

    • Undertaking market research in-house: May "save some cost" but lead to difficulty without prior knowledge/specialist systems.

  • People as Resources: May be recruited directly or drawn from existing staff.

    • Risks: Degree of "devotion" to the project.

    • Costs include recruitment, salary, overheads, benefits, transport, accommodation.

    • Challenge: Tracking existing staff time on projects (e.g., meaningful percentage from 5 or 7 days).

    • Vital for organization to account for costs and staff deployment (e.g., "staff utilization").

  • Outline Content: Understand activities required for stage completion; may need specialist input outside the organization.

  • Case Study: Hosting the Olympic Games

    • Context: Mega-events demonstrate ambition but incur massive costs and generate negative public reactions.

    • Sydney 2000: Costs rose, ticket sales slow, sponsor funding gaps (Haynes, 2001). Economic assessment later showed negative effect ($2.1 \text{ billion}$ present value loss) (Giesecke and Madden, 2007).

    • Athens 2004: Concerns about readiness (Sunday Times, 2004) due to delays (general election, snow, firm bankruptcy). Cost was 5% of 2003 Greek GDP ($800$ per inhabitant) (Economist, 2004).

    • London 2012: Initial £3.4bn budget rose to £9.3bn by 2007 (Economist, 2008). Beijing Games ($20 \text{ billion}$) focused on credit-worthiness (Bloomberg, 2008).

    • Success Criteria (Economist, 2010): Money, time, legacy utilization. London had further budget overspend warnings (BBC, 2011).

    • Economic Impact (Lloyds Banking and Oxford Economics, 2012): £16bn contribution to GDP over 12 years (70% prior/during, 30% legacy).

    • Outcome: London Games deemed successful, boosting economy by £9.9bn (BBC, 2013).

    • Sochi 2014: £31bn cost (BBC, 2014) led Norway to refuse 2022 bid, leaving Almaty/Beijing.

    • Shift in Power: Economic power shifting from west to east is reflected in mega-event hosting.

    • Challenge: Building business cases that reflect all factors. Planning essential.

    • Case Reflection: Evaluate feasibility, business case, planning impact, confidence in planning, and national reputation risk for mega-event projects.

• Cost Planning

  • Translate resource planning into initial cost estimation, then aggregate into a project budget.

  • Serves as a basis for managing cost aspects (Figure 3.5).

  • Five Areas of Cost: people, equipment, specialist knowledge/delivery expertise, other items/services, unidentified/unknown items.

  • Cost Estimation:

    • People (Item 1): Ambiguous. Costs include recruitment, salary, national insurance, pension, vehicle/travel, accommodation, other overheads (often missed by inexperienced PM).

      • Existing Staff: Difficult to estimate cost, track time (e.g., "staff utilization").

      • Creates "its own project" to track.

      • Vital for organizations to account for staff deployment.

    • Equipment (Item 2): Less unpredictable than people. Categories: personal kit, transport, specialist kit.

      • Effective WBS beneficial (e.g., for large-scale energy projects informing procurement).

    • Specialist Knowledge/Delivery Expertise (Item 3): Difficult to specify. Organizations (e.g., Welsh Development Agency) commonly procure external support (consultants, subcontractors).

      • Programme might comprise strategy, delivery, review, operational activities.

    • Other Item/Services (Item 4): Insurance, premises, logistics, subcontractor costs, cost of capital depreciation.

  • Establish Project Budget:

    • Top-down budgeting: Budget set at strategic level, project must operate within it (e.g., government-funded research).

      • Planning is more constrained, potentially requiring compromises on other constraints (e.g., high-quality emergency system with high cost constraint leads to conflict).

    • Unidentified/Unknown Items (Item 5): Expect this. Provision for with contingency/resource in budgeting.

      • Example (London 7/7 bombings and Olympic security): Security costs doubled from £282m to £553m due to perceived increased likelihood of disruption (Guardian, 2012).

    • Limitations: Forecasting and analysis have limits; expect the unexpected.

    • Negotiation skills are vital for adequate budget and project goals; projects also need limits.

  • Procurement and Contracts: Some Basics

    • Procurement Approach: Developed once project purpose/objectives are clear, informed by feasibility/business case.

    • Contractual Arrangement: Client pays for services from suppliers/contractors.

    • Mulcahy's (2001) Six Stages of Procurement:

      1. Procurement planning: Rationale, preparatory work.

      2. Solicitation planning: Develop scope of work, evaluation criteria, terms/conditions (ITT, RFT, RFQ).

      3. Solicitation: Clarification, tender/bid submission.

      4. Source selection: Bid evaluation, interviews, negotiation.

      5. Contract administration: Work begins after signing contract; formalized project management.

      6. Contract close-out: Work completed, approved final payments.

    • Challenges for Project Managers: Knowledge of process, time management, buy-in, scope importance, facilitation, relationships, schedule issues, good practice, formality.

    • Learning Point: Project managers often face simultaneous pressure to do things right and quickly, especially when contract activity is on the critical path.

• Quality Planning

  • Concept: More difficult to elaborate than time/cost planning.

  • Varies by Project: Flood defense (engineering parameters), conference (service provision), visitor center (both).

  • Two Aspects:

    • Conformance: Specific stated requirements to conform to.

    • Performance: Delivering to stakeholder expectations (often not clearly defined, requiring project manager clarification).

  • Most projects have a combination of both.

  • Influential Publications:

    • Garvin (1987): Eight dimensions of product quality (Performance, Conformance, Features, Reliability, Durability, Serviceability, Aesthetics, Perceived Quality).

    • Berry, Parasuraman and Zeithaml (1990): Service quality perspective, identifying quality as the gap between service expectation and perception (Tangibles, Reliability, Responsiveness, Competence, Courtesy, Credibility, Security, Access, Communication, Understanding the Customer).

  • Importance for Project Managers: Vital to understand stakeholder expectations and translate them into a project specification.

    • Regularly revisit throughout the project lifecycle.

    • Can involve awkward discussions.

  • Technology advances may distort customer expectations.

  • Ultimately, projects are delivered in a non-ideal world with unclear/unrealistic expectations.

• Project Management Organization

  • Development: How project management will be organized (roles, expertise, structure) evolves over project life.

  • Challenging to visualize without prior experience.

  • Roles and Responsibilities:

    • Roles for direct delivery, and supporting organization/administration/management of activities.

    • "RACI" Chart (Larson and Larson, 2007) (Figure 3.6): Responsibility, Accountability, Consult, Inform (extended to include stakeholder relationships, leadership, dependencies).

    • Core questions: Is a project manager role needed? Whole or fractional? Separate administration? Who will lead/manage/support?

    • "Accidental Project Manager": Staff member becomes manager of activity after leading it, thus identified as PM.

    • Formal PM Assignment: PM assigned from strategic requirement.

    • Need the right roles, but team shouldn't be unnecessarily large. One person may fulfill multiple roles in small organizations.

  • Project Management Structures:

    • Dedicated Project Structure (Figure 3.7): Established solely for project delivery, common in project-centric organizations. High project focus and priority.

    • Matrix Management: Staff have line responsibilities and project responsibilities.

      • Lightweight matrix: Conflicting objectives, varying project commitment, challenges for PM.

      • Heavyweight matrix: Staff "seconded" to project, similar to dedicated structure due to congruent objectives.

    • Generic Project Management Organization Structure (Figure 3.8): Clusters roles: Project Board (strategic), Project Management Team (delivery), and formalizes major stakeholder groups.

      • Ensures strategic direction, handles budget/time problems.

      • Scalability for small organizations (merging roles).

      • Technical advisory group, quality assurance (QA) role.

      • Global Projects: Many teams are not co-located, involve multiple geographies/cultures.

• Planning: Some General Aspects

  • Time and cost planning are easier to formulate but difficult to estimate with confidence; unknowns become known over time.

  • Two Key Problems: Estimation challenge, psychological aspect.

  • Estimation Methods (APM, 2012):

    • Comparative or analogous: Based on similar scenarios.

    • Parametric: Using measurable attributes (e.g., bricks for houses, lumber for circular verandas – latter presents challenges).

    • Bottom-up: Analytical, from detailed activities.

  • Parametric is valuable for data from similar work.

• Summary

  • Explored typical planning approaches: stakeholder integration, clarity in detail/logic, breaking down tasks.

  • Addressed time, resource, cost, and quality planning.

  • Included project management organization as a key planning area.

  • Transition from "ideal" to "real world" perspectives.

  • Next: challenges in project delivery.

04 After the Planning: Delivering Projects

• Learning Outcomes

  • Reflect on challenges of converting project plans into delivery.

  • Determine appropriate stakeholder engagement in this phase.

  • Discuss impact of specification and scope change.

  • Reflect on time and resource management challenges.

  • Explain key aspects of cost and budget management.

  • Develop initial perspectives on managing in the project organization.

• Introduction

  • Moving from conceptual/planning to delivery, "ideal project" notions can quickly evaporate.

  • Delivery phase tests prior planning efficacy: sometimes as expected, often different/challenging.

  • "First-timer" projects: Highest uncertainty, frequent revision/re-planning needed during delivery.

  • "As-but" projects: More informed planning, more predictable delivery.

  • "Paint-by-numbers" projects: Better insight, delivery feels more like plan conversion.

  • Cultural Aspect: Some Asia-Pacific cultures emphasize thorough planning for smooth delivery (Zhang, Zuo and Zillante, 2013 on construction project managers).

  • Project type impacts divergence from prior planning.

  • Some aspects (team functioning, resource deployment, control, problem emergence) can only be "rehearsed" during delivery.

  • This chapter integrates conceptual/planning topics with delivery dynamics, using examples.

  • For some, this is their entry point, bringing other challenges.

• Delivering: More Than Plan Conversion

  • Delivering to the Plan:

    • Expected for successful planning; answer is "yes and no."

    • Depends on quality/flexibility of planning, and project context/type.

    • "Paint-by-numbers" projects yield higher confidence.

    • "As-but" projects require higher planning effort.

    • "First-timer" projects: highest uncertainty, high challenge.

    • Stakeholder element: (e.g., new pay system) behavior can be unpredictable, difficult to model.

      • Analogy: playing chess, next few moves planned, but subsequent moves depend on opponent's reaction.

    • Aim for sufficient planning to avoid surprises.

    • Extreme examples of rapid construction (house in record time, hotel in 48 hours) involve well-rehearsed, understood activities, with everyone knowing their part and executing it.

      • These might fall outside core project definitions.

  • Using the Plan as a Basis:

    • Acknowledge that delivery phase requires ongoing development work.

    • Iterative style, changes to specification can be normal.

    • Consequences include impact on time, cost, quality objectives due to scope changes.

    • Learning Point: Project management involves managing change.

  • Delivering without Conspicuous Planning Techniques:

    • Extreme variation: no obvious prior planning initially seems to "lead to failure."

    • Apparent lack "is sometimes mistaken for a lack of planning, when in fact considerable informal forethought and analysis have been undertaken."

    • Distinguish between good and inappropriate planning (superfluous/unnecessary).

    • Example (legal sector): Historically "eschewed" dedicated project managers, now embracing notion (The Lawyer, 2014); good underlying PM is business-as-normal.

• Working with Stakeholders

  • Stakeholders are an important and strategic part of the project (Chapters 1, 2).

  • At delivery stage, it's a "business-as-normal element" of project management.

  • Activities:

    • Review preparatory work as basis for ongoing management.

    • Work with groups appropriately and effectively.

    • Acknowledge that stakeholder may own the project.

    • Incorporate stakeholder management in all other appropriate PM areas.

• Delivering to Specification

  • Chapter 2 emphasized "what" is required; ambiguity in scope/specification leads to costs/delays.

  • "First-timer" projects inherently have specification/scope uncertainty.

  • Delivery phase fully explicates the specification; deviations from original scope determine time spent on changes.

  • Dealing with What? Specification, Scope, and Quality:

    • Specification becomes clearer, unknowns become knowns, putting pressure on scope.

    • Example (systems development): Realization of requirements into an application may prompt users to suggest additional requirements.

    • Managing Expectations (and Scope): Or accept user requirement, potentially revising time and cost due to quality objective changes.

    • Analogy: "juggling" different elements under pressure.

    • Example (Conference Delivery): "Paint-by-numbers" project, but unexpected airport terminal problems cause disruption (changed programme, affected quality).

      • Some may argue risk planning should have been better; often dealing with the unknown.

      • Project manager learns retrospectively.

    • Learning Point: "Change management is project management."

  • Change Management is Project Management:

    • Change is almost inevitable; sometimes central to delivery (e.g., new product/process).

    • Accepting change management is not a euphemism for wrong planning.

    • Change applies to all aspects of project process, and characterizes project impact.

    • Requires project managers to have skills and awareness for internal and external change.

    • Stakeholders are key to change aspects.

  • Sources of Change: Project team, client, external sources. Put stakeholders at center of framing.

    • Change Control Process (APM, 2012, Table 4.1): Five-stage process:

      1. Request: Stakeholder provides info; data recorded.

      2. Review: Determine high-level impact; clarification/rejection.

      3. Assessment: Options evaluated; impacts estimated; recommendation.

      4. Decision: Communicated to team/P stakeholders.

      5. Implementation: Change implemented after plan updates.

    • Gardiner (2005) Plan Elements: Identify change, analyze effects, develop response strategy, communicate strategy and gain acceptance, revise plan and monitor effects.

    • Critical Thinking: Project driven by stakeholders, likely to have change. APM approach helps control process.

    • Contractual framework (Chapter 3) further strengthens change management.

    • Learning Point: Change can be welcomed or feared; impacts scope/profitability/stakeholder satisfaction. Gap between planning and delivery often wider than expected.

• Time and Schedule Management

  • From Planning into Delivery: Time introduced as a constraint (Chapter 1), then as a distinct/dependent aspect (Chapter 2).

  • WBS (Chapter 3) developed time into bar charts/network diagrams, introducing milestone and critical path.

  • Delivery phase presents dilemma: control to time plan, or address immediate issues (as time plan was likely "wrong" at completion).

  • Emphasis, Approach, and Style:

    • Emphasis (Figure 4.1): Depends on time's importance relative to other constraints (e.g., events with hard deadlines vs. meeting specification or budget focus).

      • Highest: Full control of time constraint, strong command/control, all milestones adhered to.

      • Mid-high: Based on planning, some flexibility, strong command/control, meet key stages/end-date.

      • Mid-low: Loosely based on planning, subordinate to other constraints, strong emphasis at certain stages.

      • Lowest: Time planning supports PM, not primary constraint over lifecycle.

    • Oscillation: Emphasis can shift over project life.

    • Style: Communicating/managing schedule depends on team experience/personality, stakeholder expectations.

      • Use dashboards, display boards (to generate urgency/competition).

      • Numerous platforms/suppliers for PMIS.

      • No one way; style varies.

  • Managing using Schedules and Milestones:

    • Schedule is a valuable management tool (e.g., time-planning bar chart).

    • Achieving milestones is a particularly effective way to monitor progress.

    • Andersen (2008) highlights milestones as building blocks; Gardiner (2005) notes their simplicity and value for less detailed plans.

    • Milestone activity is "100%" met or not.

  • Time Realities: Forecast and Actual:

    • Uncertainty in early stages leads to estimates; plans are often wrong.

    • Successful delivery involves flexibility, corrective actions, appropriate communication, and meeting requirements on time.

    • Forecast vs. actual terms apply to time too. Missed target times raise doubts about estimation/resource ability.

      • Psychological effect: may lead to changing management style, creating artificial deadlines.

  • Analysis, Variance, Response:

    • Routinely store data, use tools for analysis (e.g., search facilities for digital resources).

    • Core Areas of Concern:

      1. Value of analysis: Review milestone achievement, bar charts, network diagrams (slack, bringing things forward).

      2. Variance: Difference between progress made and expected progress.

      3. Response: Determined by level of difference.

    • Keep perspective, be pragmatic. Acknowledge errors to solve problems.

    • Quality of response to slippage is crucial.

    • Achievement of milestones has human dimension, not solely mechanistic.

• Resource Management

  • Planning, Management, Planning, Management: Chapter 1 introduced ICOM model mechanisms (people, tools, techniques, equipment) as resources.

  • Chapter 2 focused on establishing what resources required; Chapter 3 on resource planning from WBS.

  • Resource management occurs repeatedly during delivery as new info becomes available.

  • Resource Management is General Management:

    • Hitt, Black and Porter (2009) describe managing resources as a major part of a manager's job, ensuring efficient use and maximizing goal achievement.

    • Translates directly to project manager role, especially for tight timeframes/parent organization processes.

    • Example (government educational agency project): Project needs specialist skills, but standard recruitment leads to 3-month lead time, impacting 12-month delivery phase.

    • Four Important Areas:

      1. Efficiency: Crucial in project environments (resources have cost whether used or not).

      2. Maximization: Focus resources on project goals, which align with organizational goals.

         • Project parent should ensure staff are adequately trained/supported.

         • Procurement staff should be involved early.

      3. Resource portfolios: Knowledge and physical assets brought together/created for project, need management.

         • Ownership can be ambiguous.

         • Service Level Agreements (SLAs) or short-term contracts for outsourced resources (e.g., data centers).

      4. Allocation and coordination: Depends on project autonomy. Higher autonomy = greater focus/speed; lower autonomy = higher effort.

  • Case Study: JLR Evoque

    • Context: "Downsized, tarted-up reengineering of the SUV for the 21st century" (Financial Times, 2012). Jaguar Land Rover (JLR) transformed fortunes under Tata ownership (2008).

      • "Made in Britain. Saved in India. Craved in China." (Daily Mail, 2012) – Indian cash, Chinese demand.

      • Tata's enthusiasm preserved British management autonomy.

      • Ambitious five-year £1.75bn investment plan, with flexible working arrangements.

    • The Project: Complex development of new car based on an original, futuristic concept (MagBook, 2013).

      • Strong road-handling, off-road capability, lightweight materials (aluminum) with clever design (aerial/telematics in rear spoiler).

      • Single design choice for speed.

      • Extensive testing (hot deserts, race tracks, high-load towing, braking systems).

      • 500 people worked on development ("programme" for engineering, "portfolio" for parent organization).

    • Market: Success in international markets (China, Russia, Brazil) led to 24-hour production and trebling of staff at Halewood plant.

      • "Right product at the right time", favorable exchange rates, novelty factor ("anybody in China can have a Mercedes-Benz" - New York Times, 2012).

      • Tata "proved the sceptics wrong" (Daily Telegraph, 2013).

      • JLR reported record profits in 2014, with strong sales globally (BBC, 2014).

      • New projects needed to maintain high production levels.

    • Case Reflection: Evaluate project delivery in relation to brand impact, risks, change, opportunities. Key challenges in aspiration, stakeholders, resourcing, budget, management. People's roles (directing, managing, delivering, negotiating, inspiring).

• Cost and Budget Management

  • Importance: Project manager responsibility for effective financial management.

  • Challenges: Lack of experience/confidence, organizational rules/regulations, poorly estimated or inappropriate budgets.

  • Links to almost all other PM processes (e.g., changes in labor costs affecting production relocation requires financial and stakeholder management).

  • Keeping Cost Under Control:

    • Cost introduced as a constraint (Chapter 1).

    • "What is required?" "How much will it cost?" (Chapter 2) explored cost aspects.

    • Resource planning (Chapter 3) provides basis for cost estimation and budget.

    • Goal: maintain expenditure within stated limits. Used for monitoring, control, reporting.

    • Financing process underpins delivery (e.g., income from project generation or internal/external funding).

  • The Style and Format:

    • Varies by project type, context, organizational setting.

    • Small businesses may have higher autonomy than public-sector/externally funded projects.

    • Commonalities: Budgets, expenditure (and income for some), forecasts become actuals, analysis, variances, issues, responses. Individual and aggregate activities accounted for.

    • PM meets general management: vital processes for running any organization.

    • Organizational rules/audits need to be followed, reinforcing cost as a constraint.

  • Activities and Budgets:

    • Most work done in planning phase, but used as foundation for delivery phase.

    • May need revision of structure/content for monitoring, control, reporting.

  • Expenditure and Income:

    • Expenditure first to reflect psychological effect.

    • Projects always have expenditure; income varies (income-generating projects vs. internal/external funding).

    • Expenditure (costs) are most frequently monitored.

    • Project manager manages a cash-flow statement (effective for budgeting and reporting).

  • Forecast and Actual:

    • Early stages require estimates; aggregated estimates form forecasts.

    • Updating during delivery phase: estimates become actuals, clarify project cost.

    • Source of concern if original estimating process was ineffective.

  • Analysis and Variance:

    • Sufficient analysis is crucial to assess expenditure status (expected, acceptable, concerning).

    • Example (Table 4.2): Monthly/cumulative expenditure variance. Under/over-spend may or may not be a problem depending on information.

      • Rarely will forecasts equal actuals.

      • Spend may not be linear.

      • Under-spend can be good for cash-flow, bad if it delays work.

      • Avoid false conclusions.

    • Example (Figure 4.2): Progressive budget tracking shows contract sum vs. estimated outturn over project review meetings.

    • Responses to over- or under-spend need appropriate management (negotiation for funding, difficult decisions).

    • Invoice processing in specific timeframes is a subcontractor management function.

• The People Part: Delivering through the Structure and Team

  • What was envisaged and what emerged:

    • Project team may not exist in conceptual phase.

    • Planning establishes structure, roles, responsibilities.

    • Delivery phase tests robustness of intended structure (reflects people arrangement).

    • Inadequate functioning undermines early project work (adds to risks).

    • Key challenging elements: Structure, roles, relationships, teams, culture, language, ethics, gender (central to project success).

    • Uses Figure 4.3 (Generic Project Management Organization Structure) to explore topics.

  • A First View of the Impact of Structure during the Delivery Phase:

    • Figure 4.3 used as general model, tailored for scenarios; small projects merge board/team.

    • Problem: Project organizational structure vs. underlying parent/stakeholder organization structure.

    • "Two (or more) bosses" situation (Figure 4.4): Common in matrix approaches, creates conflicting priorities, unclear resolution.

      • Heavyweight matrix: Teams seconded, dedicated.

      • Lightweight matrix: Members participate but functional objectives remain primary, affecting motivation/participation.

    • Solving requires awareness of the problem. Busy people need to "step back."

    • Problem solving and decision making become crucial.

  • Roles and Responsibilities:

    • Defined in planning, but fully understood in delivery. Difference between forecast and actual.

    • Moves into human resource management and organizational behavior.

    • Project managers "wear more hats."

    • Difficulties: forecast-to-actual change, recruitment, personality, "two-bosses" problem.

    • Requires soft skills, emotional intelligence, understanding unique personalities, preferences, motivation, abilities.

  • It's a Team Game:

    • Project delivered by a team; performance is crucial.

    • Teams experience their own lifecycle if disbanding after project.

    • Requires building knowledge for successful projects.

    • Individual and collective human factors should not be underestimated.

    • Part Four will develop this area further.

• Summary

  • Examined challenges of moving from conceptual/planning to delivery.

  • Contrast between preparation and dynamic role: managing stakeholders, change, budget, time.

  • Project manager role is often at its most active during delivery.

  • Impacts meeting expectations, managing budgets, negotiating for more.

  • Developed initial perspectives on project management organization (PMO).

  • Project managers need wide skill-set, self-insight, understanding of team/project character.

  • Continued exploration of linked themes in next chapter.

05 Managing to Completion

• Learning Outcomes

  • Recognize the need to manage actively throughout the delivery phase.

  • Reflect on managing risk and maintaining control.

  • Determine generic approaches to deal with questions, problems, and decision-making.

  • Explore approaches to achieve salience in project reporting and communicating.

  • Understand the emphasis in completing and closing projects.

  • Explain the need for effective handover and resource management during this phase.

• Introduction

  • This chapter continues exploring project delivery activities, complementing Chapter 4.

  • Focus on proactively managing risk, maintaining control, handling questions/problems, and making decisions.

  • Highlights the value of analysis for decision-making and examines project reporting to avoid information overload.

  • Concludes with activities towards/at completion, including handover and resource management challenges.

• Managing Actively

  • Offline vs. Online: Planning activities (conceptual/planning phases) can be passive; delivery phase is active, testing the plan.

  • Feasibility analyses mitigate some aspects, but full test comes during delivery as "unknowns become knowns."

  • Example (Engineering Refurbishment): Substantial analysis and planning (time charts, risk profiles) "rehearsed" the project.

  • Counter-Example (New Public Building): Emotional stakeholder reaction during conceptual phase is active.

  • Focus: Converting planning into action, unknowns into knowns.

  • Four Areas of Active Management:

    • Managing risk in the delivery phase.

    • Effective monitoring and control; reviewing.

    • The emergence of problems and the need for decisions.

    • Reporting; communicating.

  • Managing Risk in the Delivery Phase:

    • Risk is ever-present and endemic (Chapter 1), continuously reviewed as "business-as-normal."

    • Context: Organization and project type frame the approach (e.g., using a risk register).

    • Delivery phase actions will raise additional risks.

    • Importance: Review and update risk register, take appropriate actions efficiently and effectively (achieve salience).

  • Monitoring and Control:

    • Often seen as key to project success, but "if something is wrong in planning, monitoring won't fix it."

    • Crucial for measuring, monitoring, analyzing, and adjusting to maintain control.

    • Application: Apply to all parameters used for planning (e.g., milestones for conference event).

    • Balance: Project manager balances urge to control with team's need not to be over-managed; beware of inappropriate control style.

    • Analytical Methods:

      • APM (2012): Small projects use charts for actual vs. baseline progress. Large/complex projects use Earned Value Management (EVM).

      • EVM: Analytical techniques for specific environments (e.g., construction with clear delivery path).

      • Simplified EVM Example (Table 5.1): 10-month project (10 activities/month, $200$/item). At month 3, Planned Value (PV) = $6,000$. Actual Cost (AC) = $5,800$. Earned Value (EV) = $5,200$ (lower delivered activities).

        • Cost variance = $-\text{US}\$600$. Schedule variance = $-\text{US}\$800$.

      • Learning Point: "The value of analytical tools in appropriate project settings." Powerful when used correctly, but require analytical skills (may need specialist input).

  • Questions, Problems, Decisions, and Answers:

    • Project managers are asked many queries from wide sources; these are often interrelated.

    • Significant component of PM process.

    • Problem Solving and Decision Making: Distinguish actual problems from others.

    • Definitions:

      • Problem: "an unfavourable matter or situation to be resolved."

      • Decision: Resolution of a problem or response to a question (not necessarily unfavorable).

    • Impact of Decisions: Every decision has an impact, crucial to understand its cost/consequence (e.g., shoes vs. automobile).

    • Speed of Decision Making (Table 5.2): Scenarios require rapid to delayed responses (seconds, minutes, hours, days, weeks, years).

      • Urgency drives quick responses (e.g., life at risk, competitive scenarios).

      • Instinct is based on developed skills/experience (e.g., tennis player's volley).

      • Avoid mixing fast/slow decision scenarios (quick vs. right decision dilemma).

  • Approaching Decision Making:

    • Simon (1960): "Programmed" (repetitive, routine) vs. "non-programmed" (novel, unstructured, consequential) decisions.

      • "First-timer" projects likely create non-programmed decision conditions.

      • Correlates with uncertainty (Figure 5.1).

    • Problem-Solving Insights (Simon, 1960): "We are camping in the woods and decide we need a table."

      1. Identify the goal.

      2. Determine difference between present situation and goal.

      3. Find tool/approach to reduce difference.

      4. Apply it.

      5. Repeat until solved (consider consequences).

    • Analytical Tools: Decision trees, cause-effect-cause analysis.

      • Example (IT support cost discrepancy): Analysis of call-out records revealed 30% could be resolved locally, informing business case for new resource.

      • Often involves spending time to analyze existing data (intuitive analysis).

      • Project manager periodically takes on analyst role.

      • Cause-Effect-Cause Analysis (Table 5.3): Problem: unusually costly support contract due to high call-outs. Causes: specific timing, same technical problems, system administration. Effect: support contract used for system administration.

  • Reporting:

    • Key activity for providing information, historically for control.

    • Technology offers new delivery opportunities (e.g., project management information systems (PMIS) for auto-generated reports).

    • Integrity: Data integrity yields efficacy in reports, but transparency needs moderation (political factors).

    • Content: Progress against KPIs, issues (resourcing, budget, team, technical, contract), problems, decisions.

    • Reporting is not exclusive to delivery phase (e.g., risk reporting in earlier stages).

    • Storytelling: Factual but engaging for the audience (e.g., nuclear power facility communication).

    • Scope of Reporting: Potentially wide, including specification/scope changes, time, resource, cost management, PM organization structure issues.

    • General Insights (Table 5.4): Audience (internal/external, stakeholders, team), content (progress, issues), timing (key stages, scheduled, ad-hoc), style/format (defined, external standard, agreed, ad-hoc), medium (appropriate, efficient, effective).

    • Management by Exception: Alternative strategy to streamline info and improve efficiency by reporting only on deviations from normal.

    • Project Board Agenda Example (Table 5.5):

      • Review of minutes: Ensures accuracy, supports audit trail.

      • Standing items: Defined for project, reviewed regularly; focus on salience.

      • Management review: Optional, for wide range of items, external dependencies, status reports.

      • Ad-hoc reports: Specific to items requiring coverage (technical, procurement, resourcing).

      • Any other business: Controlled inclusion of additional items.

      • Date of next meeting.

    • Stakeholder Reporting: Vast potential. Informing vs. consulting. Adverse response requires re-evaluating stakeholder analysis.

    • Example (Reporting Distribution Routes, Figure 5.2): Almost 40 routes, became unmanageable, reinforcing need for management by exception.

    • Learning Point: "Overloading ourselves or project stakeholders with information may mean that important parts are missed (and not responded to); this presents a risk to the project. Seek to keep the balance right."

• Completion Challenges

  • Completion: Terminology: closure, termination, handover (e.g., for information systems project).

  • Can vary by project type (ballet tour vs. emergency control system).

  • Projects terminate for various reasons (e.g., objectives met, resource depletion, time-event, abandonment).

  • Perspectives of Completion (Figure 5.3): Based on core components: specification, quality, time, cost. Progress against each target (0%, 25%, 50%, 75%, 100%, >100%).

  • Learning Point: Realities have multiple dimensions of conceptualizing, planning, delivery, management.

  • Push to Finish: Natural behavior traits; create urgency, incentives, or penalties. Pushing prematurely increases risk of compromise/problems.

  • At the Completion Point, What Is Incomplete?

    • Stakeholder satisfaction crucial. Meeting deadline but not specification = unhappiness. Delivering late but meeting spec (with managed expectations) = happiness.

    • Extended Thinking (Figure 5.4): Original conceptual questions vs. defined project parameters.

    • Meeting specification, delivering late, exceeding budget = difficult to meet stakeholder expectations (unless stakeholder is deemed unimportant).

  • Case Study: The A400M Project

    • Context: In-development military transport aircraft (Airbus). Already 3 years late, $2.7 \text{ billion}$ over budget by April 2009 (Economist, 2009).

    • Concerns: Airbus underestimated complexity; highly sophisticated propulsion system management software for novel engine designs.

    • Specification particularly challenging; doubts about meeting performance goals ("whether indeed it would fly").

    • First Flight: Successful in Dec 2009 (Bloomberg, 2009); test fleet expanded (Globalsecurity.org, 2010).

    • Public Debut: June 2010 (Jane's Defence Weekly), described positively.

    • Key Certification: Passed in Sep 2011 ("most cost-efficient and versatile airlifter ever conceived"- Defencetalk.com).

    • Maiden Flight of Production Aircraft: Successful 5h 42m flight in March 2013 (Airbus.com).

    • First Delivery: French Air Force in Aug 2013 (Aviationweek.com), but critical capabilities (air-to-air refuelling) still under development.

    • Ongoing Issues: No determined list price, "unusual situation", highlights "difficulties with the extensively revised contract" (Aviation Week, 2014a).

      • Market opportunity: 1850 military airlifters worldwide are 30 years old.

      • Airbus CEO: "I am determined… not to ever again walk into such a program" (Aviation Week, 2014b).

      • Concerns about "too many national interests, too much overlap, too much waste" in European defense.

    • Success Judgment: Will it be a success if ultimately all operational objectives are met and it's an export success? (Similar to Concorde debate).

    • Case Reflection: Evaluate project management strategy (strengths/weaknesses), whether project should be stopped, recurrence of situation, and whether success in 2020 changes initial questions.

  • Handover:

    • Physical product: acceptance/transfer/commissioning from project to post-project environment.

    • End of project defined by final payment (contractual terms).

    • Retention in construction projects (amount withheld until works complete).

    • Operational Career: Project outcome may be start of long operational career; handover may require dedicated management process.

      • Specific responsibilities, awareness training (can be mini-projects).

      • Example (Systems Implementation Handover, Figure 5.5): Training program, stakeholder communication, in-operational-mode system support, quality management, data management, activity management, reporting systems.

  • Insights:

    • Knowledge increases towards completion; better insights into estimates, assumptions, risks, organization.

    • Can lead to realization of ability to do better if starting again.

    • Resource portfolio becomes clearer; decisions on hiring, skill-sets, infrastructure make sense.

    • Resource Management at Completion: Difficult to generalize approach.

      • Example (UCI Mountain Bike World Cup): Organizational staff, external contractors, non-contract resources, volunteers.

      • Resource portfolio effectively disbands post-event.

      • Motivation: If successful, resources look forward to next project due to satisfaction, reward, passion.

      • Different for less "passionate" projects (e.g., emergency control system, government service).

    • Resource has learned and developed insights from experience.

    • Lead to reviewing the project overall and learning lessons.

    • Learning Point: Ultimately, determining completion differs project by project.

• Summary

  • Examined challenges of managing projects to completion.

  • Highlighted dynamic nature of activities from conceptual/planning phases.

  • Project manager role is active in managing risk, control, decision-making, reporting.

  • Specific aspects of nearing completion: changed emphasis, greater retrospective awareness.

  • Next: "How did it go?" – reviewing and learning.

06 Reviewing and Learning in Projects

• Learning Outcomes

  • Consider learning opportunities from informal and formal review processes.

  • Explore differences between audits and reviews in project environments.

  • Reflect on the gap emerging between ideals and realities of project delivery.

  • Reflect on terminology of project success and failure.

  • Understand how concern for success drives investment in project management knowledge development.

• Introduction

  • Two Connected Areas:

    1. Learning from project delivery: Different types of evaluation (informal, formal reviews, audits).

       • Vary in approach/style based on project/organizational frameworks.

       • Reflect motivation to improve long-term project performance.

    2. Reporting of regular project failure: Reasons for failure in specific sectors.

  • Conclusion: Gap between ideal conceptual/planning and fully delivered project.

    • Examples reflect challenges of meeting high stakeholder expectations.

    • Drives investment in project management development schemes.

  • Projects present significant challenges, requiring extended understanding beyond initial concepts.

• What We Have Learnt About the Project So Far

  • Instinctive and Informal Perspectives of Performance:

    • Reviewing is ongoing throughout project lifecycle (individual, group).

    • Actions are reviewed, knowledge applied, leading to instinctive actions based on experience.

    • Informal reviews occur at all levels (functional, general management).

    • "Noise" from meetings, discussions, messaging, digital platforms contains valuable insight.

      • Informs better management of future projects.

      • Includes: management perspectives, insights into team performance/development, resource portfolio, stakeholder participation/optimization.

  • Objective Evaluations:

    • Initial Questions: Why, When, How do we evaluate projects?

      • Answers are not always immediately apparent.

      • Reasons: procedural, necessity, genuine desire for performance improvement.

    • Learning Point: "Continuing professional development and business management degrees often provide constructive opportunities to undertake an in-depth review that has a dedicated and value-adding focus."

    • Two Widely Used Techniques: Audits and reviews.

      • Audit: "Official action," typically by independent body, synonymous with inspection of accounts. (PMI, 2013: "quality audits" to determine compliance with policies).

      • Review: Assessments for "value-adding changes." Formal, but emphasis on recommending improvements. (PMI, 2013: "performance reviews" to measure/compare actual performance against baseline. APM, 2012: "critical evaluation of a deliverable, business case or P3 management process." )

      • Maylor (2010): Compares audit vs. review for various criteria (e.g., time: audit explores conformance, review explores customer satisfaction; human resources: audit examines policy conformance, review studies team spirit).

      • Reviews provide significant value for future project performance.

      • APM suggests reviewing throughout lifecycle.

• Project Review Processes

  • Objective evaluation mechanisms: audit and review.

  • Reviews, planned for post-completion, vary in schedule/content (organizational template, PM process headings, external party input).

  • Common Formula: Depends on context, scale, complexity.

  • Post-Implementation Reviews (PIRs):

    • Scenario 1 (Sustainable-build Construction Project): Internally focused PIR.

      • Challenges: Establishing common measurement standards, sourcing documentation, emotional involvement of staff, managing expectations, availability of key people, timing, participation, cooperation.

      • Scope (Figure 6.1): Original/modified objectives, deliverables, review of PM process (leadership, management competence, organization structure, controls, interfaces).

      • Questions: How well objectives met? Efficiency? Lessons learnt? Carried forward?

      • Outcome: Cost overrun (8.5%) led to negative self-perception, but building built with sustainable process where 2-5% inconsistencies/clashes are normal (Economist Technology Quarterly, 2008). High client satisfaction post-delivery.

      • Original vision "not sufficiently ambitious." Hindsight informs future learning.

    • Scenario 2 (Multi-organizational Project): PIR for process development.

      • Headings (with explanation): Document control, Introduction, Scope of PIR, Achievement of objectives/deliverables, Changes to scope/constraints, Costs/benefits, Alignment with strategies, Client/stakeholder satisfaction, Potential future developments.

      • Document control for quality control (Table 6.1).

      • These provide generic principles applicable elsewhere.

  • Externally Deployed Reviews:

    • For publicly financed projects, funding stakeholders demand regular/final audits (to answer "how money spent?" "well spent?").

    • Reviews determine effectiveness, inform policy/strategic planning.

    • Government Guidance: (e.g., Presidency of South Africa, 2011; HM Treasury, 2003, 2011) emphasizes evaluation for performance improvement and learning from success/mistakes.

    • Example (ERDF, UK Government, 2013): Evaluation of London programme (total \euro 181\text{m} ) for "sustainable environmentally efficient growth."

      • Scope extensive, undertaken by independent organization.

      • Similar reviews across Europe (e.g., Wales).

• Were We Successful?

  • Review elements, acknowledging the gap between idealistic planning/conceptualizing and delivery/review outcomes.

  • Definition of success is challenging; often subjective.

  • Four Questions to Evaluate Success:

    1. Did we meet the performance objectives?

    2. Did we deliver to stakeholder expectations?

    3. How will it be judged?

    4. Did we deliver something of different value than expected (greater/lesser)?

  • Helps understand genuine success and shapes future approach.

  • Project Failure Appears to Be a Constant:

    • Reports of "failure," "catastrophe," "disaster" are common, often sensationalized.

    • Example 1 (Sydney Opera House): Decades after inauguration, still associated with "bad project" headlines (late, over budget, trauma), despite adding $775\text{m}$ annually to Australian economy (Courier Mail, 2013).

    • Example 2 (Jindal's Bolivian Failure): Indian company Jindal Steel and Power Ltd secured contract (2007) for mining/steel project in Bolivia (investing $2.1 \text{ billion}$), terminated 2012 due to gas supply issues (Wall Street Journal, 2012). Jindal later won $22.5\text{m}$ arbitration (Bloomberg, 2014).

      • Causes of Failure (Gateway House, 2013): Complex political relationships, misjudgment of political power, disproportionate investment raising unrealistic expectations, insufficient scenario evaluation.

      • Lessons Learned: "Brilliant business plan is not enough," thorough political/risk analysis, understanding local politics/culture necessary.

      • This is a characteristic example of genuine project failure.

  • A Sense of Perspective:

    • Flyvbjerg, Holm and Buhl (2003): Research on 258 transport infrastructure projects (1927-1998) found "nine out of ten transport infrastructure projects fall victim to cost escalation." Average rail projects: 45%; fixed links: 34%; roads: 20%. "No learning seems to have taken place over 70 years."

      • Implication: "If we were going to cancel infrastructure projects when they start to run more than 25% over budget, we’d never build any infrastructure" (Economist, 2011 on California HSR).

      • Conclusion: Cost escalation is due to project approval tactics (underestimation).

    • Projects do fail to meet original performance parameters.

    • Definition of Failure (Oxford English Dictionary, 2007): lack of success, neglect of expected action, lack of desirable quality, not functioning.

      • Misapplied terminology often "sticks to the project."

    • Example (Eurotunnel): Often cited as failure (cost twice budget, half planned customers, first dividend 14 years late), but 20 years later, optimism for increased passenger/freight (Economist, 2014).

      • "A bad project comes good." Market conditions change.

    • Learning Point: Projects described as failures despite success in other respects. Terminology often misapplied.

  • Reasons Why Projects Might Be Deemed Failures:

    • Standish Group (1994): Report on IT project failures (wasted budget).

      • Used "failed, succeeded, challenged" terminology.

      • Success reasons: user involvement, executive support, clear business objectives.

    • British Computer Society (2008): "Only one in eight IT projects truly successful." Failure = not meeting original time, cost, quality criteria. Reinforces narrow definition of failure.

    • KPMG New Zealand (2013): Average project spend NZ$15\text{m}$. Increased failure rates. Factors for "high-performing projects":

      1. Robust business case, aligned with corporate strategy.

      2. Effective sponsor, clear direction.

      3. Consistent PM methodology, high PM capability.

      4. Active risk management, variance reporting, early recovery.

      5. Run within a programme/portfolio.

      6. Coordinated by a PMO.

    • McKinsey & Company (2012): Large IT projects ($> \text{US}\$15\text{m}$) run 45% over budget, 7% over time; 56% less value than predicted.

      • Success lies in four dimensions: Managing strategy/stakeholders (not just budget/scheduling), securing critical internal/external talent, building effective teams, excelling at core PM practices.

    • PM focus needs to be high (strategic) and detailed (core practices).

    • Growth of PM industry (methods, guidance, certifications) is a response to fear of failure.

• Incentives to Succeed

  • Organizations respond to public criticism.

  • Case Study: Heathrow Airport Terminal Projects

    • T5 (2008): Operational opening fiasco (cancelled flights, lost bags, chaos) due to baggage handling failure (BBC, 2008).

      • Context: Heathrow regularly criticized (Economist, 2007); BAA (operator) acquired by Grupo Ferrovial, facing Competition Commission investigation (split BAA) and financial warnings (Sunday Times, 2008).

      • IT problems marred opening (Computer Weekly, 2008).

      • Reputational damage for BA and BAA (New York Times, 2008).

      • Later, BA ran ads: "Terminal 5 is working. Try it for yourself." (Times, 2008).

      • Brady and Davies (2010): T5 "disaster" mainly public relations, not safety. Planning/construction on time/budget by BAA's two principles: client bears risk, integrated project teams.

      • Problem: BAA and BA team integration deteriorated just prior to opening. BAA CEO admitted "unfortunate that we created an expectation of perfection."

    • T2 (2014): Opened with little chaos.

      • Same organizations (BAA and BA), but BAA split up.

      • Lessons learned: John Holland-Kaye carried T5 debacle report. Set realistic expectations 12 weeks ahead, extensive testing (180 trials, 14,000 volunteers) (Guardian, 2014).

      • Result: "Terminal 2 avoids repeat of T5 launch chaos." (Financial Times, 2014).

    • Case Reflection: Evaluate T5 conditions, stakeholder/brand impact, severity of problems, lessons learned for T2.

  • The Need to Improve:

    • Growth of formal PM methods, BoK, methodologies, accreditation, training (CPM, WBS, Prince 2®, APMP®, PMO, PMI, APM, IPMA).

    • Not always complementary with existing techniques (e.g., in construction).

    • Reasons for growth: "Rational belief" in better project management, but also "fear of failure."

    • Investment in methods/qualifications to overcome project failure likelihood.

  • Practitioner-Based Approaches:

    • UK example: APM (professional body), Cabinet Office (Prince 2®), DSDM Consortium (Agile), APM-G (accreditation), commercial training providers (Figure 7.2).

    • "Design and build consultancy, successfully delivering for 30 years:" question: "What difference will this accreditation make?"

      • Fair point: cost of accreditation, but often condition of bidding.

      • Reluctance to change, but necessary investment.

    • Gap: Between scientific tools and ever-changing stakeholder expectations. Also, non-new issues like politics, culture, strategy, organization, people.

    • "Knowing about the formal methods is not enough. It is also about a deeper understanding of project management, the science and art."

• Summary

  • Reflection on learning: Despite planning, many unknowns emerge during delivery.

  • Gap between idealistic conceptualizing/planning and delivery/review outcomes is expected.

  • Platform for Next Chapters: Projects offer significant challenges, requiring expanded understanding.

  • Evaluation is one of the most important parts of a project, even for users/customers.

  • Projects are judged as failure or success at completion.

  • Initial concepts translated to plans, then challenging delivery to completed/evaluated project.

  • "We have really just begun our project management learning journey."

  • Next chapters: projects as business-as-normal, global dynamics, interconnected stakeholders.

07 Projects: A Way of Thinking

• Learning Outcomes

  • Explore the role of bodies of knowledge and support organizations.

  • Reflect on the need for different support approaches for different project types.

  • Gain insights into scope for conflict between methods-based approaches.

  • Consider the position of projects within the corporate setting.

  • Explore the notion of value creation and its difference from value capture.

  • Understand the role of the project-based organization.

• Introduction

  • This chapter explores two project "worlds":

    1. Projects articulated as distinct from business-as-normal.

    2. Projects constituting the business or organizational activity (which may not be explicitly promoted as "projects").

  • Consider projects as unusual activities and the emergence of practitioner expertise, its impact on the "organization project theatre."

  • How does this develop a future where project management is standard for organizational objectives? (Looking at a regional example).

  • Examines organizations where projects are building blocks of purpose/service delivery.

    • Benefits from conspicuous PM guidance?

    • Or, what can struggling organizations learn from these?

  • Projects as a Bridge: Between strategy and operations – fundamental but often overlooked.

  • PM has potential overlap with other disciplines, continuing as a theme.

• The Practitioner World

  • Response to Improvement: Practitioner-based approaches emerged to improve good practice and success rates (Chapter 6).

    • Nations encouraged member organizations, BoK, methodologies, accredited training.

    • Response to "fear of failure."

  • The Bodies of Knowledge:

    • Key Parties: PMI, APM introduced earlier.

    • Global Support: Organizations worldwide support PM knowledge/skills/resources (Figure 7.1).

      • Provide knowledge, accreditation, career development, networking.

      • Issue "good" or "best practice" models/tools.

      • Offer training/development services.

    • Tied Together: Tool X (Org A), accredited by Org B, training by Org C (Figure 7.2).

    • Consistency: Broad consistency across geographies, based on generic PM methods.

      • Important for "global PM" (product designed in US, developed in India, client in China/Brazil).

    • UK Example: APM (professional body), Cabinet Office (Prince 2®), DSDM Consortium (Agile), APM-G (accreditation), commercial training providers.

    • Introduces sequential and non-sequential approaches.

  • Models and Methods Supporting Sequential Approaches:

    • "Waterfall" Approaches: Typified by Prince 2®.

      • Sequential lifecycle methods: idea -> business case development -> approval -> planning -> staged delivery -> termination (Figure 7.3).

      • Ideal Project: Water flows downhill, implying smooth progression.

      • Reality: Often moves back a step, repeats stages; "waterfall is subjected to un-worldly forces."

    • Rationale for Agile: Response to "cumbersome rigidity of 'big design upfront'" (DSDM Consortium, 2008).

      • Economist (2001) on Agile Software Development Manifesto: "a common cause of disaster in software development is that the end product is precisely what the customer ordered."

      • Challenges management of innovation-type projects.

  • Models and Methods Supporting Non-Sequential Approaches:

    • "Agile": Iterative, flexible, interactive. Breaks projects into smaller elements, regular client consultation.

      • Promoted for innovative projects where design specification is difficult to establish.

      • Expected for "genuine projects" with "newness."

    • Significance: Could be seismic in undermining established PM bases, or realistic reflection of need for varied approaches/styles.

    • Historical PM: Derived from analytical methods in engineering, construction, defense.

      • Emphasis changed to include soft skills (stakeholder management courses).

    • "New Clothes" Analogy: Agile might be something "we knew all along."

    • UK Example "Atern" (DSDM Consortium, 2008): Pocket-book approach, with project lifecycle overview, techniques, roles, products.

      • Avoids "big design upfront" risks.

      • Can complement other disciplines like Prince 2®.

    • "DSDM Agile Project Framework" (DSDm Consortium, 2012): Evolved from Atern, accredited by APM-G.

      • Eight Principles: Focus on business need, deliver on time, collaborate, never compromise quality, build incrementally, develop iteratively, communicate continuously, demonstrate control.

      • "Never compromise quality" (Principle 4): Argues that "quality often becomes a casualty" in traditional approaches.

      • Separates quality constraint into technical quality and scope.

      • Prioritization using "MoSCoW" (Must have, Should have, Could have, Won't have this time).

    • Comparison with Sequential: Agile accepts change, encourages strong client involvement; change requirements addressed during delivery.

      • Prince 2® strong on control; good for managing cost/risk, fixed specifications.

      • Agile emphasizes people interactions, working solutions, customer collaboration, responding to change.

      • Prince 2® focuses on processes/tools, rigorous documentation, contract negotiation, planning.

    • Compatibility: Mitchell (Project Manager Today, 2012), Socitm Insight (2014) find waterfall and agile mutually exclusive. complementary.

      • Complementarity emphasized by accrediting parties.

  • Integration of Development Approaches within Organizational Setting:

    • Common: practitioner model/framework adapted to specific organizational context/culture.

    • Example (Shell): Multinational petrochemical business (3,000 PM professionals, 5,000 technical staff, $93,000$ employees globally).

      • "Mature project management approach, proven and developed over 100 years. " Shell is a "projects-business." ($25-30 \text{ billion}$ annual project portfolio).

      • "Shell Project Academy": Competence development برنامج with "pentagon" of learning, experience, networking, coaching/mentoring, accreditation (aligned with APM professionalism dimensions).

      • Highlights alignment of institutional/organizational development, and businesses already being "projects-businesses."

      • Exploration projects are fundamental for hydrocarbon production.

    • Leads to concept of projects-based organizations (PBOs).

• The Context for Projects-Based Organizations

  • Many organizations are primarily concerned with delivering projects.

  • Definition of Project (PMI): "temporary group activity designed to produce a unique product, service or result" often with cross-organizational/geographical teams.

  • Examples of Organizations Fitting Definition: News production, professional service organizations.

    • Both range from "paint-by-numbers" to "low-volume high-variety."

    • Both depend on projects for throughput.

  • News Production: (e.g., Heathrow T5 coverage – BBC, March 2008) "breaking story" activities often embody project lifecycle, but incorporate danger dimension.

  • Professional Service Firms: Success tied to successful project delivery.

    • Diverse work across sectors, often international teams (e.g., lawyers, consultants, HR, accounting).

    • Example (Legal Litigation Stages, Ohio State University, 2014): Filing complaint, answering, discovery, motion, settlement/mediation, trial, appeal. Each stage is project-like.

    • Globalization: Legal Process Outsourcing (LPO) (e.g., Pangea3, headquarter in Mumbai/New York, operations in Mumbai/Delhi/Dallas). Supports "24-hour follow the sun coverage."

  • Organizations That Deliver Projects:

    • Project-based organizations (PBOs) are numerous.

    • Construction: Provides visual, understandable "traditional" PM examples (breaking down projects, lifecycles, legal aspects, temporary labor).

      • Uncertainty, visualized outcomes (drawings, designs), stakeholder management, litigation.

    • Historical Research:

      • UK Television Industry (Starkey, Barnatt and Tempest, 2000): Networks, task-by-task temporary teams, organized by central permanent group. "Latent organizations."

      • Filmmaking (DeFillippi and Arthur, 1998): "Project-based enterprises have long flourished." Impact of uncertainty, demand volatility on talent recruitment. Coordination complexities (cast, crew, sets, tech).

        • "Wholly outsourced teams." "Temporary organizations sustaining a permanent industry presents a paradox."

        • "Independent film-making may exhibit in relatively pure form a model of organizing that is broadly and increasingly applicable to other fields."

      • Contemporary Context: Growth in self-employment/freelancing (e.g., UK 2014 – Professional Contractors Group).

  • Project-Based Organizations – Definition:

    • Hobday (2000): "one in which the project is the primary unit for production organization, innovation and competition."

    • Modified Definition (for this book): "one in which the project is the primary means of delivering the product or service." (Includes media, engineering, sport, professional services, government).

    • Case Study: International PPP Scheme

      • Scenario: Natural-resource-rich nations investing in infrastructure improvements (water/waste, healthcare, transport) using Public-Private Partnership (PPP) mechanisms.

      • PPP Definition (PPIAF, 2012): Long-term contract between government and private entity for public service provision. Full cost recovery from tariffs, government as financial partner, asset transfer to private sector, supporting private development.

      • Legal/contractual/management frameworks vital before projects.

      • Professional services firms (e.g., legal) take specialist roles, potentially involving unexpected development work due to newness.

      • Urgency from pre-existing national strategic plans.

      • Example is from HNCountry1 (fictitious, well-organized government, weak/underdeveloped state provision areas).

      • LawFirm55 (professional services firm) acts for HNCountry1.

      • Projects or Programmes? Scale of projects leads to classification challenges (Figure 7.4 shows multiple PBOs for legal, management, financial, regulatory roles within a PPP enabling team).

      • Need for common vocabulary/classification framework.

      • HNCountry1 lacks experience in large PPP implementation.

      • Structural Considerations: Hierarchy in government departments, difficulty accessing decision-makers; external parties often go through intermediaries.

        • Cultural Aspect: Host nation wants expertise but may not fully acknowledge source due to historical political connotations.

      • Cultural Aspects: Competitive environment, gender role differences. External party needs to spend time with senior/powerful members.

        • Can improve communication by focusing on common ground (e.g., female PMs in male-dominated cultures).

      • Some Challenges: Intermediary office staff lack insight into PPP complexity (first-timer project for them).

        • Nervousness about responsibility, need for trust.

        • Cultural base may inhibit asking questions; aggression when nervous.

      • Timetable/Schedule (Figure 7.5): Linked to five-year planning period. External parties must comply.

      • Key Milestones/Stages: Frameworks need approval from high-level committee/legal regulatory body.

        • Low tolerance for missed deadlines.

        • Understand deadlines to establish workflow.

      • Case Reflection: Evaluate organization/structural considerations, value creation/capture, sequencing/priorities, and challenges for organizations sharing resources but with different strategies.

• Projects Create Value

  • Projects and programmes are value-creation processes.

  • Winter and Szczepanek (2008): "Conceptual shift, away from the traditional engineering view of projects, towards a more value-centric view. " Concern is creating value/benefit for multiple stakeholders, not just capital assets.

  • This helps project deliverers understand stakeholder pressures and reflects strategically on work value.

    • Even if interpreted as "failures," some projects exceed original performance objectives and are "taken for granted" for generations (e.g., Flyvbjerg et al. research, A400M, Snowdon Summit building).

  • Value creation is a "powerful observation." (Figure 7.6).

  • Caution: Does not necessarily change original business case arguments (justification on returns over a specific period).

  • Winter and Szczepanek (2008): Projects/programmes contribute to value creation, they don't create it themselves.

    • Goal: Mobilize customers to create their own value from project offerings.

    • Apposite for asset delivery with long operational life (Snowdon, Heathrow, A400M).

• Value Creation and Value Capture

  • Distinction: Value creation is distinct from value capture/retention (Lepak, Smith and Taylor, 2007).

  • "Value created by one source... may be captured at another."

  • Three distinct stakeholder sets: those for whom value is created, those who specified requirement, those who capture value.

  • Value creation refers to both content and process (process knowledge has quasi-asset value).

  • Value Lag: Slippage between value creation and capture (Lepak et al., 2007).

    • Example: 3-year asset build, contract fulfilled, monies paid -> value created. Project value lag of years until captured (e.g., London Underground, 1863 to present).

    • Current stakeholders affected by delays may not be those who benefit from lagged value.

  • Summary: Projects create value, value is captured, often with a lag. Projects are "the bridge between strategy and operations."

  • Not just about outputs or "triple constraints." Projects are "powerful, central mechanisms that enable organizations and societies to achieve things."

  • Cycle of Value and Liability Creation: Not a one-way process. Project outcome creates corresponding liability.

    • Example (Brussels Atomium): Built for 1958 World's Fair, popular, renovated in 2004-2006 for €23m. Initial project created long-term value, renovation creates new value and heralds next capture phase.

• Summary

  • Explored practitioner support and alternative PM approaches (agile) emerging from fear of failure and desire for projects-as-normal.

  • Agile approaches popular in innovation, but not mutually exclusive with traditional methods.

  • PBOs prevalent in many sectors, routinely delivering projects without conspicuous PM vocabulary.

  • Project success metrics often insufficient to measure long-term success; usually based on implementation control metrics.

  • Lag between value created and captured; stakeholders active during project may differ from beneficiaries of outcome.

  • Projects can create liabilities as well as value.

08 Within and Outside Projects

• Learning Outcomes

  • Recognize aspects of aggregation in the project environment.

  • Reflect on the impact of aggregating people in projects (groups and teams).

  • Explain challenges of locational aspects.

  • Understand the need for extended terminology: portfolio–programme–project.

  • Recognize projects in organizational strategy deployment.

  • Explain need for support and value of project management office (PMO) functions.

• Introduction

  • This chapter uses aggregation as a central theme.

  • Explores grouping opportunistically and systematically (people, locations).

  • Analyzes balance of autonomy and control in structure and governance.

  • Considers distinct internal/external forces driving projects.

  • Projects and PBOs are fundamental building blocks of society, ranging from small to large.

  • Extends thinking within and outside the project: people (size, structure), location, different forms of aggregation (programmes, portfolios).

  • Revisits previous themes (governance, stakeholders) in relation to new topics.

  • Concludes with expecting the unexpected.

• Aggregation Within and Outside Projects

  • Projects are almost never a single-person undertaking; involve multiple people, departments, organizations, locations.

  • WBS (Work Breakdown Structure): Disaggregates the challenge into smaller steps.

    • Also Organizational Breakdown Structure (OBS) or Product Breakdown Structure (PBS).

    • Project might be part of a bigger project (sub-projects).

  • Involvement of various parties -> formation of teams.

    • Affects decision-making, communication.

    • Expressed as "project autonomy."

  • Autonomy: Degree of independence/freedom to act independently.

    • Affects speed of progress.

    • Strategic problem: Decisions counter to organizational guidelines/compliance create "risk of operating out of control."

  • Focus on aggregation of people and locations.

    • Helps choose right structure, control bases, governance.

    • Optimizes decision-making, motivation.

    • Develops insights for Chapter 9 on cultural/demographic dimensions.

  • Number of People; Where Size Matters:

    • Projects vary in size (budget, activities, stakeholders, ambition, economic impact).

    • People Directly Involved: One/two (small business, single department) to thousands (mega-projects).

    • Mega-events (Olympic Games): Vancouver 2010 had >75,000 volunteers (IOC, 2011). Sochi 2014 recruited 80% of 25,000 volunteers (Russia Beyond The Headlines, 2013).

      • Recruitment of volunteers is a project in itself.

    • Impact of Size: More people/teams -> increased management challenge (Figure 8.1).

      • Project management complexity rises with number of teams.

      • Degree of autonomy enjoyed by teams often varies inversely.

    • Autonomy Constructs (Gemunden, Salomo and Krieger, 2005):

      • Goal defining: Projects don't have full autonomy.

      • Structural: Necessary but not sufficient for project success; literature recommends separation from routine organization.

      • Resources.

      • Social: Significant positive influence on project success (related to location).

    • General Management Control: Organizations extend control to project work.

      • Decision-making speed differs between small private business and hierarchical government organization (e.g., due to scrutiny).

      • Sarbanes-Oxley Act (2002): Response to corporate scandals (Enron, WorldCom) led to "tough new rules" and sharper auditing (Economist, 2007).

      • Governance: APM (2004) "governance of project management" (11 principles). APM BoK (2012) and PMI PMBOK (2013) include governance.

      • Challenge: Balance between autonomy and control.

  • Influence on Choice of Structure:

    • Size matters, but not the only factor.

    • Overarching management principles and cultural factors can make organization inherently unsuited for projects.

    • Example (Service Agency): Traditional hierarchical model inhibited effective adoption of cross-functional project practices (Figure 8.2), leading to bankruptcy (inability to support burgeoning project portfolio).

      • Investment in PM training might have helped, but underlying organizational characteristics inhibited transformation to project-based.

    • Zenger (2002) and Lindkvist (2004): "Hybrid governance forms" are alluring but limited without new systems/measures (Zenger). Projects with great autonomy can become "disconnected projects" (Lindkvist).

    • Learning Point: "Contradictory need to balance autonomy with effective management is a significant risk to project and host organization."

    • Project Team Population (Figure 8.3): As potential team population increases, need for clarification of role, responsibility, dedicated project structure rises.

    • High project freedom can create governance/compliance problems.

• Location: A Sense of Division

  • Technology improves communication, but physical location still shapes identity, relationships, perspectives, prejudices.

  • Virtual Presence: Unlimited, potentially positive for project participation, but risks include over-commitment, belief in 24/7 world solving everything.

  • Impact: Organizations operating across many locations impacts project management effectiveness.

  • Types of Team (Table 8.1):

    • Traditional (co-located): Close proximity, face-to-face interaction.

    • Hybrid: Some co-located, some remote.

    • Virtual (completely dispersed).

    • The term "virtual" becoming unnecessary as technology advances.

  • Global Virtual Team (GVT): Challenges with time zones, culture.

    • Face-to-face interaction often preferred (body language, facial expression), but video communication becoming common.

    • Shachaf (2008): Cultural diversity in GVTs has positive/negative impacts.

      • E-mail ("lean medium") reduces miscommunication.

      • ICTs help overcome cultural diversity.

  • Importance of Locational Aggregation: Introduces mix of culture, style, standards, behavioral norms (Figure 8.4).

    • Variable motivation and trust.

    • Example ("wild west" office): Suspicion and jealousy between co-located and HQ staff due to differing perceptions/culture.

  • Skills: Project manager needs understanding people and organizational behavior skills (valuable for different personalities, cultural contexts, leadership modes).

  • Learning Point Aggregation of capabilities can have unexpected effects. Deeper understanding provides better PM platform (developed in Part Four).

• Projects, Programmes, Portfolios

  • "Project" Terminology: Difficulty defining (Chapter 1) due to diverse forms/emphasis (time, cost, budget, ambiguity).

  • Large projects contain sub-projects (e.g., international sporting event, airport development, new vehicle, system implementation, energy facility).

  • Multiple-project scenarios are common.

  • Case Study: Sun Moon Lake Tourism and Energy

    • Context: Lake in Taiwan provides tourism and hydro-electric power (1,602MW pumped storage, largest in Taiwan - Taipower, 2013).

    • Management of two distinct activities by different parties, common element is the lake.

    • Portfolio–Programme–Project Segmentation:

      • Macro level (Figure 8.5): Portfolio could be twofold (hydro-power assets/systems, tourism market development).

      • Tourism focus (Figure 8.6): Portfolio as "background statements," Programme as "objectives: national development plan," Projects as "project objectives."

      • Evidence for Programme 3 (specific international markets, eco-tourism) seen in marketing campaigns (cycling, walking, music festivals, Eva Air, Economist ad for "biker’s paradise").

    • Complexity: Proliferation of government/commercial organizations, conflicting objectives, coordination challenge (magnified at macro level).

    • Visitor expectations may conflict with hydro-power operators' usage parameters.

    • Case Reflection: Evaluate scenario from portfolio–programme–project perspective (core project opportunities/conflicts, impact on organizations with shared resources/different strategies, wider party involvement).

  • Categorization Challenge: Not unique to projects (e.g., food market, dairy sub-market). Also in products/engineering (sub-assemblies).

  • Formal Terminology: Project, Programme, Portfolio.

    • Programme (Chapter 1 definition): collection of connected projects, or projects + other activities.

    • Purpose: Clarify aggregated activities, build management frameworks, disaggregate expectations/targets.

  • Problems with Approach: Different understandings of programme, frameworks vary by definition, project/programme management roles conflict, programme management often uses project management vocabulary.

    • Similar four concerns for portfolio management.

  • Alternative Perspective: Organizational strategy helps rationalize vocabulary and clarify relationships.

• Organizational Perspective

  • Organization exists to deliver products/services.

  • Strategic Capability (Johnson, Scholes and Whittington, 2008): "resource and competencies... needed for it to survive and prosper."

  • Strategic choices (products/services) lead to projects (product development, ventures).

  • Learning Point: "Exploiting strategic capability leads to projects." Form part of strategy deployment for any organization.

  • Governance Chain (Figure 8.7): Simplified: Beneficiaries -> Trustees -> Investment Managers -> Executive Directors -> Senior Executives -> Managers -> Board.

    • Linkages exist between each group.

    • Sets direction for portfolios, programmes, projects delivering strategy.

  • Deployment of Strategy (Figure 8.8): Cascading vision and organizational strategy to projects.

    • Example (Shell Exploration): Portfolios (generic areas 1, 2, 3), each delivered through programmes, each programme comprising projects (Figure 8.9).

    • Similar to WBS for strategy delivery.

    • Directing/Managing Roles (Figure 8.10): Portfolio Director/Manager, Programme Director/Manager, Project Director/Manager.

    • Ideal Model: Top-down, clear command/control. Vision -> strategy -> deployment (P-P-P) -> strategy/vision.

    • Reality: Ideas may emerge from project level, remaking original strategy.

    • May need multiple levels of strategy (organization, portfolio, programme, project).

    • Maylor (2010): CEO has vision, Senior Management develops organization strategy, Portfolio Management for portfolio, Programme Management for programmes, Project Managers for projects.

      • Applicable to most situations, even micro-businesses.

      • Problem: Ambiguity between projects/programmes leads to multiple interpretations (cooperation–competition paradox - Buuren, Buijs and Teisman, 2010).

      • Effective management/organization justifies PMO establishment.

  • Fully introduced additional terminology (programme, portfolio) through strategy deployment.

• Providing Support – Project Management Offices

  • Projects gain popularity -> rise in skilled people. Demand exceeds capacity.

  • Autonomous PM delivery brings risks (breaking rules).

  • Justification for office function to support project activities.

  • Personal Examples (6 scenarios): Highlight lack of missing knowledge (e.g., spreadsheet creation, template source, finding PMs, business case math, software tools, qualifications, team issues).

    • All are problems easily addressed but often occupy staff due to lack of time, insight, experience, or knowing where to get support.

    • Aggregating these instances makes a business case for a dedicated Project Management Office (PMO).

  • PMO can be formal (cost prohibitive for small businesses) or informal.

  • Services Provided by PMOs: Common templates, suitable method deployment, access to specialist resources/analytical skills, support for training/development, consulting-style problem solving/knowledge.

    • Centralized/distributed, heavyweight/lighter, personal/virtual, hard/soft skills focus.

  • Emergence of PMOs:

    • Dai and Wells (2004): No standard set of PMO features, but identified broad support categories:

      • Development/maintenance of PM standards/methods, archives.

      • Provision of PM administrative/staffing support, consulting/mentoring, training.

      • Conclusions: Confidence in concept, correlation of standards/methods with project performance, significance of historical archives.

    • Muller et al (2013a): "Multiple PMOs, different mandates, functions, characteristics." "Extremely heterogeneous... very ephemeral."

      • Different PMO roles: "serving" (expert/admin support), "controlling" (enforcement), "partnering" (cooperative, lateral communication) (Table 8.2).

    • Muller, Gluckler and Aubry (2013b): Research in pharmaceutical R&D (China) on knowledge flows.

      • Knowledge exchange in clusters. PMO members not most popular knowledge providers.

      • Staff preferred support from earlier collaborators.

      • Highlights value of encouraging project-focused staff to share knowledge (virtual PMO support).

    • Example (Small Education-based Service Business): Internal training day provides knowledge support, achieves PMO goals (staff provide material based on project experience), works as virtual PMO.

• Expect the Unexpected

  • Projects (and their structure/organization) can emerge from unexpected events (e.g., natural disasters).

    • Extreme examples: timing unknown, high service demands, difficult access.

    • Mountain rescue teams (volunteers, called at short notice) = PBOs with unpredictable timing.

  • Project execution often deviates from planned route.

  • Soderholm (2008): Project managers "engage in a number of practices in order to stay on track while constantly being exposed to unexpected events."

    • Innovative action, extensive meetings/short-term coordination, detachment strategies, negotiation skills, project-safeguarding.

    • Strength in these areas is crucial.

• Summary

  • Introduced/explained aggregation issues in project environment (people, location).

  • Impact of grouping people into teams, value of understanding organizational behavior/HRM, conflict between autonomy and parent organization control.

  • Co-located vs. virtual teams, impact of communication technologies.

  • Portfolio–programme–project terminology as coherent vocabulary and strategic perspective; "project" remains core.

  • Need for project support and PMO functions.

09 A Global Stage

• Learning Outcomes

  • Reflect on international aspects in many project scenarios.

  • Explore how comparable management disciplines reflect international dimensions.

  • Understand inherent in-situ challenges of international projects.

  • Evaluate core dimensions: culture, communication, commonalities.

  • Examine specific aspects affecting individuals, organizations, national perspectives.

  • Explore implications for key underlying project management models/frameworks.

• Introduction

  • This chapter explores global aspects of projects: cross-border activities and local manifestations through culture, language, delivery process.

    • Communication focuses largely on language.

  • Generalist thinking promoted, using limited geographies/examples.

  • International project management: Upscaling of PM or different?

  • Building context for international aspects, then focus on culture, communication, and commonalities to overcome challenges.

  • Discuss implications for core PM areas and carry initial conclusions to Part Four.

• Many Projects Have International Elements

  • Context: Projects are rarely single-person endeavors, and usually have international dimensions.

  • Case Examples (Table 9.1):

    • Visitor attraction: External funding, material sourcing, tourism markets.

    • Wind energy project: Supplier/engineering, specialist consultancy.

    • Mega-event hosting: International event, significant stakeholders.

    • Motor vehicle/SUV: Supply chains, international standards/clients.

    • Airlifter: Pan-European developer, international standards/clients/markets.

    • Airport terminals: International hubs, significant stakeholders.

  • This analysis is not exhaustive; even local projects have quasi-international (multinational, multicultural, multilingual, multi-ethnic) characteristics.

  • Value of Understanding: Provides insight, helps resolve problems, or reframe perceived problems.

  • Project manager needs to be a versatile skilled generalist.

  • International Management Disciplines: PMs can draw from international business, international management, international human resources management (IHRM), culture/diversity studies.

    • Example: IHRM vs. HRM. How do training/management development differ internationally?

    • Briscoe, Schuler and Tarique (2012) on T&D in MNEs: Human capital as competitive advantage, requiring:

      • Thinking/acting globally.

      • Establishing equidistance (no "overseas" designation).

      • Focusing on global system (breaking silos).

      • Developing global leadership skills.

      • Empowering cross-border/virtual teams.

      • Making learning a core competence.

      • Constant reinvention of global organization/members.

    • These points are relevant for international projects, not just organizations.

    • Learning Point Value of embracing complementary management disciplines.

  • The Significance to Projects:

    • Two Poles of Thought: Global projects often succeed despite difficulties. Conversely, unawareness of customs can lead to faux pas that cause project failure during negotiation.

    • Complex fusion of practical challenges (visa arrangements) and cultural/attitudinal/behavioral traits.

    • Awareness helps increase success likelihood; relevant locally and globally due to global diaspora.

    • Touches discrimination, politics, gender, ethics. Significant levers for motivation, leadership, change.

    • Thorough stakeholder evaluation provides insight.

    • Risk of blind spots (inadequate knowledge leading to complacency/arrogance/dismissiveness).

  • Project Management: International Perspectives:

    • Treating global projects as extension of domestic management (IHRM, int. business) is risky, may lead to wrong emphasis/frameworks.

    • Muriithi and Crawford (2003): Wariness in Africa of adopting Western concepts (post-independence resistance, inapplicability); highlights need for cultural context.

    • Many Lenses: Context/objectives change project-to-project, requiring continuous modification of approach.

      • Danger of one-size-fits-all.

    • "International project management" implies problems (stakeholders, culture, ethics, geography, nationality).

    • Culture is inherent, influences communication, negotiation, learning, motivation, change, leadership.

    • Example (Jindal's Bolivian Failure): (from Chapter 6) Complex political relationships, misjudgment of political power, disproportionate investment, insufficient evaluation, need for thorough political/risk analysis, understanding local politics and culture.

    • Learning Point: "Keep a sense of perspective." World functions despite cultural complexities. Important to recognize cultural differences but not "overpowering reasons not to undertake a project."

• Culture, Communication, Commonalities

  • Three-Part Focus for International Projects:

    • Culture: Pervasive across projects.

    • Communication: Language-focused.

    • Commonalities: Clanship, ethnicity, cultural traditions.

  • Are these barriers or opportunities (e.g., bicultural team members)?

  • Case Example (Welsh service agency): "Wild west" office (Chapter 6) with Welsh language, strong cultural factors.

    • Project: Establish support service for regional businesses (new IT). Key constraints: funding (external govt, fixed), time (funding period).

    • Scope: Decentralized service provision (virtual way) for sparse population (8,500km², >200,000 people) covering 40% of country.

    • Challenge: Fund-holder client wanted single center (per urban geographies), but external environment analysis forced decentralized solution.

    • Stakeholder Partnership (4 partners) crucial but fragile.

    • Project lead "impassioned by the project", representing partnership, presented case for decentralized services.

    • Outcome: Argument won, project proceeded on decentralized basis.

    • Reflection: Process was labored, but influenced by cultural setting, geography, demographics, politics. Demanded tuned approach.

    • Relevant in urban multicultural/multilingual settings too.

    • Project Management Areas Affected: Concept adaptation, communication/presentation, negotiation style, planning framing, cost/budget planning, team composition, stakeholder engagement.

  • Cultural Influences:

    • Hofstede and Hofstede (2005): "Culture as mental software" (learnt, collective phenomenon).

    • Trompenaars and Hampden-Turner (2005): "Culture as the way people solve problems."

    • Distinguish from individual character/personality.

    • Differences are not wrong, but challenging in global projects.

    • Mismatch of cultural familiarity can lead to project failure (e.g., product in alien market).

    • BoK on culture (Hofstede, Trumpenaars, Hall, Adler) can be as valuable as technical PM BoK.

  • Insights for Project Management: Uncertainty and Power

    • Tran and Skitmore (2002) on Singapore managers (Hofstede's concepts): "Low uncertainty-avoidance" correlates with trust-based, less formal communication.

    • Uncertainty avoidance (Hofstede and Hofstede, 2005): Degree of comfort with uncertainty.

      • Example (Japan vs. Taiwan HSR): Japan (high uncertainty avoidance) has stricter ticket inspection than Taiwan (lower), but Taiwan's system is unobtrusive. Project incorporated modified design.

      • Learning Point: Cultural programming can lead to modified project designs. "The one best way of organizing does not exist." (Trompenaars and Hampden-Turner, 2005).

      • Observation: individuals (e.g., Germans, Russians) may have direct styles, which are just "different."

    • Power distance (Hofstede and Hofstede, 2005): "Extent to which the less powerful members of institutions and organizations within a country expect and accept that power is distributed unevenly."

      • High power distance societies (e.g., China's command/control Olympics vs. London's "nudge" Olympics) may exhibit strong planning/control.

      • Gen Z workers ("Post-90 Generation") may be more averse to authority (Ting-feng, 2012).

  • Insights for Project Management: Other Aspects of Culture

    • Individualism vs. Collectivism: (Trompenaars and Hampden-Turner, 2005) "I" (individual can make decision, seeks quick deal) vs. "We" (consultation, consensus-building, building lasting relationships).

      • Important for conflict resolution in multinational teams (Moran, Harris and Moran, 2011).

    • Time Orientation: "sense of time differs by culture – some are exact and others are relative." (Moran et al., 2011).

      • Projects with critical time components require understanding team reactions to pressure.

    • 10 Categories to Understand Culture (Moran et al., 2011): Self/space, communication/language, dress/appearance, food/feeding habits, time/time consciousness, relationships, values/norms, beliefs/attitudes, mental processes/learning, work habits/practices.

    • Learning Point Diversity affects planning style. Cultural differences regarding time reflect in planning.

  • Communication: Language and Linguistics:

    • Language is often the first barrier. EU has 24 official languages.

    • English as lingua franca creates complacency (not learning other languages, assuming full understanding).

    • Non-verbal communication (body language, facial expression) adds further complexity.

    • Naive project managers may struggle with greetings, negotiation, relationship building in international contexts.

  • Specific Issues with Language and Linguistic Ability:

    • Colleagues' reluctance to learn languages, assuming English is sufficient.

    • Global Projects: Mix of host, business, individual languages.

      • Common language (English, Mandarin, French etc.) is only as good as speakers' ability.

      • Presents disastrous risks.

    • Tenzer, Pudelko and Harzing (2014) on language barriers and trust:

      • "Pervasive language-based anxiety" (insecurity, embarrassment, feeling stupid, threatened, losing face) in multinational teams (MNTs) across functions, sizes, policies.

      • Feely (in Tayeb, 2003) highlighted problems for second language users: rhetorical skill failure, "face" issues, power/authority distortion, miscommunication, attribution, code switching.

    • These manifest as project problems.

    • Technology (real-time translation) still has limitations.

    • Pragmatic approach needed; understanding problems exist helps resolve them.

  • Commonalities:

    • Opportunities through shared nationality, ethnicity, culture, communication.

    • Often viewed negatively, but "glue" for capability and project success.

    • Personality also provides opportunistic commonalities.

    • Ethnicity can overcome language barriers.

    • Understanding regional politics reveals reasons for poor collaboration. Conflict areas influence feelings/perspectives.

    • Strength of commonality of purpose, interests, personality helps overcome objective/structure/resource conflicts, cultural mismatches.

    • "Putting soft skills... in the vanguard of project management."

  • Case Study: Shoe Projects: From Design to Store

    • Context: Latest fashion shoes arrive in stores; background project development processes are unseen.

    • Focus: Design of a new shoe (Figure 9.1).

    • Interrelated Sequence (3 geographic locations): China (manufacturing), US/UK (brands), Taiwan (fabric source).

      1. Initial marketing projects: Fabric designs (swatches from Taiwan) to shoe designers (US/UK).

      2. Fabric exhibited at trade fairs (US/Europe) for designers.

      3. New product development projects: Fabric incorporated into sample shoe, extensive testing, price negotiation, production.

      4. Manufacturing: Shoe manufactured in China, sold globally. Moves to operations management.

    • Timeline: 18 months from design to manufactured item, for specific season (spring/summer, fall/winter).

    • Case Reflection: Identify key international dimensions (type/scale of challenge). Determine practical issues/solutions, business case impacts. Identify stakeholders, change issues, risk areas.

• Implications for Project Management

  • International aspects affect all areas of project management.

  • "Project" Definition (PMI, 2014): "project team often involves people who don’t usually work together – sometimes from different organizations and across multiple geographies."

  • Risk: Extended uncertainty range due to potential mismatches, barriers (culture, communication). Political risk from nationality/culture.

  • Framework (Figure 9.2 from Chapter 1): Project as a journey, with international context for components.

    • Idea/Ambition: Impact of culture, translation.

    • Performance Parameters (Time, Cost, Quality): Impact of regional/cultural dimensions, shared views.

    • Supported by People, Techniques, Tools, Equipment, Organization: Barriers to effective teams, diversity impact, tool adoption/response, cultural norms.

    • Solution/Outcome: Varying stakeholder perspectives.

  • Strategic Level: Stakeholders (enhanced/informed perspective, e.g., specific PM recruitment based on culture/gender), Risk (attitudes vary across regions).

    • Example (wire shopping basket hazard vs. climbing walls without warnings) shows different risk perspectives.

    • Trompenaars and Hampden-Turner (2005): "Weighty contracts are a way of life in individualist cultures, but may provide a rough guideline or approximation elsewhere."

  • General Types of Risk in International Business (Khattab, Anchor and Davies, 2007):

    • Political (govt. interference, societal events).

    • Financial.

    • Cultural.

    • Natural.

    • Political Risk Breakdown: Government interference (business operations, ownership, personnel, credit/taxation), societal events (civil unrest, violent expression of views).

    • Perceived high risk may deter projects.

    • Economist (2014): Multinational organizations operate in high-risk areas; "sub-prime and Eurozone crises inadvertently helped; big firms carry more cash."

    • Risk is ever-present; international projects often have higher uncertainty, but this doesn't stop them.

  • Keeping a Sense of Perspective – Cultural Friction:

    • "Cultural distance" often seen as a barrier.

    • Shenkar (2012): Replace cultural distance with "cultural friction" (positive reflection). "Scale and essence of the interface between interacting cultures, and the 'drag' produced."

    • Projects as a "bridge between strategy and operations." Project manager function also needs to provide a "robust bridge" for cultural friction.

    • Individual team members reflect cultural position, but also have unique personality/ability/style.

• Summary

  • All projects have some international degree (cross-border, multi-ethnic, multilingual, multicultural).

  • International project management can be an upscaling of PM, but best perspectives come from understanding international dimensions (culture, commonalities).

  • Asking the right questions enables international project delivery.

10 Managing and Leading in Project Environments

• Learning Outcomes

  • Consider differences between general and project management.

  • Explore whether there is a universal specification for the project manager.

  • Examine appropriate competence frameworks.

  • Evaluate the role of leadership in project environments.

  • Reflect on practicalities of leading and managing in project environments.

  • Understand the character and value of diversity in project management.

• Introduction

  • Previous chapters indirectly explored many areas of management as project management.

  • "Management" has many connotations, used differently.

  • Generalist project manager integrates diverse specialist knowledge for project delivery.

  • Requires effective leadership.

  • This chapter focuses on management and leadership in project environments.

    • Establishes broad principles for self-assessment and future development strategies.

    • Covers what managing/leading is, what's needed for success, sourcing effective project managers, value of diversity.

  • Management (general, project, international) vs. Leadership (universal).

• Managing and Leading; Distinct and Complementary Attributes

  • Individuals bring different experience, knowledge, expectations, attitudes, capabilities, characters, personalities, styles.

  • Enhancing self-profile builds capability.

  • Two Related Points:

    • What is managing and leading?

    • What's needed for effective managing/leading in project environments?

  • Management in Project Environments:

    • Hitt, Black and Porter (2009) on Management:

      • Process: planning, deciding, evaluating.

      • Assembling/Using Resources: human/financial/material/informational.

      • Goal-directed: purpose and direction.

      • Organizational Setting: common purpose through coordinated intentional structure.

      • Managers concerned with planning, organizing, directing, controlling.

    • Robbins and Coulter (2012): Four functions: planning, organizing, leading, controlling. Also efficiency (most output, least input) and effectiveness (doing right things).

    • Distinction from Project Management (Figure 10.1): High-level frameworks overlap, but differences arise in effectiveness, efficiency, and project-specific traits (creativity, uncertainty).

      • Project Planning: Foundations, decision-making, tools, techniques (similar to Gen. Mgmt. planning).

      • Organizing: Project PM emphasizes project organizational structure (distinct/related to existing). HRM knowledge expected from PMs.

      • Controlling: Gen. Mgmt. explores measurement, comparison, corrective actions, performance measures, operations/supply chain management.

        • Divergence: Projects are often new (opposite of operations). But project can implement new supply chain or depend on it.

      • London Underground Upgrade (Figure 10.2): Highlights need for coordination between operations and project management due to impacts on stakeholders.

    • PM Scope: Projects can span multiple sectors/areas, requiring broad knowledge.

    • Challenge: Difficult to create generic specification for leadership/management skills due to project type and context.

    • Three Dimensions of Capability (Figure 10.3): General management, project management, specialist skills/knowledge. Shape depends on person, experience, project needs.

• Project Manager: A Specification

  • Is there a universal specification for a "good" project manager?

  • Cheng, Dainty and Moore (2005) on "Superior" PMs in Construction Sector (12 core behavioral competences): Achievement orientation, initiative, information seeking, client focus, impact/influence, strong directiveness, teamwork/cooperation, appropriate team leadership, analytical thinking, conceptual thinking, good self-control, flexibility/adaptability.

    • Reflection: How applicable are these to general PM? How do they relate to available skills/development?

  • Practitioner and Body of Knowledge Bases:

    • Value: combines PM/HRM theory with practical basis; established qualifications.

    • Help support individual/corporate development, despite diversity of roles.

    • Competence Frameworks: IPMA Competence Baseline (2006) and APM Competence Framework (2009) (Figure 10.4) group competences:

      • Contextual: Project/programme/portfolio orientation, managing line management relations.

      • Technical: Hard skills (requirements, objectives, quality).

      • Behavioural: Leadership, results orientation, negotiation, conflict, crisis, values, ethics.

    • Commonality: Strong overlap in individual competences (e.g., requirements management, leadership, negotiation).

    • Regional Adaptations: PMSA integrated PMI framework with South African context.

  • The Value of Adopting a Framework:

    • Helps reflect on investment in qualifications.

    • Crawford (2005): No statistically significant relationship between performance against standards and perceived effectiveness of workplace performance (for engineering, construction, IT/telecom, industrial process, business services).

    • Stevenson and Starkweather (2010): IT recruiters valued education/experience. IT executives valued critical core competences (leadership, communication, verbal/writing, attitude, dealing with ambiguity/change).

      • IT executives largely found formal PM certification "irrelevant."

    • Buganza et al (2013): PMP® deployment in Finmeccanica (Italy's high-tech manufacturer) positive ("best practice") within corporate training.

    • No single answer on qualification value, but frameworks bring benefits. PM needs wide management/leadership skills.

    • Competence frameworks highlight leadership as key.

• Project Managers Need to Lead in Addition to Manage

  • PM needs to manage, leadership skills vital (when, how, what?).

  • Kent (2006) Clarification:

    • Managers do things right; Leaders do the right things.

    • Managing is an authority relationship, creating stability; Leading is an influence relationship, creating change.

    • Applies to various project roles (PM, leader, developer, programme/portfolio roles).

    • In reality, manager switches hats, managing and leading simultaneously.

  • "Two processes... cannot operate without each other working in tandem." (Kent, 2006).

    • Top part of Table 10.1 (Managing: purpose, products, processes – choosing efficient alternatives, resources, effort, performance, problem-solving, planning, organizing, directing, controlling).

    • Bottom part (Leading: purpose, products, processes – creating direction, unified will, thinking/valuing, thrust toward purpose, creation of social context, engendering higher state of behavior/thought, visions, alignment, inspiring).

  • Could be separate roles (Project Director/Project Manager) or combined roles.

  • Leadership Styles (Andersen, 2008): Trait-based, behavioral, power-influence, situational, integrative.

    • "Situational leadership will help the project manager achieve project success." contingent on circumstances (e.g., cultural dimensions).

  • Leadership Styles (Antonakis, Avolio and Sivasubramaniam, 2003):

    • Transformational - proactive.

    • Transformational - contractual obligations.

    • Non-transactional laissez-faire - passive/ineffective.

    • PMs often need to be proactive. Contractual obligations are critical.

    • Laissez-faire may be unsuitable; but relaxed style might be appropriate in certain project phases.

    • Styles reflect character; difficult to adopt new styles.

    • Learning Point: Global cultural values may be homogenous (Bigoness/Blakeley, 1996) but leadership approaches need to be contingent on particular culture (Morrison, 2000).

    • Focus on global leadership perspective.

• Leadership in Project Environments (Specific Focus)

  • Competence Groups (Dulewicz and Higgs, 2005 - Table 10.2): Intellectual (IQ), Managerial (MQ), Emotional (EQ).

  • Muller and Turner (2010): Examined leadership competence of successful PMs (by application area, complexity, importance, contract type).

    • Different profiles contributed to success (e.g., engineering PMs strong in critical thinking (IQ), developing (MQ), influence/motivation/conscientiousness (EQ)).

    • ICT project managers strong in all except vision (IQ).

    • Recommendations for Organizations (5 steps): Recognize project type/leadership style, assess skills, develop skills, match PM leadership to project, value PM.

  • Challenges: Small PM pool makes matching difficult. Training can increase self-awareness but reforming personality is limited.

  • Conclusions: Value of right person. Some can learn, others struggle. Realities to accept.

    • Example (generalist PM leading business plan): Needs finance expert for financial aspects. PM with finance background has an advantage but may need marketing expert.

    • Example (no luxury to wait for right leader): Need to act to keep project in control.

  • Intellectual Competences (IQ):

    • Critical analysis and judgment: Applied to all PM topics (lifecycle phases, review, success/failure).

      • Value creation as success output (beyond time, cost, quality).

    • Vision and imagination: Important at outset, but also for ongoing uncertainty/change (innovation, improvisation).

      • Less important if delivery follows plan closely.

    • Strategic perspective: Crucial when under pressure. Helps see "the broader picture."

      • Example: Colleague reminding "how far we’ve come."

      • Reassurance/inspiration from PM who maintains strategic perspective.

      • Micro-businesses may require lateral experts for strategic perspective.

  • Managerial (MQ):

    • Engaging communications: Critical importance, extensive reach (internal/external, hierarchies, stakeholders).

    • Managing resources: Discussed previously.

    • Empowering and developing: High prominence in team dimension.

    • Achieving: Vital in project environments. But need to moderate persistence if project should be stopped (economic, political, resource reasons).

  • Emotional (EQ):

    • Self-awareness, emotional resilience, motivation, sensitivity, influence, intuitiveness, conscientiousness.

    • Includes soft skills (PMI BoK, 2013: 275). Relevance to cross-cultural, multi-ethnic, multilingual projects.

    • Traits can be nurtured, but limited by inherent character/personality.

    • Influence: Powerful, often best achievable given limited project control. Essential to recognize this value.

    • Culture: Should it be a key competence group (CQ) or subset of EQ? Cultural empathy as an MQ dimension?

    • Global Leadership and Culture: Cultural values may be homogenous, but leadership approaches need to be contingent (Bigoness/Blakeley, 1996; Morrison, 2000).

      • Symbiotic leadership/management role benefits from emotional/cultural intelligence.

  • Gender Diversity and Leadership:

    • Explicit topic presents challenges; diversity varies across global projects and attitudes to gender.

    • Personal Example: Inspiring female leader, Nia, with principled style, challenging goals, strong team, high performance, respected by all stakeholders.

      • Exceptional team, a reflection of her principles and ethics.

      • "Inspirational leader."

    • Eagly (2013): Female leaders often more democratic/participative; males more top-down/command-control.

    • Both approaches important; combine good planning with good people skills.

    • Diversity: Opportunities for heterogeneous teams. Avoid biased views.

  • Negotiation and Cultural Intelligence:

    • Brislin, Worthley and McNab (2006) on Cultural Intelligence:

      • Expectation for misunderstanding is a critical skill.

      • Culturally intelligent people lower stress, wait to understand, look for patterns.

      • Establish rapport using body language, confirmatory communication (but be careful regarding critical areas like project scope).

    • Team Dynamics: Separate teams in different locations can develop distinct norms/behaviors despite coordination efforts.

      • "Chameleons" (people who blend in, make linkages, facilitate communication) are valuable.

    • Negotiation: Essential throughout project lifecycle (idea, planning, delivery, review, post-project).

      • Cultural bases affect negotiation styles (Adair, Brett and Okumura, 2001: US vs. Japanese managers).

    • Bicultural Individuals: Rise of employees identifying with >1 culture (Fitzsimmons, 2013; Branen and Thomas, 2010).

      • Opportunity to overcome difficulties (e.g., negotiation between dissimilar sets).

      • Liu et al (2012): "Successful cross-cultural negotiation can be fostered by the selection of people who, despite fully understanding their own culture, are open to change."

      • Value of team members who understand "other" cultures.

    • Economist (2011): Diasporas spread ideas/money, help host country companies in home country.

    • Culture also applies to organizational context: team member understanding collaborator's culture can unlock barriers. (Touches social networks).

  • Case Study: Africa and Projects

    • Context: "Why is it that the media only seems to talk about Africa when bad things happen?" (BBC, 2013).

      • Earlier article: failure of rural technology projects in South Africa due to ineffective Ministers of Communications, poor execution, lousy monitoring (IDG, 2013).

      • Ika (2012) discusses persistent problems of international development projects in Africa.

        • Economies overtaken by other countries since 1960s.

        • Implementation context differs managerially, economically, politically from developed nations.

        • Four "Traps" to Break (Ika, 2012): "One size fits all" (need alternative PM approaches), accountability for results (focus on long-term objectives), lack of PM capacity (improve aid agency supervision), cultural disparities (tailor PM to African values/cultures).

    • Bleak Picture vs. Boom: Africa "booming," 5.6% growth predicted (BBC, 2013). Second-fastest growing economic region (McKinsey, 2014) from wholesale/retail, transport, telecom, manufacturing.

      • Growth due to macro/political stability, structural reforms (privatization, trade openness, tax/regulatory reform).

      • Nigeria's GDP grow, >80% from "beyond resources" (McKinsey Global Institute, 2014).

    • Mobile Revolution: "Half of Africa's one billion people has a mobile phone – and not just for talking." (Guardian, 2011).

      • New enterprise culture, different uses (mobile banking).

      • Safaricom launched $40 \text{ billion}$ fibre-optic network project in Kenya (Ventures Africa, 2013).

    • "Pull" from African economies, significant portfolio of projects under development.

    • Case Reflection: Evaluate whether challenges in Africa are universal. Underlying PM/leadership styles – need for contingent approaches? Opportunity for new strategic approach? Other factors?

• Summary

  • Explored subtle differences between general and project management.

  • PM needs to understand diverse management functions and appropriate leadership style.

  • Competence frameworks inform skill-sets/knowledge areas.

  • Synergistic relationship between management and leadership.

  • Review of leadership, managerial, emotional dimensions, potential impact of gender/cultural diversity.

11 A Spectrum of Project Management Roles

• Learning Outcomes

  • Reflect on the importance of teams in the project environment.

  • Understand the team in the project and its own lifecycle.

  • Reflect on specifics and aspects of project teams.

  • Examine a sample of roles within the project management environment.

  • Explore the variety of expectations and development of project-focused roles.

  • Understand sector-specific characteristics and generic areas.

• Introduction

  • "Spectrum" emphasizes the wide variety of roles (managing, leading, internal/external, specialist/generalist).

  • Chapter follows previous discussion on management/leadership.

  • Considers individual and team roles, including traditional, virtual, disparate types.

  • Focus on personality (profiling frameworks, their value).

  • Explores common team challenges and unusual difficulties in project delivery.

  • Reviews specific PM roles in different sectors, reflecting varied expectations.

• Teams in Project Environments

  • Context: Projects involve working with others. Needs leadership, management, participation in teams.

  • "We" (collective ownership) is emphasized; understand psychology, ambition, dynamics of team(s).

  • Teams within the Project Lifecycle:

    • Team is required for project. Recruitment is important.

    • Formation Scenarios:

      • Systematic recruitment: Task-based approach, informs resource plan.

      • Innovation-based/Change Projects: Ambiguity in required people (skills, experience, personality).

    • Challenges: Knowing how many people, precise skill/experience/personality mix.

    • Sourcing Team Members: Existing human resources (negotiation), exclusive project recruitment (external hiring process), mix of internal/external, subcontractor responsibility.

    • Organization: Project organization chart (defined roles), or emergent (team figures it out).

    • Formal initiation (e.g., project initiation document).

    • Team development: communication increases, tasks, problems, issues, trust building, negotiation, conflict, improvisation, managing personalities.

    • Virtual Teams: Additional factors.

    • Autonomy: Affects style/speed; autonomous teams may produce outcomes that conflict with corporate governance.

    • Support, encouragement, motivation, development needed throughout.

    • Project delivered, celebrated, team disbands. Knowledge created, hindsight gained.

    • Team Lifecycle Stages (Tuckman, 1965; Tuckman and Jensen, 1977):

      • Forming: Orientation, testing, dependence.

      • Storming: Conflict, interpersonal polarization.

      • Norming: Overcoming resistance, in-group feeling, cohesiveness, new standards/roles.

      • Performing: Interpersonal structure as tool, flexible/functional roles, channeled energy, structure issues overcome, support.

      • Adjourning: Separation, "death of the group" after strong interpersonal feelings.

    • Wider framework for team formation and roles.

  • Types of Team:

    • Team vs. Group: "Team" implies common goal, interdependence, individual success depends on all (Crainer, 1998).

      • "Group" for aggregation of things, people, stakeholders.

    • Team Forms (Table 11.1): From traditional to virtual.

      • Traditional: Co-located, face-to-face.

      • Hybrid: Some co-located, some remote.

      • Virtual: Completely dispersed.

    • Team Formation in Short-Term Projects Case Study (Pilbeam, 2013): (International development, Africa/Asia, short duration projects).

      • Four Stages/Ten Steps (Figure 11.1): Preparation (appointment, document familiarization, contact team), Arrival (meet, establish consensus), Act (agree meetings, research/data, debrief, repeat), Account (develop/construct report).

      • Specifics: Prior knowledge of individuals motivates participation.

      • Vague specifications often require renegotiation.

      • Quick setup: swift role/responsibility establishment, independent work during day, evening info exchange.

      • Clarity in reporting style crucial for final report.

      • Team completes work, leaves, disbands (adjourning).

      • Returning: Individuals may join future teams (sixth step in lifecycle).

      • Similar to media/professional services (Chapter 8).

    • Case Reflection: Identify key aspects/challenges, project risks/change, stakeholder groups/relationships, applicability of team formation elsewhere.

    • Virtual Team Research (Hertel, Geister and Konradt, 2005): Five-stage lifecycle.

      • Preparation: Personnel selection, task design, reward systems.

        • Suitable for information-based work, needs appropriate technology, addresses integration issues.

      • Launch: Kick-off workshops, goal/role clarification.

      • Performance management: Leadership, communication, motivation, trust, knowledge management.

      • Team development: Identify development needs.

      • Disbanding: Project completion, recognition, reintegration.

    • Example (Education services company): Uses virtual teams for international projects; ad-hoc teams form for specific problems, disband after temporary project. Consistent with framework.

  • Assembling Teams with the Right Characteristics:

    • Key PM challenge: creating a good team. Difficult to get exactly whom you want.

    • Time-limited projects: Higher priority to get it right quickly.

    • Ideal Recruitment: Recruit based on explicit criteria. Negotiate for team members from existing workforce or outsource.

    • Example (New Multi-partner Project): Time/budget limited, outcome becomes core operational service.

      • Recruitment for two key individuals: strong technical skills, bilingual, interpersonal skills, customer-focused.

      • Applicants may not fit anticipated profiles (e.g., strong IT support skills, technical/organizational from consultancy; workaround for language).

      • Outcome: Complementary skills, character, experience lead to effective teamwork and successful project delivery (cannot be anticipated at start).

    • Question: To what extent can this be planned for?

  • Looking for the Right Team:

    • Difficult to predict effectiveness, but easy to recognize right characteristics.

    • Sporting metaphor: Team progress and effectiveness seen over a season.

    • Individual Character/Personality: Important insights (behavior, attitude, personality, character, getting along with others).

    • Psychometric Profiling: Used to understand character/personality. Growing industry (Economist, 2013).

      • Barrick and Mount (1991) "Big Five" Personality Dimensions (Table 11.2):

        • Extraversion: Predictor for managers/sales (less for skilled/semiskilled like engineers).

        • Conscientiousness: Predictor in all occupation groups (strong purpose, persistence).

        • (Also Neuroticism, Agreeableness, Openness).

      • Reflection: Engineer promoted to PM role needing high stakeholder engagement benefits from stronger extraversion traits.

    • Passmore (2008): Psychometrics for Coaching (personality, motivation, EI, leadership, resilience, stress, culture, interpersonal, lifestyle).

      • Valuable for team building.

    • Case Study: From Functional Specialist to Generalist Project Manager

      • Scenario: Capable but inexperienced marketing employee in head office, friction with central management, conflict with established thinking.

      • Incumbent objectively addressed issues with managing director, led to independent psychometric assessment ("so that we can understand how we can support your development better").

      • Outcome: Individual's psychometric type was "extremely small proportion" nationally. Transferred to different area.

      • Line manager's concern: perpetuating lack of team balance by recruiting "same type of people."

      • Incumbent "perplexed by sequence of events."

      • Poor fit initially, but later realized best contribution through generalist project management (diverse objectives, cross-functional/extra-organizational dimensions).

      • Path becomes clearer; everyone learns. Assessment models are part of broader reflective process.

    • Reflective Questions: Anticipating role types, individual awareness of difficulties, developing into a role, consequences of poor psychometric match.

    • Belbin® Team Role Summary Descriptors (Figure 11.2): (Resource Investigator, Shaper, Monitor-Evaluator, Teamworker, Specialist, Completer Finisher, Plant, Coordinator, Implementer).

    • Myers Briggs Type Indicator (MBTI®): (Extraversion/Introversion, Sensing/Intuition, Thinking/Feeling, Judging/Perceiving).

    • Both provide useful insights into individual preferences and team performance. Project managers can build their own interpretation.

• A Spectrum of Roles

  • Many different roles (managing/leading, coordination/administration, specialist, generalist) (Figure 11.3).

  • Wide range, inconsistent terminology, overlap.

  • Focus on delivery of requirements.

  • Role profiles may not concur with job requirement.

  • Learning Point: Many projects have significant uncertainty; role-holder needs awareness. Sector-specific knowledge helps predict this.

  • Recruiting the Project Manager: Typical Roles

    • Sample (Table 11.3): Three distinct PM roles.

      • Scenario 1 (Major Banking Institution): Specific project/technical experience, focus on one project or programme, knowledge of finance.

      • Scenario 2 (National Support Company): General administration/management skills, managing multiple stakeholders, improvisation, politically appropriate style. "calm and efficient manner; not given to panic."

      • Scenario 3 ("Curator Aquarium"- Roman Empire): Role in 97 CE (Frontinus), responsible for delivering fresh water to Rome. Fulfilled PM, champion, sponsor roles.

        • Projects (aqueducts) not called "project management." Technologies/approaches from other societies.

        • Wide responsibility (delivery, operations). Highly authoritarian style accepted.

        • Impact on social/political ramifications. Family reputation, vulnerability could be influenced.

  • This highlights that projects/PM are not modern inventions. Same core activities, similar constraints.

  • Project Directors for Different Situations:

    • Two Project Director Roles (2008/2009): One in UAE (development partnership, economic performance, employment, housing, regeneration), one in UK (infrastructure development – buildings, boulevard, canal, bridges, hotel, transport, light rail).

    • Similar title, many differences: First needed wide insight, second technical/sector-specific insights.

    • Differences in advertisement style indicate tightness of specification and anticipated level of expertise.

    • May reflect project type or lifecycle stage.

    • Third Example (Russian oil/gas sector, 2011): Project Director with complete responsibility, reporting to main board. "Relish the opportunity to turn around an underperforming project."

      • Different emphasis, requiring different abilities from setup stage.

  • Sector-Specific Project Management Roles:

    • PM well-established in some sectors (engineering, construction, system development) as key to strategy delivery.

    • Engineering Project Management Roles:

      • Require specific knowledge, skills, experience.

      • Example (Merseytravel, 2012): Project Director for £300m rail procurement project. Complex commercial/political environment. Sought extensive strategic project leadership skills, strong track record in rail sector.

      • Railway Career Pathways (2013): Generic PM roles, occupational descriptions, knowledge, skills, attributes (scope, time, cost, quality, human resources). Many components similar.

        • Specialist: Interpret schematic drawings, recognize working locations, work with other specialists.

        • Emphasizes qualification/relevant experience in engineering/construction.

        • Career Path (Figure 11.4): Graduate -> Project Engineer -> Project Manager -> Senior PM -> Programme Manager.

    • Construction Sector Project Management Roles:

      • Example (Shard in London): Inspires young people. Stories about construction. Tony Palgrave's journey (draughtsman -> mechanical engineer -> project manager).

      • Project director role: high/low level, bringing specialists together, complex logistics, pre-assembly of floors.

      • Similarities with Hafod Eryri case (Chapter 1).

      • Inspiration is a key aspect.

      • Perpetual industry, universal historical basis for BoK (engineering, system development).

      • Learning Point: Much PM guidance rooted in building, engineering, system development (clear priorities, goals, rules, protocols).

      • Compliance: Building codes, legal/regulatory requirements. UK building contracts (JCT, NEC) commonly used (NBS, 2013).

      • Disputes: 30% of respondents reported contract disputes (NBS, 2013).

      • Top 8 Difficult Matters (NBS, 2013): Delay assessment, employer variation, contractor variation, scheduling, slow construction, employer info, poor specification, late payment.

    • Construction Sector: Challenges Typical in Other Sectors:

      • Generic New Construction Project (Figure 11.5): Four typical steps (stakeholder support, planning permission, funding approval, on-site considerations).

        • Completion of each step for next.

        • Stakeholder support fundamental/universal.

        • Planning permission varies by territory but necessary.

        • Confirmed funding paramount.

      • Learning Point These challenges (time, scope change, scheduling, information, communication, specification, cash flow) are relevant to PM in other sectors.

  • Entrepreneur as Project Manager:

    • PM roles in all commercial areas (marketing, NPD, start-ups).

    • Example (Food sector, Western Africa): Project director for new business in existing holding company (Russian Federation base).

      • Start-up involves projects: staff recruitment, resource assembly, org structure.

      • Requires risk-profiling.

      • Emphasis on strong relationships with government, diverse stakeholders.

    • "Gated Processes" (Chapter 1): Relevant for entrepreneurs (stop, go, maybe for ideas, business plans, funding).

    • New venture is first-timer project (significant uncertainty, risk).

    • Entrepreneurs are closely related to PMs; risk takers but understand risks.

    • Entrepreneurs pursue opportunities without controlling all resources (borrow, integrate strategy/funds/people, develop business model, take risk) (Barringer and Ireland, 2012).

    • Example (Mexico Entrepreneurship): Paternalistic style, family models, collectivism, but "business and government offices open and close at different times" (David, 2005).

      • Government promoting entrepreneurship (CNBC.com, 2012).

      • Challenges (EY, 2013): Funding access, declining innovation, complicated/expensive indirect tax, low education participation.

      • Venture capital/bank credit weak, seed/pre-seed funding from friends/family (influenced by cultural setting).

    • Entrepreneur project manager needs different style/emphasis for family funding.

    • Start-up is a project; entrepreneur deals with all lifecycle stages (markets, incentives, resources, innovation, stakeholder landscape, compliance).

    • Perpetual uncertainty, cooperative partnerships, constraints, innovation are traits of good PMs.

• Summary

  • Explored importance of teams (traditional, virtual, their lifecycle) in project environments.

  • Examined sample PM roles across sectors to understand holistic solution provision.

  • Reviewed sector-specific scenarios, generic components, and wider applicability.

12 Develop the Capability

• Learning Outcomes

  • Reflect on cumulative topic building.

  • Identify key project management capability building blocks.

  • Understand the need for balance in project environments.

  • Consider orientation towards and success ingredients in projects.

  • Reflect on future directions in project management.

• Introduction

  • This chapter synthesizes thinking from previous chapters on project and project-manager-related concepts.

  • Aims to inform development of high-level perspectives for those delivering projects.

  • Includes additional topics like leading change (introduced strategically, linked to developed concepts).

  • Draws on research evaluating project success to frame holistic and strategic thinking.

  • Looks to the past to inform the future (PM is not new).

  • Final section: unpredictable technology, predictable demographics, reactive politics affect "one of the world’s oldest activities."

  • Concludes with reflective summing-up from the person's perspective, encouraging application, learning, development, and contribution to global project delivery.

• Context

  • Part One: Traditional PM approaches (projects, PMs, risk, processes, lifecycle, complexity, stakeholders, change).

    • Conceptual phase, feasibility, business cases, why, who, what, when, how. Assumptions, constraints.

    • Planning (stakeholder perspectives, clarity, WBS, time, resources, costs, quality, PM organization).

  • Part Two: Realistic perspectives on project delivery (Ch. 4 & 5).

    • Practical considerations, demands, pressures, consequences.

    • Borrowed from general management.

    • Learning in project environment (review process, auditing, valuable insights).

  • Part Three: Delivering successful projects is challenging.

    • Spectre of project failure -> formalized practitioner approaches (sequential/waterfall) or lighter (agile) models.

    • Contingency: Not one-size-fits-all.

    • Aggregation of PM vocabulary (people, teams, locations) into programme/portfolio management.

    • Language, communication, culture (global projects) extend discussion beyond idealized lifecycles.

    • Led to management/leadership and team building (Part Four).

• Undertaking Projects from a Holistic Perspective

  • Sample of PM roles showed diverse activities.

  • Projects are about people and all these things:**

    1. Being creative, open to new ideas.

    2. Realizing fundamentals (risk, change, stakeholders).

    3. Questioning and constructive.

    4. Considering the broader picture.

    5. Balancing analysis with action-orientation.

    6. Acknowledging unknowns.

    7. Developing new perspectives on success and failure.

    8. Constructively reviewing.

    9. Balancing formalization/informalization in planning/management.

    10. Developing good observational/project intelligence.

    11. Understanding project in programme/portfolio context.

    12. Acknowledging international aspects.

    13. Managing/leading synergistically, promoting wide involvement.

    14. Recognizing challenging team efforts (organizational behavior).

    15. Understanding spectrum of PM roles.

    16. Building strategic perspective from observation/experience.

  • These 16 points (Figure 12.1) summarize a personal PM journey.

  • Challenge: PM is generic, yet not generic; roles demand emphasis in certain areas (e.g., project director for infrastructure needs technical expertise).

  • Each point breaks into further knowledge, skills, traits, competences (like an iceberg).

  • Further Skill: Knowing how to deal with a knowledge gap:

    • Understand it fully.

    • Understand it sufficiently.

    • Delegate to an expert.

  • Key Word: Balance (time, benefit, cost, risk).

    • Example: Contract needs investigation; defer to expert judgement or capability if needed.

    • Example: Degree of formality in planning (over-planning vs. insufficient).

  • Answers become evident considering project type, stakeholder landscape, risks, insights from elsewhere.

  • Look at project longitudinally and laterally (phase-specific aspects).

  • Figure 12.2 shows changing emphasis over project lifecycle (goals, objectives, stakeholders, capability, phase).

  • Team Performance: $1 + 1 = >2$ (output > sum of parts). Homogenous team may lack "difference"; heterogeneous group offers more opportunities for positive interaction.

    • Analogy: Adding sodium to water produces fizzing (right reaction between people makes a difference).

• Delivering Projects in a Strategic Style

  • Built "bottom up": Projects, PM, PMs, empirical ingredients (risk, lifecycle), stakeholders, soft skills.

  • Emphasizes need for strategic perspective in project management.

  • Strategic Project Management: Managing strategic projects OR project managing strategically? Both.

  • Needs broad perspective, strategic action.

  • Focus Areas:

    1. Orientation towards projects: Appropriateness of approach, anticipating response, increasing likelihood of success.

    2. Change: Driver for project, essential to manage, key component of project leadership.

  • Project Societies:

    • Projects as modus operandi of organizations, increasingly becoming basis for societies/economies.

    • Tensions: Flat project structures in hierarchical societies (cultural basis of territory).

    • Growth in PM's contribution to economies (Crawford, French and Lloyd-Walker, 2013 on Australia).

    • Technology/globalization drive virtual teams; demographic changes stimulate short-term working.

    • Challenges for project workers: career paths in temporary organizations.

  • Leading Change:

    • Change often provokes strong reaction (silent or expressed).

    • Sources of Resistance (Piderit, 2000): Cognitive, emotional, behavioral.

      • Example: Users defending "old system" when new one replaces disliked one.

    • Lewin (planned change) vs. Burnes (emergent change, 2004): Both relevant to projects.

      • Planned change is about intended outcome; emergent change about unpredictable aspects.

    • Kotter (1996) "Leading Change" (8-stage process):

      1. Establish sense of urgency.

      2. Create guiding coalition.

      3. Develop vision and strategy.

      4. Communicate change vision.

      5. Empower broad-based action.

      6. Generate short-term wins.

      7. Consolidate gains and produce more change.

      8. Anchor new approaches in culture.

    • Exudes leadership; framework for harnessing leadership qualities (Chapter 10).

• Project Success Factors

  • Success is difficult to define/measure.

  • Dvir, Raz and Shenhar (2003): Success based on proper definition of project goals/deliverable requirements (from stakeholder, PM, contracting office perspectives).

  • Jugdev and Muller (2005): Success changes over lifecycle. PMs should:

    • Establish critical success factors at outset.

    • Understand stakeholders, determine success category for each.

    • Avoid single-point indicators; cover efficiency and effectiveness.

    • Remember success measures change.

    • Develop good relationships with key stakeholders.

  • Cooke-Davies (2002): Eight factors critical to PM success: six correlated with on-time, two with on-cost, one with project success, three with corporate success.

  • Ika (2009) Analysis (change over time):

    • 1960s–1980s (Period 1): Iron triangle (time, cost, quality) as success factor.

    • 1980s–2000s (Period 2): Added client/end-user satisfaction, benefits to stakeholders/project personnel.

    • 21st century (Period 3): Added strategic objectives of client organization, business success.

    • Highlights challenge of increasing expectations. (Chapter 6).

  • Shenhar et al (2001): Four-part framework for measuring success:

    • Project efficiency.

    • Impact on the customer.

    • Business success.

    • Preparing for the future.

    • Efficient work without effective outcome disappointing business results.

  • Capability: Mindful of all success characteristics, practice suggestions, changing stakeholder expectations.

  • Technology changed customer/supplier interaction (online retailers vs. poor service providers like UK energy suppliers).

  • Context for communicating project success to broad audience.

  • Case Study: The Case of Cricket

    • Context: Cricket World Cup semi-final (India vs. Pakistan) -> >1 billion audience. Sri Lanka is high ranked. Business to global audiences.

    • Ashes Test series (England vs. Australia): Passion, financial well-being (e.g., Trent Bridge stadium).

    • Trent Bridge (2013): Hosted Ashes Test. Extensive planning, "culmination of a master plan."

    • Problem: Match might end by day three, leading to significant financial loss for Trent Bridge and local businesses.

    • **"Luck of the ball": ** Australian player Ashton Agar (not out decision) extended game, avoiding financial loss. England won.

    • Outcome: Trent Bridge reported record income/enhanced reputation. "Had Agar been given out stumped… Club would have reported a financial loss."

    • Planning for mega-events is substantial; weather is a risk, but gameplay is unpredictable.

    • Learning Point "Acknowledging the role of 'luck' is pertinent in project environments." Influences but doesn't guarantee outcomes.

    • Case Reflection: Strategies to overcome luck, stakeholder expectations, business case modeling challenges, risk profile.

• What the Future Holds

  • Predicting future: look at past, understand influencing factors.

  • PM Deployment Pattern:

    • Hard skills stable (decades). Accredited training maintains knowledge, skills, vocabulary (influenced by sector, person's character/experience).

    • Stability not matched by stakeholder expectations. Wider, better balanced PM skills/approaches needed.

    • Fundamental principles largely unchanged (e.g., Roman Empire project manager - Figure 12.3: outsourcing different then vs. now, work-life balance issues).

    • Hughes (2013) on Victorian London sanitation projects: Cholera epidemics, bad smell from Thames (1840s) drove sanitation project. Emergence of Institution of Civil Engineers. Holistic stakeholder management.

    • Joseph Bazalgette's sewers (for 3.5m people, 30% greater than population) still in use. London population 8.4m in 2014, upgrade project by 2016.

    • Technology enables efficiency, but problems still arise (innovation, stakeholders).

    • "History repeats itself."

  • Projects Are About People; People Will Change:

    • Advertising shows societal changes, technology leads to intergenerational disconnection (digital world, job changes).

    • But sewers, buildings, infrastructure still needed. Entrepreneurs still thrive.

    • McKinsey Quarterly (2014) on "Management intuition for the next 50 years": Dynamism in emerging markets, tech/connectivity changes, ageing populations -> colliding in volatile world.

    • Change is constant, driven by projects. PM approaches need to be nimble.

    • Fundamental principles remain, but new generations act them out differently.

    • Globalization, international aspects, cultural dimensions: Economic shift East -> cultural landscape changes project landscape. PM styles/expectations may shift (individual -> collective).

    • Stakeholder power profile will change.

    • Project management must listen, observe, analyze, reflect. Ask why, what, when, who, how?

    • PM as "metaphoric bridge between strategy and operations" is crucial.

• Summary

  • Summing up: bringing together topics, needing balance in PM approach/style based on project type/stakeholder context.

  • Key factors for success, acknowledging it cannot be guaranteed. PM influences outcomes.

  • Develop insights to apply right approach, right way, right time.

  • Future is uncertain, but projects guaranteed. Enjoy anticipation, use insight, overcome challenges, deliver well, celebrate, look forward.