Quick recap
Most IT outsourcing companies with 50 to 150 engineers do not have a delivery problem. They have a framework mismatch problem. A delivery system built for a 400-person company imports badly into a 60-person one: the reports nobody reads, the templates nobody fills in, the resistance that gets blamed on the team when the real issue is scale. This post identifies the three specific signs that your delivery system is borrowed from a company twice your size, and what a right-sized alternative looks like.
This week Wiseboard ran diagnostic sessions with three IT services companies in different situations.
One was at $190k monthly revenue and had just lost a major client.
One was a 40-person shop trying to standardize delivery across three different project types.
One was a 35-person company building its first delivery governance layer from scratch.
All three had the same problem underneath the surface-level symptoms.
Someone had installed a delivery framework designed for a company two to three times their size. The reports were written for an organization with a dedicated Head of Delivery, a PMO function, and project managers who do nothing but manage projects. In each of these three companies, the PM is also the business analyst. Sometimes the PM is also the account manager. There is no dedicated Head of Delivery. There is a CTO who writes code.
The framework does not fit. And when it does not fit, two things happen: the team resists it (because the overhead is real and the value is invisible), and leadership concludes the team is the problem.
The team is almost never the problem.
The three signs your delivery framework is borrowed from a company too big for yours
Sign 1: Your PMs are producing reports nobody reads.
If your project managers spend Friday afternoon filling in status reports that nobody on the leadership team opens before Monday, the report format was designed for a management layer you do not have. In a 400-person company, a delivery director reviews those reports and synthesizes them for the CEO. In your company, the CEO looks at the project, talks to the PM, and the report sits in a folder.
This does not mean reporting is unnecessary. It means the format is wrong. A 60-person company needs a lightweight project health signal that takes 15 minutes to produce and that the CEO can actually read in three minutes. That is a different document from a multi-tab sprint budget tracker adapted from a 300-person outsourcing firm.
Sign 2: Your delivery consultant is recommending the same ten artifacts regardless of your scale.
A good delivery framework adapted for a $3M to $8M IT company typically needs five to seven operational artifacts. Incident management framework. Client communication cadence. Utilization tracking. Budget-vs-actual reporting at the project level. Escalation trigger criteria. A capacity model the sales function checks before committing timelines.
A delivery framework for a $25M company with a PMO adds four to six more. Risk register templates. Cross-project resource allocation models. Delivery health dashboards with multiple data sources. QBR structures involving multiple stakeholders on both sides.
If your advisor is recommending the full enterprise stack for your 60-person company, you are paying to build infrastructure you cannot maintain. The value is in the five to seven artifacts that match your actual management bandwidth, not in installing everything and hoping the team grows into it.
Sign 3: Your CTO or CEO is still the de facto Head of Delivery.
This is the most reliable indicator of a delivery system that never got embedded. In the companies Wiseboard works with, the CEO or CTO stepping in to manage delivery escalations is usually not a leadership failure. It is a sign that the delivery framework gave the PMs templates but not judgment: the documents exist, but nobody knows when to escalate, what threshold triggers a client call, or who owns the decision when a project is at risk.
A right-sized framework solves this by creating one clear escalation path, one weekly signal the CTO can check without getting pulled into project details, and one decision rule that PMs can apply without asking upward. That is not a complicated system. It is a simple system that actually runs.
What a right-sized delivery framework looks like at 50 to 150 engineers
The table below reflects the operational baseline Wiseboard sets in the first 30 to 60 days of a delivery engagement with IT companies at $3M to $15M in revenue.
This is not a comprehensive delivery system. It is the five things that prevent the most common delivery failures at this scale. A company at $15M to $30M needs more. A company at $3M to $8M needs these five working reliably before adding anything.
Why teams resist frameworks that are the wrong size
The resistance most CEOs interpret as the team not wanting to change is usually the team being right about something specific.
When Vlada Benyukh, a delivery advisor Wiseboard works with who has embedded delivery functions at companies including Temy, describes what she saw in her engagements: the PMs were not resistant to process. They were confused about which parts of the process applied to them. A PM running a three-developer fixed-price project and a PM running a 15-person enterprise platform build do not need the same weekly reporting structure. When they are handed the same template and told to fill it in, the one running the small project does the math correctly: the overhead is larger than the value.
The fix is not to tell the team to comply. The fix is to have two templates, or one template with two configurations, so the PM running the small project has 20 minutes of reporting work per week and the PM running the enterprise project has 45 minutes.
The companies Wiseboard diagnoses where delivery is working are almost never the ones with the most sophisticated systems. They are the ones where every PM can answer three questions without looking anything up: what is my project's current health status, what would trigger an escalation this week, and when does my client next hear from me?
If your PMs cannot answer those three questions without opening a document, the delivery framework is too heavy, too disconnected from their daily work, or both.
A practical diagnostic: is your framework the right size?
Run these five checks on your current delivery system. Each one takes under ten minutes.
1. Count the templates you ask PMs to maintain per project. If the number is above seven, audit which ones the CEO or Head of Delivery has actually read in the last 30 days. Eliminate the ones that have not been opened.
2. Time how long it takes a PM to produce the weekly project status update. If it takes more than 30 minutes per project per week, the format is overbuilt for your management bandwidth.
3. Check the last three project escalations. Were they triggered by the reporting system or by the client calling the CEO directly? If clients are bypassing the PM to reach leadership, the escalation triggers are either absent or not working.
4. Ask your newest PM what to do if a project is at risk. If they cannot describe a specific sequence of steps without asking someone, you do not have a delivery system. You have delivery documents.
5. Pull your utilization rate for the last quarter. If the number is above 90%, your sales function is committing capacity the delivery team does not have. This produces overload, not underperformance, and no delivery framework fixes it.
If three or more of these checks surface a problem, the delivery framework is not embedded. Adding more templates will not fix it. The work is in simplifying what exists until every PM runs the same five things reliably, then adding complexity only when those five are stable.
One number to track
85%. The utilization ceiling for sustainable delivery in IT outsourcing. Above that, project quality degrades, PMs burn out, and at-risk projects surface only after the client has already started looking for alternatives. Below that, margin looks worse on paper but delivery quality compounds over time.
In the three companies Wiseboard diagnosed this week, average utilization in the most recent quarter was above 100% in one case, and above 95% in the other two. In all three, the CEO described the problem as a delivery quality problem. The actual problem was a capacity planning problem that delivery quality reporting made visible too late.
Wiseboard works with IT services companies at $1M to $30M revenue to diagnose and fix delivery, account management, and growth gaps.
If you recognized your company in any of the patterns above, the first step is a 40-minute diagnostic call.
Subscribe to Wiseboard Insights for the inside view of what is actually working at IT services companies, sent every two weeks. No roundups, no generic best practices. One operational pattern per issue, grounded in real client work.