Project Planning, Organization & Control

Applied Market & Business Strategy (the “Strategy & Management Game”) - NIT / TUHH, Hamburg · part of my Technology Management MBA · study notes for revision.

---

The last chapter got us a signed project charter - the “life insurance” of the project manager, the target agreement between sponsor and PM. This chapter is the big one: how you turn that one-page promise into a plan people can actually work to, an organisation that can carry it, and a control loop that keeps it honest. This is where a strategy project either delivers or quietly falls apart.

I’ll organise the whole thing around a single running example - imagine I’m the PM on a system-development project at CERMEDES, a mid-sized German power-tool maker (build a new cordless drill platform, ship it, get it accepted by a launch customer). Five moves, in order: plan the work → schedule it → resource it → organise the people → control it, and then close it down properly.

Tip

The spine of this chapter. Almost everything hangs off one artefact - the Work Breakdown Structure (WBS). The WBS feeds the schedule, the schedule feeds the resource/budget plan, and the resource plan feeds cost control. Get the WBS right and the rest is bookkeeping; get it wrong and no amount of Gantt-chart polish will save you.

1 · Planning the work

1.1 Start with deliverables, not tasks

The temptation is to jump straight to a to-do list. Resist it. You plan a project backwards from its results. So the first artefact is a deliverables map - a mind-map (or structured list, or org-chart) of every result the project must produce, both physical (a tested prototype, an installed system) and intellectual (a specification, a training handbook, a use-case definition).

System accepted by customerthe overall project target

↑

Hardware testeddrawing · prototype · test

Software testedcompiled code · integration test

System installedsite plan · logistics

Customer trainedhandbook · training material

A deliverables map for the CERMEDES system project: the overall target at the top, key deliverables below, and the partial results that roll up into each. This is brainstorming output - it becomes the raw material for the WBS.

Mapping deliverables first does two quiet but important things: it forces the whole cross-functional team to share one picture of what “done” looks like, and it surfaces the intellectual deliverables (specs, plans, protocols) that a task-first list always forgets.

1.2 The Work Breakdown Structure (WBS)

The WBS is the structured overview of all the work in the project - the single most important planning tool. It takes the deliverables map and reorganises it into a tree of plannable, controllable chunks, arranged in a value-stream (work-flow) order so you can read the project left-to-right as it actually happens.

It has three levels:

Level	What sits here	How many
1 · Project	The whole project - one box at the top	1 element
2 · Phases	Major phases or sub-projects (plus a management “phase”)	4-8 elements
3 · Work packages (WPs)	The smallest plannable unit of work	5-10 per phase

Every box gets a WBS code derived from its position - phase 3, work package 3.2, and so on - and every phase and WP has exactly one named responsible person. A work package is the atom of the whole system: one identifiable step toward the final result, small enough to plan and control, big enough to be worth tracking.

• 1 · Project Management (the management “phase”)
  • 1.1 Project planning · 1.2 Project steering · 1.3 Reporting & communication
• 2 · Feasibility study
  • 2.1 Systems-principle analysis · 2.2 Key-component prototype test · 2.3 Hardware-in-the-loop test
• 3 · R&D
  • 3.1 Specification · 3.2 Design · 3.3 Mock-up
• 4 · Production & logistics
  • 4.1 Manufacturing requirements · 4.2 Sourcing of key components · 4.3 Factory layout
• 5 · Market launch
  • 5.1 Target markets · 5.2 Test sales · 5.3 Roll-out plan

A trimmed CERMEDES WBS. Phase 1 is pure management work (planning, steering, reporting) - always give management its own branch, or it vanishes from the budget.

Note

Who drafts what. The PM (or sponsor) sketches the first-cut deliverables plan; the detailed WBS is refined with the cross-functional team. Match the level of detail to the problem - a simple project needs a shallow tree, a system-development project a deep one. The point isn’t completeness for its own sake; it’s a “common basis for any project planning of the core team”.

1.3 Work-package specification - the mini-charter

Each work package deserves its own little agreement, the work-package specification. If the charter is the contract between sponsor and PM, the WP-spec is the contract between the PM and the WP-responsible. It’s drafted by the WP-responsible, then aligned in the team, and it exists to give everyone a common understanding of the WP’s result and to fence off its scope so two people don’t build the same thing.

WP-spec element	What it pins down
Administrative info	WBS number, WP name, WP-responsible, team members
Targets	The results - SMART: specific, measurable, achievable, relevant, time-bound
Scope / out-of-scope	What belongs to this WP - and, just as important, what deliberately does not
Pre-requisites & inputs	What must exist first, and which inputs come from other WPs
Deliverables & due dates	The end product, which function it’s delivered to, and when
Resources	The expert capacity (person-days) the WP needs

The “out-of-scope” line looks trivial and does the heaviest lifting - it’s what stops redundant work and turf-wars between neighbouring packages.

2 · Scheduling

Now the WBS gets a time axis. There are three scheduling views, from coarse to fine, and a good project uses all three.

2.1 The milestone plan - the rough-cut schedule

A milestone is a time-critical key deliverable with a duration of zero - a moment where something demonstrable has happened (“hardware tested”, “approval granted”, “system handed over”). The milestone plan is the whole project’s rough-cut schedule and, crucially, THE objective performance measure: the project is “on schedule” exactly when its milestones are hit on their dates.

Define five to ten milestones for the entire project - no more. The classic table has five columns: WBS number, milestone name, and then three dates that tell the story of how the plan drifted.

WBS code	Milestone	Basic plan	Current plan	Actual
1.1	Project START	01.01.2015	15.01.2015	20.01.2015
2.1	Hardware tested	01.01.2016	01.02.2016	01.02.2016
3.2	Software tested	31.03.2016	15.04.2016	-
4.3	System installed	01.10.2016	01.10.2016	-
4.4	Customer acceptance	01.10.2016	01.10.2016	-
1.5	Project END	31.10.2016	31.10.2016	-

• Basic plan - the baseline you first committed to (frozen; never edit it).
• Current plan - your best current forecast (this one moves).
• Actual - the real completion date, filled in as milestones pass.

The gap between basic and current is your honest record of slippage; the gap between current and actual is your record of accuracy. Rules of thumb: at least one milestone per controlling cycle; make them result-driven (something done, not a meeting); and only ever pick milestones you can document precisely.

Note

Mandatory vs optional milestones. Some are set from outside the project - contractual dates, customer payments, a certification deadline. Those are non-negotiable. The rest the team chooses to give itself useful checkpoints. Both belong on the plan; only one kind is yours to move.

2.2 The Gantt / bar chart - the detailed picture

The Gantt chart (bar chart) is the graphic, everyday schedule. One bar per work package, its length showing duration, laid on a timeline; phases get their own summary bars; responsibles are listed beside each bar; and milestones appear as diamonds with dates. Dependency links between consecutive WPs show what waits on what.

Q1 2015 - Kick-off ◆  ·  Phase I: WP 1.2, WP 1.3 Engineer A

Q3 2015 - Phase II: WP 2.1 hardware design Manager B

Q1 2016 - Handover ◆ hardware tested 1.1.16

Q4 2016 - End ◆ system handed over 1.10.16

A Gantt reads as a “waterfall-like” staircase: each phase-bar starts where the previous one roughly ends, with milestone diamonds pinned to dates. In practice you keep two Gantts - one overall chart with phases and key activities, and detailed per-phase charts with every activity.

2.3 The network graph and the critical path (CPM)

The network plan (Critical Path Method, CPM) is for complex projects where dependencies matter more than dates. Each work package is a node showing its duration and four scheduling values, and arrows show which package feeds which.

A network node (one work package)
ES earliest start	Duration (time)	EE earliest end
LS latest start		LE latest end

Each work package carries earliest/latest start and end. Where earliest equals latest, the package has no slack - those nodes form the critical path.

The critical path is the chain of packages with zero buffer - the longest dependent sequence through the project. Any delay on it delays the whole project; packages off it have float you can spend. There are four relation types between activities:

Relation	Meaning
End-Start	Activity 1 must end before activity 2 can start (the usual case - test before install)
End-End	Activity 1 must end before activity 2 can end
Start-Start	Activity 2 can’t start until activity 1 starts
Start-End	Activity 2 can’t end until activity 1 starts (rare)

2.4 PERT - estimating durations you’re unsure about

Real work packages don’t have neat durations. PERT (Program Evaluation and Review Technique) handles uncertainty with three-point estimation: instead of guessing one number, you ask the WP-responsible for three - an Optimistic, a Most-likely, and a Pessimistic duration - and blend them into an expected time that leans on the most-likely case but respects the spread.

Expected timetE = (O + 4M + P) / 6

Std. deviationσ ≈ (P − O) / 6

O · M · P optimistic, most-likely, pessimistic durations

Tiny worked example. For CERMEDES WP 3.2 “Design”, my engineer says: best case O = 8 days, most-likely M = 12 days, worst case P = 22 days. Then:

• Expected time tE = (8 + 4×12 + 22) / 6 = (8 + 48 + 22) / 6 = 78 / 6 = 13 days.
• Standard deviation σ ≈ (22 − 8) / 6 ≈ 2.3 days.

So I schedule this package at 13 days, not the 12 my engineer first blurted out - the long tail (22) drags the expectation up by a day. The σ of about 2.3 days tells me how much to trust it: a package with a wide O-to-P spread is a package to watch.

3 · Resourcing

3.1 From WBS to resource & budget plan

The resource/budget plan comes straight off the WBS: for each phase (later, each WP), how much of which resource type and which cost type does it burn?

Dimension	Examples
Resource types	Marketing, Sales, R&D, Operations, Finance, Tax… (the functions doing the work)
Cost types	HR / personnel, travel, investment (mock-ups, machinery, software), contracted services (consultants, legal, IT), material

You total these per phase to get a project budget plan - and, just as importantly, a basis for capacity checks. The plan’s job is to prove the schedule is feasible and to flag bottleneck resources before they bite.

3.2 Costing people: effective days and productivity

Here’s the trap that wrecks first-time schedules. A person is not available all year, and even when present, isn’t productive every minute. The course’s rough German-industry numbers:

Rule of thumb	Figure
Effective working days	~200 days/year (rest lost to vacation, illness, training)
Productivity while present	~85% (meetings, admin, coffee, email)
White-collar FTE cost	~€1,000 / day (≈ €200k/year)
Blue-collar FTE cost	~€750 / day (≈ €145k/year)

Caution

The 80-hour package needs 110 hours on the calendar. Because only ~85% of present time is productive, an 80-hour work package (nominally 2 weeks) must be scheduled across roughly 110 hours (about 2.75 weeks). If you plan work packages at their raw effort, every one of them runs late - not through anyone’s fault, but because you costed a fantasy human who never goes to a meeting. Always convert effort → calendar time before you promise a date.

3.3 Capacity plans and the committed-vs-planned check

Two views close the loop. The work-package capacity plan details, per WP, how many hours each department owes it. The department capacity plan flips it around - the department’s view of everything the project asks of it, month by month - which is where over-commitment shows up.

Then the money-shot check: committed vs planned. Each department committed a certain capacity to the project; the schedule plans a certain load on it. Plot both.

Committed capacitywhat the dept. promised

vs

Planned loadwhat the schedule needs

→

Planned exceeds committed?reschedule - don’t hope

In the CERMEDES mechanical department the planned load peaks around 25% above committed capacity in the middle months. That gap is not a rounding error - it’s a signal to reschedule work or renegotiate capacity now, before the packages collide.

4 · Organising the people

A project is a temporary change to the company’s functional org-structure - for its duration, people take on project roles that sit alongside (and sometimes conflict with) their line jobs. A functional manager becomes, inside my project, merely a “project expert”. Clarifying who is who is half the battle.

4.1 Organisation forms - how much power does the PM have?

Companies host projects in one of three shapes, and the real difference between them is a single variable: how much authority the project manager holds versus the functional (line) managers.

Form	How it works	PM authority	Best for
Functional	Work stays inside departments; department heads coordinate	Low / none (a coordinator)	Routine, single-function work
Matrix (incl. strong matrix)	Cross-functional team; staff grouped by specialty but loaned to projects	Moderate → high (strong matrix gives real budget & decision power)	Most real projects
Projectized / project	Company organised around projects; teams often collocated	High (great independence, resources report to PM)	Big, strategic, all-consuming projects

For a CERMEDES cross-functional launch project, a strong matrix is the realistic home: engineers still belong to their departments, but I get enough budget and decision power to actually steer.

4.2 The four core roles

Role	Owns	Key point
Project sponsor	Strategic direction & fit	Sets targets, appoints the PM, chairs the control board, supplies funding, approves the result. The project’s owner.
Control board	Strategic decisions on the sponsor’s behalf	Represents all involved functions; resolves conflicting targets and prioritisations; hears the PM’s status regularly.
Project manager	Operational delivery	Responsible for hitting the targets; plans, organises, coordinates, controls; functional lead, not disciplinary lead. There can be only one.
WP-responsible	One work package	Operational responsibility in their field of expertise; drafts and delivers their WP.

Note

Functional lead, not disciplinary lead. The PM directs the work but usually can’t hire, fire, or set salaries for team members - those stay with the line managers. That’s exactly why the matrix needs the sponsor’s active backing and a clear RACI: the PM’s authority is borrowed, not owned.

4.3 RACI - who does what to each task

The RACI matrix maps every WBS item against every role using four letters. The iron rule: exactly one “A” per task.

• R - Responsible: does the actual work (can be more than one).
• A - Accountable: ultimately answerable, signs off the result - only one per task.
• C - Consulted: experts whose input is sought (two-way).
• I - Informed: kept up to date on progress (one-way).

WBS	Work package	Sponsor	PM	Tim	Marc	Joe
1	Project (overall)	A	R
2	HW development	I	A	R	C
2.1	HW specification	I	A	R	C	C
2.2	HW design	I	A	R	C
3	SW development	I	A	R		C

Reading a row tells you instantly whether a task is owned (one A), orphaned (no A - dangerous) or muddled (two A’s - a fight waiting to happen).

4.4 The communication plan

Communication isn’t a soft extra - it’s the number-one cause of project failure (one survey pins ~57% of failures on communication breakdown; lack of planning/resources comes second at ~39%). So you plan it like anything else: which meetings, with whom, how often, where.

Meeting	Objective	Who	Cadence
Sponsor meeting	Status, approve results, project marketing	Sponsor + PM	Half-yearly
Control board	Status, approve milestones, current issues	PM + board + key TMs	Quarterly
Jour fixe	3-minute status per person, next milestone	Core team	Monthly
Working group	Prepare next milestone, current issues	PM + sub-team	Bi-weekly

(Also agree a shared file/documentation system - a SharePoint or equivalent - so the project’s memory lives in one place.)

Tip

The iceberg model. Only a sliver of communication is above the waterline - the facts: spoken words, logic, arguments, data. The bulk sits below it - the relationship: feelings, needs, beliefs, esteem, the wish to be appreciated. Most “communication problems” in a project aren’t disagreements about facts at all; they’re unspoken relationship signals. A PM who only argues the facts above the surface keeps losing to the nine-tenths they can’t see.

4.5 Team building - Tuckman’s stages

Teams don’t arrive finished; they pass through predictable stages. Knowing them stops you panicking at the ugly middle bit.

Formingpolite, unsure

→

Stormingconflict, jostling

→

Normingrules settle

→

Performingreal output

→

Adjourningwrap up, disband

Tuckman’s stages. Storming is not failure - it’s the team negotiating how it will work. Performance actually dips before it climbs; a PM who expects the dip manages through it instead of firing people.

Two lenses help you lead through those stages:

• Maslow’s hierarchy - motivation stacks from basic needs (food, rest) up through safety, belonging, esteem/respect, to self-actualisation (creativity, problem-solving). You can’t motivate someone with “interesting work” if they feel their job is unsafe. Meet the lower rungs first.
• Situational leadership - match your style to the person’s competence + confidence on the task:

Team member is…	Lead by…	Style
Incompetent & uncertain	strong direction, low support	Instruct
Incompetent but willing/confident	strong direction and strong support	Sell
Competent but uncertain/unwilling	strong support, low direction	Participate
Competent, confident & willing	low direction, low support	Delegate

5 · Stakeholder management

5.1 Why it matters: Success = Result × Acceptance

The best-planned project can still be killed by people it forgot to include. The course’s evaluation formula for (especially public) projects says it cleanly:

Project successSuccess = Result × Acceptance

Result scope, schedule, budget, quality - the “hard” delivery

Acceptance whether stakeholders at large actually back it

Because it’s a product, an acceptance of zero makes the whole thing zero, however brilliant the result. The IKEA Altona case is the textbook example: IKEA wanted its first downtown store (an 80M EUR, 3.5-year build). Local grass-roots opposition, demonstrations and a referendum forced a stop to planning. IKEA responded by treating stakeholder management as top priority - public workshops and hearings, an online platform, a pre-opening party and vouchers for residents, co-advertising with local vendors, free wifi for the neighbourhood - and turned it around to 77% approval in the final vote, then a smooth build with no noticeable protest. Same building; completely different outcome, driven entirely by the “acceptance” factor.

Caution

The cost of change rises about tenfold per phase. A change is cheap in the concept phase and brutally expensive once you’re in production - roughly ten times more with each phase you progress. A “forgotten” or “disconnected” stakeholder who surfaces late doesn’t just annoy you; they force exactly those late, tenfold-costly changes. Managing stakeholders early is cheaper than fixing their objections late.

5.2 The influence × attitude matrix

Map each stakeholder by how much influence they have and their attitude toward the project - that tells you how hard to work them.

High influence · Critical manage closely

• Win them over or contain them - they can stop the project

High influence · Supportive manage closely

• Your champions - keep them engaged and armed

Low influence · Critical keep satisfied

• Address concerns, but don’t over-invest

Low influence · Supportive keep informed / min. effort

• Light-touch updates are enough

The two high-influence quadrants both say “manage closely” - whether a powerful stakeholder loves or hates the project, you cannot afford to ignore them. Effort follows influence first, attitude second.

5.3 The stakeholder management plan

Turn the matrix into an action table - every important stakeholder gets a named owner and a concrete measure:

No.	Stakeholder	Relation / interest	Priority	Measure	Responsible
01	CEO	Positive EBIT	Keep informed	Quarterly status note	Sponsor
02	Launch customer	Premium customer (high positive)	Manage closely	Invite to kick-off & to hand-over	Sponsor / PM
03	Head of R&D	New HMI technology (high positive)	Manage closely	Keep informed, invite to prototype tests	PM
04	Works council	Wary of headcount impact	Keep satisfied	Early briefing, address concerns	PM

6 · Risk management

6.1 The process

A project risk is an uncertain event or condition that, if it occurs, affects a project objective (scope, schedule, cost, quality) - positively or negatively. You manage it as a loop:

Identifyname it, cause & effect

→

Evaluateprobability × impact

→

Plan measurespreventive & corrective

→

Controlmonitor & re-evaluate

The risk loop. You identify by brainstorming, expert interviews, past lessons-learned, SWOT, fishbone or FMEA; then you evaluate, plan, and keep controlling - because risks change as the project moves.

6.2 Evaluate: probability and impact scales

Rate each risk on two axes with agreed word-thresholds (the numbers are the calculation factors).

Probability scale:

Level	Range	Factor
Very low	under 15%	0.0
Low	15-30%	0.3
Moderate	30-50%	0.5
High	50-85%	0.7
Very high	over 85%	1.0

Impact scale (adjust to your sponsor’s tolerance):

Objective	Low	Moderate	High	Very high
Cost	under 10% increase	10-20% increase	20-40% increase	over 40% increase
Schedule	less than 5% time increase	5-10% increase	10-20% increase	over 20% increase
Scope	minor areas affected	major areas affected	reduction unacceptable to sponsor	item effectively useless

6.3 The probability × impact matrix

Multiply the two and you get a traffic-light priority.

High probability · Low impact yellow

• ”Quick-and-dirty” fix - cheap, do it and move on

High probability · High impact red

• Manage actively - these are the ones that hurt

Low probability · Low impact green

• Do nothing (for now) - just keep an eye out

Low probability · High impact yellow

• Monitor closely - rare but dangerous if it lands

Green = do nothing, Yellow = watch or cheap-fix, Red = manage actively. The red corner (likely and painful) is where your attention and your risk budget go.

6.4 The four response strategies

Avoideliminate the threat

Transfershift to a third party (insure, outsource)

Mitigatereduce probability or impact

Acceptacknowledge, act only if it occurs

Four ways to respond. “Transfer” moves the impact and the ownership of the response to someone else; “accept” is a deliberate cost trade-off, not laziness.

6.5 The risk register and risk budget

Everything lands in one living table:

#	Risk	Root cause	Impact	Prob.	Status	Budget	Measure	Responsible
1	New hires delayed	HR can’t commit capacity	2 weeks	40%	🟢	-	Accept	PM
2	Business licence delayed	Docs late, legal has no capacity	4 weeks	80%	🔴	€10k	Hire external legal consultant	WP-resp.
3	Union calls a strike	Info leak before negotiation	€50-250k	20%	🟡	-	Monitor closely, keep insiders few	PM

Tip

Keep a risk budget. Serious risks (the reds, and the expensive yellows) need money set aside to fund their response - the €10k for external legal help in row 2, for instance. A project without a risk budget is one that has to go begging to the sponsor at exactly the worst moment. Reserve for the risks you can see; you’ll still need judgement for the ones you can’t.

7 · Closing the project

Projects have a definite end - and closing badly wastes everything you built. The closing checklist:

Hand over the resultto sponsor, line function or successor

Train & support during handoverso the result actually gets used

Complete & secure documentationthe project’s memory

Lessons-learned workshopharvest what to repeat / avoid

Celebrate success · see off the teampeople remember the ending

Release the project managerthe project is formally over

Closing, in order. The lessons-learned workshop is the one everyone skips and the one that pays forward - it’s literally an input to the next project’s risk identification.

Controlling - the thread that runs through it all

One last idea that ties chapters together: while all of the above is being planned, the project is also being controlled. Two everyday instruments:

• Cost control (“burn rate”) - plot accumulated actual cost vs plan over the phases. If actual cost after phase 4 already exceeds the planned budget for phase 5 (a ~16% overrun in the CERMEDES example), you have a problem you can see months before it’s fatal.
• Performance measures - milestones passed, deliverables/artifacts produced, a WP-completion estimate, and budget-spent-vs-time-elapsed. The most sophisticated of these is earned value analysis, which combines schedule and cost into a single “how much value have we actually earned so far” number - the honest answer to “are we really on track?”.

Revision summary

Tip

The one-minute recap

• Plan backwards from deliverables → build the WBS (project → 4-8 phases → 5-10 work packages each, with WBS codes); each WP gets a SMART mini-spec with an explicit out-of-scope.
• Schedule in three views: a milestone plan (5-10 zero-duration, result-driven checkpoints; basic/current/actual dates), a Gantt (a bar per WP), and a network/CPM graph (the critical path is the zero-slack chain; four relation types). Estimate uncertain durations with PERT: tE = (O + 4M + P) / 6, σ ≈ (P − O) / 6.
• Resource off the WBS. Convert effort → calendar time: ~200 effective days/year and ~85% productivity mean an 80-hour package needs ~110 hours scheduled. Run the committed-vs-planned capacity check and reschedule if planned exceeds committed.
• Organise: pick a form (functional / matrix / projectized) by how much authority the PM needs; fill the four roles; write a RACI with exactly one Accountable per task. Plan communication deliberately - it’s the #1 failure cause - and remember the iceberg (facts above, relationship below).
• Stakeholders: Success = Result × Acceptance; map influence × attitude and give each a measure and an owner (the IKEA lesson).
• Risk: Identify → Evaluate (probability × impact) → Plan (Avoid / Transfer / Mitigate / Accept) → Control; keep a risk register and a risk budget.
• Close properly: hand over, train, secure docs, run lessons-learned, celebrate, release the team. And control throughout - burn-rate and earned value.

Next: Agile Project Management → - the other way to run a project when requirements keep changing.