peterbamuhigire ICT Services Firm Business Plan Skill
Overview
ICT services firms (digital agencies, systems integrators, IT consultancies, dev shops) have a fundamentally different economic structure from SaaS: revenue is people-bound, gross margin is 25-45% (vs SaaS 70-85%), and scaling is linear, not platform-leveraged. This skill generates the business plan for this specific company profile, with explicit guidance on the productisation roadmap (the path from services revenue to recurring revenue).
Use When
- The company sells custom development, integration, consulting, or managed services as primary revenue
- The company is an agency / SI / consultancy considering productising
- A hybrid firm is moving services revenue toward SaaS / recurring product revenue
Do Not Use When
- Pure SaaS company with services as <10% of revenue (use SaaS skills)
- Pure product / hardware company
Required Inputs
- Current service offerings (custom dev, consulting, managed services, training)
- Current revenue, headcount, utilisation
- Bench / pipeline / book-to-bill
- Capability mix (engineers, designers, PMs, BAs)
- Geographic footprint
- Productisation candidates (services repeated 5+ times)
Workflow
- Map the service offerings — discrete service lines with pricing, gross margin, demand drivers.
- Compute utilisation economics:
- Billable utilisation target (60-75% healthy)
- Realisation rate (% of billed hours that get paid)
- Per-hour / per-day / per-project rate by capability
- Bench cost
- Build the revenue model:
- Project-based revenue (fixed-fee or time-and-materials)
- Retainer revenue (monthly recurring services)
- Managed-services revenue (recurring; high margin if multi-tenant ops)
- Product / SaaS revenue (if productised)
- Plan the productisation roadmap:
- Identify services repeated 5+ times — these are candidates for productisation
- Score each by automation potential, market demand, defensibility
- Build the path from custom-build → repeated-template → semi-product → product / SaaS
- Design the org structure — capability pools (Eng, Design, PM, BA, DevOps), client pods, productisation team.
- Compute the financial profile:
- Gross margin (25-45% typical for services; 60-75% for managed services)
- S&M as % of revenue (15-25%)
- G&A (8-12%)
- Operating margin (10-20% healthy; 5-15% for growth-stage)
- Cash conversion (project receivables; usually 60-90 days DSO)
- Plan the recurring-revenue evolution — services → managed services → SaaS over 3-5 years.
- Cross-reference: Section 03 (Products) describes services + future product; Section 04 (Market) services market; Section 10 (Financials) services P&L with productisation transition.
Quality Bar
- Service-line P&L explicit (gross margin per service line)
- Utilisation targets named (with capacity formula)
- Productisation roadmap with named candidates and scoring
- Recurring-revenue evolution thesis
- Org structure supports both services delivery and product development
- Cash conversion (DSO) realistic
Anti-Patterns
- "We're a services company that will become SaaS" with no productisation roadmap
- 100% utilisation target (no bench = no growth capacity)
- Hourly billing without realisation discipline
- Services-only model with no recurring-revenue thesis (linear growth ceiling)
- Productising too early (before service is profitable + repeated)
Outputs
- Service-line P&L with gross margin per line
- Utilisation model
- Productisation roadmap (candidates, scoring, sequencing)
- Recurring-revenue evolution
- Org chart by capability pool
- Cash conversion model
References
book-extractions/walling-saas-playbook-extraction.md— stair-step method (often via services to product)book-extractions/practical-small-business-guides-extraction.md— SME services disciplinebook-extractions/cotton-run-a-saas-business-extraction.md— when services revenue makes sense in SaaSskills/ict-product-company-business-plan/SKILL.md— sister skill for product (non-SaaS) firmsskills/saas-mvp-and-product-market-fit-strategy/SKILL.md— for productisation MVP
Africa / Uganda Application Notes
- ICT services in Africa often operates as the on-ramp to SaaS (agency → repeatable project → product). The Stair-Step in African context.
- DSO is often longer in Africa (90-180 days for public-sector / large-corporate clients). Plan working capital accordingly.
- Public-sector procurement is a major services market but has 6-18 month cycles; requires dedicated sales motion.
- Donor-funded projects often have specific reporting and pricing structures (FAR rates, IFRS specific cost-categories).
- Multi-country services delivery (delivering Nigerian projects from Kenyan office, etc.) requires VAT, withholding-tax, transfer-pricing discipline.
- Productisation candidates often emerge from public-sector / donor-funded work: tax-platform, beneficiary-tracking, monitoring-evaluation tools.
- Labour-cost arbitrage is real for African ICT services — selling US/EU rates with local-cost delivery produces high margin.
- Hybrid model is increasingly common: services revenue funds the SaaS build; SaaS revenue eventually exceeds services. Pattern: Andela, Soft, Genesys Tech (Nigeria).
Inputs
| Artefact | Source or provider | Required? | If absent |
|---|---|---|---|
| Service catalogue, project history, pipeline, rates, contracts, staffing, time, utilisation, and delivery evidence | Founder, sales, delivery, HR, and systems | Required | Return a discovery gap list and qualified plan |
| Customer, competitor, procurement, partner, and channel evidence | Primary research and verified market sources | Required | Avoid invented demand and pipeline conversion |
| Revenue, work in progress, payroll, subcontractor, tax, FX, receivable, and cash treatment | Chwezi Accounting Doctrine and finance records | Required for projections | Stop financial conclusions pending doctrine and reconciliation |
Outputs
| Artefact | Consumer | Acceptance condition |
|---|---|---|
| ICT services-firm plan input pack | Business-plan pipeline, founder, lender, or investor | Demand, sales capacity, delivery capacity, utilisation, margin, cash, growth, and risks reconcile |
| Services economics and capacity register | Sales, delivery, HR, finance, and reviewers | Rates, effort, utilisation, bench, subcontracting, collection, and hiring assumptions are sourced and testable |
Evidence Produced
| Evidence | Format | Acceptance condition |
|---|---|---|
| Pipeline-to-capacity traceability | Opportunity, probability, timing, skills, effort, owner, and evidence table | Forecast work can be delivered by available or funded capacity |
| Finance quality-gate result | Doctrine mapping, model reconciliation, and professional-review status | Revenue, WIP, payroll, tax, FX, receivables, and cash treatment pass Chwezi doctrine |
Capability Contract
Analysis defaults to read-only. Edit the plan only when authorised. Do not change CRM probabilities, rates, contracts, staffing, payroll, client systems, or production delivery; spending, hiring, contracting, certification, and financial claims require explicit authority and qualified review.
Degraded Mode
Without time data, contract history, pipeline evidence, current market sources, or reconciled finance records, return a scenario-based module with ranges and validation actions. Mark utilisation, margin, or cash checks not assessed rather than assuming industry benchmarks are achieved.
Decision Rules
| Choice | Action | Failure or risk avoided |
|---|---|---|
| Revenue scales mainly with billable people or project capacity | Use the services-firm model | False software scalability |
| Revenue scales mainly with product units or licences | Route to ict-product-company-business-plan |
Hiding product lifecycle economics |
| Recurring subscriptions dominate value and revenue | Route to the SaaS stack | Wrong retention and gross-margin model |
| Financial treatment is material or disputed | Apply Chwezi doctrine and professional review | Misstated revenue or cash |
Workflow
- Classify service lines, contract types, clients, geography, decision, and audience; stop if product or subscription economics dominate.
- Gather pipeline, win rate, cycle, backlog, rates, effort, utilisation, bench, skills, delivery, receivables, and client-concentration evidence.
- Map lead-to-cash and project delivery, including scope change, acceptance, billing, collection, support, and knowledge retention.
- Build capacity and economics under current Chwezi doctrine, separating billable delivery, overhead, subcontracting, and product investment.
- Reconcile sales pipeline with delivery capacity, hiring lead time, working capital, and funding.
- Stress delays, scope creep, attrition, bench, collection, client concentration, and FX.
- Recover from evidence gaps by narrowing claims and defining dated validation or instrumentation work.
- Release only after business-logic, finance, evidence, risk, and anti-slop gates pass.
Quality Standards
The plan must prove how leads become collectable engagements and how delivery capacity turns into contribution and cash. It must expose bench, concentration, hiring, acceptance, and collection constraints rather than hiding them in a revenue growth rate.
Anti-Patterns
- Forecasting revenue without delivery hours. Fix: translate backlog and pipeline into skills, effort, utilisation, and timing.
- Treating all staff cost as variable COGS. Fix: apply the documented payroll, bench, overhead, and delivery allocation policy.
- Assuming proposals equal pipeline. Fix: use stage evidence, probability, cycle, and decision dates.
- Ignoring client acceptance and receivable timing. Fix: model milestones, sign-off, invoicing, disputes, and collection.
- Funding a product from services without ring-fencing capacity. Fix: show people, cash, milestones, and stop conditions.
- Finalising project revenue without Chwezi review. Fix: map contracts and recognition evidence to doctrine and professional sign-off.
Worked Example
A systems integrator has three likely projects but only one implementation team. Sequence the opportunities by evidence and start date, model subcontracting or hiring lead time, and cap recognised capacity rather than booking all three at once.