1. A hospital requires 99.99% uptime for its patient records system. During the PPDIOO lifecycle, in which phase would you first document this availability requirement and build the financial justification for the infrastructure needed to meet it?
Plan -- because this is where gap analysis occurs
Prepare -- because this is where business requirements and financial cases are established
Design -- because this is where technical specifications are created
Implement -- because this is where the network is built to meet the requirement
2. An enterprise discovers during network implementation that a key business unit was never consulted about their application requirements. Which best practice was most likely violated?
Keeping specifications implementation-neutral
Planning for 18-month forward requirements
Identifying all stakeholders early in the process
Using a requirements traceability matrix
3. Which PPDIOO phase is described as the "most underutilized" yet is critical for identifying gaps between current and desired network states?
Prepare
Plan
Design
Optimize
4. A managed service provider is rolling out SD-WAN to 50 branches. After deploying to the first 15 branches, they discover a regional ISP performs poorly and want to change the design for remaining sites. Which project management methodology best supports this mid-project adjustment?
Waterfall, because the full scope was defined upfront
Agile, because iterative sprints allow incorporating feedback between deployments
Waterfall with a formal change order process
Neither -- the original design should be maintained for consistency
5. Why does a hybrid methodology typically use waterfall for requirements gathering and high-level architecture, but agile for detailed design and implementation?
Because agile does not support documentation, which is only needed at the start
Because foundational architecture needs stability and sign-off, while iterative delivery benefits from rapid feedback and adaptability
Because waterfall is faster for early phases and agile is faster for later phases
Because executives prefer waterfall and engineers prefer agile
6. A network designer presents three data center options to a CFO: no redundancy ($500K, 99.5% uptime), active-passive ($1.2M, 99.95%), and active-active ($1.8M, 99.99%). If the business loses $50,000 per hour of downtime, what is the strongest argument for the active-active option?
It uses the most advanced technology available
The annual cost of downtime for the cheapest option far exceeds the incremental infrastructure investment
Active-active is always the industry best practice
The CFO should always choose the most expensive option for critical systems
7. What is the primary purpose of a requirements traceability matrix (RTM) in a network design project?
To list all network hardware and software to be purchased
To map each business requirement to its corresponding design decision, implementation task, and test case
To track project budget expenditures against forecasts
To document the change management approval workflow
8. A retail chain needs to open 10 new stores per quarter with network connectivity. The design team proposes template-based SD-WAN with zero-touch provisioning. Which business requirement does this design decision most directly address?
Maximum network security for payment processing
Rapid, standardized, and repeatable branch deployment at scale
Minimizing WAN bandwidth costs across all locations
Achieving 99.99% uptime at each store
9. In a change management process, what distinguishes a "standard change" from a "major change"?
Standard changes are free; major changes have associated costs
Standard changes are pre-approved and low-risk; major changes require Change Advisory Board review
Standard changes affect software only; major changes affect hardware
Standard changes are temporary; major changes are permanent
10. An organization translates a business KPI of "99.9% order processing uptime" into a network SLA of "99.95% network availability." Why is the network SLA set higher than the business KPI?
To impress executives with better numbers
Because the network is only one component in the end-to-end service chain, so it needs a safety margin to account for other failure points
Because network equipment is more reliable than application software
Because SLAs must always exceed KPIs by regulation
11. Why does a pure agile approach sometimes clash with network design projects involving physical hardware?
Because agile requires all team members to be co-located
Because hardware procurement cycles of weeks or months conflict with two-week sprint expectations, and network components are tightly interdependent
Because agile does not allow for any documentation
Because network hardware cannot be tested incrementally
12. Business Application Profiles (BAPs) and User Application Profiles (UAPs) are used primarily to:
Document the technical specifications of network equipment
Systematically translate business and application requirements into network technology selection criteria
Track project milestones and budget expenditures
Define the organizational chart for the project team
13. The PPDIOO model is described as "iterative, not strictly sequential." What does this mean in practice?
You can skip any phase that seems unnecessary for your project
After completing a phase, you may need to return to earlier phases as requirements change, technologies evolve, or issues are discovered
All six phases happen simultaneously
The phases can be completed in any random order
14. When communicating design trade-offs to non-technical executives, which approach is most effective?
Present detailed protocol comparisons (e.g., OSPF vs. BGP convergence timers)
Frame options in business terms, quantify risk in dollars, and provide a clear recommendation
Let the executives choose based on vendor marketing materials
Always recommend the lowest-cost option to show fiscal responsibility
15. A network requirements document states: "Deploy Cisco ISR 4451 routers at all branch sites." What best practice does this specification violate?
Planning for 18-month forward requirements
Keeping specifications implementation-neutral to avoid premature vendor commitment
Engaging all stakeholders early
Using a cross-functional technology selection team
Every network begins not with a router or a switch, but with a business need. The network design lifecycle is the structured process that translates business imperatives into a network that delivers on them -- and keeps delivering as the business evolves.
Think of the lifecycle as the blueprint-to-building process in architecture. An architect does not start pouring concrete on day one; there is a sequence of site surveys, zoning approvals, structural calculations, construction, inspections, and ongoing maintenance. Skip a step and the building may be unsafe, over budget, or simply in the wrong location.
PPDIOO Lifecycle Model
The most widely referenced lifecycle model is PPDIOO: Prepare, Plan, Design, Implement, Operate, and Optimize. It defines a continuous lifecycle of services for enterprise network design.
graph LR
A[Prepare] --> B[Plan]
B --> C[Design]
C --> D[Implement]
D --> E[Operate]
E --> F[Optimize]
F -->|Continuous Improvement| A
D -->|Revise if needed| B
E -->|Feedback| C
Figure 1.1: The PPDIOO Lifecycle -- an iterative cycle where each phase feeds forward and feedback loops allow revisiting earlier phases.
| Phase | Objective | Key Deliverables |
|---|
| Prepare | Establish business requirements and goals; build the financial case | Business case, budget estimates, risk analysis, conceptual architecture |
| Plan | Gather detailed requirements; identify current-to-desired state gap | Gap analysis, project plan, financial resource plan |
| Design | Create detailed technical design aligned with business goals | Design documentation, bill of materials, stakeholder sign-off |
| Implement | Move design into production without compromising existing services | Lab verification, pilot report, rollback procedures, rollout plan |
| Operate | Maintain network health through day-to-day management | Monitoring dashboards, incident reports, capacity plans |
| Optimize | Continuously improve performance and expand services | Performance baselines, improvement recommendations, reassessment reports |
Crucially, PPDIOO is iterative, not strictly sequential. After implementation you might need to return to planning or design. The lifecycle adapts to changing technologies, budget, infrastructure, and business needs.
Animation: Interactive PPDIOO cycle -- click each phase to reveal details, with animated arrows showing feedback loops between phases.
Mapping Business Goals to Technical Requirements
The gap between what a CEO says ("We need to be faster than our competitors") and what a network engineer configures (QoS policies, link capacity, routing protocol timers) is vast. Bridging that gap uses Business Application Profiles (BAPs) and User Application Profiles (UAPs) to systematically translate business requirements into technology selection criteria.
flowchart TD
A[Business Goal] --> B[Identify Business Requirements]
B --> C[Construct Business Application Profiles - BAPs]
B --> D[Construct User Application Profiles - UAPs]
C --> E[Define Compliance Points]
D --> E
E --> F[Derive Technical Requirements]
F --> G[Network Design Decisions]
G --> H[Validate Against Business Goals]
H -->|Gap Found| B
Figure 1.2: Translating business goals into network design decisions through BAPs and UAPs, with validation feedback.
| Business Requirement | Technical Requirement | Network Design Implication |
|---|
| "Patient records must be accessible 24/7" | 99.99% uptime SLA (< 52.6 min downtime/year) | Redundant paths, dual data centers, automated failover |
| "Doctors need imaging results in under 3 seconds" | < 150 ms round-trip latency, > 500 Mbps per site | WAN optimization, local caching, adequate bandwidth |
| "We must comply with HIPAA" | End-to-end encryption, access control, audit logging | Segmented VLANs, IPsec/MACsec, centralized SIEM |
| "Open 10 new clinics per quarter" | Standardized, rapidly deployable branch design | Template-based SD-WAN, zero-touch provisioning |
Stakeholder Analysis and Requirements Gathering
All stakeholders must be identified early; otherwise the project risks failure when an unknown stakeholder emerges at launch to say the system does not meet their needs. A cross-functional technology selection team -- including accounting, contracts, development operations, technical support, and user representatives -- should be chartered rather than relying solely on technical SMEs.
| Stakeholder Group | Typical Concerns | How to Engage |
|---|
| Executive sponsors | ROI, risk, timeline | Business case presentations, milestone dashboards |
| Line-of-business managers | Application performance, user experience | Application profile workshops, SLA reviews |
| IT operations | Manageability, supportability, skills gaps | Technical design reviews, training plans |
| Security and compliance | Regulatory adherence, threat posture | Security architecture reviews, audit evidence |
| End users | Speed, reliability, ease of use | Surveys, pilot programs, feedback sessions |
| Finance | Budget accuracy, cost predictability | Detailed BOMs, phased investment plans |
Best practices for requirements gathering:
- Research the business context -- know the client's customers, market, and competitors.
- Avoid assumptions -- if you assume incorrectly, the entire solution process is affected.
- Keep specifications implementation-neutral -- avoid specifying vendor or technology in requirements.
- Plan for the future -- 18-month forward planning and annual revalidation of requirements.
The methodology determines how requirements are gathered, how changes are handled, and how quickly the business sees value. Two dominant philosophies -- waterfall and agile -- sit at opposite ends of a spectrum, with most successful projects landing somewhere in between.
Waterfall Methodology
Waterfall is a sequential approach where each phase must be completed before the next begins: Requirements, Design, Implementation, Verification, Maintenance.
Strengths: Predictability (accurate cost/timeline estimates), comprehensive documentation (audit trail), clarity for vendors (fixed specs for procurement).
Limitations: Critical path dependencies block progress, issues are discovered late when the end customer cannot interact until completion, and rigidity makes mid-project changes costly.
Agile and Iterative Approaches
Agile breaks work into small increments called sprints (2-4 weeks). Each sprint produces a working, tested increment. Stakeholders review and provide feedback that shapes the next sprint.
sequenceDiagram
participant PO as Product Owner
participant Team as Design Team
participant Stakeholders as Stakeholders
participant Network as Network
rect rgb(230, 240, 255)
note over PO, Network: Sprint N (2-4 weeks)
PO->>Team: Prioritized backlog items
Team->>Team: Design and implement increment
Team->>Network: Deploy tested increment
Network->>Stakeholders: Demonstrate working network
Stakeholders->>PO: Feedback and change requests
end
rect rgb(230, 255, 230)
note over PO, Network: Sprint N+1
PO->>Team: Adjusted backlog with feedback
Team->>Team: Design and implement next increment
Team->>Network: Deploy tested increment
Network->>Stakeholders: Demonstrate updated network
Stakeholders->>PO: Further feedback
end
Figure 1.3: Agile sprint cycle -- each sprint delivers a working increment; stakeholder feedback flows back into the next sprint's backlog.
Strengths: Resilience to change, early value delivery (incremental improvements), rapid feedback loops (problems surface early).
Challenges for network projects: Hardware lead times (weeks/months vs. 2-week sprints), tight interdependencies (a routing change in Sprint 3 may invalidate Sprint 1's security policy), stakeholder availability for frequent reviews.
Animation: Side-by-side comparison of waterfall (linear cascade) vs. agile (iterative spiral) timelines, showing how a mid-project requirements change impacts each methodology differently.
Hybrid Methodologies
Research suggests the dominant successful methodology will combine agile practices with a traditional waterfall approach. Most successful projects used frequent delivery (2-4 week sprints) but with a robust preliminary definition of the final product.
| Project Phase | Methodology | Rationale |
|---|
| Requirements and high-level design | Waterfall | Core architecture needs stability and stakeholder sign-off |
| Detailed design and implementation | Agile (sprints) | Iterative delivery allows rapid feedback and change accommodation |
| Verification and acceptance | Waterfall | Formal testing against documented requirements provides contractual clarity |
| Operations and optimization | Agile (continuous improvement) | Ongoing tuning benefits from short feedback loops |
flowchart TD
subgraph Waterfall ["Waterfall Phases"]
A[Requirements Gathering] --> B[High-Level Architecture Design]
B --> C[Stakeholder Sign-Off]
end
subgraph Agile ["Agile Sprints"]
C --> D[Sprint 1: Detailed Design + Deploy Subset]
D --> E[Sprint Review + Feedback]
E --> F[Sprint 2: Adjust + Deploy Next Subset]
F --> G[Sprint Review + Feedback]
G --> H[Sprint N: Final Deployment]
end
subgraph Waterfall2 ["Waterfall Closure"]
H --> I[Formal Acceptance Testing]
I --> J[Operations Handoff]
end
J --> K[Continuous Improvement - Agile]
Figure 1.4: Hybrid methodology -- waterfall bookends wrap around agile sprints for iterative delivery.
Change Management and Design Governance
Regardless of methodology, every project needs change management (structured transitions minimizing disruption) and design governance (policies and review boards ensuring alignment with business objectives).
flowchart TD
A[Change Request Submitted] --> B[Change Classification]
B -->|Standard Change| C[Pre-Approved: Execute]
B -->|Major Change| D[Change Advisory Board Review]
D -->|Approved| E[Schedule Implementation Window]
D -->|Rejected| F[Return to Requestor]
E --> G[Implement with Rollback Plan]
G --> H{Success?}
H -->|Yes| I[Post-Implementation Review]
H -->|No| J[Execute Rollback]
J --> I
I --> K[Document Lessons Learned]
Figure 1.5: Change management process flow.
Key elements: Change Advisory Board (CAB) for risk assessment and approval, change classification (standard vs. major), rollback planning with defined trigger points, and post-implementation review comparing actual to expected outcomes.
Design governance mechanisms: architecture review boards, design pattern libraries (pre-approved solutions), and exception processes for justified deviations from standards.
A technically elegant network design that does not deliver measurable business value is an expensive academic exercise. The key mechanisms: translating KPIs to SLAs, maintaining traceability, and communicating trade-offs effectively.
Translating Business KPIs into Network SLAs
A KPI is a measurable value demonstrating business effectiveness. An SLA is a formal commitment defining performance metrics and thresholds. The translation from KPI to SLA is the quantitative bridge between business language and network language.
flowchart LR
subgraph Business ["Business Layer"]
A[Business KPI]
B["e.g. 99.9% order uptime"]
end
subgraph Translation ["Translation Layer"]
C[Define Measurement Method]
D[Add Safety Margin]
E[Map to Network Metrics]
end
subgraph Network ["Network Layer"]
F[Network SLA]
G["e.g. 99.95% availability"]
H[Monitoring and Enforcement]
end
A --> C
B --> D
C --> E
D --> E
E --> F
E --> G
F --> H
H -->|Reporting| A
Figure 1.6: Translating business KPIs into network SLAs with safety margins and monitoring feedback.
| Business KPI | Network SLA | Measurement Method |
|---|
| "99.9% order processing uptime" | Network availability >= 99.95% (safety margin) | Synthetic transaction monitoring, SNMP polling |
| "Customer calls answered within 30 sec" | VoIP MOS >= 4.0, jitter < 30 ms, latency < 150 ms | IP SLA probes, call quality monitoring |
| "Same-day shipping for orders before 2 PM" | WAN availability >= 99.99% during business hours | Link utilization reporting, failover testing |
| "Quarterly close within 5 business days" | DB replication latency < 10 ms, backup within 4-hour window | APM, backup job reporting |
The analogy is a thermostat: the business sets the desired temperature (KPI), the HVAC system has its own SLAs, and the thermostat (translation layer) converts comfort requirements into mechanical instructions.
Animation: Interactive KPI-to-SLA translator -- select a business requirement and see it decompose through the translation layer into specific network metrics with safety margins.
Design Documentation and Traceability Matrices
A requirements traceability matrix (RTM) maps each business requirement to design decisions, implementation tasks, and test cases -- the project's "chain of evidence."
| Req ID | Business Requirement | Design Decision | Test Case | Status |
|---|
| BR-001 | Branch operations during WAN failure | Dual WAN links with automatic failover; local caching | Simulate primary WAN failure; verify failover < 5 sec | Verified |
| BR-002 | PCI compliance for payments | Dedicated POS VLAN; end-to-end encryption; firewall segmentation | PCI vulnerability scan; traffic isolation verification | Verified |
| BR-003 | 50 concurrent video conferences per site | QoS marking/queuing; 200 Mbps reserved bandwidth | Generate 50 concurrent streams; measure MOS and loss | Pending |
The RTM is a living document. As requirements change, the matrix is updated. Requirements should state what the business needs, not how the network provides it.
Executive Communication of Design Trade-offs
Effective executive communication follows four principles:
- Frame trade-offs in business terms -- "We have two routing approaches: one is simpler but limits partner connectivity; the other is more complex but supports growth."
- Use a decision matrix -- present options side by side with impact on cost, timeline, risk, and capability.
- Quantify risk in dollars -- if downtime costs $50K/hour, the difference between 43 hours/year and 0.9 hours/year ($2.15M vs. $45K) dwarfs the infrastructure cost difference.
- Recommend, do not just present -- executives want expert guidance with clear reasoning.
1. A hospital requires 99.99% uptime for its patient records system. During the PPDIOO lifecycle, in which phase would you first document this availability requirement and build the financial justification for the infrastructure needed to meet it?
Plan -- because this is where gap analysis occurs
Prepare -- because this is where business requirements and financial cases are established
Design -- because this is where technical specifications are created
Implement -- because this is where the network is built to meet the requirement
2. An enterprise discovers during network implementation that a key business unit was never consulted about their application requirements. Which best practice was most likely violated?
Keeping specifications implementation-neutral
Planning for 18-month forward requirements
Identifying all stakeholders early in the process
Using a requirements traceability matrix
3. Which PPDIOO phase is described as the "most underutilized" yet is critical for identifying gaps between current and desired network states?
Prepare
Plan
Design
Optimize
4. A managed service provider is rolling out SD-WAN to 50 branches. After deploying to the first 15 branches, they discover a regional ISP performs poorly and want to change the design for remaining sites. Which project management methodology best supports this mid-project adjustment?
Waterfall, because the full scope was defined upfront
Agile, because iterative sprints allow incorporating feedback between deployments
Waterfall with a formal change order process
Neither -- the original design should be maintained for consistency
5. Why does a hybrid methodology typically use waterfall for requirements gathering and high-level architecture, but agile for detailed design and implementation?
Because agile does not support documentation, which is only needed at the start
Because foundational architecture needs stability and sign-off, while iterative delivery benefits from rapid feedback and adaptability
Because waterfall is faster for early phases and agile is faster for later phases
Because executives prefer waterfall and engineers prefer agile
6. A network designer presents three data center options to a CFO: no redundancy ($500K, 99.5% uptime), active-passive ($1.2M, 99.95%), and active-active ($1.8M, 99.99%). If the business loses $50,000 per hour of downtime, what is the strongest argument for the active-active option?
It uses the most advanced technology available
The annual cost of downtime for the cheapest option far exceeds the incremental infrastructure investment
Active-active is always the industry best practice
The CFO should always choose the most expensive option for critical systems
7. What is the primary purpose of a requirements traceability matrix (RTM) in a network design project?
To list all network hardware and software to be purchased
To map each business requirement to its corresponding design decision, implementation task, and test case
To track project budget expenditures against forecasts
To document the change management approval workflow
8. A retail chain needs to open 10 new stores per quarter with network connectivity. The design team proposes template-based SD-WAN with zero-touch provisioning. Which business requirement does this design decision most directly address?
Maximum network security for payment processing
Rapid, standardized, and repeatable branch deployment at scale
Minimizing WAN bandwidth costs across all locations
Achieving 99.99% uptime at each store
9. In a change management process, what distinguishes a "standard change" from a "major change"?
Standard changes are free; major changes have associated costs
Standard changes are pre-approved and low-risk; major changes require Change Advisory Board review
Standard changes affect software only; major changes affect hardware
Standard changes are temporary; major changes are permanent
10. An organization translates a business KPI of "99.9% order processing uptime" into a network SLA of "99.95% network availability." Why is the network SLA set higher than the business KPI?
To impress executives with better numbers
Because the network is only one component in the end-to-end service chain, so it needs a safety margin to account for other failure points
Because network equipment is more reliable than application software
Because SLAs must always exceed KPIs by regulation
11. Why does a pure agile approach sometimes clash with network design projects involving physical hardware?
Because agile requires all team members to be co-located
Because hardware procurement cycles of weeks or months conflict with two-week sprint expectations, and network components are tightly interdependent
Because agile does not allow for any documentation
Because network hardware cannot be tested incrementally
12. Business Application Profiles (BAPs) and User Application Profiles (UAPs) are used primarily to:
Document the technical specifications of network equipment
Systematically translate business and application requirements into network technology selection criteria
Track project milestones and budget expenditures
Define the organizational chart for the project team
13. The PPDIOO model is described as "iterative, not strictly sequential." What does this mean in practice?
You can skip any phase that seems unnecessary for your project
After completing a phase, you may need to return to earlier phases as requirements change, technologies evolve, or issues are discovered
All six phases happen simultaneously
The phases can be completed in any random order
14. When communicating design trade-offs to non-technical executives, which approach is most effective?
Present detailed protocol comparisons (e.g., OSPF vs. BGP convergence timers)
Frame options in business terms, quantify risk in dollars, and provide a clear recommendation
Let the executives choose based on vendor marketing materials
Always recommend the lowest-cost option to show fiscal responsibility
15. A network requirements document states: "Deploy Cisco ISR 4451 routers at all branch sites." What best practice does this specification violate?
Planning for 18-month forward requirements
Keeping specifications implementation-neutral to avoid premature vendor commitment
Engaging all stakeholders early
Using a cross-functional technology selection team