The Workloads Your ITSM Playbook Was Not Written For

Standard ITSM (Information Technology Service Management) falls short in AEC firms when project workloads set the rules for the workstation, data path and maintenance window.

The challenge reaches beyond buying powerful PCs. Simply because it affects how you track upgraded components, triage model sync failures, keep specialist workstations available remotely and patch machines without losing milestone output.

The response is workload-aware ITSM. Your controls can stay standardised. Each workstation profile can respond to the work it is doing.

The asset record, support runbook and maintenance window should do the same.

This gives IT managers a better way to protect delivery dates while keeping hardware exceptions and patch deferrals visible. It is also where managed IT services for AEC teams earn their keep, because those profiles, runbooks and maintenance windows have to be maintained, not written once and forgotten.

The Fleet That Refuses to Be a Fleet

An AEC workstation fleet stops acting like a fleet when software, model load and project deadlines drive each machine's configuration.

Autodesk's Revit 2026 requirements show the gap. Its large, complex model tier specifies 64 GB of RAM or more. Other workloads may rely more heavily on graphics, processor speed or fast local storage.

Keep the fleet manageable by standardising a small set of workload profiles:

• Core CAD and BIM authoring: Set an approved baseline for everyday production work.
• Large-model coordination: Allow extra memory and local cache capacity for linked and federated models.
• Rendering and analysis: Record the processor or GPU requirement and the expected run time of long jobs.

These profiles let your team buy for the work, reassign machines as projects change and approve targeted upgrades.

They also avoid two expensive outcomes: overspecifying every desk or leaving a deadline-critical user with an underpowered workstation.

Asset Lifecycle When Every Machine Is Different

When every machine is different, asset lifecycle management has to treat each upgrade as a configuration change.

A purchase date and device serial number cannot tell you whether a RAM upgrade extended the machine's useful life or a replacement GPU introduced a separate warranty.

Track the fields that change the next support or refresh decision:

Use that record to choose between adding memory, replacing a component, moving the workstation to lighter work or completing a full refresh.

The decision becomes easier to budget and less likely to disrupt the next project.

A disciplined view of how asset lifecycle tracking holds up under mixed hardware turns case-by-case upgrades into fleet-level data.

Your asset register stays useful for support, warranty tracking and project allocation.

The File Is the Bottleneck, Not the Network

Large model files turn a healthy network into a project bottleneck, so support has to diagnose the full data path.

Three issues change the operating model: file size changes what the ticket must capture, concurrent syncing creates coordination incidents, and remote access may need to keep the workstation and data together.

Why File Size Changes the Support Conversation

File size changes support because throughput, storage I/O, cache space and concurrency can determine whether the application works.

Autodesk recommends a gigabit LAN throughout file-based Revit worksharing. Its cloud-worksharing tests also found bandwidth availability more influential than latency.

A ping or browser speed test cannot clear the full collaboration path. Capture these facts before escalation:

• Model, linked-file and local-cache size;
• Central or cloud storage location and transfer direction;
• Free space on the workstation and shared storage; and
• Concurrent users and recent sync times.

This evidence lets your service desk distinguish limited headroom from storage, cache or model-health issues. It prevents the ticket from being closed at “network looks fine”.

Sync Conflicts as an Operational Issue, Not a User Error

Sync conflicts are operational incidents when shared state, timing or version mismatch decides whether a save succeeds.

Autodesk documents reduced performance when multiple users synchronise a cloud model at the same time. Ideally, the runbook should record:

• Who synchronised and when;
• The application build used by each affected user;
• Whether the model is central, local or cloud-hosted; and
• Cache state and recent model operations.

That evidence tells you whether to stagger sync activity, investigate a cache or version mismatch, or escalate model health. “File corrupted” describes the symptom. Even though it does not establish the cause.

Remote Access When the Asset Cannot Travel

Remote access works best when the workstation and model need to stay together.

Autodesk describes remote desktop sharing as sending keystrokes, mouse input and screen updates while Revit and its data remain on local or virtualised infrastructure.

This avoids copying large model sets to an unsuitable laptop or rebuilding a specialist workstation for temporary access.

Your support runbook still needs to cover authentication, graphics behaviour, session recovery and the workstation's availability.

Maintenance Windows That Never Open

Maintenance windows have to follow the workload state because a fixed Friday-night reboot can destroy a job that is still running.

A workstation may look unattended while it completes a 48-hour render or structural calculation for a Monday milestone. That is why IT needs a verified run-state before approving a reboot.

Once that run-state is visible, managed IT services for project-driven teams can coordinate maintenance with project owners and update deadlines.

The aim is to protect the live job while still setting a clear time to patch. Four controls make that coordination workable:

• Name the job owner: Record the workload and its expected completion time.
• Use deployment rings: Test operating-system, driver and application compatibility before broader rollout.
• Offer one alternate window: Record the deferral and the new maintenance time.
• Keep a final deadline: Escalate any job likely to cross it.

Together, these controls turn a deferral into a managed decision: the job has an owner, the update has a new window and the exception has an end point.

Microsoft's current Windows guidance uses deadlines and grace periods, after which updates and restarts may proceed regardless of active hours.

The final deadline protects milestone output without allowing the security update to slip indefinitely.

What Changes When Support Is Built Around the Workload

Support built around the workload standardises operating controls across different devices. The model stays consistent in four places:

• Hardware differences fit approved workload profiles;
• Component changes update the asset record;
• Support tickets capture the data path and application state; and
• Maintenance deferrals have an owner, alternate window and final deadline.

The result is a flexible service model with a reliable asset register, repeatable incident triage and visible exceptions. In compute-heavy environments, that is operational control.