Projects fail not because teams lack effort, but because they lack informed planning. You cannot estimate what you have not designed.<\/p>\n\n\n\n
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<\/strong>.<\/p>\n\n\n\n The premise: the system architecture is<\/em> 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Three roles collaborate throughout the planning process, each bringing a perspective the others cannot provide:<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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 \u2014 only the Core Triad. Full team staffing begins after management commits to a plan.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Each component identified during design \u2014 whether Manager, Engine, Resource Accessor, or Utility \u2014 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.<\/p>\n\n\n\n A useful calibration: total activity effort is roughly six times the design effort \u2014 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.<\/p>\n\n\n\n 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 \u2014 it is miscounting. Categories that are consistently omitted:<\/p>\n\n\n\n With the activity inventory complete, the project network is constructed \u2014 a directed graph modeling the precedence relationships between all activities. The network is the structural foundation for all subsequent analysis.<\/p>\n\n\n\n In a VBD decomposition, dependencies flow naturally from the component taxonomy:<\/p>\n\n\n\n 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 \u2014 preparation activities precede all construction, test planning runs parallel to early construction, integration testing follows each connected component pair.<\/p>\n\n\n\n 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 \u2014 network complexity often signals architectural coupling that should be addressed before planning proceeds.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Float<\/strong> \u2014 the amount of time an activity can slip without delaying the project \u2014 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Activities are classified into four risk categories based on their float:<\/p>\n\n\n\n This classification is not just a risk label \u2014 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.<\/p>\n\n\n\n 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 \u2014 acting on it before activities cross into the critical zone preserves options. Waiting until they become critical eliminates them.<\/p>\n\n\n\n Estimation operates at three levels, each serving a distinct purpose. The levels validate each other \u2014 significant discrepancies indicate problems that must be resolved before proceeding.<\/p>\n\n\n\n Project cost is the area under the staffing curve \u2014 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.<\/p>\n\n\n\n Project efficiency \u2014 productive effort as a fraction of total effort \u2014 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n A top-performing resource can complete an activity faster than the normal estimate, but at disproportionately higher cost \u2014 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 \u2014 staffed with weaker resources \u2014 produces fragility that exceeds the schedule benefit.<\/p>\n\n\n\n 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 \u2014 simulators must be built, contracts specified in detail \u2014 but schedule reductions can exceed what activity compression alone achieves.<\/p>\n\n\n\n Plotting all feasible solutions \u2014 from maximum compression to padded decompression \u2014 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:<\/p>\n\n\n\n When management requests delivery in the death zone, the project designer’s responsibility is to communicate this clearly with supporting analysis \u2014 not to find a way to comply.<\/p>\n\n\n\n Risk in Project Design is measured objectively from the float distribution. Risk represents the fragility of the plan \u2014 its sensitivity to activities slipping \u2014 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.<\/p>\n\n\n\n The criticality risk index classifies all activities by float into the four categories \u2014 critical, red, yellow, green \u2014 and computes a weighted average. The result falls between 0.25 and 1.0.<\/p>\n\n\n\n Risk is not linear. A risk index of 0.69 is substantially more dangerous than 0.50 \u2014 the relationship is closer to the Richter scale than a percentage. Small numerical differences in the upper range represent dramatically different exposure.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n The result of Project Design is not one plan but a set of viable options \u2014 typically three \u2014 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Earned value serves dual purposes: as a validation tool during planning, and as a tracking tool during execution.<\/p>\n\n\n\n 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:<\/p>\n\n\n\n A well-designed plan produces an S-curve with a coefficient of determination exceeding 0.95 when fit to a third-degree polynomial.<\/p>\n\n\n\n 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 \u2014 effort is being consumed without proportional progress.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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 \u2014 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.<\/p>\n\n\n\n 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:<\/p>\n\n\n\n Sub-critical staffing \u2014 resource levels insufficient to staff the critical path \u2014 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.<\/p>\n\n\n\n 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 \u2014 using a senior hand-off with a junior team produces architectural drift and quality problems.<\/p>\n\n\n\n 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:<\/p>\n\n\n\n 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 \u2014 a feature only exists when the components required to produce it are integrated and functioning together.<\/p>\n\n\n\n Project Design is not opposed to agile delivery \u2014 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.<\/p>\n\n\n\n The mappings are direct: Feed Me or Kill Me \u2192 Sprint Zero or PI Planning commitment. Core Triad \u2192 Product Owner, Scrum Master, Tech Lead. Activity inventory \u2192 refined backlog with architectural dependencies. Three options \u2192 release plan scenarios. Broadband estimation \u2192 Planning Poker. Sprint velocity \u2192 earned value rate. S-curve \u2192 cumulative flow diagram or burnup chart.<\/p>\n\n\n\n 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 \u2014 standups, Kanban, user stories, burndown charts \u2014 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.<\/p>\n\n\n\n Every activity in the project \u2014 whether it produces code, tests, documentation, or infrastructure \u2014 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.<\/p>\n\n\n\nThe Core Triad<\/h2>\n\n\n\n
\n
The Fuzzy Front End<\/h2>\n\n\n\n
\n\n\n\nActivity Inventory<\/h2>\n\n\n\n
Architecture-Derived Activities<\/h3>\n\n\n\n
Non-Code Activities<\/h3>\n\n\n\n
\n
\n\n\n\nNetwork Construction<\/h2>\n\n\n\n
Architecture-Derived Dependencies<\/h3>\n\n\n\n
\n
Dependency Consolidation<\/h3>\n\n\n\n
\n\n\n\nCritical Path Analysis<\/h2>\n\n\n\n
Forward and Backward Pass<\/h3>\n\n\n\n
Float Analysis<\/h3>\n\n\n\n
Float Classification and Resource Assignment<\/h3>\n\n\n\n
\n
Proactive Risk Management<\/h3>\n\n\n\n
\n\n\n\nThree-Level Estimation<\/h2>\n\n\n\n
\n
Cost and Efficiency<\/h3>\n\n\n\n
\n\n\n\nSchedule Compression<\/h2>\n\n\n\n
Activity Compression<\/h3>\n\n\n\n
Network Restructuring<\/h3>\n\n\n\n
The Time-Cost Curve<\/h3>\n\n\n\n
\n
\n\n\n\nRisk Quantification<\/h2>\n\n\n\n
Criticality Risk Index<\/h3>\n\n\n\n
\n
Risk Decompression<\/h3>\n\n\n\n
\n\n\n\nOptions, Not a Single Plan<\/h2>\n\n\n\n
\n
The Feed Me or Kill Me Decision<\/h3>\n\n\n\n
\n\n\n\nEarned Value Planning and Tracking<\/h2>\n\n\n\n
Plan Validation \u2014 The S-Curve<\/h3>\n\n\n\n
\n
Execution Tracking<\/h3>\n\n\n\n
\n\n\n\nStaffing<\/h2>\n\n\n\n
The One-to-One Rule<\/h3>\n\n\n\n
The Staffing Curve<\/h3>\n\n\n\n
\n
The Hand-Off Point<\/h3>\n\n\n\n
\n\n\n\nStaged Delivery<\/h2>\n\n\n\n
\n
\n\n\n\nAgile Alignment<\/h2>\n\n\n\n
\n\n\n\nWork Package Classification<\/h2>\n\n\n\n