Project Design
Projects fail not because teams lack effort, but because they lack informed planning. You cannot estimate what you have not designed.
The Core Premise
Traditional project management estimates cost and schedule from requirements alone, producing plans that are routinely two to four times off from reality. Project Design addresses this by treating the system architecture as the foundation for all planning decisions.
The premise: the system architecture is the project plan. This is not a metaphor. Components become work packages. Dependencies between components become the project network. Integration points become milestones. The critical path through dependencies determines duration. The staffing required to execute that path determines cost.
Without an architectural decomposition, you cannot identify the components that constitute the work. Without components, you cannot identify the dependencies that constrain sequencing. Without dependencies, you cannot identify the critical path that determines duration. Without duration, you cannot calculate cost. Without cost and risk, you cannot make informed decisions. Every project management failure traces back to planning without designing first.
This premise inverts the traditional relationship between architecture and project management. In conventional practice, project managers estimate effort from requirements, construct schedules from those estimates, and treat architecture as a technical detail handled during execution. In Project Design, the architecture comes first. It must be substantially complete before any meaningful estimation can begin.
The Core Triad
Three roles collaborate throughout the planning process, each bringing a perspective the others cannot provide:
- The Architect — owns the system decomposition, identifies components, defines dependencies, analyzes the critical path, and provides technical risk assessment. Responsible for the structural integrity of the plan.
- The Project Manager — owns resource allocation, assesses availability, cost, organizational constraints, and political feasibility. Responsible for the operational integrity of the plan.
- The Product Manager — owns requirements prioritization, serves as the customer proxy, resolves requirement conflicts, and manages stakeholder expectations. Responsible for the value integrity of the plan.
In agile contexts, these roles map to Tech Lead, Scrum Master or Delivery Lead, and Product Owner respectively. All three perspectives must be present throughout planning. Removing any one produces plans with blind spots that manifest as failures during execution.
The Fuzzy Front End
The period between project inception and the commitment to a specific plan is the fuzzy front end. During this period, the Core Triad produces the architecture, the project design, and the options for management. This period typically consumes fifteen to twenty-five percent of the total project duration.
This is not wasted time. It is the mechanism by which the remaining seventy-five to eighty-five percent is executed efficiently. Projects that skip the front end invariably spend more total time and money, because the cost of planning failures during execution far exceeds the cost of planning itself. Staffing during the front end is minimal — only the Core Triad. Full team staffing begins after management commits to a plan.
Activity Inventory
The first step in Project Design is constructing a complete inventory of all activities required to deliver the system. The most common source of estimation error is not incorrect estimates for known activities, but the complete omission of activities that were never identified.
Architecture-Derived Activities
Each component identified during design — whether Manager, Engine, Resource Accessor, or Utility — becomes a work package with a predictable lifecycle: detailed design, implementation, unit testing, code review, and documentation. Each pair of connected components generates an integration activity. Each use case generates a system-level verification activity.
A useful calibration: total activity effort is roughly six times the design effort — one unit for design, three for implementation, one for unit testing, one for integration. This ratio varies by complexity and team experience, but provides a starting point for cross-checking individual estimates.
Non-Code Activities
A software project involves substantially more than writing code. Non-code activities often account for thirty to fifty percent of total project effort, yet are routinely excluded from initial estimates. Failing to include them is not conservatism — it is miscounting. Categories that are consistently omitted:
- Planning and design — requirements analysis, architectural design, technology spikes, proof-of-concept development, and the project design process itself
- Organizational coordination — stakeholder communication, vendor procurement, licensing, legal and regulatory review
- Quality and compliance — security review, accessibility audit, performance and load testing, penetration testing, disaster recovery testing
- Operational setup — CI/CD pipeline, monitoring and alerting, runbooks, on-call rotation setup, release planning, go-live and cutover, rollback procedures
- Knowledge and documentation — learning curves for new technology, architecture documentation, API documentation, onboarding materials
- Post-launch stabilization — hypercare period, post-mortems, warranty support
Network Construction
With the activity inventory complete, the project network is constructed — a directed graph modeling the precedence relationships between all activities. The network is the structural foundation for all subsequent analysis.
Architecture-Derived Dependencies
In a VBD decomposition, dependencies flow naturally from the component taxonomy:
- Utilities have no upstream dependencies — they form the leaf nodes, enabling early construction starts
- Resource Accessors depend on infrastructure and Utilities
- Engines depend on Resource Accessors
- Managers depend on Engines and Resource Accessors
This ordering provides the skeleton of the project network. It is the natural consequence of the communication model: you cannot build what orchestrates before you build what is orchestrated. Non-code activities slot into the network at appropriate positions — preparation activities precede all construction, test planning runs parallel to early construction, integration testing follows each connected component pair.
Dependency Consolidation
Unconsolidated networks contain redundant dependencies that distort analysis. If activity A depends on B and B depends on C, then A implicitly depends on C and the explicit dependency is redundant and should be removed. Redundant dependencies inflate apparent complexity, produce incorrect float values, and obscure the true critical path. A well-consolidated network has roughly three to four dependencies per activity. Higher counts warrant architectural review — network complexity often signals architectural coupling that should be addressed before planning proceeds.
Critical Path Analysis
The critical path is the longest path through the project network from start to finish. Its duration is the duration of the project. No project can be accelerated beyond its critical path regardless of resource availability.
Forward and Backward Pass
The forward pass traverses the network from start to finish, calculating the earliest possible start and finish time for each activity. The earliest start of each activity is the maximum of the earliest finish times of all its predecessors. The backward pass traverses from finish to start, calculating the latest allowable start and finish time. The latest finish is the minimum of the latest start times of all successors. Together, these two passes define the float of every activity.
Float Analysis
Float — the amount of time an activity can slip without delaying the project — is the objective measure of risk. Activities with zero float are on the critical path. Free float measures how much an activity can slip without delaying any immediate successor. Interfering float is the difference between total float and free float: consuming it delays successors but not the project overall.
The distribution of float across all activities determines the overall risk profile of the project. A plan where most activities have near-zero float is fragile. A plan with healthy float distribution across non-critical activities absorbs normal execution variability without cascading into delays.
Float Classification and Resource Assignment
Activities are classified into four risk categories based on their float:
- Critical (zero float) — receive the best available resources. Any delay extends the project.
- Red (small float, typically under 5 days) — near-critical. Assigned strong resources and closely monitored.
- Yellow (moderate float) — medium risk. Standard resource allocation.
- Green (large float) — can be staffed flexibly; float can be traded for resource availability.
This classification is not just a risk label — it is the primary input to resource assignment decisions. Getting the best people onto critical and near-critical paths is one of the highest-leverage interventions available to a project manager.
Proactive Risk Management
The primary reason well-managed projects slip is that non-critical activities consume their float and become critical, creating a new critical path that was not planned for and does not have the best resources assigned to it. Continuous monitoring of float degradation enables proactive resource reassignment before this transition occurs. A sudden degradation in float on a near-critical chain is an early warning signal — acting on it before activities cross into the critical zone preserves options. Waiting until they become critical eliminates them.
Three-Level Estimation
Estimation operates at three levels, each serving a distinct purpose. The levels validate each other — significant discrepancies indicate problems that must be resolved before proceeding.
- Activity-based — bottom-up, activity-by-activity estimation including the complete lifecycle: design, implementation, testing, review, documentation. Estimates are made by the people who will do the work, expressed in five-day increments. Both underestimation and overestimation are harmful. The goal is nominal estimation — the most likely duration assuming normal conditions and competent execution.
- Broadband — input from twelve to thirty diverse participants through successive refinement rounds. The statistical advantage: the error of the sum is less than the sum of the errors. Individual overestimates and underestimates cancel. The participant pool should include veterans and newcomers, specialists and generalists, optimists and skeptics. In agile contexts, Planning Poker is a form of broadband estimation.
- Historical calibration — comparison against past performance on similar projects to reveal systemic biases. Teams that consistently underestimate integration effort, or fail to account for organizational overhead, will repeat those biases unless historical data surfaces them.
Cost and Efficiency
Project cost is the area under the staffing curve — the integral of staffing level over time. Direct costs (salaries, tools, equipment) scale with team size and duration. Indirect costs (management overhead, facilities) scale primarily with duration. The total cost is a quadratic polynomial of time: both excessively compressed and excessively extended projects are more expensive than the optimal point, which typically falls near the all-normal solution.
Project efficiency — productive effort as a fraction of total effort — commonly falls between fifteen and twenty-five percent on complex multi-contributor projects. The remainder is communication overhead, coordination, waiting, and context switching. Efficiency estimates significantly above this range likely underestimate communication costs and should be scrutinized.
Schedule Compression
Schedule compression reduces the project duration below the all-normal solution. There are exactly two mechanisms: making individual activities shorter, and restructuring the network to enable more parallelism.
Activity Compression
A top-performing resource can complete an activity faster than the normal estimate, but at disproportionately higher cost — the relationship between time saved and cost incurred is nonlinear. Only activities on or near the critical path should be compressed; compressing non-critical activities consumes budget without accelerating the project. Practical maximum compression typically falls in the range of twenty-five to thirty percent of normal duration, after which creating new critical paths through previously non-critical activities — staffed with weaker resources — produces fragility that exceeds the schedule benefit.
Network Restructuring
The more powerful acceleration technique is restructuring the network to enable parallel work: investing in detailed interface contracts that allow implementation against specifications rather than completed implementations, developing simulators that decouple Manager development from Engine and Accessor availability, and pipelining architect design with developer construction. Network restructuring costs more — simulators must be built, contracts specified in detail — but schedule reductions can exceed what activity compression alone achieves.
The Time-Cost Curve
Plotting all feasible solutions — from maximum compression to padded decompression — produces the time-cost curve. Points below the curve are infeasible regardless of resources. Points on the curve represent efficient solutions. Points above represent waste. Several named points anchor the analysis:
- All-normal — every activity at nominal duration; lowest-cost starting point
- Least-cost — minimum total cost; typically near all-normal
- All-crash — maximum compression of all critical activities; highest cost on the curve
- Least-duration — absolute minimum achievable schedule, including network restructuring
- Death zone — to the left of least-duration; no amount of resources can achieve these schedules
When management requests delivery in the death zone, the project designer’s responsibility is to communicate this clearly with supporting analysis — not to find a way to comply.
Risk Quantification
Risk in Project Design is measured objectively from the float distribution. Risk represents the fragility of the plan — its sensitivity to activities slipping — not the probability of specific events occurring. Subjective risk registers are inputs to conversation. Quantified float-based risk is a property of the plan itself.
Criticality Risk Index
The criticality risk index classifies all activities by float into the four categories — critical, red, yellow, green — and computes a weighted average. The result falls between 0.25 and 1.0.
- Below 0.30 — over-decompressed; resources are being wasted on excessive buffer
- 0.30–0.50 — comfortable zone; adequate buffer without waste
- ≈ 0.50 — design target; optimal balance of schedule efficiency and plan resilience
- 0.50–0.75 — increasing fragility; scrutinize near-critical chains
- Above 0.75 — avoid; too brittle to survive normal execution variability
Risk is not linear. A risk index of 0.69 is substantially more dangerous than 0.50 — the relationship is closer to the Richter scale than a percentage. Small numerical differences in the upper range represent dramatically different exposure.
Risk Decompression
Deliberately planning for a slightly later delivery than the all-normal solution reduces risk by adding float to near-critical activities. Even two weeks of decompression can significantly reduce the risk index. The optimal decompression point typically produces a risk index near 0.50. The cost of decompression is modest compared to the risk reduction achieved, making it one of the most cost-effective mitigation strategies available.
Options, Not a Single Plan
The result of Project Design is not one plan but a set of viable options — typically three — spanning the feasible zone of the time-cost curve. Presenting a single plan is not a recommendation. It is a demand. Management cannot make a rational decision between alternatives that were never offered.
- Conservative — longest schedule, lowest cost, lowest risk. Minimal compression, substantial float buffers, accommodates uncertainty in requirements, technology, and team capability.
- Balanced — recommended for most projects. Moderate compression, risk index near 0.50, balances schedule efficiency against plan resilience.
- Aggressive — shortest feasible schedule at highest cost and risk. Maximum practical compression, requires top resources on all critical activities, minimal buffer for absorbing delays.
Each option includes quantified values for duration, direct and indirect cost, risk index, peak staffing, critical path identification, milestone schedule, key assumptions, and the top three to five specific risks.
The Feed Me or Kill Me Decision
Management reviews the options and makes one of two decisions: commit resources to a selected option, or cancel the project. Both outcomes are valid. Killing a project that cannot be executed within acceptable parameters is a responsible act that preserves resources for better opportunities. The architect recommends. Management decides. Never staff up before this decision. Never let management select an option outside the feasible zone.
Once management commits, scope is locked, resources are assigned, milestones are set, staged delivery begins, and earned value tracking commences against the selected option’s planned progress curve.
Earned Value Planning and Tracking
Earned value serves dual purposes: as a validation tool during planning, and as a tracking tool during execution.
Plan Validation — The S-Curve
Each activity is assigned a value representing its contribution to system completion. Plotting cumulative earned value over time for a well-designed plan produces an S-curve: slow initial progress during the Core Triad’s front-end work, accelerating progress during ramp-up and construction, decelerating progress during integration and testing. The shape validates the plan’s sanity:
- Steep early curve — unrealistic optimism
- Flat early, steep late — unrealistic pessimism
- Straight line — fixed team size; nearly always suboptimal
- Very shallow, nearly straight — sub-critical staffing
A well-designed plan produces an S-curve with a coefficient of determination exceeding 0.95 when fit to a third-degree polynomial.
Execution Tracking
During execution, three lines are tracked: planned progress, actual progress, and actual effort. Their relationship is diagnostic. When progress falls behind while effort exceeds the plan, the project is underestimating complexity. When progress leads while effort is below the plan, the project may be overestimating. When progress falls behind while effort dramatically exceeds the plan, there is a resource leak — effort is being consumed without proportional progress.
The critical capability is projection: by extrapolating actual progress and effort curves, the project manager can forecast completion date and final cost while there is still time to act. The ability to project is the essence of project management.
Staffing
The One-to-One Rule
Each component is assigned to one developer. This principle enables reliable estimation, clear ownership, and minimal communication overhead. Assigning multiple developers to a single component introduces coordination costs that are difficult to estimate and manage. If a component cannot be built by one developer within the project timeline, it should be decomposed further — this is an architectural problem, not a staffing problem. Conway’s Law makes this concrete: interaction between team members mirrors interaction between the components they build. Well-decomposed architecture minimizes both.
The Staffing Curve
A properly planned project produces a staffing curve shaped like a smooth hump: a small core team during the front end, gradual ramp-up as construction begins, a peak during maximum parallel activity, and gradual wind-down during integration and testing. Anti-patterns that indicate poor planning:
- Peaks and valleys — poor float utilization; team members churning in and out
- Steep ramp — exceeds absorption capacity; new team members reduce velocity before they add to it
- Fixed team size — ignores critical path dynamics; over-staffs early, under-staffs late or vice versa
- Flat, anemic curve — telltale sign of sub-critical staffing; earned value approximates a straight line
Sub-critical staffing — resource levels insufficient to staff the critical path — tends to increase cost by twenty-five percent or more while extending the schedule by a comparable margin. There are no savings from sub-critical staffing. The combination of extended duration and increased overhead consistently exceeds the cost of adequate staffing.
The Hand-Off Point
The hand-off point determines where the architect transfers design responsibility to developers. At the senior hand-off point, the architect specifies service-level contracts and interfaces; developers handle detailed design and implementation. This enables pipelining and is faster and cheaper, but requires senior developers. At the junior hand-off point, the architect specifies detailed class-level design; developers implement to specification. The hand-off point must match actual team composition — using a senior hand-off with a junior team produces architectural drift and quality problems.
Staged Delivery
Project Design always uses staged delivery. The system is delivered in incremental stages, each producing a working increment that demonstrates progress and enables early feedback. In systems built using Volatility-Based Decomposition, stages align naturally with the component taxonomy:
- Infrastructure and Utilities — the foundation. No upstream dependencies; builds confidence and unblocks all parallel work.
- Resource Accessors — verified data access and external integration. The boundary is tested before business logic is built on top of it.
- Engines with their Accessors — working business logic verified against real data access.
- Managers — complete workflows and orchestration. End-to-end functionality is first available here.
- Client applications and user interfaces — public-facing delivery.
Public releases begin after Managers are complete, because only at that point do user-visible workflows function end-to-end. Earlier stages are internal releases that build confidence and enable early integration testing. Milestones are based on integration, not features — a feature only exists when the components required to produce it are integrated and functioning together.
Agile Alignment
Project Design is not opposed to agile delivery — it is complementary to it. The distinction is between planning and execution. Project Design provides the planning discipline that determines what is built, in what order, with what resources, and at what cost. Agile methods provide the execution discipline that governs how the work is performed day to day.
The mappings are direct: Feed Me or Kill Me → Sprint Zero or PI Planning commitment. Core Triad → Product Owner, Scrum Master, Tech Lead. Activity inventory → refined backlog with architectural dependencies. Three options → release plan scenarios. Broadband estimation → Planning Poker. Sprint velocity → earned value rate. S-curve → cumulative flow diagram or burnup chart.
Good agile combines architectural discipline with iterative delivery. Bad agile uses agile terminology as justification for skipping architecture and project design, producing teams that are busy but not productive. All agile construction techniques — standups, Kanban, user stories, burndown charts — are assembly techniques. They are excellent for execution. But they are not design techniques. Just as lean manufacturing depends on meticulous design of both the product and the assembly line, good agile depends on meticulous architecture and project design.
Work Package Classification
Every activity in the project — whether it produces code, tests, documentation, or infrastructure — is a work package. The characteristics of each work package derive from its source: which component tier or activity category it belongs to. Click any type to see its estimation and risk profile.
Where Project Design Applies
The underlying techniques — critical path analysis, float-based risk quantification, earned value tracking, compression analysis, and structured decision-making — apply to any project with a decomposable structure and identifiable dependencies. In software, the architecture provides the components, dependencies, and integration points. In construction, product development, or infrastructure programs, the structural decomposition takes a different form, but the planning discipline is identical: design the project before you estimate it.
Project Design is particularly valuable when the team size exceeds the number of network paths, when management needs defensible options rather than a single plan, when prior similar projects have experienced estimation failures, or when schedule pressure demands a clear understanding of compression limits. Small projects are paradoxically more sensitive to project design errors — with small teams on short durations, almost every planning mistake becomes critical.