Most guides on public procurement end at the moment the contract is signed. As if it were the culmination of the journey, time for champagne and a photo for LinkedIn.

And then the real work begins. And that is what decides whether this contract will be a reference for subsequent tenders, or an operation on which you came out net around zero (and often less).

At Mimira, we help companies reach the signature - from finding the right tender, through analysis, to preparing the bidding documentation. But we know perfectly well that it does not end there at all. That is why, together with the IC Project team, we have written down what to do in the first 30 days after winning so that the contract does not start living its own life.

Day zero, or the moment when things usually fall apart

Winning a public tender is a specific situation. Everything you wrote in the bid becomes a commitment. Deadlines, contractual penalties, schedules, quality requirements, reporting methods. The Employer has it in black and white and will monitor it.

The most common mistake at the start? The company treats the contract as something that is signed once and only returned to upon acceptance. This is a recipe for unpleasant surprises around milestones.

The second thing we see with clients. The bid was prepared by one team, while the execution goes to another. And this second team often does not know exactly what the company has committed to. Penalties for delays, subcontractor requirements, acceptance criteria disappear from the radar on the way from the sales department to operations.

The third classic is the lack of a single place where everything lives. Emails, Excel, Teams, WhatsApp, some notes in Word. After three months, it is impossible to reconstruct who made what decision and when. In public procurement, this is not an abstract problem, but a real risk in the event of a dispute.

Week 1: break the contract down into prime factors

It sounds cliché, but practically no one does it properly.

Take the contract, terms of reference (SIWZ), your bid, and all attachments. Extract specific commitments from them. Dates, deadlines, penalties, acceptance criteria, subcontractor requirements, reporting, warranties. Quality requirements that are easy to miss because they were hidden in annex number 7.

In IC Project, this can be uploaded as a separate project, where each contract provision becomes a task or a phase. Thanks to the template system, a once-prepared "Public contract execution" template can be used for every subsequent contract. You do not start from scratch; you just click, copy, and adapt to the specific contract.

What specifically is worth writing down in the first week:

• schedule of hard deadlines from the contract (the ones you cannot change)

• internal milestones (the ones you give yourself to ensure hard deadlines are met on time)

• list of responsible persons on your side with specific roles

• list of contact persons on the Employer's side

• reporting requirements and their frequency

• all contractual penalties entered as separate monitoring tasks

The Gantt chart in IC Project allows you to see the entire schedule in a single view. You see where phases overlap and where trouble begins to brew before it actually happens. If you work on tasks with dependencies, this perspective is essential. You will not catch on a task list alone that delaying phase A by three days will push back the acceptance of phase C by a week.

Kanban, list, schedule, or calendar - each team works in the view that suits them best. The important thing is that the data is the same, regardless of who is looking at it and how.

This last point on the list above is highly underestimated. If the contract says you must report progress every two weeks, and you forget the first time, you are theoretically in breach of contract. In practice, no one will take the contract away from you for that, but it builds an atmosphere that can carry real weight in disputes over acceptance or contractual penalties.

Week 2: risk register, or the thing almost no one keeps

Risk management in Polish companies executing public contracts is often an empty attachment from a quality procedure. Something that exists because the auditor demanded it, but no one looks at.

Meanwhile, in the first month of execution, a living risk register should be created for this specific contract. What can go wrong. With what probability. With what impact on the budget, schedule, scope, or quality. Who is responsible for this risk. What is your response plan if it materializes.

The risk management module in IC Project is designed exactly for this. Each risk has its owner, status, assessment of probability and impact, area (budget, schedule, scope, quality). A risk can be pinned to a specific phase or task, so it does not hang in a vacuum - it is linked to the context of work. And with one click, you turn the response plan into a task with a deadline and a responsible person.

Classic risks worth listing in a public contract:

• unavailability of a subcontractor at a key stage

• changes in material prices (with long contracts, this is a real risk to the margin)

• change of contact person on the Employer's side

• problems with obtaining consents and permits (if the contract requires it)

• illness of a key team member

Each of these risks should have an assigned owner and a clearly described plan B. Without this, a company reacts to problems instead of managing them.

Week 3: communication that cannot be reconstructed after the fact

In public procurement, documentation is sacred. Not a message on Slack from Friday evening, but official letters, protocols, emails with specific content and date. Everything of legal significance must have a paper (or electronic) trail.

At the same time, your team must work quickly, asynchronously, and in the context of specific tasks. And here tension arises, because internal communication cannot live in the same tools as official communication with the Employer, but at the same time, both layers must be consistent.

What makes sense:

Internal communication goes where the team works. In IC Project, the communication module provides comments on tasks, voice messages, and file exchange within the context of a specific project phase. After six months, when you need to reconstruct who made what decision and when, it won't be a game of solitaire with twenty threads across different messengers. Everything sits with the task where it happened.

Communication with the Employer goes through the official channel. ePUAP, purchasing platforms, emails from company inboxes. You upload each such letter to the project in IC Project as an attachment or scan. The team has the full picture. The salesperson doesn't send the Employer one thing while the project manager says another, because both see the same correspondence history.

The third layer is company knowledge, which should be shared. Procedures for responding to typical problems, contacts to decision-makers on the Employer's side, a list of typical inquiries that come during project execution. The Wiki module in IC Project allows you to keep all of this in one place, accessible to the entire team. Without this, know-how stays in one person's head and disappears with them when they change jobs.

Week 4: budget and profitability, or the thing companies discover too late

In public tenders, price is often the key criterion. You win with a price that leaves some 8 to 15 percent margin if everything goes according to plan. And then it turns out it doesn't.

A classic scenario. After three months of execution, someone asks how many team hours went into this contract and whether we are over budget. Nobody knows. Because nobody tracked it. The finance department only sees invoices issued and direct costs. Team time (the biggest hidden cost) is not measured because "everyone knows what they are doing."

After execution, it turns out that you made 2 percent on the contract instead of 12, because the team spent twice as many hours as the sales director assumed in the valuation. The question of causes remains unanswered because there was no measurement.

That's why in the first month it is worth establishing how you will measure:

• how many team hours went into specific tasks

• what direct costs have already appeared in the project

• how budget burn rate looks vs. schedule

• where the margin starts bleeding out

IC Project has dedicated features for this. Work time logged on tasks automatically translates into team costs. The Finance module provides a real-time view of project profitability, not once a quarter when the accountant closes the period. Every week you see if execution is on track, and the AI Assistant can generate a summary of what is happening without manually clicking through reports.

Without this, you find out the project was unprofitable only after final acceptance. By then, it is too late to do anything about it.

A related matter - team workload. With public contracts, you get a contract with a specific schedule. The question is whether your team is already booked for another project or holidays during those same weeks. The workload view in IC Project shows all of this instantly, so when planning the next stages of execution, you know if you have capacity available in July or if you need to bring in a subcontractor.

Who already works this way

IC Project works with companies in very diverse industries, but two case studies are particularly close to the realities of public contracts.

ATAL S.A., a publicly traded developer, uses IC Project to coordinate development projects, from the construction schedule to communication between teams in different regions. Vice President Mateusz Bromboszcz says it directly - the system has become a key coordination tool. Another example is Wawel S.A., a company with a 127-year history and over 1,000 people on board. They analyzed offers from global giants and smaller firms. They chose IC Project due to its full functionality and customer openness.

The full list of implementations, including NOVI Architekci, Swimer, and ECO Energy Poland, can be found on the case studies page.

The average figures that IC Project shares publicly are quite concrete. 15 percent higher project profitability. 2.5 hours less wasted work time per day. 37 percent more projects delivered on time. These are aggregated numbers from clients, not marketing fantasy.

The thing nobody wants to do, but which saves future tenders

Lessons learned. After completing a contract (and preferably after each milestone), it is worth doing a retrospective. What went according to plan, what fell apart, where the assumptions from the bid diverged from reality.

This is the data you will use in the next tender. At Mimir, we see that companies that keep such records estimate subsequent bids much better. They know better how much time a specific stage takes, what risks are real, and what Employer requirements were problematic.

In IC Project, you can keep this alongside the project. Comments on tasks at acceptance, notes in the Wiki, time-tracking reports that show where the hours really went. Next time you estimate a bid for a similar scope, you will open the historical project and see how it looked before.

Why a Polish system matters in public procurement

A detail that seemingly shouldn't matter, but in practice, it does. IC Project is a Polish company, a Polish team, servers in the European Union, Polish support. In the execution of public contracts, it sometimes happens that the Employer asks where project data is stored (especially in the defense sector, energy, and administration). The answer "American cloud, terms in English" is rarely what they want to hear.

Additionally, when something isn't working, you call Kielce and talk to a person who understands how Polish business and Polish public contracts work. It is not a global hotline where the first line reads from a script.

Security, localization, business context - in public contracts, this is not a nice addition, but a practical requirement.

How it all comes together

From Mimir's perspective: We help companies win tenders they are suited for. The system analyzes the business profile, documents, history of decisions, and suggests tenders where you realistically have a chance. Then, AI prepares the first draft of the bidding documents, a public procurement expert verifies it, and you get a ready package to submit.

From IC Project's perspective: After winning, execution must have a structure. Gantt schedule, tasks with responsibilities, risk register, communication at tasks, measured work time, real-time budget control. Everything in one system, with Polish support, on Polish servers.

Together, it forms this sequence: Find a tender you fit. Submit a bid that stands a chance. Execute the contract to make a profit and build references for the next ones. Each of these stages requires different tools, but they work best when they speak to each other.

If you run a company that participates or wants to participate in public tenders, check out both tools. Mimir at the stage before winning, IC Project at the stage after it. The first 30 days of execution decide whether the next tender will be a repeat success or a lesson you would have preferred not to receive.