Process management goes beyond documenting how work flows. Its real test begins where one process crosses several teams, functions or organisations. LOT Polish Airlines’ presentation shows how to give this cooperation a shared goal, allocate accountability and manage change while maintaining everyday operations.
This case study is based on a presentation by Wiktoria Kalinowska, Head of the Continuous Improvement Section in LOT’s Technical Operations area. It is not a description of one project concluded with a table of quantified results. It offers a practical model for initiatives where several parties must carry out their own tasks, protect operational continuity and improve the entire flow together.
Process management at LOT: why cooperation is part of the process
In an organisation with extensive operations, results rarely depend on one department. Each team can perform its own part well while the overall process remains too slow, unstable or burdened with unnecessary handovers. Local optimisation is insufficient when value is created in the flow between people.
LOT’s presentation distinguishes three contexts for cooperation. Within one area, shared operational goals and a quick understanding of the problem are easier to achieve. Across areas of the same company, a common corporate goal coexists with different priorities and perspectives. In an external partnership, cooperation centres on interfaces while each organisation retains its own business objectives.
The more boundaries a process crosses, the more important agreed rules become. This is why process management must also be understood as organising cooperation, with a clearly defined goal, roles, communication routine and a method for learning from successive changes.
From silos to a shared process goal
The first step is neither selecting a Lean tool nor creating an elaborate plan. The parties must first agree what outcome they want to achieve together and why it requires cooperation. A shared goal acts as a filter, distinguishing actions that improve the entire process from those that merely move a problem to the next team.
This matters especially when local measures drive conflicting behaviours. One area may seek maximum use of its resources, another shorter queues, and an external partner lower service costs. Without an overarching goal, each party may rationally optimise its part while worsening the overall result.
A shared goal does not remove differences between teams. It allows those differences to be managed in relation to the whole process.
Good practice is to describe the goal as an outcome rather than a task list. “Run a workshop” and “implement a system” are activities. A process goal could instead be a shorter response time, fewer interface errors or more predictable flow. The appropriate working method can then be selected.
Process management: four steps to launch cooperation
LOT’s model structures the start of cooperation into four steps. Their sequence matters: the goal precedes team selection, the team precedes allocation of work, and monitoring closes the learning loop.
1. Kick-off: purpose and values
The opening meeting should answer several simple questions: which problem are we solving, what shared value will we create, where are the initiative’s boundaries and how will we recognise progress? It is also the time to agree communication and decision-making rules. A well-run kick-off reduces later disputes about the goal’s meaning.
2. Team structure: knowledge and process capabilities
The team should combine people who understand the work with people who can lead process analysis. Knowledge of improvement methods cannot replace operational experience. Equally, subject-matter experts without a shared method may discuss details at length without reaching a decision. LOT therefore highlights the need to combine subject-matter and process expertise and establish clear roles.
3. Task structure: workstreams and accountability
A large challenge should be divided into logical workstreams while preserving their interdependencies. Each task needs an owner, an expected outcome, a deadline and a way to hand over its result. This reduces situations where everyone participates in a project but nobody feels responsible for closing a specific issue.
4. Monitoring: progress, lessons and future solutions
Monitoring should go beyond checking deadlines. It should also detect obstacles, test assumptions and develop solutions that can be used in future initiatives. A project then leaves behind a better way of cooperating as well as its immediate outcome.
Process management: five models of joint improvement
Cooperation does not always need to begin as a major transformation project. LOT presents five models that can be selected according to relationship maturity, change risk and the type of problem.
Partner benchmarking
Partners compare working methods, learn from one another and identify differences without automatically copying solutions. Benchmarking’s value lies in a good question: why does a standard work in this context, and what conditions are needed to apply its logic elsewhere?
Joint retrospectives
A retrospective shifts attention from assigning blame to understanding mechanisms. The parties analyse what worked, where difficulties arose and what should change in the next cycle. Regularity matters more than an elaborate format.
Expert exchange
Temporarily involving an expert in another team’s work shortens the path from describing a problem to understanding it. It also helps build a common language. The exchange needs a clear purpose: transferring knowledge and problem-solving capability rather than simply adding another pair of hands.
Process pilots
A pilot tests a new workflow in a limited area. Before scaling a solution, the team tests roles, standards, handovers and measures. This is particularly useful when a change affects several areas and a wrong assumption could be costly.
Technology pilots
Technology can support a good process but cannot replace process clarity. A technology pilot should therefore test the tool, the working method and user responses together. Digitalising unclear responsibilities or unnecessary handovers merely makes the problem faster and harder to see.
Process management during project delivery
After a good start, a regular routine is needed to sustain cooperation. LOT’s presentation focuses this stage on three areas: communication, progress monitoring and implementing changes.
- Communication: the parties agree channels, frequency and recipients. Meeting numbers alone do not create information flow; transparency and sufficient trust to raise risks early are essential.
- Progress monitoring: a regular review routine helps oversee timeliness, remove obstacles and make decisions requiring sponsor support. A steering committee may fulfil this role in larger initiatives.
- Implementing changes: every change should end with a review, feedback and identification of the next improvement. This connects delivery with continuous improvement.
Understood in this way, process management reduces ambiguity rather than adding bureaucracy: who decides, what the current priority is, where a deviation occurred and when escalation is needed.
Process management: how to implement change
Many aviation processes must operate continuously. Changes cannot therefore be designed independently of daily work and simply “switched on” on a chosen date. LOT’s model describes a transition through three states: current, design and future.
- Current state: the team identifies areas for improvement, observes actual work and distinguishes symptoms from causes while protecting operational continuity.
- Design: the solution undergoes risk analysis. Responsibilities, a test plan and consultations with people doing the work and process recipients are established.
- Future state: the implemented standard remains open to critical review. Users report observations, and the organisation treats the change as another step rather than the end of improvement opportunities.
Benefits of process management identified by LOT
The conference material identified four main benefit areas: shorter response times in daily cooperation, consistent processes and reduced waste, higher quality combined with standardisation, and automation. A shared goal can also strengthen strategic partnerships, motivate participants and accelerate learning between teams.
Precision matters: the presentation does not publish figures or a study confirming the final outcome of one specific project. These are benefit directions reported by LOT, rather than data supporting a percentage improvement calculation. This article deliberately avoids adding results absent from the source.
Trust as process infrastructure
Even the best process map cannot reveal everything if participants raise risks too late, defend their own area or avoid difficult information. LOT describes building cooperation as a journey from relationships through transparent boundaries and overcoming barriers to a sense of accountability.
Trust does not mean an absence of control. It means being able to say openly: “We do not understand this”, “This assumption was not confirmed” or “This deadline is at risk”. Problems then enter the management system earlier, while simple corrective action is still possible.
Four practices that sustain cooperation
LOT closes its presentation with four short recommendations. Together, they form a simple way to sustain cooperation after the initial enthusiasm.
- Shared KPIs. A measure should describe the flow’s outcome rather than only one team’s activity.
- Closer cooperation. Relationships develop through jointly solving real problems rather than declarations.
- Everyday trust. Transparency must be visible in routine decisions, communication and responses to deviations.
- Feedback and corrections. Cooperation standards should be improved like any other process standard.
Common risks in process cooperation
Several practical risks can be inferred from the model. These are editorial conclusions based on the source’s logic, rather than incidents reported by LOT.
- A goal defined as a task. The team completes activities without knowing whether process performance improved.
- No owner at the interface. Each party owns its area but nobody owns handover quality.
- An excessively broad first step. A large scope makes assumptions harder to test and dilutes accountability.
- Technology before standards. A digital tool reinforces inconsistent working practices.
- Reviews focused only on deadlines. Problems are reported but the team does not learn from their mechanisms.
- Local KPIs outweighing the shared goal. Rational departmental decisions produce an irrational result for the whole process.
A practical checklist before launching an initiative
An organisation applying this model can begin with ten questions:
- Does the problem actually cross a team boundary?
- What shared outcome justifies cooperation?
- Which local objectives could conflict with it?
- Who knows the actual work, and who will lead process analysis?
- Where are the most important interfaces?
- How will roles, tasks and decisions be allocated?
- Which model is the best first step: benchmarking, a retrospective, expert exchange or a pilot?
- How will we protect operational continuity during the test?
- Which shared KPI will show the result of the whole flow?
- When and how will the team review its lessons?
Unclear answers do not necessarily mean the project should stop. They signal that the structure of cooperation should be refined first. This effort usually costs less than correcting misunderstandings during implementation.
Process management: lessons from LOT
The most important lesson goes beyond an individual tool. Process management requires conditions that allow different teams to examine a shared flow, make decisions against the same objective and raise deviations safely.
LOT’s model combines structure—goals, roles, tasks, KPIs and monitoring routines—with the human conditions for success: relationships, transparency, trust and a willingness to correct course. Separating these dimensions weakens change. Relationships alone may not deliver results, while procedures alone cannot ensure honest information about problems.
A useful starting point is therefore a limited joint pilot rather than an ideal target model. Participants agree an outcome, test the working method, measure the effect and improve both the process and their cooperation.
More information about the organisation and its operations is available on the official LOT Polish Airlines website.
FAQ: process management in practice
How does process management differ from project management?
A project has a defined beginning, scope and end. A process operates continuously and creates a repeatable outcome. A project can improve a process, but ownership, standards, measures and a routine for further improvement remain necessary afterwards.
Does a shared KPI replace departmental measures?
No. Local measures still help manage individual areas. However, a shared KPI should show whether cooperation improves the entire flow and prevent one section being optimised at the next section’s expense.
Which cooperation model is the best starting point?
When trust is low or process understanding incomplete, benchmarking or a joint retrospective can be a suitable beginning. Once the problem is well defined, a limited process pilot is useful. Technology is best tested after clarifying the goal and workflow.
Does LOT’s presentation confirm specific numerical results?
No. It identifies expected benefit areas and good practices but does not publish final KPI values for a single project. The case therefore describes an operating model without attributing undocumented results to LOT.
About the case study presenter
Wiktoria Kalinowska is Head of the Continuous Improvement Section in the Technical Operations area of LOT Polish Airlines. She specialises in aviation-process improvement, cross-functional initiatives and cooperation between teams. Her approach combines process-management structure with operational practice, focusing on shared purpose, accountability, trust and the safe implementation of changes in processes that cannot simply stop for a project. View Wiktoria Kalinowska’s profile on the Leantrix website (in Polish).
This article is based on materials presented by Wiktoria Kalinowska at the 2nd Lean TWI Summit on 11 June 2025. The illustrations are original Leantrix interpretations of the publicly presented case-study logic. They do not reproduce LOT’s operational documentation.
