Course Overview

This lesson traces how a project manager's leadership style shifts across the life cycle, moving from directive and democratic approaches to transactional and coaching roles as a project evolves. Ultimately, the material positions the project manager as a vital bridge between strategic vision and operational delivery, emphasizing that both technical precision and interpersonal flexibility are essential for professional success.

Foundational Concepts of Project Management

Architect of Execution Dock ×

Introduction to Project Management

Project management is the application of knowledge, skills, tools, and techniques to project activities to meet specific requirements. It allows organizations to execute strategies, optimize resource utilization, and deliver value to stakeholders. Managing a project requires balancing constraints, including scope, quality, schedule, budget, resources, and risk.

What the discipline actually covers

Project management is frequently mistaken for scheduling. Building a schedule is one activity within it, but the discipline is broader: deciding what will be delivered and what will not, sequencing the work, securing and allocating people and money, managing uncertainty before it becomes damage, coordinating stakeholders who often want different things, and controlling change once work is underway.

What binds these together is integration. Specialists own the parts; the project manager owns the coherence of the whole. A decision that looks correct inside one specialism — a design change, an early hire, a deferred test — may be wrong for the project once its effect on the other constraints is traced. Recognising those interactions is the core of the role.

Plans are also refined rather than fixed. Progressive elaboration is the principle that detail is added as more becomes known: early estimates are deliberately coarse, and they tighten as requirements settle and uncertainty falls. A plan that claims precision it cannot possess is not a better plan.

The competing constraints

The six constraints named above are not a checklist to satisfy independently. They compete, and the defining skill is trading them against one another deliberately rather than accidentally.

• Scope — the totality of the work required and the deliverables produced.
• Quality — the degree to which those deliverables meet requirements and are fit for their purpose.
• Schedule — the time available and the sequence in which work must occur.
• Budget — the funding authorised for the work.
• Resources — the people, equipment, materials, and facilities the work consumes.
• Risk — exposure to uncertain events that could help or harm the objectives.

Moving one generally forces another to move. Compressing a schedule usually costs money, consumes more resources, or sheds scope; protecting scope and budget against a slipping schedule usually costs quality. The older triple constraint or “iron triangle” captured the same idea with three variables — scope, time, and cost — with quality dependent on their balance.

The consequence is governance, not arithmetic. Because every trade-off reassigns value between things stakeholders care about, it is a decision for the sponsor and affected stakeholders through change control, not one for the project manager to absorb quietly.

Projects, programmes, and portfolios

Projects rarely exist alone. Organizations nest them inside larger structures, and the level determines who decides what.

The distinction is one of purpose. A project asks whether the work was delivered correctly. A programme asks whether the combined benefit was achieved. A portfolio asks a prior question — whether this is work the organization should be doing at all, given finite funding and competing candidates. Portfolio selection is where strategy is actually enacted; project execution merely carries it out.

What counts as success

The traditional measure is delivery against the baselines: on time, within budget, in scope, and to the agreed quality. That test is necessary but insufficient. A project can satisfy every baseline and still fail, if the thing it produced does not get used or does not produce the benefit that justified funding it.

Benefits are therefore usually realised after the project closes, once the deliverable is in operational use. This has a direct implication for the project manager: success criteria must be defined and agreed during Initiation, while there is still freedom to shape the objectives, and the handover into operations must be planned rather than assumed.

Project vs. Operations

Organizations balance two types of work: project-based work and ongoing operations. Organizations must distinguish between these two modes of execution to allocate resources and apply appropriate management frameworks.

What makes work project work

• Temporary — it has a definite start and finish. Temporary describes the endeavour, not the deliverable: the project to build a bridge ends, while the bridge stands for decades. Nor does temporary mean short.
• Unique — there is no exact precedent. Two office fit-outs to the same drawings still differ in site, team, suppliers, and regulation, and those differences are where the work lives.
• Progressively elaborated — understanding deepens as the work proceeds, so plans are refined rather than perfected up front.
• Cross-functional — it draws people from multiple specialisms, frequently into a team that disbands at closure.
• Uncertain — because the output is unique, estimates are forecasts rather than measurements, and risk is inherent rather than exceptional.

A project ends for one of several reasons, and only the first is a success: the objectives were achieved; the objectives cannot or will not be met; funding is exhausted or withdrawn; the need no longer exists; the resources are no longer available; or it is terminated for legal cause or convenience. Closure is a defined activity in every one of these cases, not only the happy one.

What makes work operational

• Repetitive and ongoing — the same process runs again and again with no planned end date.
• Standardised — inputs and outputs are known, and variation is a defect to be removed rather than a discovery to be managed.
• Efficiency-oriented — the goal is throughput, reliability, and unit cost, not novelty.
• Permanently staffed — teams are stable and usually sit within a functional structure.
• Measured continuously — performance is judged against steady-state indicators such as uptime, cycle time, or cost per transaction, rather than against a baseline that was fixed once.

Where the two meet

The categories are distinct but the work is connected, and the connection is where projects most often fail quietly. The critical junction is handover: the point where a deliverable passes into operational custody. Getting it wrong produces the familiar outcome of a system that was delivered on time and on budget and that nobody can actually run.

Operational readiness is the project manager's responsibility to plan for, and it typically includes training, documentation, a support model, spare parts or licences, and agreed service levels. Because benefits are realised in operations rather than during the project, a project that ships a deliverable without preparing the receiving organization has not finished its job.

Traffic runs the other way too. Operations generate projects — a capacity expansion, a system upgrade, a regulatory change, a process improvement — so the boundary is crossed repeatedly throughout an asset's life, not once.

Why the distinction matters in practice

• Funding and governance — projects receive discrete authorisation through a business case, a charter, and stage gates; operations receive recurring budgets. Funding a project like an operation removes the decision points where it could have been stopped.
• Metrics — projects are measured as variance against a baseline; operations are measured against steady-state targets. Applying the wrong instrument produces confident, meaningless reporting.
• Staffing — projects borrow people that operations own. This is the structural source of matrix tension, and it is why a project manager's authority over resources is so often partial.
• Management approach — optimising a project for efficiency starves it of the exploration it needs, and managing operations as a project imposes ceremony on work that should simply run.

A worked example

Consider payroll. Designing, configuring, testing, and implementing a new payroll system is a project: it is temporary, it produces a unique result, and it ends once the system is accepted and handed over. Running payroll every fortnight afterwards is an operation: repetitive, indefinite, and judged on accuracy and timeliness rather than against a baseline.

The same business domain contains both modes, and they demand different management. Note also where the judgement finally lands: the project is not successful because it went live on schedule, but because payroll now runs reliably. The operational outcome is the measure of the project.

The Project Life Cycle

The project life cycle represents the series of phases a project passes through from its initiation to its closure. These phases provide a framework for controlling project delivery. A standard project life cycle consists of five sequential phases.

1. Initiation

   The organization defines the initial scope, establishes the project purpose, and secures formal authorization. A project charter is drafted during this phase to name the project manager and grant them authority to apply organizational resources to project activities.

   Typical activities: developing the business case, assessing feasibility, identifying stakeholders, framing high-level objectives and success criteria, appointing the project manager, and making a first pass at risk.

   Key outputs: project charter, business case, initial stakeholder register.

   Exit criteria: the charter is approved and funding is authorised.

2. Planning

   The project team develops the operational roadmap. This involves refining the project requirements, creating a work breakdown structure, scheduling tasks, estimating costs, and formulating risk mitigation strategies.

   Typical activities: collecting requirements, defining scope, decomposing work, sequencing activities, estimating durations and costs, planning resources and procurement, and building the risk register.

   Key outputs: the project management plan, and the scope, schedule, and cost baselines against which performance will later be judged.

   Exit criteria: the plan is baselined and approved.

3. Execution

   The project team completes the activities outlined in the project plan to develop the required deliverables. This phase involves coordinating human resources, managing stakeholder communications, and consuming the allocated budget.

   Typical activities: producing deliverables, acquiring and developing the team, assuring quality, managing communications and stakeholder engagement, conducting procurements, and implementing approved changes.

   Key outputs: completed deliverables, work performance data, change requests.

   Note: this phase consumes the majority of the budget and effort, which is precisely why it must be measured rather than trusted.

4. Monitoring and Controlling

   This phase runs concurrently with execution. The project manager measures current project performance against the planning baselines. If variances are identified, the manager implements corrective actions or processes formal change requests.

   Typical activities: measuring progress against the baselines, variance and trend analysis, integrated change control, monitoring risks, controlling quality, and validating scope with the customer.

   Key outputs: work performance reports, approved or rejected change requests, corrective and preventive actions.

   Note: validating scope is formal acceptance of deliverables by the customer, which is distinct from controlling quality — the internal check that the deliverable is correct in the first place.

5. Closing

   The project manager formalizes the final acceptance of the project deliverables from the client or sponsor. Administrative close-out activities occur here, including archiving documentation, releasing project resources, and conducting a lessons learned review.

   Typical activities: obtaining final acceptance, closing contracts, transitioning the deliverable into operations, releasing the team, capturing lessons, and archiving records.

   Key outputs: formal sign-off, final report, lessons learned register, archived project records.

   Note: closure is performed even when a project is terminated early. A cancelled project still has contracts to settle, resources to release, and lessons worth more than the ones a successful project produces.

Key planning concepts

Planning is the phase where most of a project's eventual fate is decided, and a handful of concepts carry a disproportionate share of the weight.

• Work breakdown structure (WBS) — a hierarchical decomposition of the total scope. It obeys the 100% rule: the WBS captures all of the work and nothing that is not in scope. Work absent from the WBS is, by definition, work nobody planned, estimated, or resourced.
• Work package — the lowest level of the WBS: the point where work can be reliably estimated, assigned, and tracked.
• Critical path — the longest path through the network of activities, which determines the shortest possible project duration. Activities on it have no float, so any delay to one delays the project.
• Float (or slack) — how long an activity can slip without delaying the project. It is where recovery options live.
• Rolling wave planning — planning imminent work in detail and distant work coarsely, then elaborating it as it approaches. This is progressive elaboration applied to the schedule.
• Baselines — the approved versions of scope, schedule, and cost. They are the reference for measuring performance, which is why they may only be altered through change control.

Measuring performance against the baselines

Monitoring and Controlling depends on comparing what was planned with what has actually happened. Earned value analysis does this by reducing progress to three measurements taken at the same moment.

• Planned value (PV) — the budgeted cost of the work that should have been completed by now.
• Earned value (EV) — the budgeted cost of the work actually completed.
• Actual cost (AC) — what has genuinely been spent achieving it.

From these, schedule variance is EV − PV and cost variance is EV − AC; negative values indicate behind schedule and over budget respectively. The same comparison expressed as a ratio gives the schedule performance index (EV ÷ PV) and the cost performance index (EV ÷ AC), where any value below 1.0 signals underperformance.

The reason this matters is that percentage complete, reported by the person doing the work, is an opinion. Earned value converts progress into the same unit as the budget, which makes optimism visible early enough to act on.

Controlling change

Change is not a failure of planning; on a unique endeavour it is inevitable. What distinguishes a controlled project is that changes pass through a defined route: a request is raised, its impact on all the constraints is analysed, an authorised body accepts or rejects it, and only if approved are the baselines updated.

Two failure modes explain why the discipline exists. Scope creep is the uncontrolled expansion of scope without corresponding adjustment to time, cost, or resources — each addition individually reasonable, collectively fatal. Gold plating is the team adding work nobody asked for, on the assumption the customer will be pleased. Both consume budget that was never authorised, and both are invisible in reporting precisely because they never went through change control.

Phase gates

The boundary between phases is a decision point, not a formality. At a phase gate — also called a stage gate or kill point — the sponsor reviews performance so far and the continued validity of the business case, then chooses to continue, continue with modifications, hold, or terminate.

The gate's real function is to make stopping legitimate. Without explicit decision points, projects continue on momentum and sunk cost long after the need that justified them has evaporated. Terminating a project at a gate is the system working, not failing.

How the variables behave across the life cycle

Several patterns hold across almost all projects, and each has a practical consequence.

• Cost and staffing are low during Initiation, rise through Planning, peak during Execution, and fall sharply at Closing.
• Risk and uncertainty are highest at the start, when least is known, and decline as decisions are made and unknowns resolve.
• The cost of making a change moves in the opposite direction: cheapest at the start, rising steeply as work is built on earlier decisions.
• Stakeholder influence over the outcome is greatest at the beginning and diminishes steadily thereafter.

Read together, these curves explain why early phases repay disproportionate attention. Influence and cheap change are both concentrated at exactly the moment when the least is known — and the temptation to rush past that moment toward visible progress is the most expensive instinct in the discipline.

Choosing a life cycle

The five sequential phases described above are a predictive life cycle, appropriate when requirements are well understood and stable, and scope can be fixed early. It is not the only option, and the choice should follow the nature of the work.

• Predictive — scope, schedule, and cost are determined early; phases run largely in sequence. Suits stable, well-understood work such as construction or regulated manufacturing.
• Iterative — repeated cycles progressively refine a single product, deliberately revisiting earlier decisions as understanding improves.
• Incremental — the deliverable is produced in usable pieces, each adding function to what already works.
• Adaptive (agile) — used where requirements are volatile. Time and cost are fixed in short timeboxes while scope is negotiated continuously.
• Hybrid — combines approaches, commonly predictive governance over an adaptive delivery team. This is what most real organizations actually run.

Whatever the approach, monitoring and controlling remains continuous rather than a stage to be reached. Only the size of the feedback loop changes.

Roles and Leadership Adaptability of the Project Manager

The project manager acts as the bridge between organizational strategy and execution. The role demands core competencies across technical methodologies, strategic business alignment, and interpersonal leadership.

Because the objectives, team dynamics, and operational risks change within each phase of the project life cycle, a project manager must adapt their leadership style to match the current phase.

The three competency areas

The competencies named above — technical methodology, strategic and business alignment, and interpersonal leadership — correspond to PMI's Talent Triangle, introduced in 2015 to argue that technical skill alone does not make a capable project manager. PMI renamed the three sides in 2022 to reflect how the work had changed.

• Ways of Working (formerly Technical Project Management) — command of the methods themselves, and of more than one of them. Predictive, agile, design thinking, and hybrid approaches each suit different problems, and competence means applying the right one rather than defaulting to the familiar one.
• Power Skills (formerly Leadership) — the interpersonal capabilities the role runs on: collaborative leadership, communication, empathy, and an innovative mindset. The rename was pointed, since these are routinely dismissed as “soft” while being the skills that most often decide whether a project succeeds.
• Business Acumen (formerly Strategic and Business Management) — understanding the organization and its industry well enough to make good decisions and to see how the project connects to strategy.

The project manager as integrator

The role's defining characteristic is that nobody else holds the whole picture. Every specialist sees their own part clearly; the project manager is accountable for how the parts fit, for the trade-offs between constraints, and for the decisions that fall between two functions and would otherwise fall to neither.

This makes communication the dominant activity of the job rather than an adjunct to it — a share of a project manager's time commonly cited as up to 90 per cent. The implication is that a project manager who is technically excellent and communicatively poor is, in the terms of the role, simply poor.

Authority and organisational structure

How much authority a project manager actually holds is largely determined by the organization's structure, not by the individual. This is why identical job titles carry radically different power across companies, and why the leadership adaptation described below is constrained by circumstance.

In the weaker structures, authority has to be earned through influence because it is not granted by position. A project manager who cannot direct can still persuade, and in a functional or weak matrix organization that is the entire job.

Leadership and management are not the same thing

The role demands both, and they are not interchangeable. Management works through position and process — directing work, allocating resources, and applying systems to get things done correctly. Leadership works through influence — setting direction, building commitment, and getting people to want to get the right things done.

Process without influence produces a compliant team building the wrong thing on schedule. Influence without process produces an inspired team missing its dates. The adaptation described below is the deliberate rebalancing of the two as a project's needs change.

Working with conflict

Conflict on a project is normal rather than pathological. Its common sources are competing schedules and priorities, contested resources, technical disagreement, cost, and occasionally personality. Because a project manager frequently lacks the authority to simply settle disputes, technique matters.

• Collaborate / problem solve — incorporate multiple viewpoints and work to a genuine consensus. Slowest, and the only one that reliably resolves the underlying issue rather than the symptom.
• Compromise / reconcile — find a solution bringing some satisfaction to all parties. Everyone concedes something; nobody is fully satisfied.
• Smooth / accommodate — emphasise agreement over difference. Useful to preserve a relationship or buy time; it does not settle anything.
• Force / direct — impose one view at the expense of others. Fast and sometimes necessary in a genuine emergency, but produces a win–lose outcome and lasting resentment.
• Withdraw / avoid — retreat or defer. Legitimate when the issue is trivial or the parties need to cool down; corrosive when it is a substitute for deciding.

Collaboration generally produces the most durable resolution. Forcing and avoiding are the two that most often reappear later, larger.

How teams develop

Because project teams are assembled temporarily from people who may never have worked together, they predictably pass through stages, described by Tuckman as forming, storming, norming, performing, and adjourning.

The sequence is the practical justification for adapting leadership style. A newly formed team genuinely needs direction; a storming team needs conflict addressed rather than smoothed over; a performing team needs to be empowered and then left alone; and an adjourning team needs its closure handled with some care, because the way people leave a project shapes their willingness to join the next one. Applying a performing team's autonomy to a forming team — or a forming team's direction to a performing one — is the most common failure of leadership adaptability.

Module Summary

The infographic below consolidates the whole module: the project–operations distinction and the six core constraints on the left, and the five life cycle phases mapped to their leadership styles on the right.

Click to enlarge

References

• Abbas, M., & Ali, R. (2023). Transformational versus transactional leadership styles and project success: A metanalytic review. European Management Journal, 41(1), 125–142. DOI: 10.1016/j.emj.2021.10.011
• Liu, Y., Zeng, Y., Papadonikolaki, E., Maritshane, M., & Chan, A. P. C. (2024). The evolution of the project manager's competencies: a systematic literature review. Central European Management Journal. DOI: 10.1108/CEMJ-09-2025-0283
• Project Management Institute. (2021). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (7th ed.). Project Management Institute. ISBN: 9781628256642

Knowledge Check

Module 1 Quiz

Ten questions covering the project life cycle, the project–operations distinction, and leadership adaptability. Select an answer to see whether it is correct and why.

1 / 10

Hint Previous Next