Scoping Data Volume and Growth Trajectories: Size for Year Three, Not Day One

Many proposals are sized for the data the customer has today. By the time the solution goes live, that figure is already out of date, and two or three years later the architecture, the licence model or both can be under strain. Seasonal peaks make it worse: a system that copes on an average Tuesday can fail on the busiest day of the year. A Solution Engineer who does not ask about growth is, in effect, guessing on the customer’s behalf.

This article covers an atomic discovery skill from the SE Ignite catalog: projecting how multi-year data growth and seasonal spikes will stress the proposed architecture.

The problem this solves

• Problem: volume is captured as a single current number. The design or pricing then fails under growth or peak load, leading to performance problems, unplanned costs or a difficult renewal conversation.
• Reader: Solution Engineers and solution architects responsible for sizing and technical scoping.
• Stage: discovery and solution design, before the commercial proposal is priced.
• Decision it supports: what capacity, architecture pattern and commercial tier to propose, and which growth assumptions to state in writing.
• Success test: your proposal states current volume, expected growth, peak multiplier and retention period, each confirmed by the customer, and shows how the design handles year three.

The four numbers to capture

1. Current volume. Records, events, transactions, users or storage, using the customer’s own definitions. Agree what each unit means first, as covered in clarifying internal jargon.
2. Growth trajectory. Ask how volume changed over the past two or three years and what the business plan expects. Planned product launches, acquisitions or new regions matter more than a generic percentage.
3. Peak pattern. When is the busiest hour, day or season, and how does it compare with an average day? Ask for evidence from the last peak.
4. Retention. How long data must be kept, by law or by business need. Retention multiplies storage even when daily volume is flat.

A method for projecting growth without guessing

1. Ask for the history first. Real past growth is more reliable than a forecast.
2. Ask for the drivers. “What would make this number double?” usually reveals the events that matter: a new market, a migration, a regulatory change.
3. Build three scenarios. Expected, high and peak. Show the customer the assumptions behind each.
4. Test the design against the high scenario. Identify which component reaches its limit first.
5. Write the assumptions down. Put them in the proposal so later changes in volume lead to a planned conversation, not a dispute.

Adapting it to the situation

• A rapid-growth assessment after outages: the outages are evidence. Ask what load level triggered them and size above that point.
• A multi-region rollout: growth and peaks differ by region and time zone. Model each region, then the combined load.
• A merger or acquisition: volumes from both organisations will combine. Ask about the timing of the consolidation.
• A regulated environment: retention and data residency rules can dominate storage and architecture choices. Confirm them with the compliance owner.
• “Our homegrown system works well enough”: ask how it performed at the last peak. Growth is often what will break a system that works today.

Common mistakes

• Using one average number. Averages hide peaks, and peaks cause failures.
• Inventing a growth rate. If the customer cannot give one, build scenarios and say they are scenarios.
• Sizing only the core system. Integrations, logs, backups and analytics copies grow too.
• Keeping assumptions in your head. Unwritten assumptions cannot be checked or defended later.

Where this skill sits

Volume and growth are a specific part of non-functional requirements gathering, and they feed the broader scoping, sizing and volumetrics work in solution design. They also connect to integration touchpoints, because each integration carries its own share of the load.

Practising the 80%

Projecting growth and peaks is a vendor-neutral sizing discipline, part of the 80% of Solution Engineering that SE Ignite teaches. Practise it by taking a past opportunity and rebuilding its sizing with the four numbers and three scenarios above. The SE Ignite curriculum is free to use.