Case 03 / 05 Process & systems design · IFIN Sistemi · Zucchetti
A development process from nothing
Not a screen: the process itself, designed for three departments.
The process Not public
The company had no structured way to move work from request to release. I designed the system they didn’t know they were missing, across three departments and 20+ people.
01of 04
Context
Not every design problem shows up on a screen. IFIN Sistemi had no structured development line. Departments worked waterfall-style, sales opened processes that never formally ended, and change requests went straight to developers, who agreed dates with sales and then missed them. Nothing was bundling the work. So the process is what I designed.
02of 04
Problem
Three departments, three private versions of the process, none agreeing at the boundaries. Handoffs were lost, ownership was ambiguous and “done” meant something different to every team. There was no testing step at all, and an estimate was whatever date the customer had already asked for.
03of 04
Process
I treated the organisation itself as the product. I mapped how work really flowed across the three departments, found where it stalled, and designed a process with explicit stages, owners and deliverables: one people would follow, not a chart nobody uses.
04of 04
Outcome
Three departments and more than twenty people moved onto a shared, structured way of delivering, and a backlog of more than 1,000 items came down to just over 100. Saving time was never the goal; organising the people was. Everyone got a set role and every backlog item a place in a proper hierarchy, so “not my jurisdiction” stopped being an answer, and change requests resolve into real deliverables instead of noise.
- 01 ISSUER: the request. PM, direzione or commerciali.
- 02 PRESALE: analisi presale. Leaves as an initial specification.
- 03 PRODUCT OWNER: analisi PO, with the PM on what already exists and can be reused.
- 04 ISSUER + PO + TEAM LEADER: revisione specifiche e tempi. Leaves as a document both sides signed, carrying the first estimate.
- 05 PRODUCT OWNER: generazione backlog e scheduling attività.
- 06 TEAM LEADER + DEV: sprint planning, stand-up, code review, sprint review, SAL.
- 07 GATE: tutte le feature sviluppate e approvate? No returns to the backlog.
- 08 ISSUER: consegna e test in produzione, with prepared instructions and interviews.
- 09 GATE: necessarie modifiche o nuove implementazioni? Sì returns to the backlog, not to the start.
Version history What was tried first
What it could have been
The finished screens argue for themselves. These are the forks: what was tried first, and what replaced it.
- Fork 01
Which framework, and how faithfully?
v1Rejected
Installing Scrum by the book, inside the development team.
v2Shipped
A Scrum baseline stretched across the whole pipeline: marketing, sales, proposals, change requests. Nobody runs these frameworks to the book; I bent one on purpose, towards where work actually got lost, which was never inside the dev team.
- Fork 02
Who owns the customer after the signature?
v1Rejected
Leaving them with the person who sold them: the natural arrangement, because sales already has the relationship.
v2Shipped
The product team takes them. That was the point of the project: with the change requests and the customer handled after the sale, the commercial team got its time back to find the next one, and a dev team with dates it can meet stops dragging sales back in.
- Fork 03
Does the middle get authority, or only coordination?
v1Rejected
A product team that routes and facilitates: visible, useful, and unable to say no to anyone.
v2Shipped
A team that can refuse a date to sales and set a hard priority for the devs. That was the deal that made the rest work, and it put blame where the expertise was: everyone accountable for what they actually own.
- Fork 04
How does a change request become a date?
v1Rejected
Promising each one as it lands, so sales and the devs agree a date for a colour change that was never going to ship alone.
v2Shipped
Requests stop at the product team and accumulate into one change set with one date, sized to how the work actually deploys. The devs never absorbed a request directly again. Fewer promises, and the ones we make hold.
Signed off IFIN Sistemi
His workload spanned from the designing of new components and assets for the various software application produced by our company to the complete review and restructuring of our development process, introducing the agile scrum methodology and fitting it perfectly with our existing flow. […] As a designer, he was always on time with the deliveries and often gave better results.
Reference letter, Padua, January 2023