The title „At our company it works differently” did not appear by accident. It is one of the first responses I used to hear as a Scrum Master when I joined a new team and asked why something was done in a particular way. On a certain level, this statement is true. Every company has its own specifics, history, constraints, and culture. But over 18 years of working in IT, in different roles and positions, I have learned that when we move from generalities to details, a great deal can actually be structured and clearly defined.
This text is an attempt to introduce a way of looking at an organization from multiple perspectives – with the precision I gained from working with management frameworks, but without jargon for the sake of jargon. My goal is to defuse the natural tensions that arise between different activities within a company and to show that differences in approach usually do not stem from bad intentions, but from different operational objectives.
Instead of looking for someone to blame for delays, bureaucracy, or chaos, I prefer to look at a company as a living organism – one that must simultaneously take care of both stability and innovation.
A project and a process are not the same
A project is a unique, one-time journey into the unknown. Its goal is to change the status quo. The key word here is uniqueness. We create something that has not previously existed in this form, which automatically introduces uncertainty about both the outcome and the path leading to it. Every project has a clearly defined beginning and end, as well as assigned roles, responsibilities, and a budget.
A good example is the creation and deployment of a new mobile application for a bank’s customers. Such an effort includes phases such as design, testing, release, and later maintenance. There are specific dates, a specific team, and a clearly defined scope and all of this together constitutes a project.
A process, on the other hand, is like a factory that thrives on predictability. It has defined inputs, outputs, and standards. Unlike a project, it is continuous and repeatable. Success is not about discovering something new, but about achieving the same result every time, regardless of who performs the task. In a process, the focus is on efficiency – how to perform the same steps faster, cheaper, and with fewer errors.
An example? The daily posting of invoices must follow a strict scheme to avoid legal or tax errors. Or consider a helpdesk: every issue should be resolved according to a defined technical and time standard. This ensures that the customer knows what to expect.
In this context, boredom is actually a compliment for a process. If things are boring, they are stable. And if they are stable, the process is probably working.
In everyday work, however, we usually operate in a hybrid mode. When I ask people to list three things they do at work and then ask themselves whether tomorrow they will do them exactly the same way or aim for a different result, the answer is usually: a bit of both. If tomorrow we fill out the same report again according to a familiar template, we are acting in a process-oriented way. If we plan a meeting with a new client to discuss topics we have not encountered before, the situation changes. Even if the meeting itself is routine, the result will be new. Is that already a project? Not necessarily in a formal management sense. But thinking about what we do not yet know is already a form of project thinking.
In a project we manage the unknown, in a process we manage efficiency
In a project, planning is not about predicting the future, but about consciously managing the unknown. That is why established project management frameworks include dozens of management processes from risk management, budgeting, stakeholders and requirements, to change management. All of this exists to gradually reduce the area of uncertainty.
Because we operate in a space of novelty, change is a natural part of the work – it is not evidence of a bad plan. In the traditional waterfall approach, subsequent phases are meant to confirm earlier decisions. In practice, however, regardless of the methodology used, a project requires continuous adaptation to new information: from the market, from technology, from testing, and from internal discussions.
Let us imagine building a prototype of a new electric car. It was initially assumed that the chosen battery would be optimal, but tests on the track show that it overheats in the sun. In project mode, we do not pretend the problem does not exist. We go back to the drawing board and search for a better solution. That is adaptation. The best project plans are not those that pretend to be infallible, but those that include mechanisms for updating decisions.
In a process, the situation is the opposite. The goal is not exploration but the elimination of deviations and the pursuit of operational maturity. If a single operation can be shortened by two seconds, then across a million repetitions we save hundreds of hours of work. In a beverage bottling plant, each bottle must be filled with great precision – too little and the customer is dissatisfied, too much and the company loses product. There is no room here for creative interpretation.
Why do we so often misunderstand each other?
Within the same organization, there are people responsible for change and people responsible for stability. Some are evaluated based on results and new solutions, while others are accountable for stability and continuity of operations. The conflicts that arise do not stem from personalities, but from a clash of priorities: innovation versus safety. And most importantly, both sides are right-each within the context of their own responsibilities.
Let’s look at a few typical statements:
„We can’t deploy this on Friday. What if something breaks over the weekend?” This is classic process language. Friday is the worst moment to take risks – any change could disrupt the operational machine that is expected to run without surprises.
„Why do we need this fifty-page documentation? The requirements will change anyway.” This is the language of projects. People working in a project environment know that change is inevitable, and that excessive documentation created too early often becomes more of a burden than a benefit.
„You reported a bug, but do you have the ZB17/C form completed and signed?” Once again, this is the language of processes and it does not necessarily mean bureaucracy for the sake of bureaucracy. The form is often simply a safeguard: it ensures that the report contains all the necessary information and does not come back to the sender with questions like „but how can this be reproduced?” or „what exactly isn’t working?”.
„Let’s build an MVP and first check whether customers actually want it.” This is pure project language – the goal is to test a hypothesis at the lowest possible cost.
A good illustration of this last approach is a story I heard during SAFe training conducted for an airline. The idea of introducing cold brew coffee on board came up. At first glance, it seemed like a great idea, but the costs of certified machines, logistics and storage turned out to be enormous. Instead of investing right away, the team ran a simple experiment: the onboard magazine included information that cold brew was available. Whenever a passenger tried to order it, the crew recorded the interest. After a moment, they would inform the passenger that the drink had unfortunately run out and was no longer available. The result? Demand turned out to be too low to justify the real costs. It was a classic fake door test – an experiment conducted without making an actual investment.
The biggest mistake is assuming that someone is complaining out of bad intentions or simply to block our work. In most cases, a different approach is driven by goals that we simply do not see. Understanding that the other side is not acting out of malice, but is taking care of a different aspect of the company’s health, is the key to effective collaboration.
Risk works differently on both sides
In a project, risk often has an „all or nothing” character. Moreover, the cost of fixing an error grows exponentially over time. A mistake detected at the concept stage may cost a symbolic dollar. The same problem discovered after production deployment can cost a hundred times more. Every fix involves people, analysis, time and communication.
In a process, the greatest threat is the scale effect. A small, repeatable system error can generate enormous losses. If a machine cuts every element 1 mm too short and we produce a million parts, we are no longer talking about a minor deviation. A flawed process rarely causes a company to collapse overnight. More often, it slowly drains the organization through errors embedded in procedures and technology.
A process does not improve by itself
If we pour tea into a glass and start stirring it with a spoon, it will not become sweeter just by stirring. Something has to be added. Improving a process requires an external impulse-most often a project. If the current way of working generates errors or is too costly, repeating the same actions over and over again will not fix it.
For example, a complaints department notices that the response time has increased to seven days. A customer service optimization project is launched. The team analyzes bottlenecks, perhaps purchases new software, or introduces a new service standard. After implementation, the company gains a new, faster operational process. In most cases, processes are created by projects-not the other way around.
A trap I often observe is the so-called „eternal project”- a situation in which a change is never truly completed and stabilized. People operate in a constant emergency mode, as if they are permanently stuck between the old and the new. A mature project should eventually end with a clear statement: it’s done- this is your new routine from today onward.
This moment of transition – the handover – rests on three pillars: verification and validation (whether the solution works and meets expectations), user education (both internal and external), and a clear definition of responsibilities (who takes over maintenance after the project is completed). Without these three elements, even a brilliant solution may be rejected by the operational team, simply because they do not feel safe or confident working with it.
Let’s imagine an IT department finishing a project to implement a new CRM system. For the handover to succeed, it is not enough to simply deploy and release the application. Validation, training, and the designation of a person or team responsible for responding to failures after the project is completed are also required. Many innovations fail not because they were bad ideas, but because they were thrown over the fence – without preparing the operational teams for everyday use and without assigning an owner on the operations side. Modern approaches, such as the DevOps culture, aim to remove this barrier by ensuring that creators and operators work as one team from start to finish.
Run and change – the two legs of an organization
A healthy organization is able to both protect today’s profits and build tomorrow’s competitive advantage. Today’s profits come from stability, predictability and operational efficiency. Tomorrow’s advantage comes from experimenting, testing ideas and implementing change.
That is why I think about an organization in two areas:
Run – the heart of the company, where efficiency, standards, predictability, and operational excellence matter most.
Change – the company’s laboratory, where through projects we experiment with new ideas that may, in a year or two, become the next standard way of generating revenue.
Kodak is often cited as an example here and rightly so, although the story is more complex than the common myth about a company that simply ignored the digital revolution. In fact, Kodak itself invented the digital camera in 1975. The real issue was different: for a long time, digital photography truly was a niche market, and that assessment was accurate at the time. The mistake was switching too late, when the market began to change faster than expected. There was too much dominance of the run area over change – too much focus on what worked at the moment, and not enough courage to invest in what might work in the future.
On the other hand, there are startups that often operate almost entirely in the change mode. Speed, competition for the market, and experimentation are what matter most there. Stability usually comes later. However, this approach also carries risks—it can burn out people, money, and entire organizations.
That is why one cannot function effectively without the other.
What happens when we choose the wrong tools?
Chaos appears-or innovation gets suffocated. You can try to hammer a nail with a microscope, but that is not what a microscope is designed for. The same applies to methods and frameworks. If we misdiagnose the situation, we start applying the wrong tools to the wrong problems.
To bring some order to this, I propose a simple matrix based on two axes: repeatability and variability. This matrix helps us pause and answer a few key questions: what exactly are we dealing with, what language should we adopt and what kinds of tensions we can expect in conversations with stakeholders.
| Low Variability | High Variability | |
|---|---|---|
| High Repeatability | Process (Lean, standardization) | Chaos – requires immediate correction |
| Low Repeatability | Traditional Project (Waterfall) | Agile Project (experiments, iteration) |
High repeatability and low variability mean – a process. This is the domain of standards and optimization. Process-oriented approaches such as Lean work best here, focusing on reducing waste, waiting time, overproduction, and unnecessary movements.
Low repeatability and low variability – mean a traditional project. We know what we want to achieve, and to a large extent we know how to do it. The plan is linear, and the variability of the goal remains relatively small.
Low repeatability and high variability – mean an innovative project. This is the world of experiments, iterations, and agility. Each iteration can bring new knowledge and influence both the path and the final outcome. We still focus on the goal, but we discover it step by step.
High repeatability and high variability mean chaos. This is the worst possible combination. Neither process tools nor project approaches work well here-there is no stable point of reference. If a process that should produce predictable results starts generating different outcomes every time, the situation requires immediate correction.
Whether something is a project or a process also depends on the context and scale. For some people, ordering a pizza by phone may be the project of a lifetime-they are doing it for the first time and perhaps the last. For others, it is a routine process that always leads to the same result. That is why, before choosing a tool or method, it is worth asking a simple question: where exactly are we?
What does this mean in practice?
Projects and processes are not enemies. They are the two legs on which most organizations stand. If one becomes weaker, the organization starts to limp. Before taking action, it is worth asking a simple question: are we dealing with a project or a process? And even if something is called a project-is it really one? A wrong diagnosis leads to using the wrong tools. It is like trying to screw in a bolt with a hammer. It might work, but it will hurt.
We need balance. Too much run, and we end up like Kodak. Too much change, and we behave like a startup that is constantly running but does not always manage to stay on its feet. An organization that wants to run efficiently must also know how to tie its shoes. It may sound absurd, but that is exactly what everyday life looks like in many companies.
The most important thing is to start recognizing what we are really dealing with. Does what we are doing require predictability and standardization today? Or rather exploration, experimentation, and conscious management of the unknown? Should we be improving a process here, or launching a project? Or perhaps the first step is simply to name the problem using the right language?
For me, this is the starting point for further discussion. Because this topic is only the beginning-in future installments it is worth exploring in more depth the comparison between traditional and agile approaches, their fundamental differences, and when they help and when they begin to get in the way.
And that is where everything begins: with the understanding that „at our company it works differently” does not necessarily mean chaos. Sometimes it simply means that we are looking at the same problem from two different, but equally necessary, perspectives.
About the author
Maciek has been involved in IT in various ways for nearly 20 years. Over that time, he has gained experience as a graphic designer, full-stack developer, tester, Scrum Master, Team Lead, Release and Test Manager, and SAFe trainer. Since July 2025, he has been working at fireup.pro. Professionally, he enjoys bringing structure to complexity. Privately, he is passionate about rhythm and precision.
