A loss-making support unit, turned profitable by fixing how it worked
A loss-making team supporting about 55 applications for wind turbines that run around the clock. Fixing how the work was organised, before cutting any people, took it to profit within six months.
- Client
- Global wind-energy companyNot named
- Role
- Project Manager, Product Owner, Scrum MasterInfosys
- Team
- 35 people20 in delivery, 15 in support
- Timeline
- Nov 2024 to Jan 2026Profitable within six months
The challenge
The team supported about 55 applications that watch wind turbines, so they cannot stop at the end of the working day. When the project started, the unit was making a complete loss. It had about twice the people the contract needed. Knowledge sat in a few senior engineers. Support, enhancements and changes were measured as one pool, which hid where the service was failing, and extra work was being done for free.
The usual answer to a loss-making unit is to cut people. That would have removed the cost and left the cause.
What was done
1. Fix how the work is organised before reducing people.
Standard operating procedures replaced knowledge held in individuals. Repetitive work moved to a new support layer between first-line support and the engineers. Only then was the team resized. It delayed the visible saving by some months, but the reduction did not push risk onto the people who stayed.
2. Measure support, enhancements and changes separately.
Each got its own target. Three targets are harder to report than one blended number, but they showed where the real problem was.
3. Charge for extra work.
Requests outside the contract had been delivered for free. They became separately scoped and paid work, worth around $200,000 a year of new business.
4. Bring in AI in stages.
In production
AI first watched the support tickets, then handled a six-hour window, then full days. Each step needed evidence from the one before. It reached production and was never rolled back.My role
What I owned
The P&L, the operating-model redesign, the split of commitments, the staged introduction of AI, and incident leadership.
What the team delivered
Day-to-day support, enhancements and automation across the portfolio, by a core delivery team and an L1.5 support team.
What the client decided
Service levels, contractual scope, and acceptance of the commercial changes.
The result
The unit went from a complete loss to about 15% profit within six months, and now runs at around 25%. Service levels held at 99.9% across about 55 applications. The time to fix a production issue fell from 4 days to under 12 hours, and automation covers 70 to 80% of the portfolio. The team won several internal awards.
The lesson
Reduce people last. Standardise the knowledge, move work to the right level, then resize. Reverse the order and the risk lands on whoever is left.
A single blended number is a place for failure to hide. Separate targets cost some simplicity in reporting and showed what was actually wrong.
View the numbers as a table
| Milestone | Profit (approximate) |
|---|---|
| Start | -100% (a complete loss) |
| After six months | around 15% profit |
| Now | around 25% profit |
View the numbers as a table
| Measure | Value |
|---|---|
| MTTR before | 4 days |
| MTTR after | under 12 hours |
| SLA | 99.9% |
Read the detailsThe situation in full, decisions with their costs, a night when safety alerts failed, and the numbers
A unit at 100% loss, supporting hardware that does not stop
I inherited an application organisation supporting a wind portfolio at a complete loss, staffed at roughly twice the contractual requirement, with genuine round-the-clock obligations. Turbines do not stop at close of business, and neither can the applications watching them.
The scope was about 55 applications for a global wind-energy OEM. The client is not named here.
The obvious fix was the wrong one
The standard response to a loss-making unit at twice its required staffing is to cut. That would have removed the cost and left the cause, because the cause was spread across six things at once.
Critical knowledge lived inside individual senior engineers. Support, enhancements and environment changes were measured as one blended pool, which hid where the service was actually failing. Out-of-scope work was absorbed rather than charged.
Own the whole unit
I owned the P&L, delivery, operational performance, product responsibilities and people management for the application organisation, as Project Manager, Product Owner and Scrum Master.
Four calls, each with its cost
Decision 1. Fix the operating model before reducing people.
WhyCutting first removes capacity and keeps the dependency: the work still needs doing and only a few people can do it. I standardised SOPs so knowledge stopped living in individuals, shifted repetitive work left, and established an L1.5 layer. Only then did I reduce headcount.
Trade-off acceptedIt delayed the visible financial improvement by months while the cost base stayed where it was, which is an uncomfortable thing to hold in front of a P&L review. It made the reduction survivable instead of a transfer of risk onto the people who remained.
- Standardise the knowledgeSOPs, not individuals
- Move work leftrepetitive work to the right tier
- Add an L1.5 layerbetween first line and engineers
- Then resizelast, not first
Decision 2. Measure support, enhancements and changes separately.
WhySupport, enhancements and environment changes were measured as one service pool, so failures in one averaged out against successes in another. Each got its own commitment, which made the real failure visible and chargeable.
Trade-off acceptedThree commitments are harder to report and to govern than one blended number, and it removed a convenient place to hide. That was the point.
Decision 3. Charge for extra work instead of absorbing it.
WhyOut-of-scope requests were being delivered for free, which hid demand and funded the loss. They became separately scoped work, generating around $200,000 a year of new business.
Trade-off acceptedIt introduced friction into requests that used to just happen, and it meant holding a line with a client used to getting them. It turned a leak into revenue and made the real demand visible.
View the numbers as a table
| Treatment | Value per year |
|---|---|
| Absorbed, not billed | $0 |
| Scoped separately | around $200,000 |
Decision 4. Give AI more responsibility only as fast as the results justified.
WhyIn production AI entered production support in controlled stages: shadow mode, then a six-hour window, then full-day operation, with each expansion resting on evidence from the stage before. The environment combined rule-based scripting with agentic AI and AIOps on an internal platform. It reached production, measured by successful ticket closure and routing, and no false positives were detected.
Trade-off acceptedStaging meant running human and machine in parallel for longer than strictly necessary, paying twice for the same coverage during shadow. It is why the expansion was never reversed.
When the safety alerting failed with technicians on a turbine
A safety-alerting service used by field technicians failed overnight while two technicians were on a turbine. I raised it as a P1 and activated the on-call rota. The fault was traced to a third-party regional outage outside our application stack.
Outside our stack did not make it outside our responsibility. Until the provider restored service, the team kept manual all-clear controls in place and sanitised the affected regions before the incident was closed.
From a complete loss to around a quarter profit
- The unit now operates at around 25% profit
- Weekends run without a human rota
- Around $200,000 a year of new business from scope that used to be absorbed
Reduce people last
A unit losing money at twice the required headcount looks like a staffing problem and usually is not. Standardise the knowledge, move the work to the right tier, then resize. Reversing that order transfers the risk to whoever is left.
A blended metric is a place for failure to hide. Separating the commitments cost reporting simplicity and bought the ability to see what was actually wrong.