In-house Development
In-house Development is a WBS template that breaks an internal system build into 23 tasks across 6 phases. It runs from requirements gathering to operations handover and stabilization, with dependencies and WEIGHT filled in. Its point of view: the destination is operations, not delivery.
When this template fits
- You are building an internal system with your own team or a mixed team
- User training and operations handover must be part of the plan
- You open in stages, gated by UAT (user acceptance testing)
- You want an explicit hypercare period after the build
When another template fits
- If there is contract acceptance for external delivery, SI Delivery is the better fit
- If it is a first product for market validation, IT New-Product MVP is the better fit
Phase by phase
Requirements
Define the problem through current-state analysis, gather requirements, then lock scope and priorities. Internal projects grow requirements easily, so the scope decision here becomes the schedule's line of defense.
Analysis & Design
Business process analysis, system architecture design, and UI/UX design. Aligning the real workflow with the system structure here is what cuts rework during development.
Development
The longest phase in the template. Four tracks run in parallel: DB build, backend API, frontend, and the infrastructure and deployment pipeline.
Integration Testing
Integration and regression tests, performance and security tests, then UAT closes the phase. The destination is UAT — verification by the people who will actually use the system.
User Training
Produce training material and run the sessions. Internal systems succeed or fail on adoption more often than on features.
Stabilization
Operations handover and hypercare wrap up stabilization. Done means the operating team can carry the system without the build team.
Full template structure
| WBS Code | Task Name | Type | Duration (d) | WEIGHT (%) |
|---|---|---|---|---|
| 1 | In-house Development | Deliverable | — | 100% |
| 1.1 | Requirements | Phase | — | 15% |
| 1.1.1 | Current-state analysis & problem definition | Work Package | 4 | 40% |
| 1.1.2 | Requirements gathering & definition | Work Package | 4 | 35% |
| 1.1.3 | Scope finalization & prioritization | Work Package | 3 | 25% |
| 1.2 | Analysis & Design | Phase | — | 20% |
| 1.2.1 | Business process analysis | Work Package | 5 | 30% |
| 1.2.2 | System architecture design | Work Package | 5 | 35% |
| 1.2.3 | UI/UX design | Work Package | 6 | 35% |
| 1.3 | Development | Phase | — | 30% |
| 1.3.1 | DB design & build | Work Package | 7 | 20% |
| 1.3.2 | Backend API development | Work Package | 14 | 35% |
| 1.3.3 | Frontend development | Work Package | 14 | 30% |
| 1.3.4 | Infrastructure & deployment pipeline setup | Work Package | 5 | 15% |
| 1.4 | Integration Testing | Phase | — | 20% |
| 1.4.1 | Integration & regression testing | Work Package | 7 | 50% |
| 1.4.2 | Performance & security testing | Work Package | 5 | 30% |
| 1.4.3 | UAT (User Acceptance Testing) | Work Package | 5 | 20% |
| 1.5 | User Training | Phase | — | 8% |
| 1.5.1 | Training material development | Work Package | 3 | 40% |
| 1.5.2 | Training delivery | Work Package | 5 | 60% |
| 1.6 | Stabilization | Phase | — | 7% |
| 1.6.1 | Operations handover & hypercare | Work Package | 10 | 60% |
| 1.6.2 | Stabilization complete | Work Package | 5 | 40% |
Start with this template
FAQ
- How is this different from the SI Delivery template?
- The point of view differs. SI Delivery cuts phases around the contract and acceptance Milestones; In-house Development cuts them around user training and operations handover. There is no kickoff report or acceptance gate — training and hypercare are formal phases instead.
- Do I have to use all 23 tasks?
- No. After applying, delete what does not fit your organization and add what is missing. When removing an entire phase, first decide where its verification work goes.
- What scale do the durations assume?
- Roughly a four-month, mid-sized build in total. Durations are working days, so the calendar span depends on your calendar settings. Adjust each task to your team size and scope.
- Why is UAT inside Integration Testing?
- Because it is the last gate of quality verification. Technical tests come first, then real users verify against business scenarios. What UAT surfaces becomes the input to Stabilization.
- What does the Excel file contain?
- A table with WBS codes, task names, types, durations, WEIGHT, and each task's definition. It is a static document with no formulas, ready to circulate or move into your internal format.