How to Write a Network Proposal: Sections, Lengths and What Reviewers Score

What a network proposal is (and who reads it twice)

A network proposal argues that a specific design solves a documented problem for a stated cost — which makes it a persuasion document built on engineering. The reader is a manager who signs budgets, so the proposal leads with impact (outages, security exposure, capacity limits) and follows with the architecture that fixes it. Course versions simulate the client: the prompt names a business scenario, and the rubric checks whether the design decisions trace back to that scenario's requirements rather than to generic best practice.

Two audiences read it differently, and the format has to serve both. The manager reads the executive summary, the cost table and the timeline; the technical reviewer reads the requirements, the topology and the IP plan. That split is why the summary is written last and why every section opens with its conclusion: 'The existing single-switch core creates a single point of failure' is a sentence both audiences can use. A proposal that buries its argument inside configuration detail loses the first reader before the second one starts.

The numbers at a glance

Section budgets for a 10-page course network proposal — the range, and where each row actually shows up in coursework. Skim it first; the sections below explain why the range exists and which row applies to you.

The sections in order, with budgets

The standard seven parts run: executive summary, current state assessment, requirements, proposed design, equipment and costs, implementation timeline, and risks. At the 10-page scale that most courses assign, the budgets in the table above total roughly 2,500 words plus the diagrams and tables that carry the design itself. The current state section earns its 300-500 words by diagnosing, not describing — 'the 2016 access switches run at 92% utilization during peak hours' beats a neutral inventory the client could read on the hardware itself.

The proposed design section is the document's center of gravity at two to four pages, and it should open with the topology overview before any device-specific detail: the layer structure, the redundancy approach, the VLAN and IP scheme, the wireless coverage plan. Requirements come before the design because they justify it — each numbered requirement should map to a design element, and a design element with no requirement behind it invites the reviewer's question about cost. Risks and maintenance windows close the document honestly, which is the credibility move reviewers notice.

Diagrams: the part graders zoom in on

The topology diagram is the proposal's centerpiece, and annotation density is what separates graded work from screenshots. Every diagram needs a title and figure number, a legend for icons and line styles, labeled VLANs and subnets with their address ranges, and device names that match the cost table exactly — a switch called SW-CORE-01 in the diagram and 'core switch' in the budget reads as two switches to a skimming grader. Port-level annotation matters in upper-division courses: uplink speeds, trunk ports, and where redundancy actually connects.

Tool choice is visible and fine either way: draw.io or Lucidchart produce clean generic topologies, while Packet Tracer, GNS3 or EVE-NG screenshots prove the design was simulated. If you built it in Packet Tracer, say so in the caption and export at high resolution, because unreadable screenshots are the most common diagram deduction. One diagram per idea scales best — logical topology, physical placement, and IP plan as separate figures — since a single diagram carrying all three layers turns into the unreadable one that loses the points.

Requirements and justification language

Requirements are numbered, classified and testable: 'R3. The WLAN must support 250 concurrent clients per building at 802.11ax speeds.' The classification layers business requirements (the outcome the client buys), user requirements (what staff and guests experience) and technical requirements (the measurable specs), and the numbering is what enables traceability — the design section then cites requirement IDs as it commits to solutions, 'redundant core per R7.' A design choice justified by an ID never has to defend itself from scratch, which is the efficiency the whole document is built on.

Justification language compares alternatives instead of asserting superiority: 'A star topology was selected over a ring because the building's conduit runs make a ring costlier by roughly $4,000 with no uptime gain at this scale.' Two or three alternatives considered per major decision — routed access versus layer 2, controller-based versus autonomous wireless, on-premises versus cloud management — signals engineering judgment, the rubric line that separates A proposals from accurate ones. Vendors' white papers can cite standards (IEEE 802.1X, NIST guidance), but the comparison logic must be yours.

Costs, timeline and the risk paragraph

The cost table itemizes hardware with model numbers and quantities, licenses, cabling and labor, and it reconciles with the diagram's device names — graders check that arithmetic without announcing it. Realistic pricing earns trust: a proposal pricing enterprise switches at consumer prices signals research not done, so use street prices from a vendor or distributor and state the source. A contingency line of 10-15% is standard practice and shows budget literacy. Total cost of ownership can earn a sentence: licensing renewals, power, and the support contract that keeps the design alive after year one.

The implementation timeline is phased, with dependencies and a downtime window per phase: 'Phase 2 migrates VLANs on the Saturday window, with rollback to the prior config if authentication fails testing.' Risks close the document with a short table — failure mode, likelihood, mitigation — and the honest inclusion of a risk you cannot fully mitigate (a legacy system that cannot join the new authentication scheme) reads as competence, not weakness. Courses grading capstone-style expect this section to make the proposal executable by someone who is not you.

Run your own numbers before you submit

Guidelines are ranges; your document is a fact. Paste your current draft into the word counter below and the page estimate recalculates live for double-spaced and single-spaced formats — no account, nothing uploaded, the text never leaves your browser. Check the word count rather than the page display in your editor: word processors pad pages with headings, breaks and whitespace, and instructors check words.

If the count lands below your target, add analysis before adding sources: two more sentences of interpretation in your three weakest paragraphs usually beats one new summary paragraph. If it lands above, cut your most summarizing paragraph — the one that retells a source instead of using it. Both edits take ten minutes and both make the paper better while fixing the number.