1. Why Organization Is the First Real Project Problem
Most projects do not fail because the idea is wrong. They fail because nobody really thought through how the project is organized.
Who is involved?
Who decides?
Who actually works on the tasks?
Who can stop the project without being part of the team?
Before we talk about leadership or planning tools, we need to understand the organizational setup of projects. Without this, even very motivated people will struggle.
2. A Structured View on Project Management – The DIN Logic
To give the course a clear structure, we use a formal definition that fits well with the German preference for order.
Project management is the totality of:
- organization
- leadership
- management techniques
required to complete a project.
This definition is useful because it avoids a common misunderstanding. Project management is not just planning or controlling. It is the combination of:
- organization: how the project is embedded in the company
- leadership: how people become a real team
- management techniques: how tasks are planned, tracked and delivered
This structure will guide the entire course.
3. Organization, Leadership and Management – How the Course Is Built
Following the definition, the course is divided into three main blocks:
- Organization
- Leadership
- Management techniques
In this session we start with organization:
- project organization forms
- project roles
- stakeholder analysis
Leadership and detailed management tools come later. Organization is the foundation. If this is weak, everything built on top becomes unstable.
4. Three Ways to Organize Projects
In practice, projects are organized in only three basic ways. You will see all of them in your careers.
Understanding these forms helps you:
- explain why conflicts arise
- understand your own power as a project manager
- adapt your behavior to reality instead of fighting it
5. Pure Project Organization – The Ideal Case (and Why It Is Rare)
In a pure project organization:
- a project manager is appointed
- a dedicated project team is formed
- team members work 100% on the project
- normal line duties are paused
From a project manager’s perspective, this setup is excellent.
Communication is clear.
Decisions are fast.
The team can fully focus on the goal.
However, companies rarely choose this setup.
Why? Because people taken out of business-as-usual leave gaps. Someone still needs to do the daily work. Line managers hesitate to give away their best people. And after long projects, reintegration can be difficult.
Pure project organizations are usually limited to:
- mergers and acquisitions
- major IT replacements
- large strategic transformations
6. Functional Project Organization – Easy to Start, Hard to Steer
In a functional project organization:
- a project manager exists
- no dedicated project team is assigned
- project work is done inside normal departments
- line managers control priorities
This setup is attractive for companies.
It is fast.
It is cheap.
It causes little disruption.
But for the project manager it is often frustrating.
When a key customer calls, project work stops. When priorities change, the project waits. Escalating repeatedly to the sponsor feels like complaining.
This form can work for small, simple projects. For complex or time-critical projects, it is fragile.
7. Matrix Organization – The Reality You Will Mostly Face
Most real projects are run in a matrix organization.
In a matrix:
- a project manager exists
- named people are assigned to the project
- allocation is partial (for example 50/50 or 70/30)
- employees remain in their line organization
This is a compromise.
The company keeps capacity in BAU. The project gets named resources.
But the main challenge appears immediately: people effectively have two bosses.
In reality, workload agreements are often theoretical. Employees receive full task lists from both sides.
Successful matrix projects require:
- strong communication
- early detection of overload
- clear prioritization discussions
8. Why Clear Roles Matter More Than Perfect Plans
Many project problems are not technical. They are organizational.
If it is unclear:
- who decides
- who delivers
- who escalates
- who owns results
then issues are detected late and solved slowly.
Clear roles do not guarantee success. But unclear roles almost guarantee problems.
9. Core Project Roles
Project Manager
The project manager carries overall responsibility for the outcome.
Key tasks:
- develop and maintain the project plan
- coordinate tasks and dependencies
- lead the project team
- steer progress and react to deviations
If a project fails, nobody says “the team failed”. They say “the project manager failed”. That is the reality of the role.
Project Team
The project team:
- executes the tasks
- delivers the outcomes
- contributes expertise and capacity
Depending on the organization, team members are fully or partially allocated.
Sponsor
The sponsor:
- initiates the project
- provides budget and priority
- makes fundamental decisions
If line managers refuse resources, this becomes a sponsor decision, not a project manager fight.
Stakeholders
Stakeholders are individuals or groups that:
- are affected by the project
- or can influence the project
They are not passive observers. They can accelerate or block progress.
10. Stakeholder Analysis – Promoters, Neutrals and Blockers
Stakeholder analysis answers two simple questions:
- how does this stakeholder feel about the project?
- how much power does this stakeholder have?
Stakeholders can be:
- promoters
- neutral
- blockers
High-power blockers deserve the most attention. Ignoring them often leads to delays that no project plan can fix later.
11. Stakeholder Reality – A Real Project Story
I once managed a large integration project involving two parts of a bank.
On paper, everything looked perfect:
- strong sponsor
- clear structure
- experienced project managers
- a large team
After a few weeks I noticed something strange.
One part of the project progressed well. The other part moved slowly, without clear technical reasons.
Only later did I learn what was happening.
The back-office unit was a subsidiary with its own general manager. She openly told her management team that the project was stupid and would soon be stopped anyway. Her message was clear: do not invest too much effort.
This single stakeholder:
- disliked the project
- had high power
- influenced hundreds of people
From that moment on, managing this stakeholder became my main job.
I spent hours talking to her. I tried to escalate jointly to the sponsor. I never fully convinced her.
But after confronting the issue, the open sabotage stopped. The project continued, but the lost time could never be recovered.
That was the moment I truly understood what a blocker with power means.
12. Key Takeaways from This Session
- project management starts with organization
- there are three basic project organization forms
- pure projects are effective but expensive
- functional projects are easy but weak to steer
- matrix projects are the most common reality
- clear roles prevent chaos
- stakeholders can delay projects even if plans are perfect
13. Reflection Questions
- Have you seen a project slowed down by hidden resistance?
- Who would be a potential blocker in a project you know?
- In which organization form would you personally prefer to work?
- How early would you involve critical stakeholders?