Projects & Project Management

Process, Product, Project and Operations

Before you can manage a project you need to know exactly what one is, and what it is not. Four words get blurred all the time in everyday speech: process, product, project and operations. This section pulls them apart, because almost every later idea in the subject (the business case, the charter, the plan, Scrum) assumes you can tell them apart.

Process and product

So if a team ships working code but no user guide, no tests and no maintenance notes, they have delivered only part of the product.

Why the subject cares so much about process

In 1986 Parnas and Clements wrote a famous paper with a cheeky title, A Rational Design Process: How and Why to Fake It. Their argument has two halves. First, nobody can actually follow a perfectly rational process that runs straight from requirements to finished product: users don't know everything they want at the start, important details only surface late, and requirements change. Second, we should still document the product as if we had followed such a process, because a defined process guides the team and makes life easier for the people who review and maintain the work later.

The opposite of a defined process is ad hoc work, where people just do whatever seems right at the moment. The slides' verdict is that ad hoc work rarely succeeds. They give three reasons for the subject's focus on process:

What a project is exam

Two words in that definition do most of the work. Temporary means the project has a start and an end; unique means it has not been done before in exactly this form. The slides expand the definition into six key characteristics.

Taking each in turn: a project introduces change (after it, the organisation works differently); it is temporary, with a defined beginning and end, although its outcome may last for decades; it is cross-functional, cutting across organisational boundaries such as IT, the users, finance and outside vendors; it deals with the unknown, so it carries uncertainty and risk; it is unique; and it varies in size, whether you measure that in people, dollars or time.

Textbooks add three more features. A project has a sponsor, the senior person who pays for it and champions it. It has a specific objective. And its details are progressively elaborated, which means they are filled in gradually as the team learns more, rather than all being known on day one.

Project versus process versus operations

A project is most often confused with the two things on either side of it. The key contrast is that a project is temporary and unique, whereas a process is reused across many projects and operations (also called Business As Usual, or BAU: the day-to-day running of the organisation) goes on indefinitely.

The three fit together in a chain. A project uses a process, and once the project hands its product over, that product moves into operations. In the Medic case (the tutorials' running case study, introduced fully in 1.11: a virtual-reality surgical simulator built for a Melbourne eye and ear hospital), the hospital's own IT department, RVEEH IT, maintains the simulator after handover. Building the simulator is the project; keeping it running afterwards is operations.

Why organisations use projects

If projects are risky and temporary, why not just do everything as part of normal operations? The slides give six reasons why organisations deliberately package work into projects.

1. Strategic alignment. Key activities line up with the organisation's strategy, with visibility at the right levels of management.
2. A way to prioritise work, whether the driver is benefits, regulation or a hardware refresh.
3. Structured change. Change is delivered in a structured, formal way, outside Business As Usual, so it doesn't disrupt daily operations.
4. Efficient use of limited resources: people and money are scarce.
5. Ownership and accountability for both the process and the benefits.
6. Clarity, buy-in and agreement on what will be done, when, by whom, why, and with what outcomes.

Programmes and portfolios

Projects rarely live alone. A programme groups related projects so that together they deliver shared benefits, and a portfolio is the whole set of an organisation's projects and programmes.

Project Management and the Triple Constraint

A project is temporary, unique and full of unknowns, so left alone it drifts: it runs late, costs more than promised and delivers the wrong thing. Project management is the discipline that stops that drift. This section defines it, shows the one picture every PM carries in their head (the triple constraint), and introduces the three broad approaches to running a project.

Two definitions exam

The slides' version is the more useful one to learn, because it lists both the verbs (plan, delegate, monitor, control, motivate) and the six targets a PM is held to: time, costs, quality, scope, benefits and risks. PMI's version is short and general: PM is just applying know-how to project work so that it meets its requirements.

Where project management adds value

Why pay for a project manager at all? According to the slides, PM adds value in six ways:

The triple constraint (iron triangle) exam

Every project is squeezed by three limits at once: how much it must deliver, how long it has, and how much it can spend. The slides draw these as the three sides of a triangle, often called the iron triangle because its sides are locked together.

The point of the triangle is that its sides are linked: change one side and at least one other must change, or quality suffers. Step through the Medic example below to see the four ways a PM can respond when the scope grows.

The triangle has critics. They argue that it misses three more things that matter just as much, which together with the original three make up the "six triple constraints": quality, risk and customer satisfaction (ProjectSmart 2009).

Three approaches to managing a project

The PMI reading describes three broad approaches, which Part II and Part III develop in detail. The choice depends mainly on how settled the requirements are.

• A predictive approach suits stable requirements: you plan up front and run the phases in sequence (waterfall is the classic example).
• An adaptive approach suits volatile requirements (ones that keep changing): it works iteratively (repeating short cycles) and incrementally (delivering the product in growing slices). Scrum is adaptive.
• A hybrid approach mixes the two.

The PM Process, Planning and Gates

Knowing what project management is doesn't tell you what a PM actually does from Monday to Friday, or in what order. PMBOK answers that with five process groups; the slides add a planning cycle and the idea of breaking a project into phases with gates, so that nobody commits all the money on day one.

Five process groups

PMBOK organises project work into five process groups. Four of them follow one another in time; the fifth, monitoring and controlling, runs alongside the others and feeds back into them. Step through the diagram to build it up.

Planning is a cycle

The Week 1 slides present planning itself as a cycle. It runs from the charter and scope to the schedule, then resources, budget and cost, quality, risk and communication, and then back to the start.

Because planning keeps cycling, the plan is a living document: it is updated as the team learns. Its baselines for scope, schedule and cost, however, change only through formal change control (LinkedIn reading), so that nobody quietly moves the goalposts. The plan itself is covered in Part V, and change control in Part X.

Phases with management reviews exam

The biggest risk with a big project is pouring money into something that has stopped making sense. The answer is to split the project into phases, each ending at a gate (also called a "kill point") where management makes a go/no-go decision before committing more money.

Knowledge Areas and Organisation Structures

Two older topics round out the picture of project management. PMBOK's knowledge areas carve PM into subjects a PM must master, and the organisation structure decides how much power the PM actually has to use them. Neither is in the 2026 slides as a headline topic, but both appeared on predecessor subjects' exams, so the guide keeps them.

PMBOK knowledge areas older exam topic

A knowledge area is a field of PM expertise, such as managing cost or managing risk. Older PMBOK editions name four core knowledge areas, the ones that lead directly to project objectives: scope, time, cost and quality. Four facilitating areas support them (human resources, communications, risk and procurement), and integration ties all of them together. The 5th and 6th editions of PMBOK list ten areas instead.

Notice how the four core areas line up with the triple constraint from 1.2: scope, time and cost are its sides, and quality sits in the middle. Procurement means buying goods or services from outside suppliers.

Organisation structures older exam topic

How much power a PM has depends heavily on how the organisation is structured. In a functional organisation, staff belong to departments (engineering, finance and so on) run by functional managers. In a projectised organisation, staff belong to projects run by PMs. A matrix organisation is a mix: staff belong to a department and work on projects, so they have two bosses. A "weak" matrix leans functional; a "strong" matrix leans projectised.

Reading the table from left to right, the PM's authority, budget control and time on the project all grow, but each structure brings its own main problem.

The Project Manager and the Scrum Master

Who actually does project management? In a traditional project the answer is one person, the project manager (PM). In Scrum there is no such role, and yet the work still has to be done. This section looks at what a PM is and does, and then at how Agile redistributes that work and changes the style of leadership from command and control to servant leadership.

What a PM is

The slides describe a PM as a highly skilled knowledge worker and change agent: someone who takes accountability, makes the project's goals their own, and inspires a shared sense of purpose in the team.

A traditional PM's key activities exam

The slides group a traditional PM's work under four headings: planning, organising, leading and controlling. Learn the four headings first, then the items under each.

Agile: "a change is occurring" exam

The slides' message is that in pure Agile there is no defined PM role. The key activities are shared across the team, but they are still done formally, with appropriate documentation, and there is some alignment between a Scrum Master and a PM. (The Scrum Master is the Scrum role responsible for making Scrum work: coaching the team and removing impediments, the obstacles that slow it down.)

The biggest shift is in leadership, which moves from command and control to servant leadership.

The servant leader, as SAFe (the Scaled Agile Framework, Part XI) describes it via Cornelius (2014), does six things:

1. Coaches and facilitates teams to deliver.
2. Emphasises objectives.
3. Is invested in the program's overall performance.
4. Asks the teams for answers.
5. Lets teams self-organise and hit their stride.
6. Helps others fix issues.

Traditional PM versus Scrum Master

The table compares the two roles along the same dimensions. The last row matters most: in Scrum the PM's duties don't disappear, they are split across three roles.

What happens to PMs in agile organisations

Cornelius (2014, PMI) finds that an agile PM has far fewer activities, because the team absorbs them: planning activities, for example, drop from 24 to 2. Former PMs move into one of three kinds of role. Strategic PMs look after portfolio ROI (return on investment, 1.9); leading PMs become Release Train Engineers (a SAFe role), Product Owners or Scrum Masters; and lagging PMs report velocity (how much work a team finishes per sprint), defects and finances.

So agile changes leadership but does not remove it, and agile teams still plan, just more often (Mountain Goat).

Project Success and Failure

Software projects have a poor reputation, and much of the rest of the subject exists to improve the odds. But before you can improve the odds you need to agree what "success" even means, and know which factors really drive it. This section covers the slides' thought experiment, the industry's best-known scorecard (the Standish Group's CHAOS reports), why projects fail, and how good PM counters each cause.

"Success or failure: you decide"

A Week 1 slide describes two projects. Project 1 was estimated at $500m, cost $1.35bn (+170%), and took more than 5 years. Project 2 was estimated at $7m and 6 years, but finished at $102m and 16 years.

Project 2's overrun is worth computing the way an exam would want it, because "percent over budget" is measured against the estimate:

% over budget = (actual − estimate) / estimate
              = (102 − 7) / 7
              = 95 / 7
              = 13.57  →  1,357% over budget, and 16 − 6 = 10 years late

Project 2 matches the Sydney Opera House, which failed on the triple constraint and yet became a national icon. The lesson is that success depends on the criteria, the stakeholder and the time horizon: a taxpayer at the time and a tourist today would give different verdicts. That is why success criteria should be defined in the charter (1.10), before arguments start.

The CHAOS categories exam

The Standish Group's CHAOS reports survey thousands of IT projects and sort each into one of three categories.

• A successful project is on time and on budget, with all features and functions as initially specified.
• A challenged project is completed and operational, but over budget, over time, or with fewer features.
• A failed project is cancelled during development. The 2009 report also counts systems that were delivered but never used.

Across all IT projects, the figures barely move between 2011 and 2015, and challenged is the largest category in every year.

Over a longer span, success was 16% in 1994 and 32% in 2009 (ProjectSmart). In 2015 Standish redefined success as on time, on budget, with a satisfactory result, because some projects had met the triple constraint yet delivered no value. (Notice the parallel with the Opera House: the old definition could call a useless project a success and an icon a failure.)

Three more findings from CHAOS 2015

The 2015 report, as InfoQ describes it, covered 50,000 projects and had three other findings.

• Agile beats waterfall at every project size. Overall, 39% of agile projects succeeded and 9% failed, against 11% and 29% for waterfall. Among large projects, 18% of agile ones succeeded compared with 3% of waterfall ones.
• Small projects make up 62% of all successful projects, against 2% for "grand" ones, since the larger and more complex a project is, the riskier it is. Agile helps "by failing earlier and restarting faster".
• Vague goals beat precise ones, because "only that which is unknown produces real value".

The CHAOS 2015 success factors exam

The slides list ten factors, each with a percentage weight, and the meanings come from InfoQ. Notice how much of the weight sits in the first four.

The slides draw three conclusions from this list.

1. The factors are relatively constant over time.
2. The top four, which together account for 60%, are non-technical and hard to change.
3. A broader organisational system is at play, which is why simply "knowing the reasons" doesn't fix them.

Why projects fail exam

The common causes are these. Many are the CHAOS success factors turned upside down.

1. There is no executive support.
2. User involvement is poor.
3. Objectives are unclear or requirements keep changing, which leads to scope creep: the slow, uncontrolled growth of scope as small additions pile up without matching changes to time or budget.
4. Estimates and schedules are unrealistic.
5. Risk, such as new technology, goes unmanaged.
6. Staff are unskilled or inexperienced.
7. Communication and stakeholder management are poor. (A stakeholder is anyone who affects, or is affected by, the project.)
8. Monitoring and control are weak, so slippage is spotted late.
9. The project is large and complex.
10. The organisation makes strategic or organisational mistakes.

How good PM contributes to success exam

Good PM counters each failure cause with a specific practice. Most of these practices are the subject of a later Part.

Project Screening and Selection

"If you don't know where you're going, any road will take you there." Every organisation has more project ideas than people and money to carry them out. Without a deliberate way of choosing, the loudest idea wins rather than the best one. So, the slides argue, organisations need a formal, structured approach to select, prioritise, oversee and drive accountability across all their projects. This is the first of the four initiation steps: screening, then the business case (1.8), investment appraisal (1.9) and the charter (1.10).

Screening criteria

Projects are screened against several criteria:

1. Strategic alignment: does it serve the organisation's strategy?
2. Mandatory or discretionary? Regulatory work or a hardware refresh must proceed regardless of its return; only discretionary work competes on merit.
3. Financial return, measured by investment appraisal (1.9).
4. Risk and achievability: can it realistically be done?
5. Resources and dependencies: are the people available, and what else must happen first?
6. Non-financial benefits, such as safety and reputation.

The weighted scoring model (worked)

How do you combine several criteria into one ranking? A weighted scoring model gives each project a score (1–10) on each criterion, multiplies each score by the criterion's weight, and adds the results. The project with the highest total ranks first.

weighted score = Σ (weight of criterion × project's score on it),   with Σ weights = 1

A ranks higher, 7.5 to 6.4. The weights sum to 1 and reflect the organisation's priorities: change the weights and the ranking can change, which is exactly why agreeing them is a management decision, not a technical one.

The Business Case

Once a project idea survives screening, someone has to justify actually spending money on it. That justification is the business case. It turns "this seems like a good idea" into a documented argument that decision makers can check, compare with other projects, and revisit later.

Purpose exam

In practice, the business case does five things:

• It gives decision makers a factual basis for their decision, and shows how the project adds value.
• It uses standard headings (costs, benefits, risks) so that different projects can be compared with each other.
• Its size is set by the costs and benefits involved, not by the size of the project.
• It is a living document, reviewed and signed off at key stages.
• If the case fails at any point, the project should be stopped.

Contents exam

The slides follow the PRINCE2 structure (PRINCE2 is a widely used UK project-management method), which has nine parts. Two of them need a word of explanation. Business options must always include "do nothing" and "do the minimum", so that the chosen option is shown to beat the cheap alternatives. A dis-benefit is an outcome that someone will see as negative, such as disruption, retraining or extra maintenance: honest business cases list them.

Responsibilities

The slides give each role a part in the business case. The key distinction is that the Executive or Sponsor owns it, while the Project Manager prepares it. (In PRINCE2, the Executive is the sponsor's role on the project board, and Senior Users represent the people who will use the product and receive its benefits.)

Where the business case sits in a project's life

The business case is not written once and filed. Step through its journey from the first idea to benefits validation at close.

Investment Appraisal: NPV, ROI and Payback exam

A business case must answer "is this worth the money?", and for most projects that is a question with numbers in it. For non-mandatory projects the main benefit is often financial, which is what investment appraisal measures. The slides cover four techniques: Return On Investment (ROI), Net Present Value (NPV), the payback period and the Rough Order of Magnitude (ROM). They also warn that "it is not always about the best return": organisations must invest across the whole business, not only in the most profitable idea.

The time value of money

Would you rather have $100 today or $100 in three years? Today, because you could put it to work and have more than $100 by then. So a dollar in the future is worth less than a dollar today, and to compare cash arriving in different years we must convert every amount into today's value. That conversion is called discounting.

The formulas

NPV     = Σ (Benefits_t − Costs_t) / (1 + r)^t
          accept if NPV > 0; prefer the option with the higher NPV

ROI     = (total discounted benefits − total discounted costs)
          ÷ total discounted costs
          compare with the hurdle rate (typically 11–14%)

Payback = years before break-even
          + (unrecovered amount ÷ net flow in the break-even year)
          shorter = less risk

• NPV (net present value) adds up every year's net cash flow in today's dollars. A positive NPV means the project earns more than the required rate r, so accept it; between options, prefer the higher NPV.
• ROI, in the slides' version, is the discounted profit divided by the discounted costs. Higher is better, and you compare it with the required or minimum acceptable rate of return (the hurdle rate), which the slides put at typically 11–14%.
• The payback period is the time until the cumulative (running-total) net cash flow reaches 0, the break-even point. A shorter payback means less risk. Discounted payback is the same calculation using discounted flows.
• A Rough Order of Magnitude (ROM) is a very early, low-accuracy estimate used to screen ideas. PMBOK gives its range as −25% to +75%, whereas a later definitive estimate is about −5% to +10%.

Worked example: Project A

Project A (all figures in $k, r = 10%) costs 200 up front and 20 a year to run, and brings benefits of 100, 120 and 140 in years 1–3. Step through the stepper to fill in the discounting table one year at a time, exactly as you would in the exam.

1. NPV = 295.27 − 249.74 = +$45.5k. Because it is positive, the project beats the 10% required rate, so accept it.
2. ROI = 45.53 / 249.74 = 18.2%, which is above an 11–14% hurdle. Undiscounted, it would be (360 − 260)/260 = 38.5%, so discounting makes a real difference.
3. After year 2, 20 is still unrecovered and year 3's net flow is 120, so payback = 2 + 20/120 = 2.17 years.
4. On discounted flows, 44.63 is still unrecovered after year 2, so discounted payback = 2 + 44.63/90.16 = 2.495 ≈ 2.5 years.

Project B, and when NPV and payback disagree

Project B has net flows of −100, +70, +40 and +10 (same r = 10%).

So the two measures disagree: payback prefers B (1.75 years against A's 2.17), while NPV prefers A (+$45.5k against B's +$4.2k).

Rough Order of Magnitude

Very early on, nobody knows enough to fill in a discounting table. A ROM gives a first, deliberately rough figure. Because its range is −25% to +75%, a $400k ROM implies a range of 400 × 0.75 = $300k to 400 × 1.75 = $700k. That is enough to screen an idea, but not to set a budget.

Practice: Self-test Q8

Costs are $150k now plus $10k a year for three years. Benefits are $60k, $80k and $90k in years 1–3. With r = 8%, compute NPV, ROI and payback. Should it proceed if the hurdle rate is 12%? Try it on paper first, then step through.

The Project Charter and Integration Management

The business case argued that the project should happen. Somebody now has to say, formally and in writing, that it will happen, and hand the PM the authority to spend money and use people. That document is the project charter, the last of the four initiation steps.

Definition and purpose exam

The charter does several jobs at once. It authorises the project and empowers the PM. It records the high-level purpose, objectives, boundaries, deliverables and success criteria (remember the Opera House lesson: define success up front), and it names the sponsor, stakeholders and roles. It is the starting point for the PM plan. And the people who sign it commit funding, so they also control later changes.

The course charter template exam

The course template opens with a document control section, a version table recording the author, revision date, approver, approval date and reason for each version. Seven numbered sections follow, then two appendices.

1. Project Purpose gives the strategic reasons for the project and its expected profitability.
2. Project Objectives sets out who, what, when and where, plus the estimated duration and budget. It has two subsections: 2.1 Objectives and Scope, which covers the objectives, the scope and the boundaries (what is out of scope), and 2.2 Major Deliverables, given as a table. (A deliverable is any product or result the project must hand over.)
3. Overview.
4. Schedule gives the summary schedule and milestones (the detailed WBS, or work breakdown structure, is in Part VIII). A milestone is a significant point in the schedule, such as "prototype accepted".
5. Personnel and Stakeholders has 5.1 Roles and Responsibilities, for example Project Sponsor and Product Owner, and 5.2 Stakeholders, both internal and external.
6. Risk Management has 6.1 Assumptions and 6.2 Risks, each risk with a contingency plan (what you will do if it happens).
7. Project Charter Approval lists the signatories who "authorize and fund" the project and must approve changes.

The template closes with Appendix A: References and Appendix B: Key Terms. PMBOK's own version of the charter also lists high-level requirements, preapproved finances, exit criteria (the conditions for closing or cancelling the project) and the PM's authority level.

Business case vs charter vs PM plan

These three documents are easy to confuse, so the table compares them directly. The first row is the one to remember, because each document answers a different question.

Integration management

Integration management is the knowledge area that coordinates all the others (1.4). PMBOK 6th edition gives it seven processes, in this order:

The reading (PMBOK §4.2) makes four points about how these fit together.

• The charter is the main input to the PM plan.
• The PM plan "describes how the project will be executed, monitored and controlled, and closed". It integrates the subsidiary plans (scope, requirements, schedule, cost, quality, resource, communications, risk, procurement, stakeholder), the scope, schedule and cost baselines, the change and configuration management plans, the development approach (predictive, iterative, agile, hybrid) and management reviews.
• Once the plan is baselined, it changes only through Perform Integrated Change Control, where a change control board (CCB, the group with authority to approve or reject changes) decides.
• A kick-off meeting communicates the objectives, gains commitment and explains roles. Its timing depends on the project.

Applying It to the Medic Case

The tutorials run one case study all semester, and the exam can ask you to apply any idea to it. This section applies everything in this Part to Medic: its business drivers, why it counts as a project, its goal and scope, its business case and charter, and how to handle its triple constraint.

Business drivers exam

Tutorial 1 flags documenting these as an "intended testing area for final exam", so know all six.

1. There is a shortage of quality cadavers for practising cochlear-implant and temporal-bone surgery. This is the problem statement.
2. The apprenticeship model is criticised for giving too little focused practice and case diversity, including non-standard cases.
3. Patient safety and quality of care are at stake.
4. Medical indemnifiers (the insurers who cover doctors against negligence claims) carry risk from poorly trained surgeons.
5. Implant manufacturers suffer from the public's perceived risk.
6. The clients' standing is involved too: the RVEEH surgeons gain from cutting-edge work and better training.

Why Medic is a project

Medic shows all six characteristics from 1.1.

Goal versus scope

The goal is safer, more competent surgeons, achieved through diverse, repeatable practice without cadavers. The scope is seven features: load model; stereoscopic rendering; 3D and microscope viewing; select procedure and configure haptics; perform procedure; save and restore; and replay and pause. The boundaries might, for example, rule out patient-specific scans and other specialties.

Success criteria

These are illustrative, drawn from the case's reliability, performance and usability needs. Notice that each one can be checked, which is what makes a success criterion useful.

Business case

Charter sketch

A charter for Medic would fill the template sections (1.10) like this.

Triple constraint and approach

Resources are fixed and inexperienced and scope is uncertain, so the side to give is scope: flex scope by delivering load, view and perform first, and save and replay later.

The approach should combine four things:

• an iterative or hybrid lifecycle with early prototypes (Part II, Part III);
• servant leadership to grow the inexperienced team;
• close surgeon involvement, which is user involvement, a CHAOS top-three factor;
• an executive sponsor at RVEEH, the top CHAOS factor.

Pitfalls and Self-Test Map

This last section gathers the mistakes that most often cost marks on this Part, and maps every self-test question from the study guide to the place on this page where it is worked.

Common pitfalls

Each pair shows the tempting wrong statement on the left and what to write instead on the right.

To these add the calculation pitfalls from 1.9: don't discount year 0, ROI divides by discounted costs, and interpolate payback using the break-even year's own net flow.

Self-test map

All twelve of the study guide's self-test questions for this topic are worked on this page. Questions tagged as past exams come from predecessor subjects (433-443 and 433-341), not from SWEN90016 itself, and the model answers are the study guide's own, not official ones.