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.
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
- The Project Manager — owns resource allocation, assesses availability, cost, organizational constraints, and political feasibility
- The Product Manager — owns requirements prioritization, serves as the customer proxy, resolves requirement conflicts, and manages stakeholder expectations
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.
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. These include planning and design, organizational coordination, quality and compliance activities (security review, accessibility audit, performance testing), operational setup (CI/CD, monitoring, runbooks), knowledge transfer and documentation, and post-launch stabilization.
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.
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.
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 and receive the highest resource priority. Near-critical activities with small float are assigned strong resources. Activities with large float can be staffed flexibly.
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.
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. Both underestimation and overestimation are harmful.
- Broadband — input from twelve to thirty diverse participants through successive refinement. The statistical advantage: the error of the sum is less than the sum of the errors.
- Historical calibration — comparison against past performance on similar projects to reveal systemic biases
Options, Not a Single Plan
The result of Project Design is not one plan but a set of viable options — typically three — spanning conservative, balanced, and aggressive approaches. Each comes with quantified cost, schedule, risk, and staffing requirements. Management selects from these options in a structured decision meeting, committing resources or canceling the project based on objective trade-off analysis rather than intuition.
Work Package Classification
| Work Package Type | Source Tier | Estimation Characteristics |
|---|---|---|
| Integration Milestone | Manager / Experience | Dominated by integration effort. Number and complexity of seams. Near the critical path. |
| Core Work Package | Engine / Flow | Highest functional volatility. Widest estimation ranges. Most design iteration. |
| Boundary Work Package | Accessor / API Accessor | Defined by external system complexity. Simple component, external risk dominates. |
| Shared Infrastructure | Utility | Most stable. Tightest ranges. Most parallelizable. Leaf nodes of the network. |
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.