Environment size
Footprint and ownership
User count, system count, cloud footprint, and who owns day-to-day administration change the amount of follow-through.
Engagement Scoping
The same service changes with footprint, depth, cadence, and delivery model. Scoping turns those inputs into a work shape.
Bring these numbers
Scope inputs
Footprint, depth, cadence, and delivery determine the lift.

Sizing matrix
The goal is to estimate work honestly before delivery starts.
How scoping works
How to read this
These scope drivers are planning anchors, not fixed packages. Final sizing depends on platform mix, admin maturity, and how much security oversight belongs in the work.
Environment size
User count, system count, cloud footprint, and who owns day-to-day administration change the amount of follow-through.
Delivery model
Some problems need ongoing operational cadence. Others need a defined project with an endpoint. The delivery model changes pacing and lift.
Review depth
Scope expands when the work needs broader validation, deeper testing, or review across several systems.
Managed Support Sizing
How to read this
These support bands are planning anchors, not fixed packages. Final sizing depends on platform mix, admin maturity, and how much security oversight belongs in the support motion.
Sizing example
Band 1
Up to 10 users, 10 workstations, and 5 servers
Small teams that need support ownership and routine hygiene.
Light recurring cadence with baseline review and priority guidance.
Sizing example
Band 2
Up to 50 users, 50 workstations, and 20 servers
Growing environments where admin practice and support coordination need structure.
Recurring support with change-window help and broader operational review.
Sizing example
Band 3
Up to 200 users, 200 workstations, and 50 servers
Larger teams that need deeper support, review, and prioritization.
Ongoing review of support hygiene, posture drift, and operational decision points.
Sizing example
Band 4+
Over 200 users, over 200 workstations, or over 50 servers
Environments where support, security review, and architecture need custom sizing.
Custom support shape based on platform mix, operational complexity, and exposure.
Consulting Scope Area
Scope Track
For teams cleaning up IT process, support ownership, and admin friction.
Scope Track
For application, workflow, or automation work that needs design review and implementation guidance.
Scope Track
For teams using AI to streamline work while keeping adoption supportable.
Scope Track
For domain-specific or revenue-critical systems where workflow, architecture, and delivery risk need review together.
Security Scope Area
Scope Track
When system design, identity flow, or trust boundaries are the main unknown.
Scope Track
When a web app or API needs direct testing and fix order.
Scope Track
When Windows, Linux, or cloud systems need a stronger baseline.
Scope Track
When the work needs a wider attack path or combined testing surfaces.