Updated
Growing a software delivery company: one framework, shared KPIs
Summary
I led delivery at a growing software services company, focusing on profitable accounts, one delivery framework and KPIs that sales, delivery and HR could all steer by.
Key figures
- About 80people in the delivery organization
- Up to 6project managers in the team I built
- 50,000person-hours in one large project
Context
DOOK.pro delivered software for clients across several domains, including fintech, cryptocurrency, insurance, HR and healthcare.
Challenge
Growth needed a different way of working: clear rules for which accounts to keep, a repeatable delivery framework, and numbers that sales, delivery and HR could steer by together.
Starting point
Delivery practices were not yet standardized. The project framework, risk management, KPI tracking and a common tracking tool were all introduced during my time.
My role
I led the delivery organization (about 80 engineers, project managers and delivery leaders), advised the CEO on commercial and structural decisions, and worked with sales and HR on capacity and hiring. I built and mentored the delivery team, which included up to six project managers.
What I did
Keep the accounts worth keeping.
We closed non-profitable accounts and built partnerships on trust and a Time and Material model.
One way to run a project.
I introduced a framework to assess, initiate, plan, execute, track and close projects, added risk management, and made Jira the main tool for tracking projects and initiatives.
Numbers everyone can steer by.
We tracked utilization rate, bench size, team velocity, service availability, revenue and profit per account, stop-light status on budget, timeline and scope, and days since the last release on production and on staging.
Turn service levels into a product.
We introduced SLA as a product. We also built a cross-company team plan that let companies of a software development association form virtual teams from a pool of 1,400 IT professionals.
Align sales, delivery and HR.
I streamlined communication between the three, helped build a probability-based model for planning new hires, and advised the CEO on opening a Dutch subsidiary.
Outcome and evidence
Delivery ran on a shared framework and a shared set of numbers, and the organization delivered a large project of about 50,000 person-hours over about 18 months with about 30 people.
| Measure | Value | Basis | Scope note |
|---|---|---|---|
| Delivery organization | About 80 people | Engineers, project managers and delivery leaders | Peak value in the period |
| Project management team | Up to 6 project managers | Team I built | |
| Large project | About 50,000 person-hours, about 18 months, about 30 FTE | One project |
What the figures do not show
The delivery figures are peak values over the period. Company financial results are not published here, and I do not claim company-level outcomes alone: they were co-created with the CEO, sales and the delivery team.
Learnings
- Say no to the wrong accounts early. Revenue growth and account quality can conflict, and the second matters more once you scale.
- A small, shared set of numbers beats a large report. Utilization, bench, velocity, availability and account profit gave sales, delivery and HR one language.
- Service levels are a product. Defining them explicitly turns "we will fix it" into something a client can buy and a team can plan for.
Want the next case study when it is out?
An occasional email about my work, such as new case studies and articles.
Check your inbox
I sent you a link to confirm your address. Nothing is added until you confirm. The link works for 7 days.
Growing faster than your delivery model?
Describe where growth is putting pressure on delivery.