From a sales spreadsheet to a single project lifecycle

On project delays

When we talk about "why projects fall behind", the focus usually lands on not enough engineers, not enough process, or some particular hand-off between departments that failed.

But the truth is: most delays are decided long before any of that — at the moment the deal closes.

How does an opportunity become a number, and a project, that can actually be tracked?
After a deal closes, how does sales avoid manually chasing every progress update and re-coordinating headcount each time?
How does the executing team know which projects they are actually responsible for?
How does a new team member know what deliverables and preparations belong to their current stage?
When does finance get to confirm the numbers, so reports reflect what is really happening?

The actual pain points

Opportunity numbers were still being counted by hand. After a deal closed, nobody could really track the execution. Headcount allocation lived inside one person's head. So projects slipped quietly — and by the time anyone noticed, it was already too late.

Every salesperson had their own way of tracking deals; the documents were completely inconsistent.
After a deal closed, it was passed to the executing department through a one-liner or a single email — usually without checking headcount availability with that department head, who was then left guessing at his own team's state.
In progress meetings, the gap between what sales said and what the executing team actually saw was wide enough that customer satisfaction kept dropping.
There was no way to compare an opportunity's estimated cost with its actual cost after closing — and no way to track sales' judgment or follow-through.
The same project, inside the same company, was producing different document formats — confusing the customer.

Once I understood this, I realised the pain was not "anyone's capability falling short". It was that each department had its own legitimate logic and habits — but there was no shared process, no shared standard, no way to make these hidden numbers and hidden progress visible together.

After interviewing each department

What I found was that these daily workflows all had clear starts and ends, and clear stages. The closing of an opportunity and the issuing of the first invoice; the start of a project and the completion of the contract — every step has a clear output. From the first call with a customer, all the way to the last invoice and the last work log, the whole thing can be threaded into one workflow. That is what PMS is built to do.

One lifecycle from sales pipeline to project finance, with cross-department workflow as the connective tissue.

A working mechanism, restructured

To understand what PMS is doing, you only need to follow one variable: visibility of progress.

The old way of handing things off between sales and the executing department relied on direct communication, individual conscientiousness, and a bit of luck. That approach broke in two ways:

Slow — by the time the problem surfaces, the project has already drifted by weeks. —
Distorted — every retelling through a human bends the original terms, commitments, prices, status. —

PMS reroutes those questions straight to the source:

From the moment an opportunity is created — cost analysis, quoting, all the way to closing — when it converts into a formal project, the system maps services and products to the responsible departments. One button moves it to project mode and lets each manager assign the right team members.
Milestones, deliverables, members, cross-department assignments are all created in the same single action.
Finance's view of estimated vs. actual cost, and invoice status, runs off the same data the other two are using.
Personnel hours and opportunity-level cost-vs-margin become input for management decisions.

Building the system is the easy part. The hard part is getting every department to bring their work into the same system.

The real design call: the responsibility behind that one button

The most important design decision was treating "close the deal, convert to project" as a properly designed first-class action — not an afterthought.

What does that button do?

When sales hits "convert to project", the system maps the opportunity's services and products onto the responsible executing departments, carries the project start/end dates over in one go, and builds out the milestones for each product as part of the same action.

Every person's home page, after login, shows their own project status — not yet started, in progress, at risk, delayed. Department heads see how many projects still need members assigned, what stage each project is at, what the next stage is, and the daily work logs and deliverables of their team.

Underneath "cross-department collaboration", three harder problems

The hardest part is not the data structure. It is making sure "cross-department collaboration" is real — not just a line in a meeting deck.

When sales assigns a technical-validation task to engineering, the engineering manager needs to get a real notification, with a real button to accept or push back — not yet another message that gets buried in chat.

So three layers were stacked on top of this workflow:

Permissions — read role, region, and module together to decide who can do what. —
Notifications — every meaningful state change actively fires. —
Assignment tracking — at every stage, every deliverable, you can see who is on the hook. —

Templates: making the senior team's implicit playbook visible

During discovery I noticed something: every project type — government tender, enterprise project, maintenance contract — had its own implicit stage flow that nobody had ever written down. New members had to rediscover it every single time.

So I turned that implicit knowledge sitting inside senior colleagues' heads into a reusable template system.

Every template defines the stages, required deliverables, and the cadence of reminders. A department manager can fork a template and edit it, or save their own version as a new template.

Over time, this becomes the company's living dictionary of "how each kind of project should run" — rather than something that only exists in one veteran's head.

What the system actively surfaces, and what it deliberately does not

This system actively tells you: which projects are still on track, which milestones are about to slip, which deliverables haven't been submitted, which invoices haven't been collected, which assignments haven't been closed.

But it deliberately does not score anyone. It does not rank teams.

The reason is simple: the point is to bring the work itself out into the open, not to turn it into a competition.

Fewer required fields
More sensible defaults
Drafts that auto-save
Every page loads in one click

A good tool isn't one that "forces people to complete it". It's one that "people come back to open, because it's the single source of truth".

What this gives the team

PMS is not a tool. It is a shared work cadence.

It takes everything that used to live separately inside different people's heads — the commitments, the progress, the risks, the reminders — and puts them on one screen everyone can look at together.

Sales gets to see that their deals are actually being executed. The PM or the executing team gets to see what scope and timeline sales originally promised. Finance gets to see receivables that haven't come in and costs that haven't closed. Senior leadership gets to see the entire company's progress, bottlenecks, and emerging risks.

More importantly: for the first time, three departments share a single timeline. Where sales, project, and finance used to be three lines running at their own pace, now everyone sits on the same data stream.

Closing

The most lasting takeaway from this case: the most important prerequisite is the organisation's own definition of responsibility and ownership.

Cross-department collaboration looks like a data problem on the surface; underneath, it is a permissions and notifications problem. Without a clear definition of responsibility, no system can know whose work this task, this project, or this opportunity is supposed to belong to.

Any feature that has to rely on "let's just adjust the permissions when needed" or "someone will remember to do this at the right moment" is a bad design.

What PMS can do is make the process traceable, make progress transparent, and handle reminders and notifications. But if ownership and the commitments that used to live inside someone's head are not actually put back into the system — no system in the world can conjure them out of thin air.