I always start by verifying the assumptions: scope, technical requirements, and realistic time and human resources. I check the consistency of the requirements and identify key risks. Only then do I build an implementation plan.
As for what is important at the start of a project, a precisely defined scope and a common understanding of the objectives by all stakeholders are certainly important. Without this, the project very quickly loses its coherence. And we all know that without proper coherence, you can’t move forward!
I get the most satisfaction from solving complex technical problems and organising complicated dependencies. What I like least is collecting scattered data from multiple departments — it’s a time-consuming and inefficient process.
Yes — a project with very good ‘visual’ documentation (entrusted to me), but it was disastrous in terms of production, completely unsuited to our plant’s technology. While working on the project, it turned out that the environmental assumptions were unrealistic, which forced us to redesign a key solution.
I start by gathering facts. First, I identify the source of the problem and its impact on the project, and only then do I make decisions. This helps to avoid chaos and actions taken under emotional pressure.
The organisation uses an information and, to some extent, planning tool – a project card, which is mainly used for project planning. I plan to introduce another one, but everything is still in the testing phase. When it comes to work in the department, I mainly delegate tasks through individual task lists.
I always see the risks first, because they determine the feasibility of the plan. I only analyse the opportunities for acceleration once I know that the foundation is stable.
I base the conversation on data and facts. In addition, I explain the business context so that technical decisions are understandable and acceptable to all parties. The same applies to customers, who very often want to know the specific specifications of the vehicle or fleet they have ordered.
Most often, these are discrepancies between documentation and reality, legal frameworks, limitations of existing infrastructure, and incorrect input assumptions. I solve them through rapid prototyping, data verification, and updating assumptions.
Yes. Building prototypes often shows that the original solutions need to be optimised or simplified. I treat this as a natural part of the engineering process. Thanks to this, future changes in projects are not so surprising.
The fact that I can see the full picture of the project and anticipate problems before they arise, while creating solutions that are technically feasible and in line with the customer’s expectations.
A single, consistent tool that integrates technical data, scheduling, production and risks. This information is often scattered across several systems, but fortunately, everything will soon be operating in a single, comprehensive system.
I involve contractors at the design stage, try to provide clear instructions, easy access to documentation and quick support when problems arise. The project should be tailored to the realities of the team’s work.
A project with a repeatedly changed scope, time pressure from the client and parallel technological changes. Difficult, but very developmental — it taught me how to prioritise effectively and work in a dynamic environment.
Improving the way tasks are delegated and communication within project teams. A clear division of responsibilities and regular exchange of information have streamlined cooperation and allowed projects to be carried out in a calmer, more predictable atmosphere.
.jpg)
