More meetings, longer status reports and additional tracking tools rarely solve a project’s underlying problems. Sometimes the most valuable intervention is simply to establish what is actually happening.
The project is running. Meetings take place, tasks are assigned, dashboards are updated and progress reports are distributed. Everyone is busy. And yet, somehow, the project is not moving forward.
Decisions remain unresolved. Requirements are discussed repeatedly. Responsibilities overlap or disappear into organisational gaps. Problems are documented, but not necessarily addressed. From the outside, everything appears reasonably well organised. Inside the project, however, uncertainty is quietly accumulating.
I have encountered variations of this situation throughout my work in IT projects, particularly in complex organisational environments. The interesting question is not always why people are failing to deliver. Quite often, they are working very hard. The question is whether their efforts are directed towards the same, clearly understood objective.
Modern project environments offer an impressive collection of tools for organising work. Jira tracks tasks, Confluence stores documentation, dashboards display progress, and meetings provide opportunities for alignment. All of these can be valuable. But none of them automatically creates clarity.
A project may have hundreds of well-maintained tickets and still lack agreement on what the business actually needs. A status report may be entirely accurate while failing to reveal that a critical decision has been postponed for weeks. And a calendar filled with meetings can create the reassuring impression that everything is under control. Unfortunately, a full calendar is not a project deliverable.
The distinction between activity and progress is one of the most important principles in effective project management. It is tempting to measure what is easy to count: completed tasks, closed tickets, workshops held. Those numbers are useful only when they can be connected to an outcome that matters. Otherwise, the organisation becomes exceptionally efficient at describing its own activity.
A requirement is more than a sentence in a specification. It represents a business need, an expected outcome and, often, an assumption about how people or systems should work. When those assumptions remain unexamined, misunderstandings can survive for months.
For example, two departments may agree that a new process should be ‘automated’ while imagining entirely different results. One expects fewer manual steps; the other expects no human intervention at all. Both may approve the same high-level requirement. The disagreement becomes visible only when implementation is well under way.
A structured Business Analysis approach helps distinguish genuine requirements from proposed solutions, clarify dependencies and establish meaningful acceptance criteria. The objective is not to produce more documentation. It is to make the right decisions possible, early enough for them to matter.
Projects frequently involve several departments, external service providers, business representatives and technical teams. Everyone has a role. But who actually owns the next decision? Who resolves conflicting priorities? Who is responsible when a dependency crosses organisational boundaries?
When these questions cannot be answered clearly, work slows down. Teams wait for approvals, make assumptions or revisit decisions they believed had already been made. A simple, agreed responsibility structure is often more valuable than another sophisticated reporting mechanism. Clear ownership is not about assigning blame; it is about ensuring that important matters do not fall between the chairs.
Meetings are essential when they create shared understanding, resolve issues or enable decisions. They become expensive when the same questions return week after week. A useful meeting should have a purpose, the right participants and a clear result. Sometimes that result is a decision. Sometimes it is an assigned action with a responsible owner and a deadline.
If neither happens, it is worth asking whether the meeting is serving the project or merely occupying its calendar. I prefer a short, focused discussion that removes a blocker to an elaborate workshop that produces another list of open questions. Preparation and follow-through are rarely glamorous, but they are where much of the value is created.
A good project report should do more than communicate what happened last week. It should help management understand what requires attention now. Which decisions are overdue? Which dependencies threaten delivery? Which risks have become issues? Where does the project need support?
A green status indicator can be reassuring, but it is not an answer in itself. If important assumptions remain untested, a project can appear healthy until a critical milestone is missed. The value of reporting lies not in the number of charts but in the quality of the decisions those charts enable.
When a project begins to struggle, there is often pressure to introduce something new: a framework, a tool, a meeting structure, perhaps even a complete reorganisation. Occasionally, such changes are necessary. But before adding complexity, I prefer to establish a clear picture of the existing situation.
That means understanding the intended outcome, reviewing the actual state of delivery, identifying unresolved decisions and making critical dependencies visible. It also means speaking with the people who perform the work. They frequently know where the real difficulties lie, even when official reporting does not fully reflect them.
In practical terms, this might begin with a small number of conversations and a review of the existing requirements, decision log, risks and delivery plan. Where do descriptions contradict one another? Which actions have no owner? What is blocked by an external dependency? The purpose is to create a shared picture that is sufficiently accurate to act upon, not to conduct an elaborate diagnostic exercise that becomes another project in itself.
Project Management Office support and Business Analysis are sometimes treated primarily as administrative or documentation functions. That interpretation misses much of their potential value. When applied effectively, they connect business objectives with operational delivery.
Business Analysis helps establish what needs to be achieved and why. It makes expectations explicit, exposes conflicting assumptions and translates business needs into something teams can evaluate and deliver. PMO provides transparency around progress, dependencies, responsibilities, risks and decisions. It helps ensure that the information needed for steering is available, understandable and current.
Together, these disciplines can create the conditions in which project teams work with greater confidence and fewer unnecessary interruptions. This does not require taking control away from the people doing the work. On the contrary, good structure should enable them to concentrate on it. The best process is not necessarily the most elaborate one; it is the one that helps people move forward reliably.
Complex projects rarely benefit from unnecessary drama. When deadlines approach and pressure increases, the temptation to respond with more activity is understandable. But urgency should not be confused with effectiveness. A calm, analytical approach makes it easier to distinguish between symptoms and causes, identify priorities and communicate difficult information without creating additional uncertainty.
This matters particularly in regulated environments, including banking, where traceability, accountability and reliable delivery are essential. It is possible to be candid about a problem without making it theatrical. A clearly described risk, a realistic decision request and a credible next step will generally serve a project better than a dramatic escalation without a proposed way forward.
Calmness is not passivity. It is the discipline to respond deliberately rather than react automatically. And it requires the confidence to say, when necessary, that a project needs clarity before it needs more speed.
When a project appears busy but progress remains uncertain, I would begin with five questions:
These questions are not complicated. Obtaining clear, consistent answers can be surprisingly difficult. And that is precisely why they matter. If the answers differ depending on whom you ask, the discrepancy itself is useful information: it shows where alignment is missing and where the next conversation should begin.
Successful project delivery does not necessarily depend on introducing more processes, more meetings or more sophisticated tools. It depends on ensuring that people understand the objective, their responsibilities and the decisions required to move forward.
My work in Business Analysis, Project Management and PMO has repeatedly reinforced one principle: Structure should make work easier, not become additional work. When a project loses momentum, the first priority is not always to move faster. Sometimes, it is to establish where we are going — and then make sure everyone is moving in the same direction.
Christoph Kopowski works in Business Analysis, Project Management and PMO, supporting organisations with requirements, processes and structured delivery, particularly in complex IT and banking environments.
'/%3E%3C/svg%3E){kind=small}
