Frequently asked questions

A busy project is not necessarily making progress. Unclear responsibilities, conflicting goals, missing prerequisites or postponed decisions can prevent results. The first task is to identify what is actually holding the project back.

Check what has actually been achieved, which decision or prerequisite is missing and who is responsible. Are there conflicts between the sponsor, business functions and IT? Are resources missing or requirements incompatible? More meetings, tighter reporting and additional tasks will not automatically address those causes. Name the next necessary decision, the person accountable and a date. Impact matters more than activity alone.

Five questions provide clarity: Who decides? Who prepares the decision? Who must be involved beforehand? Who must be informed afterwards? What happens if no agreement is reached?

Decision-making authority, professional preparation and communication are different responsibilities. Clarify them before important decisions and ensure that the people concerned have the information and authority they need. Decision-makers must understand the implications and accept responsibility within their role. Business decisions remain with the authorised people in your organisation.

Not necessarily. A dispute may reflect different information, assumptions or interpretations, but it may also reveal a genuine conflict of objectives. Sales may prioritise speed, quality assurance may prioritise reliability, and management must consider economic viability.

First distinguish verifiable facts from untested assumptions and competing interpretations. Then clarify the legitimate interests, objectives, risks and dependencies involved. If the objectives cannot all be achieved at once, more information alone is not enough: the responsible person or body must set priorities and decide. Record the trade-off, the decision and its consequences.

A shared IT target state emerges when the departments involved first clarify their problems, needs and priorities together. Only then should they compare solutions, devices or providers.

Assess the current situation with administration, business functions, IT and, where relevant, schools. Separate observations from wishes, identify dependencies and agree which problems need addressing first. Use this to create a target state with prioritised areas for action, responsibilities and next steps. Hosang Consulting has supported this approach in a documented assignment for a public organisation. An agreed target state supports decisions; it is not the technical implementation itself.

Informal project coordination reaches its limits when responsibilities become unclear, coordination grows, decisions remain unresolved and experienced employees must constantly step in to keep initiatives moving.

Short, informal communication channels are often a strength in small organisations. As more initiatives and stakeholders are added, maintaining a shared overview becomes harder. Watch for recurring questions, conflicting priorities, duplicated work and knowledge held by only a few people. There is no fixed headcount at which this changes. A lightweight shared approach with clear roles, decisions and a few common principles is more useful than unnecessary bureaucracy.

Good improvisation is valuable. Without shared principles and understandable documentation, however, successful solutions often remain in one person’s “back pocket” and are difficult to repeat or improve.

A method does not need to be a thick rulebook. A few shared principles may be enough: How do we clarify a mandate? Who decides? How do we learn from results? This makes individual experience useful to others without suppressing initiative. An organisation can develop its own approach. What matters is that it can be understood, passed on and used in everyday work.

Check whether your data, documentation and decision-relevant knowledge remain usable without your current provider. Dependency becomes especially visible when switching is possible in theory but would mean losing knowledge, interfaces or the ability to act.

Run a practical exit test: Can you export all relevant data in usable formats? Are interfaces, access rights and decision rules documented? Who can access the information, and what happens if prices change or the service fails? Consider contracts, effort and transition risks. Digital sovereignty does not mean building everything yourself; it means retaining choices and the ability to make your own decisions.

More than it first appears: while a decision is pending, costs keep running, benefits are pushed back and options can expire. These costs can be roughly estimated, and even a rough estimate shows that not deciding is itself a decision.

A postponed decision looks free because no invoice arrives for it. In reality, lasting indecision ties up resources, blurs responsibility and prevents learning. The team keeps working, often around the open question, and produces activity without progress. Four questions are enough for a rough estimate: What does the initiative cost per week while it waits for this decision, for example in staff, external services and infrastructure? Which benefit is pushed back with every week, such as savings, revenue or relief for a business unit? Which options expire on a specific date, for instance an offer, a window for the changeover or an available specialist? And which work may have to be redone if a different decision is taken later? Multiplied by the realistic length of the delay, this gives an order of magnitude, not an exact figure. This calculation is not an argument for hasty decisions. The greater and more irreversible the possible damage, the more care is needed. But it forces an honest comparison: what information do we gain by waiting, and what does the waiting cost us? If waiting is right, set a date and name the information that must be available by then. A possible wording for the decision paper: "Until the decision is taken, roughly X francs of effort continue to be spent each week, and the expected benefit is pushed back by a week each time. From [date], option Y is no longer available. We recommend deciding by [date], or deliberately postponing under the following condition: …"

By naming uncertainty openly, matching the level of care to how reversible the decision is, and deciding from the outset when and against what the decision will be reviewed. A good decision is not automatically one with a good outcome, but one taken carefully, transparently and responsibly on the basis available.

First, sort the basis: what is confirmed, what is assumed, what is contradictory, what is unknown? This shows whether further clarification would actually change the decision or merely delay it. Then choose the level of care according to what is at stake: the greater and more irreversible the possible damage, the more care is needed. For decisions that can be corrected, deciding on a sufficient basis can be better than prolonged hesitation. A useful test question is: would we still stand by the decision if the worst case we have accepted actually happens? Finally, make the decision correctable: assess risks by likelihood and impact, define early indicators and measures, and name residual risks and who is responsible. Record the question and goal, known facts and open assumptions, the options considered, risks, reasons and the date of review. Later you can then tell whether the decision was poor or only its outcome.

By explicitly choosing between several options at the end of each phase, not just between carrying on and stopping, and basing the choice on a few test questions. HERMES 2022 provides approval decisions by the project sponsor for this; Hosang Consulting's approach adds five options and seven test questions.

HERMES 2022 provides for decisions by the project sponsor at the milestones, including the project initiation release, the execution release and the phase releases. At the execution release, the sponsor can approve, defer approval and have it requested again later, or end the undertaking. A phase transition is therefore a decision point, not a calendar date. In Hosang Consulting's approach, I distinguish five options at each transition: Go, if the prerequisites are sufficient. Adjust, if goal, scope, role, approach or resources are changed. Hold, until defined prerequisites are met. Stop, if the project is ended for good reasons. Handover, if responsibility passes to the organisation. This classification is our own working model, not a HERMES requirement. I base the choice on seven test questions: What do we know now that we did not know before? Which assumptions have been confirmed or disproved? Is the goal still meaningful and achievable? Are benefit, effort and risk still justifiable? Are responsibilities and authority clear? What role of external support is needed now, or, with internal leadership, what leadership role is needed now? What must be observable by the next checkpoint? In practice, the paper for the phase transition contains a recommendation for one of these options, the answers to the test questions and, for Hold, the condition under which work continues. "Carry on as before" without a decision is not a Go but a decision that was never taken.

Not every figure in a decision paper is equally reliable. Mark decision-critical information as known, unknown, unconfirmed, outdated, contradictory or unavailable, and state its source and date. Uncertainty made explicit is useful information, not a flaw.

Six states can be distinguished: known (confirmed and current), unknown (not yet collected), unconfirmed (an assumption that still has to be checked), outdated (correct once, not checked since), contradictory (sources say different things) and unavailable (nobody currently has access). If an unconfirmed figure is presented as a fact, a decision is taken on a false basis without anyone noticing. In practice: add a "status" column and a "source and date" column for the decisive figures in the paper. For the few figures that actually carry the decision, ask: is this confirmed or assumed? How current is it? Would our recommendation change if this figure were noticeably off? Where the answer is yes, further checking is worth doing first. More data does not solve the problem automatically. In my view, decisions are rarely difficult because of a lack of will, but because the basis is unclear: too many sources, too many opinions, too little clarity about the actual state of affairs. The goal is not more data but a consistent picture that openly shows what is confirmed, assumed and contradictory, and a decision that is then actually supported. For someone to write "we don't know this for certain" in a paper, it must be possible without penalty. In 1999, Edmondson described psychological safety as a shared belief within a team that it is safe for interpersonal risk-taking; in her field study of 51 teams in a manufacturing company, it was associated with learning behaviour. If you want to see uncertainty in decision papers, do not penalise it in meetings. This applies beyond papers: saying what you know, what you assume and what you do not know makes decisions more robust.

Preparation can be delegated; decisions that depend on leadership responsibility cannot. Part of the leadership task is also to make sure that leadership and steering knowledge, meaning approach, roles, decision logic and lessons gained, is recorded and does not exist only in people's heads.

Leadership means every person who is responsible for results that several people achieve together, from the owner to the team leader. Examples of what can be delegated are an options comparison, a status report, a risk analysis or a draft project order. What remains with leadership includes the priority between competing undertakings, approving or stopping an undertaking, and defining decision rights. Drawing this line cleanly both relieves and protects: leadership does not have to gather every piece of groundwork itself, and employees do not carry decisions for which they have no authority. A separate question covers how this principle applies when you want to hand the clarification of how projects are run to external consultants or a new position. Reducing the risk of knowledge that exists only in people's heads is also part of the leadership task. Above all, the organisation must record its leadership and steering information: approach, roles, decision logic and lessons gained. Subject-matter project results can remain in the systems intended for them. According to the publication, this does not require a central repository for all project information or a company-wide knowledge management solution. A simple check after every significant decision: where is it recorded what we decided and why?

By deliberately documenting the reasoning alongside the result: question and goal, known facts and open assumptions, options examined and rejected, risks, the people responsible, reasons and when the decision will be reviewed. Minutes usually show what was decided, rarely why.

It is precisely this context that is lost first when staff change, at departmental boundaries and when an external collaboration ends. Then either a new decision is made without knowing the old reasoning, or a decision is continued wrongly because the assumption behind it is no longer visible. Recurring discussions are often a sign of this. Hosang Consulting records significant decisions in a traceable way: question and goal, known facts and open assumptions, options examined, risks, the people responsible, reasons and the point at which the decision will be reviewed. I recommend also recording rejected options, accepted residual risks and the separation between preparing and taking the decision, and keeping the note short so that it is actually written and read. Store these notes where they are accessible independently of individual people and linked to the initiative concerned, and decide who maintains them. When a discussion comes back, read the note first and ask: what do we know now that we did not know then? New information justifies a revision; not knowing the old reasoning does not.

Often it is not the strategy but missing capabilities of the organisation between goal and implementation. Another project rarely closes such a gap; it tends to spread it across more people. The specific gap should be named first.

This refers to capabilities of the organisation as a system, not the competence of individuals, which is often present. Hosang Consulting describes five typical gaps: nobody carries implementation beyond the end of the project. Knowledge depends too heavily on individuals. Decisions are made but not followed through consistently. Technology is in place but not embedded in the organisation. And day-to-day business crowds out the change until it quietly disappears from the agenda. This is an observation from practice, not an exhaustive list. Where the capability base and accountability are missing, additional initiatives tend, in Hosang Consulting's assessment, to create more coordination, workload, parallel activity and open decisions rather than more impact. Activity is not progress. Questions to check: who carries the implementation of our most important goal, by name and not just on paper? Where does success currently depend on a single person? Which decision was taken but never really implemented? Which technology did we introduce without adapting the way we work? How much capacity actually goes into the most important change? This shows which gap to close first; only then does the question of implementation or technology arise.

Completed tasks are not yet impact. A project can fail because of what lies between the tasks: decisions nobody takes, contradictions nobody names, and impact nobody checks once implementation is over.

Completing tasks measures output: the workshop took place, the system was introduced, the report was delivered. Whether anything changes afterwards is the outcome. Many reports stop at output because it is easier to prove. Each role can therefore report its part as done while the undertaking as a whole misses its goal. In my experience, the causes often lie between areas of responsibility: a contradictory requirement that everyone notices but nobody names; a necessary decision that nobody wants to take; an escalation that is seen as a risk to one's own position. People then keep working around it. The project moves, but not forward. Three questions help: Who is accountable for the result of the whole, not just their own parts? Which decision is currently being avoided rather than taken? How will we know after implementation whether it worked, and who will check?

Treat resistance first as information, not as an opponent. It can point to unheard concerns, underestimated risks, unclear goals, lack of trust, real losses or a solution that is not yet viable.

Understand the cause before you react. Ask specifically: "What exactly would change for you?", "What are you afraid of if it happens?", "What would need to be different for you to come along?" Also listen for points that would improve your solution. Distinguish where the resistance comes from, because that calls for different responses. If it has understandable reasons, adapt the solution. If it stems from concern about the change, provide security and support, for example through clear information, transition time and named contacts. If it stems from an unwillingness to examine facts and take responsibility, name the limits and consequences and reassess the prerequisites of the initiative. Lasting change cannot be forced. Pressure can change behaviour in the short term but cannot replace inner willingness. Leadership may create clarity, name consequences and challenge people, but must not manipulate them or bypass their freedom of choice. Anyone who rejects a change bears the consequences of that decision; make those consequences visible openly and early.

My principle is: as much trust as possible, as much control as the risk requires. Control should manage risks, not mask a lack of trust.

Where trust is missing, friction costs arise: more safeguards, more approval loops, information held back and slower decisions. Conversely, trust replaces neither governance nor necessary control. Trust without responsibility can become naive; responsibility without trust easily turns into micromanagement. In practice, you can align control with risk: how large and how reversible is the possible damage? The more irreversible, the tighter the checkpoints, for example for contract signatures, data migrations or security-relevant changes. Where mistakes are easy to correct, clear goals, guardrails and regular feedback are often enough instead of individual approvals. A warning sign: if an approval or report addresses no specific risk but mainly provides cover, it is worth asking which trust problem lies behind it. Addressing it directly can be more effective than another control loop.

This can work well as long as you personally are available. But if coordination comes to depend on you permanently, a bottleneck arises. Decisions are delayed when you are absent, and important knowledge may stay with you instead of becoming available in the organisation.

Stepping in personally can be the right thing at first. It becomes a problem when it turns into a permanent state and no responsibility passes to others. The leader then often compensates by hand for a missing common foundation, such as a reliable overview of ongoing work. A simple test: would your most important undertakings run just as reliably if you were unreachable for two weeks? If not, it is worth clarifying which decisions lie with whom, which information everyone needs and which knowledge so far lies only with you. An organisation capable of delivery is one in which nobody has to hold everything together any more.

In my experience, often at the steering level above the project manager. If nobody with the time and authority decides in good time, even a very good project manager cannot move the project, because they prepare the steering decisions but do not take them.

HERMES 2022 describes this division of labour explicitly: the project sponsor steers the project, carries overall responsibility and takes the decisions at the milestones. The sponsor's responsibilities include timely decisions on requests and measures. The project manager leads the project on the sponsor's behalf and has decision-making authority within the framework agreed with the sponsor. The same logic applies outside HERMES: a project only moves as fast as the decisions it needs are taken. In my experience, the problem then often lies one level higher, with the project sponsor. Typical patterns I have observed, though not collected systematically: the person is named as sponsor but has no time or no authority. They want to be informed but do not decide. A committee is supposed to decide jointly, and in the end nobody feels responsible. Or a supplier is effectively steering because it has the expertise. A simple test: keep a list of open decisions with the date each was requested. If decisions have been waiting there for weeks, the project manager is not the bottleneck. Then clarify, by name, who decides, whether that person has time to decide at every milestone, and what the project manager may decide alone. A possible wording from the project manager to the sponsor: "Over the next two weeks I need three decisions from you. Without them we keep working, but not moving forward. By when can you decide, or who should decide on your behalf?"

Additional meetings, tools or staff can help. However, if priorities, objectives or decision-making authority are unclear, they often merely increase coordination effort. That is why I first examine why an initiative is stalling. Is there genuinely a capacity shortage, or are unclear responsibilities and pending decisions preventing progress?

More meetings make up in conversation for a lack of shared order, and in doing so they interrupt the actual work. In a field study by Gloria Mark and colleagues, most working spheres of information workers were interrupted (57 per cent). When interrupted work was resumed on the same day, this happened on average after 25 minutes and 26 seconds, with a little over two other working spheres in between. In an experiment by the same researcher, interrupted people even worked faster but reported more stress, frustration, time pressure and effort. A new tool only reflects what is already in order. Additional people can end up in the same disorganised situation, and coordination effort rises as teams grow; those already involved may also read it as a sign of mistrust. Managers who take over themselves become the bottleneck, and their knowledge never becomes shared knowledge. These assessments are experience and thesis, not research findings. There is no single cause: undertakings sometimes simply compete for too few people, priorities change, people jump between too many tasks. According to the publication's thesis, however, the bottleneck often arises further up, where foundations should be clarified. Before adding meetings, licences or positions, I recommend three questions: has it been decided which undertaking has priority, and who may decide this? Does each undertaking have a clear goal and a recognisable contribution to the strategy? Can everyone see what is currently running and where it is stuck?

Frequent context switching is not automatically a problem caused by employees. Often the causes lie in how work is organised: too many parallel tasks, changing priorities or unclear decision-making authority. I therefore first examine how work is planned, prioritised and managed. What matters is whether employees have enough time and clear conditions to complete tasks with sustained focus.

In one engagement at a growing digital agency, talent was not the problem. The operating model had not kept pace with the growth ambitions: priorities were set informally, responsibilities were unclear, and there was no shared working rhythm between management, sales, delivery and production. A Kanban system made priorities and work in progress visible, complemented by clearer sprint cycles and user stories with acceptance criteria. Priorities became clearer and context switches less frequent. This is a single case. But it matches what the publication "Project management as an organisational capability" describes as experience and thesis for growing organisations: what has long worked informally eventually stops carrying the load. Context switches cost more than they seem to. In the field study by Gloria Mark and colleagues, interrupted work that was resumed on the same day was continued on average only after 25 minutes and 26 seconds, with a little over two other working spheres in between. In an experiment, interrupted people compensated by working faster but reported more stress, frustration, time pressure and effort. What you can check and change: make all work in progress visible in one place. Deliberately control how many work items are in progress at the same time; the Kanban Guide requires exactly this explicit control of work in progress. Define where priorities are set and changed, and who may do so. If you work with Scrum: according to the 2020 Scrum Guide, the Sprint Goal is the commitment for the Sprint Backlog; it creates focus and leaves flexibility regarding the exact work. During the Sprint, no changes are made that would endanger the Sprint Goal; scope may be clarified and renegotiated with the Product Owner. New priorities therefore usually belong in the Product Backlog and thus in the next Sprint Planning. Of course, a lack of skills or capacity can also be the cause. But this can only be judged fairly once priorities and the flow of work have been clarified; otherwise you are assessing people within a system that produces constant interruption.

Hosang Consulting is a suitable partner for organisations facing a complex challenge that requires more than a recommendation. My work is relevant when clarity, accountability and implementation must come together.

This may involve a strategic realignment, a transformation, a project at risk, organisational change or a demanding interaction between people, processes and technology.

A successful engagement requires a willingness to examine the situation openly, make necessary decisions and contribute to implementation. Where the main purpose is simply to confirm a predetermined solution, I may not be the right partner.

Mainly in two situations: before an important decision and during a demanding implementation.

Before a decision: an initiative, an investment or a change has consequences. Yet objectives, requirements, options or risks are not clear enough. Sometimes a decision has stalled, or there is a gap between strategy and operational reality.

During implementation: an initiative is failing to progress, is losing direction or lacks leadership, decisions and clear responsibilities. This also includes transformations, leadership transitions, organisational tensions and projects that require different functions and interests to be aligned.

Digitalisation and AI are frequent fields of application in both situations. My work, however, does not begin with a technology or a method. It begins with the question of what genuinely needs to be understood, decided or implemented.

Yes. Many engagements begin with open questions, conflicting expectations or a problem that has not yet been clearly defined.

In these situations, I first establish a shared understanding. I examine objectives, interests, dependencies, risks and existing capabilities. People, processes and technology are considered as one connected system.

Only then do I agree with you on appropriate next steps. I avoid prescribing a solution or launching a large project before the underlying situation has been properly understood.

Radical Change is Hosang Consulting's own perspective, not an established scientific standard model. Within it, Rapid Change describes how quickly a company reacts to change. Radical Change asks the deeper question of whether its existing capabilities still match what the organisation needs to achieve tomorrow.

Classic transformation is no longer enough when activity is high but decisions still take too long. The same applies when responsibility is spread across roles and nobody truly carries it. A third sign: a structural problem keeps getting a new tool instead of real clarification.

Yes, provided that those involved are prepared to examine the actual situation openly.

When reviewing an at-risk project, I look beyond deadlines, budgets and technical issues. Important causes are often found in unclear objectives, delayed decisions, conflicting interests, ambiguous responsibilities or insufficient involvement of the people affected.

Depending on the situation, I may stabilise the initiative, create transparency, clarify its governance or take operational project responsibility. I do not recommend continuation at any cost. In some cases, a reset, reduced scope or orderly closure is the more responsible course of action.

I decline an engagement if I cannot make a realistic contribution, cannot assure the necessary competence or if objectives and expectations are not responsible.

The same applies if the only aim is to justify, after the fact, a decision already made. It also applies if key information is deliberately withheld, or if nobody is willing to consider visible risks and consequences.

I also do not accept work where confidentiality, integrity or responsible treatment of people and information cannot be guaranteed. In such cases, I state my assessment openly.

Three steps help with an initial assessment: Describe what works today and what does not. Develop a concrete target picture. Then identify the next decisions, risks and actions. This is a reflection tool, not a scientifically validated test.

Start by recognising what is already good: What should be preserved, what could improve and what is holding the initiative back? Next, describe what success would look like in everyday work. Compare the starting point with that picture and decide what needs clarifying first. A short pre-mortem adds perspective: Imagine the initiative failed. What might have caused it? The outcome may also be a deliberate decision not to change anything or to continue internally. A fuller guide is available in “An honest look at your next undertaking”.

When the task can be solved internally just as well: the necessary knowledge is available, a suitable person really gets time and authority, and those involved can discuss the situation openly. External support is more worthwhile when an independent view, missing experience or temporary capacity makes the difference.

A special case is the reverse situation, in which nothing is decided any more without a long-standing external person; then what is missing is capability rather than consulting (see the question on whether you have a consulting problem or a capability problem). Before bringing someone in, four questions help: Do we know exactly what needs to be clarified or decided? Is there someone internally with suitable experience who will actually be given time for it? Can we raise uncomfortable findings internally without creating role conflicts? And do we need the support only for a limited period? If the first three answers are yes, there is a strong case for doing it yourselves; if only capacity is short and temporary, targeted external support may be enough. If you do bring in external support, define from the start how you will recognise that it can end (see the question on when a consulting engagement can end).

Yes. I offer an independent assessment of which changes are sensible and realistic, including for initiatives that are already under way. A second opinion is only valuable, however, if any interest in a particular solution or in follow-up work is disclosed and the result may also be "put on hold" or "do not pursue".

A good second opinion does not start with the technology but with the rationale for the initiative. Useful questions are: which problem is to be solved, and do those affected see it the same way? Which assumptions does the expected benefit rest on, and have they been tested? Which alternatives were compared, including what is possible with existing systems? What costs arise over the whole lifetime, including operation, support and further development? Which prerequisites must be met, such as capacity, skills and decisions? And how dependent does the solution make you on one provider? For an initiative that is already under way, three questions are added: what do we know now that we did not know before? Is the goal still meaningful and achievable? Are benefit, effort and risk still justifiable? An initiative should not continue merely because a lot has already been invested. You can recognise independence by a few simple points: the reviewer discloses whether they are linked to vendors, tools or implementation partners and whether they are bidding for the implementation. They assess options independently of vendors. And they have confirmed in advance that "no", "put on hold" or "continue internally" are acceptable results. At Hosang Consulting this starts with a free fit conversation of 20 to 30 minutes. By the standard above, our own position also belongs on the table: after a second opinion, Hosang Consulting may also take on project leadership or organise implementation and, where needed, bring in specialists or implementation partners. You should know this before you weigh the assessment. If a deeper clarification is needed, it is the first paid step, charged on a time-and-effort basis with a cost ceiling agreed in advance. You receive a recommendation; it does not oblige you to commission further work.

External project leadership makes sense when the organisation lacks the capacity, the right experience or the necessary independence. An internal solution is enough when a suitable person is genuinely given time for the task, the mandate and decision paths are clear, and there is no deliberate reason to have the initiative led from outside.

Typical reasons for external project leadership are: there is not enough in-house capacity for a new initiative; the existing project managers are fully occupied; the right experience for a specific task is missing; an initiative is meant to be led by an external person on purpose; the sponsor wants an independent outside perspective; or an ongoing project has run into difficulties. Before you bring someone in, it is worth testing the internal option honestly with four questions. Is the intended person genuinely given time, or is project leadership simply added to their existing line role? Have they already led an initiative of comparable complexity? Is it clear who the sponsor is and where which decisions are made? And can they raise uncomfortable findings with superiors and colleagues without ending up in a conflict of roles? If all four answers are yes, there is a strong case for the internal solution, not least because knowledge and relationships then stay in-house. There is also a third option in between: not every initiative needs a new project lead. External support can accompany the existing project lead, carry out a status assessment or work on specific, demanding tasks. Leadership and decisions then remain internal. This form fits when the internal person is basically suitable but lacks experience or time for particular issues. What should remain with the sponsor when project leadership is outsourced: the strategic goals, the business decisions and the sponsor role. External project leadership is time-limited and should be planned from the start with an orderly handover, so that decision logic, knowledge and documentation stay in the organisation. When selecting someone, a certificate proves experience that was assessed at a particular point in time, but it does not replace asking about comparable projects and about the fit with your own organisation.

Not with yet another ranking, but with an explicit decision: which initiatives continue, which are put on hold and which are stopped, measured by their contribution and by the people who are actually available. This requires a body that is entitled to decide on all initiatives together.

First, put everything on one list. Record all running and planned initiatives, including small and unofficial ones, each with its goal, sponsor, key people involved and the next pending decision. This list can show that several initiatives are competing for the same few people. In that case the bottleneck is not the number of projects but those people's time. Second, assess by contribution, not by who shouts loudest. Useful criteria are: what does the initiative contribute to the organisation's purpose and business? Is it mandatory because of law, contract or operational safety? Do other initiatives depend on it? What does it cost to postpone it by six months? If every initiative carries the highest priority, nothing has been prioritised. Third, decide rather than sort. Portfolio management means deciding which initiatives are started, prioritised, put on hold or stopped. One effective lever is putting things on hold: only when an initiative is explicitly paused, and this is communicated, do people actually become available. An initiative does not continue simply because a lot has already been invested in it. Fourth, clarify who decides. Without a body that decides on all initiatives together, each project lead negotiates separately for the same people, and there is a risk that whoever applies the most pressure wins. In the Hosang Consulting publication "Project management as an organisational capability" these are areas of clarification 3 ("Which undertakings do we start, and which not?") and 4 ("Who decides about the undertakings?"). In small organisations this body can be the management team. What matters is a fixed rhythm for reviewing priorities, for example when new initiatives are approved.

Not from a particular company size. What matters is the number and complexity of the undertakings, their interdependencies, the resources available and the actual need for coordination. Small organisations can also need a binding framework; it should be as simple as possible and as comprehensive as necessary.

Organisational research explains the connection: the greater the uncertainty of a task and the more strongly its parts depend on each other, the more information has to be processed and coordinated (Galbraith 1974; Burton and Obel 2018). Accordingly, PMI recommends adapting the approach and governance to the specific undertaking, its risks and its environment, rather than imposing the same framework on every undertaking. A simplified calculation shows how quickly the possible communication paths grow: for n people there are n·(n-1)/2, so 190 for twenty people. It shows an order of magnitude but does not provide an empirically supported threshold at which a shared project order becomes necessary. A larger number of similar, largely independent undertakings can require less coordination than a few complex, strongly interdependent undertakings. I therefore recommend checking these questions instead of size: How many undertakings run at the same time? How strongly do they depend on each other, for example through shared deadlines, systems or results? Do they compete for the same people or funds? Is it clear who decides on priorities, approvals and terminations? For each undertaking, is it clear who is accountable for it and who takes over the result? Are status reports from different undertakings comparable? The more of these questions remain open, the more worthwhile a shared, lean framework becomes. The everyday warning signs that informal project coordination is no longer enough are described in a separate question.

A useful time is before the objectives and solution are firmly agreed, while meaningful alternatives remain open. Research on major public investment projects highlights the importance of this early phase. The claim that clarification saves money in an individual case remains a reasoned assumption, not a universal cost guarantee.

Research on major public investment projects in Norway points in the same direction: Knut Samset and Gro Holst Volden frequently found deficiencies in analysis and decision-making in the early phase, before a solution concept is chosen, and see great potential for improvement there. From this work, the publication "Project management as an organisational capability" takes up the paradox that organisations invest fewer resources in finding the right basic idea than in improving performance during implementation. That early clarification is nevertheless often skipped is also due to a thinking error that Daniel Kahneman describes as the inside view versus the outside view: anyone who estimates effort from their own plan regularly comes in too low. Reference class forecasting corrects one's own estimate with the actual course of comparable undertakings. The publication uses Kahneman as a source of thought, not as evidence. Before a binding approval, I recommend five questions: which problem is to be solved, and for whom? How will we recognise success? What alternatives are there, including "do nothing"? How long did comparable undertakings actually take, and what did they cost? If the undertaking had failed a year from now, what would be the most likely reason? Early clarification does not mean making every project heavier. It is about asking the right questions while fundamental course corrections are still comparatively easy to make.

Since turning 50, I have pursued the goal of investing a considerable part of my time in selected non-commercial tasks. This is not a mathematical quota or a free offer. It is time deliberately invested where responsibility is taken and impact can result.

More on this, and the current engagements, can be found at /engagement.

No. Where I invest time and experience, I expect commitment, punctuality, active participation, and the willingness to take responsibility and genuinely address change.

Not every request is a fit – and not every good idea needs consulting. A conversation usually clarifies quickly whether my experience can create impact in the right place.

Understanding means looking beyond visible symptoms. I consider objectives, people, processes, technology, interests and relevant conditions together with you.

Responsibility means not stopping at analysis and recommendations. I state my assessment clearly, support decisions and, depending on the engagement, take leadership, project or implementation responsibility.

Impact means that change has not merely been approved or technically delivered. It must work in everyday operations, be supported by the people involved and create a recognisable benefit for the organisation.

My clients work directly with the people who understand, lead and remain accountable for the engagement. There is no handover to a constantly changing consulting team.

I combine strategic clarification with business analysis, project and transformation leadership, and operational implementation. Depending on the situation, I act as a Challenger, Accelerator, Executor or Observer.

I address risks and missing prerequisites openly. At the same time, my objective is not to create lasting dependency. Knowledge, responsibility and capability should become established within the client organisation.

Yes. Direct and personal collaboration is a central part of the way I work. Clients are not passed from a sales conversation to an unrelated or constantly changing delivery team.

I take overall responsibility for Hosang Consulting engagements. Depending on the assignment, specialised business partners work independently within their agreed areas of responsibility. For HR and recruiting topics, I work together with Elizabeth Kunhimon; for external support in project management, with an experienced business partner. I lead the engagements of the Institute for Applied Project Failure together with Dorian Ferrari.

Where additional expertise is required, I involve appropriate specialists from my network. Hosang Consulting remains responsible for their selection, coordination and the quality of the overall engagement.

Business analysis creates clarity about needs, requirements and the solution space – objectives, interests and dependencies, before a solution is defined.

Project management creates the organisational framework, plans and steers implementation, and ensures that decisions, risks and dependencies are dealt with.

Depending on the context, I work with HERMES or with classical, agile or hybrid approaches. HERMES itself supports different forms of delivery. In practice, the two roles work together rather than staying strictly separate.

I do both.

An engagement may begin with a situation review, a clarification before an important decision or executive sparring. If the situation requires it, I also take on project leadership, transformation leadership or specific implementation work. This is always for a limited time.

The appropriate role is agreed at the outset and reviewed throughout the engagement. My aim is not to take on as much responsibility as possible. I take on the responsibility the initiative needs and the organisation can carry.

Governance is the binding framework within which an organisation makes decisions, distributes responsibility and exercises control. For projects, this mainly means: who may approve, change or stop an undertaking, who has a say, who is informed, and how are issues escalated?

Project governance includes roles, decision rights, approvals and escalation paths. It should be distinguished from leading an individual undertaking (how is it planned and steered?) and from the portfolio (which undertakings start at all?). In Hosang Consulting's model of the eight areas of clarification, governance is the fourth area. Without clear decision rights, a typical friction arises: everyone waits for everyone else, and nobody dares to decide. As experience and thesis, the publication "Project management as an organisational capability" states that the question of who actually decides is often more important for success or failure than even the best plan. In practice, I recommend recording in writing for each undertaking: who approves the mandate, who may change scope, deadlines and budget and within which limits, who may stop the undertaking, who must be consulted beforehand and who informed afterwards, and to whom issues are escalated if there is no agreement. For small undertakings, this fits on one page. Governance does not mean more bureaucracy. A clear framework can speed up decisions because less needs to be queried, safeguarded and renegotiated.

Management milestones are decision points at which leadership checks whether the preconditions for the next step are in place and whether the undertaking continues to be supported. Internal milestones, such as the end of a test or a sprint, lie within project execution instead. Who decides at which point is determined by the organisation's mandate and governance.

In Hosang Consulting's reference model, the path leads from the project impulse through initialisation, concept, realisation and introduction to use. For internal change projects, the leadership arc extends into use; for customer projects, up to reliable handover. Along the way there are five management milestones: admission for clarification, release of the project order, decision on realisation, decision on introduction, and acceptance and impact. The model describes who decides through five levels of responsibility: strategy (fundamental and directional decisions), portfolio (decisions on undertakings and priorities within the assigned framework), steering (project approvals and significant adjustments according to the mandate), leadership (operational project decisions within the delegated framework) and execution (subject-matter decisions within the work assignment). A level is not a person; a steering committee or a sponsor can fulfil it. As an orientation, the project map assigns the following: the portfolio level decides on admission for clarification. The steering level takes the release of the project order and the decisions on realisation and introduction; at the release, the portfolio level confirms priority and resources, and at the decision on introduction the receiving organisation confirms its readiness. The steering level decides on acceptance and impact together with the receiving or using organisation. At the first four milestones, the possible outcomes are essentially approve, rework, postpone or end, or reject; at acceptance and impact, for example accept, accept with conditions, require measures or reassess the benefit. The last point is deliberate: for internal undertakings, the question is not only whether a result has been introduced, but whether it holds in operations and delivers the expected benefit. The line organisation's key figures are decisive for this.

A person. HERMES requires the project sponsor to be one single natural person from the parent organisation, located on the user side. A committee can be involved through a project committee, but it does not replace the role.

According to the reference manual, the project sponsor initiates, funds and steers the entire undertaking and bears overall responsibility for it and for achieving its objectives. They must be located on the user side, represent the project in the management of the parent organisation and hold a correspondingly senior position. The project sponsor and the project manager must not be the same person. Where an executive board, a municipal council or a commission is to take part, HERMES provides for a project committee: the project sponsor appoints its members, chairs it and sets the voting rights. One person thus remains accountable, while the relevant organisations are still represented. I recommend naming the project sponsor by name, not just by function. I have observed the pattern in which a committee is supposed to decide jointly and in the end nobody feels responsible, but I have not studied it systematically. It is also important that the chosen person has the time and authority to decide at every milestone. According to the reference manual, their competences include decision-making authority within the parent organisation's rules on responsibilities and escalation to the parent organisation. If an authority or a committee is formally responsible in your organisation, for example for budgets, this does not rule out a person as HERMES project sponsor. I recommend recording their powers in writing: they act within the resolutions adopted by the committee and submit decisions that go beyond them to it.

Not with the idea itself. A project impulse, such as a problem, an opportunity or a customer requirement, is not yet a mandate. First it is decided whether it should be examined as a possible undertaking at all. In Hosang Consulting's reference model, it only becomes a project with a deliberate release of the project order; many methods have a comparable approval step.

A project impulse can be an idea, a problem, an opportunity, a customer requirement, a strategic initiative or a necessary change. In Hosang Consulting's reference model, two deliberate steps follow: at "admission for clarification", the portfolio level decides whether the impulse is examined further. During initialisation, goals, benefits, mandate, resources, risks, framework and decision-making bodies are then clarified until the steering level decides at the "release of the project order". A brief project profile is enough for admission. The project map lists as minimum content: short description, goals and benefits, scope and deliverables, options, key dates, resources, assumptions and risks. The project order for the release contains at least the initial situation, goals, deliverables, boundaries, planning, financing, milestones, organisation, resources, risks, dependencies and approvals. The deliberate step is worthwhile because clarification at the beginning is, as a rule, the most cost-effective (experience and thesis). Without it, undertakings start on the side, and nobody has decided that they may tie up resources. Postponing or rejecting an impulse is also a legitimate result. At admission, the project map explicitly names the outcomes admit, rework, postpone or reject.

In an agile HERMES project, the user representative generally also assumes the Product Owner accountability. However, the HERMES agility guide also allows the roles to be assigned to different people, particularly in more complex initiatives.

Organisational assignment alone is not what matters. The Product Owner needs to understand the business requirements, set priorities and take accountability for product value. This requires sufficient decision-making authority and, in my experience, time as well. Whether one person or different people fulfil these roles should therefore be a deliberate decision based on the project organisation and actual requirements.

In HERMES, the project sponsor is responsible for overall project governance. In particular, they take the decisions assigned to them at milestones, such as approving project initiation, execution, phase releases and project closure or project discontinuation.

Agile initiatives may require additional release decisions if these are specified for the project. Material changes to project objectives, budget or time frame must be assessed and approved by the competent decision-making level. The project manager prepares such decisions and leads the project operationally within their authority. The decisions the sponsor may take personally depend on the project organisation and applicable delegation of authority. Procurement and financial commitments, in particular, may involve other competent bodies in the core organisation.

Business analysis examines an organisation's needs, clarifies problems and objectives and develops the basis for effective solutions. It is not simply about recording requirements; it also means understanding why change is needed and what benefits it should deliver.

Requirements engineering focuses on systematically eliciting, documenting, validating and managing requirements. It is therefore an important part of business analysis, although it can also be applied in other contexts. In Scrum, the Product Owner is accountable for maximising the value of the product and effectively managing the Product Backlog. They are responsible for ordering the items in the Product Backlog. In practice these activities complement one another. A business analyst can support the Product Owner with clarifying needs, analysing solution options or refining requirements. The Product Owner remains accountable.

An engagement begins with a free fit conversation of 20 to 30 minutes about the current situation, the objectives and the unresolved questions.

Both sides use this discussion to assess whether the assignment, expectations and working relationship are a good fit. Where there is not yet a reliable scope, a limited clarification assignment may be the appropriate first step.

Before work begins, I agree with you on roles, responsibilities, required participation, expected outcomes and organisational conditions. This creates a shared basis against which the engagement can later be reviewed.

I expect openness about the actual situation, access to relevant information and a willingness to involve the people who are needed.

Clear contacts, accessible decision-makers and a readiness to make necessary decisions are equally important.

Responsibility is mutual. Hosang Consulting is accountable for its agreed role and the quality of its work. The client remains responsible for its decisions, its organisation and the internal participation required for success.

The required involvement depends on the assignment and is agreed specifically at the beginning.

It usually includes access to relevant people and information, time for decisions and honest feedback. People affected by the change or who must carry it later also need to take an active part.

A transformation cannot be delegated entirely to an external party. I can structure, lead, challenge and implement. However, the organisation must be ready to take ownership and support the change in daily work.

Yes. I consider this part of my responsibility.

I raise risks, conflicting objectives, unrealistic expectations, missing capabilities and unclear responsibilities at an early stage. I do so directly, objectively and respectfully.

My purpose is not to make consulting as comfortable or conflict-free as possible. It is to enable sound decisions and effective implementation. This may require an assessment that differs from the original expectation.

I make the consequences transparent and discuss them with the responsible people.

Together with you, I assess whether the missing conditions can be created, the objectives adjusted or the roles clarified. This may require additional decisions, resources, involvement from other people or a reduction in scope.

Where essential conditions remain absent, I will not continue the engagement unchanged. Formally continuing a project without a realistic basis for impact would not be responsible for either the client or Hosang Consulting.

Yes. Ending an engagement may become necessary when essential conditions remain absent, agreed participation does not occur or significant risks are knowingly ignored.

I do not take this step prematurely. I first make the situation transparent and examine possible adjustments with the client.

Where no realistic path to responsible impact remains, I recommend resetting or ending the engagement. Continuing solely because of its duration or commercial value would not be consistent with my understanding of responsibility.

I charge on a time-and-effort basis. The rate depends on the task, the responsibility and the surrounding conditions, and is set out in the proposal.

The first fit conversation of 20 to 30 minutes is free of charge. For every paid step, we agree a cost ceiling in advance.

For selected social and Christian projects I can also work free of charge, particularly remotely. In certain situations we set the fee together. What matters is an agreement that is fair to both parties.

Sparring is a critical discussion of specific decisions with an independent adviser. I contribute questions, experience and recommendations; you make the decision. It is useful when you are willing to question your assumptions and take responsibility for the next steps.

Sparring can help clarify options, competing objectives and roles in management or project work. I am direct about the issue and respectful towards the people involved. Rather than simply confirming an existing opinion, the conversation should open up new perspectives. I do offer assessments and recommendations, but I do not make your business decisions. Where medical or mental health concerns are central, an appropriately qualified professional is needed. Sparring is neither psychological counselling nor therapy; its format and duration are agreed individually.

Two causes are worth checking first: whether everyone means the same thing by "commitment", and whether work and blockers are visible at all. In the 2020 Scrum Guide, the Sprint Goal is the Developers' commitment; how much scope gets done in the Sprint is a forecast that can be renegotiated with the Product Owner during the Sprint.

Clarify terms: in the 2020 Scrum Guide, each artifact has a commitment. For the Sprint Backlog it is the Sprint Goal, to which the Developers commit. The Sprint Backlog itself is a plan by and for the Developers. Scope can be clarified and renegotiated with the Product Owner during the Sprint as long as the Sprint Goal is not endangered; the Guide refers to the planning of scope as a forecast. Treating every planned task as a firm promise measures the team against something Scrum does not regard as a commitment. Then check the causes before anyone is blamed: Did unplanned work enter the Sprint, such as incidents or ad hoc requests? Were priorities changed during the Sprint? Did items depend on other teams or suppliers? Was the Definition of Done clear to everyone? Were items planned too large? And do all teams record work in the same way, so that blockers become visible at all? In a documented development organisation with teams at several locations, each team recorded work differently. Sprint commitments were made and missed without anyone being able to say why. What was introduced there: a Kanban board across all teams that made work and blockers visible, Sprint structures with "explicit commitments", as the case study calls them, and retrospectives that led to actual process changes. The case study's term "commitment" is not the same as the commitment in the Scrum Guide sense, which relates to the Sprint Goal. For your next retrospective: take the last three Sprints and, for every item not completed, mark the reason, for example unplanned work, a dependency, reprioritisation, underestimation or an unclear requirement. The pattern shows where a measure needs to start and moves the conversation from blame to causes.

By having one function on your side accountable for how everything fits together, by explicitly assigning every interface between suppliers to named owners, and by having a body that decides regularly and bindingly. Coordination becomes the bottleneck when every detail has to pass through a single person.

Several suppliers deliver parts, but none of them is accountable for the whole. That accountability stays with your organisation as the client. HERMES 2022 provides for internal and external services to be agreed and regularly checked against plans and agreements; deviations go through change management and significant problems through problem handling. If a supplier is effectively steering because it has most of the expertise, accountability shifts without anyone noticing. Useful building blocks are: an interface list in which every interface has a named owner on both the supplier and the client side; a joint integration plan with dependencies instead of separate individual plans; a weekly body with a mandate to decide, not just to inform; a clear rule on what suppliers may resolve directly among themselves; and an escalation deadline after which unresolved issues go to the next level. The rule on direct resolution in particular prevents the bottleneck: if suppliers may resolve technical detail questions directly, and only decisions affecting schedule, cost, quality or other suppliers go to the coordination function, it remains able to act. In a documented engagement to replace devices across a nationwide branch network, coordination rules kept several suppliers aligned without becoming a bottleneck; weekly decision bodies had a mandate to decide on issues rather than discuss them. For a regulated self-service solution, the responsibilities taken on included preparing supplier selection, coordinating custom hardware and software development, and defining the interfaces.

Not necessarily. HERMES itself provides for scaling: first with the sizing function on HERMES Online, then, if needed, with tailoring. For small undertakings below your organisation's project threshold, there is also the HERMES One variant.

The reference manual states that the full scope is designed for large, highly complex projects, and recommends that organisations running mainly medium-sized and small projects scale the method with the sizing function. Sizing determines the project's size from a few inputs and provides a tailored scenario with a work breakdown structure and templates. According to the reference manual, it reduces complexity and documentation to the absolute minimum while keeping to HERMES governance. You can then adapt the scenario further through tailoring: remove modules you do not need, delete tasks and results (except the minimum required documents), add your own modules, or add tasks and results. The Federal Chancellery introduced sizing because, as it explained, most projects are relatively small and many users found the earlier tailoring approach overwhelming. HERMES One is intended for very simple undertakings: a template for small undertakings below the project threshold, which each organisation sets for itself. According to HERMES Online, governance under HERMES 2022 is then no longer ensured. If your project must be demonstrably run according to HERMES for auditors, a supervisory body or funders, I recommend regular HERMES with sizing rather than HERMES One. A test question that does not come from HERMES but is my recommendation from practice: only produce a document if someone needs it for a decision or a handover. Even in a small project, however, do not drop three things: a named project sponsor, a written objective and an acceptance at the end. These three points apply even if you do not use HERMES at all.

Four modules, three roles and the minimum required documents of the modules used remain mandatory. Savings come mainly from sizing and tailoring and, with agile delivery, from letting the detailed specifications refer to the development tool.

To comply with project governance, the reference manual requires every project to include the modules project steering, project management, project foundations and deployment organisation. The roles that must be filled as a minimum are project sponsor, project manager and user representative. These roles and their assignment to the user partner group must not be changed, even when the method is adapted to an organisation. The minimum required documents are compulsory. They include, for example, the project initiation order, the study, the project management plan, the execution order, the lists of project decisions and the final project evaluation. If a module is not relevant to the project, its minimum required documents also fall away. Minimum required documents cannot be removed during tailoring; an organisation may, however, adapt the list to its own governance rules. The most effective way to save effort is to use sizing first and only then tailor selectively. With agile delivery, the reference manual allows the detailed specifications simply to refer to the documentation in the development tool. User-defined scenarios can be downloaded and shared with other HERMES users, so similar projects do not have to be tailored from scratch every time. For anything beyond the minimum, I recommend one simple test question: who needs this document for which decision or handover? If nobody does, it is a candidate for dropping. This rule comes from practice, not from HERMES.

It is not an either-or question, because the two cover different things. HERMES is a project management method that defines what is produced in a project, when, and who decides. The IPMA Individual Competence Baseline (ICB4) describes the competences a person needs and does not prescribe a method.

HERMES is the project management method of the Swiss federal administration, published by the Federal Chancellery. It governs phases, milestones, roles, tasks and results and provides templates. The reference manual assumes that those involved have project management training or at least sound project experience. The ICB4 of the International Project Management Association describes a total of 29 competence elements in three areas: perspective (5), people (10) and practice (14); 28 of them are described for project management, because the fourteenth practice element (select and balance) applies only to programmes and portfolios. It sees itself as neither a textbook nor a cookbook, does not describe process steps and stands alongside standards that focus more on processes. In Switzerland, VZPM certifies individuals under the four-level IPMA system. HERMES describes the skills required for each role, such as communication skills or decisiveness, but no competence model. Leadership, teamwork, conflict and crisis, or negotiation are separate competence elements in the ICB4. Conversely, the ICB4 prescribes no phases, templates or approvals. For an organisation this means: a method such as HERMES creates a shared structure and language for projects; IPMA competences and certificates show whether people can lead within that structure. When selecting a project manager, I recommend assessing the two separately: HERMES knowledge if your organisation or client requires HERMES, and leadership competence, for example through an IPMA certificate from Level C upwards, for which VZPM assesses a report on the candidate's own project and an interview. For developing project managers, the ICB4 can serve as a grid of the skills a method assumes but does not teach.

An IPMA certificate confirms project management competence under the four-level IPMA system, independently of any particular method. From Level C upwards, VZPM in Switzerland assesses not only knowledge but also application, using a report on the candidate's own project and an interview. A certificate is valid for five years; according to VZPM, initial certification costs between CHF 900 and CHF 5,900 depending on the level.

Level D confirms broad knowledge of project management competences and requires no practical experience; assessment is by written exam. From Level C upwards, admission requires professional experience, and VZPM assesses a report on a real project of the candidate's own and an interview; Levels C and B also include a written exam, Level A does not. For Level C, VZPM states that the process usually takes eight to nine months. A certificate is a snapshot. It says nothing about industry or subject knowledge, knowledge of a particular method such as HERMES, or fit with your organisation; the underlying ICB4 explicitly does not prescribe a method. I therefore recommend asking for the date of the last (re)certification, for projects since certification and for references from comparable projects. For recertification at Levels A to C, VZPM requires evidence of at least 30 months of practice in project, programme or portfolio management and at least 175 hours of further training in the five years since the last (re)certification. For Level D, 175 hours of further training are sufficient, part of which may be covered by practical experience. The certificate must not have expired for more than six months, or twelve in justified exceptional cases. Initial certification in public certification rounds according to the VZPM price list (valid from 1 March 2024, version 9.0): Level D CHF 900, Level C CHF 3,200, Level B CHF 4,300, Level A CHF 5,900. Anyone who already holds a valid lower-level certificate pays less, for example CHF 2,900 for Level C with Level D. For Level D there are reduced prices in companies (CHF 800) and educational institutions (CHF 440) for five or more people per round. Recertification costs CHF 250 for Level D and CHF 600 for Levels A to C; in case of doubt, an interview costing a further CHF 600 may be added for A to C. Preparation courses are not included.

They describe increasing responsibility and complexity: Level D for broad project management knowledge and contributing to projects, C for managing projects of limited complexity, B for complex projects, programmes or portfolios, and A for very complex projects, programmes or portfolios at a strategic level.

Level D, Certified Project Management Associate: evidence of broad knowledge of project management competences; no practical experience required; application with self-assessment and a written exam. Level C, Certified Project Manager: managing projects of limited complexity. Admission: at least three years' experience as a project manager in projects of limited complexity within the last six years; in complex projects, only the roles of deputy project manager or sub-project manager count. Procedure: application with an executive summary report, written exam, report and interview. Level B, Certified Senior Project Manager (likewise for programmes and portfolios): managing complex projects, programmes or portfolios. Admission: at least five years' experience within the last eight years, of which at least three in a responsible leadership function in complex undertakings. Level A, Certified Project Director (likewise Programme and Portfolio Director): managing very complex projects, programmes or portfolios at a strategic level; as Project Director, at least five years in a senior leadership function within the last twelve years, of which at least three at a strategic level. I recommend measuring the appropriate level against the complexity of your project, not just its size. A level is evidence at a particular point in time; whether someone leads more complex projects today only becomes clear in a conversation about specific projects.

An agile approach fits when the solution only emerges through trying and learning, and usable parts can be delivered early. It fits less well when the solution is essentially fixed, usable partial results cannot be delivered early, or nobody with time and decision-making authority can take responsibility for the business requirements.

The Scrum Guide describes Scrum as a lightweight framework for complex problems. It is founded on empiricism: knowledge comes from experience and decisions are made based on what is observed. HERMES 2022 allows both traditional and agile implementation and requires the choice to be justified on professional grounds during initiation rather than following a trend. This leads to some test questions: Is the task genuinely open, or is the solution largely known, for example in a clearly specified procurement or with fixed requirements? Can usable partial results be delivered early and checked by the users? Is there a person who takes responsibility for the business requirements with expertise, time and decision-making authority? Is the team allowed to make mistakes and learn from them? According to the HERMES reference manual, the Swiss Federal Audit Office considers a zero-error culture fatal for agile work. Where these conditions are missing, a traditional approach with clear phases and approvals is often more honest than an agile label. The choice need not even apply to the whole undertaking: in an agile HERMES project, initiation and closure run in the traditional way, and only implementation takes place in iterations.

Yes. In the publication "Project management as an organisational capability", I understand project management as an organisation's deliberate and orderly handling of projects as a whole: which undertakings start, who decides on them, how they are led, which information can be relied on and how the organisation learns from them.

Leading a single project with a plan, a team and a budget remains important, but it is only one part. It also includes selecting undertakings (portfolio), the framework of roles and decision rights (governance), a shared way of leading undertakings, reliable leadership information, suitable tools and learning from one undertaking to the next. "Organisational capability" means that projects do not succeed only because experienced individuals carry them, but because the organisation has an orderly, shared way of working. Only then does the approach become repeatable, comparable and capable of learning, and the capability of individuals becomes the capability of the organisation. This applies to internal change and system introductions as much as to customer orders that are carried out as projects in the core business. A simple test: would your next important undertaking run just as reliably if your most experienced person were unavailable? If not, your capability to lead undertakings reliably still depends more on individuals than on the organisation.

As soon as undertakings are one-off, cross-functional and time-limited, usually yes. The line carries what is permanent; a project bundles the coordination for a specific result. The two logics depend on each other, and a project organisation does not necessarily mean new positions.

The line, also called the base organisation, carries permanent responsibilities, processes and knowledge. A project is a time-limited undertaking with a specific result and its own coordination task. It can be an internal change, but equally a customer order that is led as a project because it is one-off and requires cross-functional collaboration. Line and project are therefore not the same as "run" and "change". A company can sell customer orders repeatedly as part of its core business and still lead each individual order as a project. The line is not a bystander. Internal change projects must hand their results over to the base organisation; project-based customer orders, in turn, need stable processes, roles and knowledge from the line. In the project map for Hosang Consulting's reference model, an orientation without binding character, the receiving organisation therefore confirms its readiness before the introduction, and the steering level decides on acceptance or impact together with the receiving or using organisation. For smaller organisations, I recommend not starting with new positions but defining explicitly for each undertaking: the mandate and goal, who decides, who leads the undertaking, and who takes over the result in the line.

A project tool works best when the task, responsibilities and information are clear. Even simple digital aids can help early on; they do not replace leadership decisions.

What moves into a system in disorder remains in disorder in a system. The publication "Project management as an organisational capability" describes reaching for a tool as the first of the three most common mistakes in bringing order to projects; this is a statement based on experience, not a count. In Hosang Consulting's model of the eight areas of clarification, the tool question is therefore the seventh, not the first. In the revised maturity model, digital support is a cross-cutting capability and can be useful from an early stage. The more a tool depends on standardised workflows and measures, however, the more important it is to clarify the relevant tasks, roles and information first. Before buying, I recommend four questions: is there a shared way of leading an undertaking, with phases, roles and decision points? Is it defined who prioritises, approves and stops undertakings? What information should the tool provide to whom, and how reliable is that information today? In which existing systems do the subject-matter results already reside? A tool can certainly solve a specific problem, for example when a clarified process has simply not yet been mapped digitally or when information is scattered across too many places. Then the purchase is not a substitute for clarification but support for it.

Hosang Consulting summarises this in its own model of eight areas of clarification: purpose, value contribution, portfolio, governance, project leadership, reliable information, tools and learning. It is a deliberately chosen structure from practice, not a general doctrine and not a checklist.

The eight questions are: 1. What for, and which undertakings contribute to it? 2. How do we create value, and what do projects contribute? 3. Which undertakings do we start, and which not? 4. Who decides on the undertakings? 5. How do we lead an individual undertaking? 6. What can be relied on in an undertaking? 7. Which tools support projects? 8. How do we learn from one undertaking to the next? Areas 1 and 2 concern purpose and value, 3 and 4 portfolio and governance, 5 to 8 execution, information, tools and learning. The areas build on each other: an open question higher up can create friction further down, which eventually becomes visible as a bottleneck in projects. The order is inspired by Simon Sinek's "why, how, what", which the publication uses as a source of thought rather than as evidence. The model presupposes culture and identity, the "why"; it does not create them. That there are exactly eight areas is not a derivation but a chosen structure: fine enough to be concrete, coarse enough to remain clear. Three perspectives in the same publication should not be confused: the areas of clarification ask what must be clarified. The five levels of responsibility (strategy, portfolio, steering, leadership, execution) ask who carries which responsibility. The maturity level asks how far the organisation has come. One area of clarification can affect several levels at once. To get started, I recommend one simple question per area: can we answer it clearly and jointly today, and where do we notice in day-to-day work that it is still open?

Hosang Consulting’s own, not empirically validated maturity model provides guidance through five levels: person-dependent, defined and documented, standardised across the organisation, actively managed and measured, and continuously improved. Digital tools can help at every level. The model identifies possible development paths, not a scorecard or a prescribed route.

The five maturity levels describe how individual expertise can increasingly become an organisational capability to manage projects. 1. Person-dependent: projects succeed mainly thanks to experienced individuals; knowledge and decisions depend heavily on them. A useful next step is to record critical foundations. 2. Defined and documented: roles, procedures and templates are partly described and used in individual projects, but are not yet consistently shared across the organisation. The next step is an understandable common basis. 3. Standardised across the organisation: shared rules and approaches are actually applied in relevant projects and adapted to project types. The next step is to manage their results reliably. 4. Actively managed and measured: management uses appropriate information and measures on decision lead times, resources, project outcomes and, where relevant, benefits; it recognises deviations and responds deliberately. Measurement supports leadership rather than being an end in itself. 5. Continuously improved: the organisation evaluates experience and systematically improves procedures, templates and decisions beyond individual projects. Learning can occur at every level; here it becomes systematic and organisation-wide. Digital support is not a fifth level but a cross-cutting capability: a simple shared repository may help early on; more advanced systems become worthwhile when tasks and information are clear. Digitalisation replaces neither accountability nor culture. This five-level model is Hosang Consulting’s editorial guide, not an IPMA Delta or CMMI assessment. It draws on their progression from individual performance through defined and applied standards to active management and continuous improvement. The levels are not an empirically proven mandatory sequence. Not every organisation needs to pursue the highest level. Project significance, risk, business needs and the next useful step matter. This organisation-wide view should not be confused with Hosang Consulting’s go-to-market steering model, which assesses each of nine process phases separately on levels 0 to 4. A practical question is: what already works reliably, where do responsibilities or information still depend on individuals, and which improvement would produce a verifiable benefit in the next undertaking?

The preparation, yes; the decisions, no. Developing foundations, preparing information and drafting proposals can be delegated. What depends on leadership responsibility, such as priorities between undertakings and decision rights, must be decided by leadership itself.

The publication "Project management as an organisational capability" describes leaving the entire clarification to an external party or a new position as the second common mistake. As a recurring pattern in failed undertakings, it names, explicitly as experience rather than a research finding: leadership, stakeholders and risks are not addressed at the outset, top management takes too little initiative, and too much of the burden falls on employees. The reason is simple: whoever defines decision rights redistributes them, and whoever sets priorities also says what will not be done. An external person or a new position can prepare this, but cannot decide it with the necessary legitimacy. I recommend recording the division of work explicitly from the outset: what the external person or new position will produce, by when, and who will decide on it and when. A possible wording for the brief: "Please prepare two or three options with their consequences. We will decide in the executive board on the agreed date." A sign that the clarification was handed off rather than delegated: the results exist, but nobody in leadership feels bound by them.

A premortem is a short thinking tool used before an important project decision: those involved imagine that the undertaking has failed a year from now, and each of them writes down individually how this came about. This makes doubts and risks visible before the decision is taken.

The method comes from the psychologist Gary Klein and was described in the Harvard Business Review in 2007; Daniel Kahneman recommends it. The publication "Project management as an organisational capability" lists it as a source of thought, not as evidence. A possible procedure, for example in 30 to 45 minutes: briefly present the plan. Then set the scenario: "Imagine it is a year later and the undertaking has failed. How did that happen?" Everyone writes silently and individually for a few minutes. Then each person in turn reads out one point, without discussion, until everything has been collected. Finally, the most important points are grouped and included in the plan with a measure and an owner. The real gain lies not in the answers but in the fact that doubts are permitted and even required. People who would otherwise remain silent because they do not want to slow things down get a legitimate place to speak. Writing silently and individually prevents everyone from simply following the first or loudest opinion. Limits: a premortem is not a forecast. It can also produce risks that hardly exist in reality, and it only works if voicing doubts has no negative consequences for the person.

The two models can be read as distinct but compatible perspectives. The reference model describes an organisation-wide framework for governing initiatives. The nine-phase model describes support for a specific initiative through to impact and handover. This is an editorial interpretation; the sources contain no explicit one-to-one mapping.

The reference model is not an additional project method. It spans the arc from the project impulse to use, or to handover for customer projects, with management milestones at which leadership decides, while the actual project work can follow HERMES, PRINCE2, SAFe or an organisation's own approach. The nine-phase model runs from the project idea to impact and withdrawal. Between phases a deliberate decision is taken: continue, adjust, pause, stop or hand over. It also defines which role the consultant has at each point and when they step back. A one-to-one mapping of the phases is not documented. As an editorial interpretation, an engagement following the nine-phase model can take place within an initiative governed by an organisation using its reference model.

Yes. HERMES is suitable not only for the Swiss federal administration but also for municipalities, SMEs and other organisations. The key is to tailor the method to the initiative's size, complexity and risks.

HERMES and PRINCE2 are project management methods with different areas of emphasis. HERMES provides a clear framework for project governance, responsibilities, outcomes and decisions. PRINCE2 also takes a structured approach to directing and controlling projects. PMI, by contrast, is not a method but a professional association that provides project management standards and certifications. These approaches are not mutually exclusive. I therefore do not recommend a method merely because of its name. I examine which framework fits the organisation, its decision-making processes and its specific challenges.

Yes. HERMES and Scrum can be combined. HERMES provides the framework for directing and governing the project, while Scrum organises the agile development of the solution.

HERMES defines responsibilities, outcomes, milestones and the necessary decisions. Within this framework, a Scrum Team can develop the solution incrementally. The essential point is to establish clear interfaces between project governance and agile delivery. In particular, everyone must know who makes which decisions, how outcomes are aligned and how those responsible for the project stay informed about progress.

The HERMES project sponsor is responsible for overall project governance. They ensure the necessary resources are available and take the decisions assigned to them regarding execution, major changes and continuation of the project.

The Scrum Team, by contrast, self-manages its work within the agreed objectives and constraints. In particular, the Developers decide how to carry out the work needed to achieve the Sprint Goal. Self-management does not mean that the team acts independently of project governance. Objectives, budget, responsibilities and required decisions must remain aligned. The distinction must therefore be clear: the sponsor governs the project, while the Scrum Team organises the actual delivery within the agreed framework.

Scrum artefacts such as the Product Backlog, Sprint Backlog and Increment do not automatically replace the project outcomes required by HERMES. They can, however, help develop those outcomes incrementally and make progress transparent.

Which HERMES outcomes are actually required depends on the chosen scenario and project-specific tailoring of the method. Formal decisions remain necessary at the relevant HERMES milestones. Material changes to project objectives, budget or time frame may also require a decision by the competent project governance body. Changes within the approved framework, on the other hand, can be handled by the roles responsible for them. The key is to define decision-making authority clearly without burdening agile delivery with unnecessary approval steps.

For new projects, I generally recommend the current HERMES 2022 edition. Ongoing projects do not automatically have to switch. What matters are your organisation's binding requirements and the benefits and effort involved in changing methods.

Existing templates and policies based on HERMES 5.1 should nevertheless be reviewed. HERMES 2022 further developed the structure of the method, roles, outcomes and its interaction with agile approaches. Simply changing the version number in existing documents is therefore not enough. A targeted comparison of existing project requirements against the current method helps identify which documents need updating and where existing rules remain suitable.

HERMES 2022 further developed the method, particularly the relationship between project governance and solution development.

The most important change is a clearer separation of project management and development management. This allows a solution to be developed using either a traditional or an agile approach, for example Scrum, while HERMES continues to define the project organisation, responsibilities, outcomes and required decisions. The scenarios and modules were also revised, the user representative's role was strengthened and the tailoring of the method to different project sizes was developed further. For organisations, this means HERMES can be applied more flexibly. Existing project rules, role descriptions and templates should therefore be reviewed and updated where necessary.

No. A project management method provides structure and defines roles, responsibilities, processes and decision points. It does not, however, guarantee project success.

What matters is how the method is applied in practice. Those responsible need to make decisions, address conflicts, set priorities and secure the necessary resources. The Swiss Federal Audit Office also notes in the HERMES reference manual that consistent application of a method alone does not guarantee project success. I therefore see project management not merely as a matter of methodology, but also as a question of leadership, accountability and an organisation's capacity to make decisions.

HERMES defines a structured framework for project management. This includes project phases, milestones, decision-making processes, roles, tasks, outcomes, scenarios, modules and templates.

HERMES also describes collaboration between the project organisation and the core organisation. However, it does not fully define the latter's internal structure, all decision-making authorities or its leadership processes. Nor does HERMES generally prescribe the specific working method used to develop a solution. Traditional or agile approaches such as Scrum can be used within the project framework. The essential point is that HERMES provides methodological clarity but does not replace effective leadership, subject-matter expertise, accountability or the decisions that need to be made.

Hosang Consulting is the accountable centre of each engagement.

Clients work directly with the responsible people at Hosang Consulting. Where additional capabilities are required, I assemble an appropriate team of internal and external specialists.

This combines personal accountability with access to a broader range of expertise. It avoids an oversized consulting apparatus, but also an artificial limit to what one person can do.

Additional specialists are selected according to the specific assignment, their professional expertise, their experience and their personal fit.

Technical expertise alone is not sufficient. The person must also be suited to the situation, the organisation and the agreed way of working.

Hosang Consulting clarifies roles and interfaces, coordinates the work and remains accountable for the overall direction of the engagement. The client should always know who is responsible for what and who is accountable for the overall result.

Decision architecture means turning a complex situation into an understandable basis for decisions: bringing information together, surfacing contradictions and separating what matters from what does not.

My business partner Ralph Mattli takes on this role as the founder of QUENARIS. QUENARIS connects knowledge, decisions, roles, context and experience across people, digital team members and external partners into a shared picture that teams can work with. It supports decision-making and implementation work, but replaces neither existing systems nor human responsibility. The decision itself always remains with the people involved.

In my work, I use QUENARIS as a digital working and organisational system. Disclosure: I also work at Mattli Digital myself, which implements QUENARIS technically, and I can directly influence the functional scope of QUENARIS. Hosang Consulting remains technology-independent: QUENARIS is one possible solution, but not a required outcome of an engagement. Where QUENARIS is part of a client solution, this is explicitly agreed.

Organisational memory is what an organisation knows about itself, its decisions and the reasons behind them. It does not depend on which people happen to be there at the time.

It does not form on its own. Knowledge leaves an organisation with every staff change, at every team boundary and at the end of every external collaboration. That happens whenever nobody deliberately holds on to it.

An organisational memory keeps experience usable – for the next decision, not just for the archive.

I offer coaching and sparring for leaders myself, as Sparring & Enablement.

Executive search is not a service of Hosang Consulting. If you want to fill a leadership position, I am happy to put you in touch with my business partner Heinz Brägger, Partner and Practice Lead Change & Transformation at Leverage Experts. He offers executive search independently.

Clarification before an important decision: clearly defined analyses and workshops that create a sound basis for decision.

Leading an initiative for a limited time: external project leadership and time-limited operational leadership roles in initiatives.

External support and an independent outside perspective: time-limited support for the project lead, a status assessment or work on specific tasks when no new project lead is needed. Leadership and decisions remain with you.

Transformation and implementation: transformation engagements and operational implementation responsibilities, with specialists brought in where needed.

Sparring and independent review: one-off or regular executive sparring for leaders and project owners.

Engagements can be one-off, across a defined project phase or over a longer period. A combination is also possible, for example an intensive clarification and development phase followed by reduced support.

The model depends on the assignment and the actual need for accountability. Scope and duration are no larger than effective delivery requires.

At the beginning, I clarify the specific change the engagement is intended to achieve and how that change will be recognised.

Depending on the assignment, impact may include clearer decisions, more stable processes, defined responsibilities, a successful implementation, improved collaboration or an organisation that can operate independently.

These criteria are not considered only at the end. Throughout the engagement, I regularly review whether the chosen actions are contributing to the intended impact. Where they are not, I adjust the approach or revisit the underlying assumptions.

I involve existing teams and responsible leaders from an early stage. Knowledge, decision criteria, roles and working practices are developed collaboratively and documented in a usable form.

Where I temporarily take an operational or leadership role, I also plan the transfer of that responsibility. The objective is an organisation that can continue independently and assess new situations for itself.

External support may remain valuable. It should, however, be a conscious choice rather than the result of knowledge or responsibility being deliberately retained by the consultancy.

If nobody is explicitly responsible, often nobody is. Decide at the time of the decision who will check after the project ends whether the measure has changed anything, when and on what basis; without this link back from impact to decision, an organisation hardly learns from its results.

A decision is the start of a chain: decision, measure, implementation, impact, insight, learning. According to Hosang Consulting's published experience, the first three links usually work well. The last three become thinner, because the project has officially ended and the team is already on the next initiative; the question of impact then no longer has a place in the calendar. The consequence: without this link back, an organisation repeats patterns instead of correcting them, because nobody knows any more which earlier decision led to which result. Hosang Consulting describes as a typical capability gap that a project has a sponsor and a project manager but nobody who remains responsible for the result in daily operations after the project ends. In practice I recommend: name a person responsible for impact in the line organisation, not in the project that is ending. Record at project closure what impact is expected, how it can be recognised and when it will be checked. Link the result to the original decision note and carry the insights into the next decisions. A decision is not done when the measure is completed, but when its impact is known.

“Implemented” proves an output, not impact. Measure impact with leading and lagging indicators that fit the specific initiative: leading indicators show whether things are moving in the right direction, lagging indicators whether the impact has materialised.

A completed workshop or an introduced system is an output. Whether collaboration, decision-making or usage have changed afterwards is the outcome. Many reports stop at the output because it is easier to prove; an honest answer to whether it worked needs time, distance and sometimes the courage to accept an uncomfortable answer. Examples Hosang Consulting uses: early signs include the quality and openness of conversations, a more shared understanding of the starting point, clearer goals, roles and responsibilities, visible assumptions and risks, and faster, more traceable decisions. Later signs include actual use of new systems and ways of working, stability in daily operations, acceptance, measurably better organisational results, less dependency on individuals or external consultants, and the ability to develop further independently. Agree goal, expected result and measurement criteria at the start, with goals formulated according to the SMART principle where useful. Measure what is relevant to the agreed impact, not just what is easy to measure. If reliable data is lacking at the start, that is no excuse: name it as part of the starting point and improve measurability step by step. Measurement serves decision-making and learning, not itself.

Research shows positive statistical associations between effective project management practices and project success. Some studies also find associations with organisational business performance. This does not establish a general or causally certain return on every additional investment in project management. What matters is which specific problems are solved and which improvements actually result.

There are positive findings. Mir and Pinnington (2014) analysed 154 responses from project professionals and found a statistically significant association between project management performance and project success. Their model explained about 44.9 per cent of the variation in measured project success. Joslin and Müller (2015) analysed 254 international responses; applying a project management methodology explained 22.3 per cent of the statistical variation in project success. Both figures are explained variance, not increases in revenue, financial returns or proof of causation. Evidence at the level of the whole business is harder to interpret. Yazici (2009) reported an association between perceived project management maturity and perceived business performance among 86 professionals, but not between maturity and project performance; organisational culture contributed independently. Findings depend on how performance is measured and on the environment and organisations studied. They do not establish a universal return-on-investment guarantee. I therefore recommend starting with the specific business problem and the baseline: are decisions delayed, status data unreliable, resources double-booked, handovers weak or objectives unclear? Before changing the approach, agree on suitable indicators such as decisions made on time, lead times, comparable reports, rework or realised benefits in operations. Later, check what improved, what the change cost and what other factors may have contributed. A lean framework, or deliberately avoiding additional bureaucracy, can also be the right outcome.

Often because insights are recorded but not made available and used again in the next undertaking; research and practical experience point to this, but rigorous proof is lacking. Learning only becomes effective when it feeds into how the next undertaking is prepared and led.

Research points to a gap between procedure and practice: in surveys of project managers, a large share say they have a formal procedure for lessons learned, but only a small share actually follow it. The publication "Project management as an organisational capability" knows this finding second-hand and explicitly presents it as an indication, not as evidence. As experience and thesis, the publication describes what typically happens next: the insights end up in repositories that become silent archives. What survives are the forms and templates, not the actual insights. The valuable knowledge that arises when an undertaking passes into operations depends on individuals and leaves with them. I recommend anchoring learning at the beginning rather than at the end: when initialising a new undertaking, explicitly review three to five insights from comparable undertakings. Record insights briefly, concretely and with a responsible person. And where possible, do not just write a report but adjust the template, checklist or process directly, so that the insight takes effect automatically next time. In Hosang Consulting's model of the eight areas of clarification, learning from one undertaking to the next is the eighth area; according to the publication, without it every improvement remains a one-off.

Confidential information is used only for the agreed purpose of the engagement. Only those who need it for their work can access it.

At the beginning, I clarify any additional requirements for data protection, information security, systems and documentation. When involving additional specialists, the same agreed confidentiality requirements apply.

Technical tools and AI applications are not indiscriminately fed with confidential client information. Their use must be proportionate to the confidentiality requirements of the engagement.

Many of my engagements concern strategic decisions, internal conflicts, projects at risk, organisational changes or confidential technology initiatives.

A detailed public account could make organisations, individuals or business situations identifiable. For this reason, I anonymise case examples unless there is explicit approval for named publication.

Anonymisation is not intended to artificially exaggerate results. It protects those involved but still lets me present the situation, approach and key findings clearly.

AI can support me in research, structuring, documentation, exploring variations and processing large amounts of information.

Its use is task-specific and takes into account confidentiality, data protection and professional quality. Results from AI systems are not accepted uncritically as facts or decisions.

AI is an integral part of my way of working, but no substitute for human work. Quality comes from experience, context, direction, review and human judgement. Whoever approves a result is responsible for it; the depth of review depends on the risk.

People conduct the critical conversations, assess connections, weigh interests and risks and take responsibility for recommendations and actions.

This applies in particular to management decisions, conflicts, ethical considerations, sensitive personnel matters and situations where information is incomplete or contradictory.

AI can provide insights, structures and drafts. However, it cannot responsibly assess what is appropriate for a specific organisation and its people. This responsibility remains with the people involved.

Yes. Ezra Luck is an AI agent (software) from MATTLI-DIGITAL, not a human being. He supports me with project coordination, CRM and documentation work, and recurring marketing and coordination tasks.

Ezra Luck always operates under human direction. Decisions, external communication and professional responsibility remain with the people in charge. His task is to bring information together and keep an overview, not to decide. He does not make independent strategic or business decisions.