The people side of project delivery
I'm a project manager with many years of experience — and with a TA practice behind it. This work takes the project as a container: goals, scope, roles, rhythm — and reads what stalls delivery inside that container: unclear responsibility, broken communication, the team's games, a contract that has worn out. The unit of work is the working agreement: what the team actually agreed, who owns what, how feedback moves, how a situation gets escalated instead of endured. The result is delivery-grade: decisions with owners, a rhythm the team keeps, and rules that survive the next conflict.
Project as a container
A project sets the boundaries, roles and rhythm inside which people can act without overload: what is mine, what is not mine, when a decision counts as made, and by what signs the work is finished. Where the container is broken — diffused responsibility, endless coordination, "do it somehow" — anxiety stops being an individual problem and becomes a property of the system. Projects also seldom run in a straight line: real courses move in highs and lows, as budgets are cut, priorities shift and support from above fades — and recover when coordination works. The causes are rarely in the plan itself; they are in motives, interests, communication and behaviour. So the container is audited first, and the human factors are mapped next to the schedule, because they decide whether the plan survives contact with reality.
- Charter, scope and done-criteria agreed in writing
- WBS against overwhelm: the work broken down until each piece has an owner
- RACI: who is responsible, who decides, who must be asked
- Working rhythm: plan → execute → control → close
Roles and responsibility
What usually hurts is not the load; it is role diffusion. A project team is short-lived, mixed in expertise and double-loaded — its members still carry their line duties — so a role that was never written down drifts: a person answers for results they do not control, does other people's work, and holds no authority over the decisions they are blamed for. We take the factual role apart: what you are responsible for, what you actually control, what you do instead of others, and where you have no authority. Responsibility and authority are then brought back into correspondence — by a role map (responsibility, authority, resources, escalation) and by delegation understood as a release of control, not a transfer of blame.
- Responsibility vs authority — mapped separately for each role
- Delegation without blame: the task, the limit, the check-in
- Escalation: who takes a problem, at what threshold, how fast
- The role map is reviewed when the team or the scope changes
Communication by TA
Communication has structures, processes and practices — and all three can be designed: who learns what, from whom and when; which meetings exist to decide and which only to inform; how bad news travels upward. When communication fails in a project, it usually fails as a system, not as somebody's shortcoming. Transactional Analysis reads the same meetings at the role level. A discussion derails the moment one participant switches into Controlling Parent — evaluation, correction, blame — and another answers from Adapted Child: justification, silence, or agreement without commitment. The same switches run in writing: messages "from Parent" (instructions without context, verdicts without questions) and messages "from Child" (complaints without a proposal, hints instead of requests). We map these transactions on your real material and rebuild the practices: shorter paths for decisions, written agreements after meetings, feedback that describes behaviour instead of judging the person.
- Ego states in meetings: who speaks from Parent, Adult or Child — and what it costs
- Drivers in the room: "Be perfect" and "Hurry up" as hidden standards
- Games: "Yes, but…", "Look how hard I tried" — named and closed
- Three-way contract (client — team — consultant); recognition as a managed resource
Risk and decisions
Risk and crisis are two different jobs, and mixing them is expensive. A risk is an event that may damage the project: it can be registered, weighed by probability and impact, given an owner and early indicators, and answered in advance — avoid, transfer, reduce, accept. A crisis calls the project's success itself into question and is worked by different principles: first stabilise, then decide — including the human side: who panics, who goes silent, who starts rescuing everyone. Decisions inside the project are collective information work: knowledge is distributed across people and levels, and the known failure mode is that the team discusses what everyone already knows while the one fact that would change the decision stays in somebody's head. So the surfacing of unique knowledge is structured before the decision, and the method is matched to the uncertainty — a decision tree, criteria for choice under unknown probabilities, an expert round, a pre-mortem, or a 2×2 scenario map instead of a single forecast.
- Risk register: probability × impact, owner, early indicators
- Pre-mortem: "assume we have already failed — what happened?"
- Decisions as collective information work: unique knowledge on the table first
- Decision method matched to the uncertainty: tree, criteria, expert round, pilot
Team
A project team is built for conflict, not instead of it: short-lived, mixed in expertise, double-loaded — interpersonal conflict under these conditions is part of the design, not an accident. Teams also develop in stages — forming, storming, norming, performing — and the storming stage is a working stage, not a malfunction; the leader's style has to match the stage the team is actually in. What predicts the project's energy is not motivation in general but commitment: how tightly people are linked to this particular project, and whether being on this team has become part of how they see themselves. Commitment grows from clear goals, visible progress and recognition, and it erodes in silence — which is why recognition is handled here as a manageable resource: specific, timely, tied to real work, not praise in general.
- Tuckman stages: forming, storming, norming, performing — and the task of each
- Feedback that describes behaviour, never judges the person
- Conflict as information: what the disagreement is really about
- Double messages in matrix structures — named and closed
Change
Change fails quietly when the announced priorities contradict each other: people stop believing any of them. It also fails where the loss inside the change is never explained — every reorganisation takes away a familiar order, a status, a predictability, and resistance to that loss is lawful, not sabotage. So readiness is checked before the plan: who is affected, what they gain, what they lose, and which stakeholders carry the change or quietly block it. The stakeholder map turns that into conversations — one per stakeholder, with the message that stakeholder actually needs. And because a project that ends without capturing what it learned taxes the next one, the work closes with knowledge practices: short reviews at phase gates, and decisions recorded together with their reasons.
- Readiness: who is affected, what they gain, what they lose
- Stakeholder map: influence, interest, and the conversation each one needs
- Contradicting priorities named openly — one list, one order
- Knowledge captured at phase gates: decisions and their reasons recorded
How an engagement goes
An engagement follows a fixed protocol, so both sides always know where the work stands. It opens with the request and an assessment — your deadlines, team, conflicts and overload on one side; the games, drivers and real transactions mapped on the other. The formulation then separates the systemic from the communicative: what is fixed by management instruments — roles, rhythm, escalation — and what is a pattern of communication and script that instruments alone will not move. Only after that is the contract signed: rules, roles, boundaries, feedback, recognition. The intervention works on the live project, and the consolidation closes with rituals and a written working scheme for the next 90 days.
Formats for organisations
Team assessment
An assessment of a stuck team of three to twelve people, before anyone prescribes a fix. Role interviews with the lead and the key members; a map of the team's games and drivers; the project's risk register read together with the role map, so the management facts and the relationship facts sit on one page. The work closes with a written report and a review session that separates, item by item, what is fixed in management — charter, roles, rhythm — from what is fixed in relationships — games, contracts, recognition.
You receive: a written report: the role map, the map of games and drivers, and the project risk register — plus the review session and the first agreements to change, contracted with the team
Brief: the written assessment report — the role map, the map of games and drivers, the first agreementsExample: one page per role — responsibility, authority, escalation — agreed by the team
Project kick-off contracting
Contracting at the start of a project, while agreements are still cheap. We set the launch properly: the charter and done-criteria; roles contracted with a RACI map, so responsibility and authority match from day one; feedback rules the team itself adopts; a light information system — the status rhythm and the decision log; and the team's working contract made explicit before the first deadline pressure tests it. Most mid-project crises are kick-off omissions arriving on schedule; this format removes them at the source.
You receive: the launch scheme in writing: charter and done-criteria, the RACI role map, the feedback rules, the status rhythm and decision log — the project's working contract, agreed before the work starts
Brief: the kick-off protocol — roles, communication rules and the feedback format, written down before the work startsExample: the project’s first meeting ends with the protocol on one page
Project accompaniment
Monthly accompaniment of a live project: the lead, and where needed the team, bring real situations — a decision slipping, a conflict hardening, roles drifting, a contract wearing out — and we work them with both instrument sets at once. The project instruments: charter, WBS, RACI, risk register, the rhythm of decisions. The TA instruments: the games and drivers in the room, the three-way contract with the sponsor, recognition as the resource that keeps commitment alive. The cycle closes the way the method prescribes: a working management scheme and a plan for the next 90 days.
You receive: a monthly review of real situations from your project with the working agreements updated — and, at the end of each cycle, a working management scheme and a 90-day plan
Brief: a one-page note after each monthly review — situations covered, agreements updated, open pointsExample: the month’s stuck decision is unblocked at the review, with a named owner
Scope and price are set on the intro call.
What this is — and isn't
- This is work on communication, roles and recurring patterns in business — not an HR audit, and not legal or financial advice.
- I don't make management decisions for you, and I don't replace the leader: the decision — and the responsibility for it — stays with you.
- In team work, the material is protected by the contract itself: the employer never gets access to individual material from sessions.
- Not psychotherapy. If clinical help is needed, I'll refer you.