Project Management - Foundations & Initiation
Applied Market & Business Strategy (the “Strategy & Management Game”) - NIT / TUHH, Hamburg · part of my Technology Management MBA · study notes for revision.
The first half of this course was about choosing a strategy - the analysis, the positioning, the business model. This chapter starts the second half: delivering it. A strategy that nobody executes is just a nicely formatted PDF, and the vehicle companies use to make change happen is the project. So the next two chapters are a compact project-management course, framed around a running example the deck itself uses - developing a new cordless power drill - and, where it helps, around running a strategy-delivery project for CERMEDES (the mid-sized German power-tool maker I keep using as a stand-in company).
This chapter covers everything up to the moment a project is properly initiated: what a project even is, whether an idea deserves to become one, the life cycle it moves through, the constraints it fights against, the delivery approaches on offer, and finally the project charter - the document that turns a fuzzy idea into a signed agreement.
1 · Why project management, and what a “project” actually is
Section titled “1 · Why project management, and what a “project” actually is”Projects exist for one reason: to create something new. Routine, repeatable work (running payroll, shipping stock) is handled by the normal organisation. When a company wants something that doesn’t exist yet - a new drill, a new market entry, a new IT system - it needs a temporary, purpose-built effort with its own goal, team and end date. That’s a project, and managing it well is what stops “something new” from turning into “something late, over budget and disappointing.”
The textbook definition is worth memorising because every later tool hangs off it:
Unpacking that definition gives the traits that separate a project from day-to-day operations:
| Trait | What it means in practice |
|---|---|
| Definite beginning & end | It finishes when the objectives are achieved (or the plug is pulled) - it is not open-ended |
| Creates a lasting outcome | It leaves behind something durable, tangible or intangible (a product, a report, a capability) |
| Always constrained | Time and resources are limited by definition - you never get “as long as you like” |
| Carries risk & uncertainty | Because it’s new, you cannot fully predict it; surprises are guaranteed |
| Interdisciplinary & complex | It cuts across functions and needs several kinds of expertise pulled together |
| Variable scale | It can be one person for a week, or many organisations over years |
2 · Not every problem needs a project
Section titled “2 · Not every problem needs a project”Here is the counter-intuitive bit that a lot of eager people miss: most unique problems should not become projects. Shipping to an overseas customer for the very first time feels new, but the existing sales, logistics and finance functions can absorb it. Spinning up a formal project - with a charter, a team pulled off their day jobs, governance and reporting - is expensive overhead. You only pay it when the problem genuinely warrants it.
So a project idea has to earn its place. It must prove its project-worthiness before anyone commits budget. Companies formalise this so it isn’t just whoever-shouts-loudest:
- SOPs (standard operating procedures) - a defined process for how ideas are raised, reviewed and initiated.
- Project decision boards - the committee that challenges each idea, prioritises the portfolio and awards budgets. They are the gatekeepers; a good idea with no board sponsor goes nowhere.
- PMO (project management office) - a central function that supports or steers project managers, sets standards and produces status overviews across all live projects.
2.1 The project-worthiness scoring matrix
Section titled “2.1 The project-worthiness scoring matrix”To keep the decision honest, boards often score an idea against a few criteria and add up the points. Each criterion earns 1-2, 3-4 or 5-6 points depending on how demanding it is; the total lands the idea in one of three bands.
| Criterion | 1-2 points | 3-4 points | 5-6 points |
|---|---|---|---|
| Departments involved | 3 internal and/or 1 external | 5 internal and/or 3 external | More than 5 internal and/or more than 3 external |
| Uniqueness | Routine - done several times a year | Similar tasks done a few times before | Completely new problem |
| Number of work packages | Fewer than ten | 10 - 50 | More than 50 |
| Importance / risk | Limited to the department(s) involved | Important to several functions | Strategic for the unit or company |
| Estimated cost | Under 50,000 EUR | 50,000 - 250,000 EUR | Over 250,000 EUR |
The total score sorts the idea into one of three responses:
3 · The project life cycle
Section titled “3 · The project life cycle”Every project moves through the same five phases. They aren’t rigid walls - planning bleeds into execution, controlling runs the whole time - but the sequence is a reliable mental map. The classic shape shows staffing and spend ramping up through planning and execution, then tailing off at closing.
Each phase has a distinct output, a milestone that marks its close, and a bundle of activities:
| Phase | Key result | Milestone | Main activities |
|---|---|---|---|
| Initiation | A rough idea with backing | Idea agreed | Find a sponsor, describe the goal, align peers, sketch a draft plan, find a team |
| Planning | The project plan | Kick-off | Analyse the problem, define goals, commit the team, detail the plan |
| Execution | Accepted deliverables | (Interim milestones) | Do the actual content work - build the drill |
| Monitoring & Controlling | Project documents kept true | (Each controlling cycle) | Track progress vs. plan, steer, correct course |
| Closing | Handover complete | End | Transfer the output, run a “lessons learned”, formally end the project |
The two documents worth naming: planning first produces a draft project management plan, which is refined into the full project management plan at kick-off. Closing produces accepted deliverables and a set of accepted project documents that outlive the project.
4 · Constraints and success criteria
Section titled “4 · Constraints and success criteria”A project is a balancing act between competing limits. The simplest model is the triple constraint (also called the iron triangle): scope, time and budget. Pull on any one and the others move. Want more scope? It costs more time or money. Slash the budget? Scope or schedule gives. You cannot freely fix all three at once.
The magic pentagon adds quality and risk to the three. It’s the more honest model, because in the real world you can hit time and budget and still fail - by cutting quality to the bone, or by carrying a level of risk the sponsor never signed up for. Good project management is really the ongoing negotiation of these five against each other.
5 · Delivery approaches: plan-based vs. agile
Section titled “5 · Delivery approaches: plan-based vs. agile”There isn’t one way to run a project. The approaches split into two families: plan-based (decide most of it up front, then execute the plan) and agile (work in short cycles, replan constantly as you learn). Which you pick depends on how well you can define the outcome at the start.
| Approach | Family | Idea in one line |
|---|---|---|
| Stage-gate / waterfall | Plan-based | Sequential phases separated by decision “gates” you must pass to continue |
| Incremental | Plan-based | Build the result in repeated cycles, each adding a usable increment |
| V-model | Plan-based | Requirements go down one side, matching tests come back up the other (verification-heavy) |
| Concurrent product development | Plan-based | Overlap phases (design, production planning) to compress the timeline |
| Scrum | Agile | Short sprints, a backlog, and frequent inspect-and-adapt cycles |
For the cordless drill, a plan-based, stage-gate approach fits the hardware side well (you can’t “sprint” a moulded casing into existence overnight), while the app or firmware around it might run agile. Real product programmes usually blend both.
6 · The project charter - a manager’s life insurance
Section titled “6 · The project charter - a manager’s life insurance”Once an idea passes the worthiness test and gets a sponsor, initiation produces the single most important document of the whole exercise: the project charter (sometimes called the project letter).
I love the deck’s phrase for it: the charter is the project manager’s “life insurance.” When someone later claims “that was supposed to be in scope” or “you promised it in March,” the signed charter is what protects the PM. Without it, every disagreement becomes your word against theirs.
6.1 What goes in the charter
Section titled “6.1 What goes in the charter”A charter is generally comprehensive but not long. Its standard contents:
| Section | What it records |
|---|---|
| Target, background, business case | Where we’re going and why - the strategic reason it exists |
| Scope & out-of-scope | What belongs to the project - and, crucially, what does not |
| Deliverables | The concrete outputs the project will produce |
| Key milestones | The critical dates: kick-off, planning complete, project complete |
| Budget | Estimated project cost |
| Resources | The core team and how much of their time is committed |
| Key stakeholders | Who has a stake, and how success will be visible to them |
| Risks & pre-requisites | Known threats and things that must be true for the project to work |
The charter carries a special focus on scope, examined through three lenses - time, subject and social - which I’ll unpack in section 8. The reason to do the scope and context analyses jointly with the team isn’t bureaucracy: it’s how you get everyone sharing the same “big picture,” and it wins their genuine commitment before the hard work starts. You can only plan for a well-defined problem, and every project has interfaces to its surroundings that have to be pinned down.
7 · Defining targets that actually work
Section titled “7 · Defining targets that actually work”The charter lives or dies on how well its targets are written. Vague goals (“improve the product,” “grow the business”) are useless - nobody can tell whether you hit them. Three habits fix this.
First, make targets SMART:
Second, describe targets as future states, not events or problems. “Launch the drill” is an event; “the drill is a profitable top-5 seller in the professional segment” is a state you can steer toward. And use non-targets - explicit statements of what you are not trying to do - to sharpen the boundary. Saying “this project does not redesign the battery platform” removes a whole category of scope creep before it starts.
7.1 The target system: from overall goal down to specification
Section titled “7.1 The target system: from overall goal down to specification”Targets aren’t a flat list - they cascade. One overall target breaks into a few project targets, each of which gets criteria (how you’ll judge it) and finally a hard specification (the exact number). Here’s the drill example the deck uses:
| Level | Cordless-drill example |
|---|---|
| Overall target | Develop a new cordless power drill for the professional segment that becomes a substantial new business |
| Project targets | Reach significant first-year sales · be a profitable business line · offer a superior hammer-drill function · be a top-5 seller in the segment |
| Criteria | Sales volume · gross-profit margin · drilling performance · market share |
| Specification | 50M EUR first-year sales · 25% GP margin · 15 mm bore in reinforced concrete within 30 seconds · 35% share of segment |
Notice how each row gets more concrete. By the bottom you have numbers a stranger could test - that’s the point of the ladder.
7.2 When targets fight each other
Section titled “7.2 When targets fight each other”Targets have relationships, and not all of them are friendly. There are four kinds:
| Relationship | Meaning | Example |
|---|---|---|
| Independent | Moving one doesn’t affect the other | Warranty length vs. packaging design |
| Complementary | Helping one helps the other | Better ergonomics and higher customer satisfaction |
| Competitive | Helping one hurts the other | Highest quality vs. lowest cost |
| Antagonistic | The two directly oppose | Maximum power vs. minimum weight |
When targets genuinely compete, you can’t keep all of them at full priority - you have to decide which wins. A pairwise prioritisation table makes that decision transparent instead of political: you compare every target against every other, one duel at a time, and count the wins.
| vs. | (1) High market share | (2) Superior product | (3) Profitable line | Hits | Weight |
|---|---|---|---|---|---|
| (1) High market share | / | (1) | (3) | 1 | 30% |
| (2) Superior product | (1) | / | (3) | 0 | 20% |
| (3) Profitable line | (3) | (3) | / | 2 | 50% |
8 · The scope & context analyses behind the charter
Section titled “8 · The scope & context analyses behind the charter”The charter doesn’t appear from nowhere - it’s the summary of six structured analyses. They come from crossing two axes: three dimensions (subject, time, social) with two ranges (the project’s own scope, and its surrounding context). That gives a tidy 3×2 grid of lenses.
| Scope (inside the project) | Context (the environment) | |
|---|---|---|
| Subject | (a) Targets & deliverables | (d) Interfaces to other projects & strategy fit |
| Time | (b) Milestones - start & finish | (e) Background: history & consequences |
| Social | (c) Core team roles | (f) Stakeholders & their attitude |
(a) Subject-scope - targets & deliverables. Define the project’s targets and non-targets, list the four or five key tasks needed to reach them, and estimate the overall budget. Keeping to a handful of key tasks lets you sanity-check the project’s logic and rough schedule without drowning in detail.
(b) Time-scope - milestones. Fix the start and finish as actual dates, not vague periods, and tie each to an output-oriented event rather than a management meeting. “Contract signed by customer” and “products handed to logistics” stay meaningful even if the calendar slips - a “board review” date doesn’t. This keeps the schedule anchored to real content work.
(c) Social-scope - core team roles. Name the three role types and the specific experts filling them:
(d) Subject-context - interfaces & strategy fit. List the other projects your project links to (a marketing campaign in Argentina alongside one in Venezuela, say), describe the planned interaction, and check the project genuinely fits the company strategy. Neighbouring projects can create synergies or conflicts - you want to spot both early.
(e) Time-context - background & consequences. Look backward and forward. History: what happened before the project, what decisions were already made, what baseline documents exist, whether earlier attempts failed, who’s supportive and who’s hostile. Consequences: what the benefit is, what happens to the results afterwards, and what post-project preparation must happen during the project.
(f) Social-context - stakeholders. List everyone with a stake - sponsor, a labour union, a public initiative, the manager of a neighbouring project, a department head - and mark each as supportive, confronting or neutral, with an initial plan to manage them. Stakeholder management is a core PM job: harvest the synergies from allies, and build strategies to soften the opponents.
8.1 Two extra scans that feed the charter
Section titled “8.1 Two extra scans that feed the charter”PESTEL - the project-environment scan. Beyond the six lenses, sweep the wider environment with the familiar six factors, now aimed at the project rather than the market:
The cost-estimate checklist. The budget line in the charter is only as good as the cost categories you remember to include. The classic five:
| Cost position | Typical items |
|---|---|
| Internal staff | Project capacity of your own people (the biggest hidden cost) |
| Travel | Flights, hotels, expenses |
| Investments | Mock-ups, machinery, tools, software |
| External services | Consultants, legal advice, IT, advertising |
| Equipment | Consumables, training, database access |
Revision summary
Section titled “Revision summary”Next: Project Planning, Organization & Control → - turning the charter into a real plan, team and control system.