How to convince I.T. to buy computers that can handle ArcGIS Pro?

[Bud]

My department's computers are up for replacement this year. So I've asked my I.T. department to buy us computers that meet the ArcGIS Pro Optimal requirements: ArcGIS Pro 3.1 system requirements.

To my surprise, my I.T. department say they can't afford to buy computers that meet those requirements. They actually say they'll be replacing in kind -- meaning we'll get the same specs as we already have, which doesn't even meet the Recommended requirements, let alone the Optimal requirements. Screenshot.

To be honest, if that's the case, I'm not really looking forward to my next few years of using ArcGIS Pro.

I actually don't end up doing much mapping in Pro. I normally just test individual queries or add a table/small FC to the map to do testing. I don't do anything that has heavy graphics requirements; the enterprise geodatabase does most of the heavy lifting.

Even still, I end up waiting for Pro to load more often than I'd like. It's little things like:

• Geoprocessing tools are slow to load/initialize. (I'm not talking about running the tool; I'm talking about opening the tool.)
• Right-clicking a layer in the Contents pane. The right-click items are greyed-out initially and take a few seconds to load.
• Using the Explore tool on a small FC. Takes a few seconds to load.

I can't say I really understand why simple things like that take a few seconds to load. I can understand slow performance when running complex analysis or maps. But not so much when opening a GP tool, etc.

But that's beyond my control. 

What I want to ask is:

Has anyone else been in a similar situation? Have you had any luck convincing your organizations to buy high-performance computers for using ArcGIS Pro? If so, how? For example, I've tried saying, "We spend all this money on software, it would only make sense to have hardware that can run it properly." But that hasn't worked so far.  

Any tips or lessons learned?

[Bud]

Notes:

• Yes, I've disabled indexing and am not storing any files on a cloud drive. I think those things can impact performance.
• I'm currently using ArcGIS Pro 2.6.8; will be upgraded to the latest version in the fall.
• I hope we can keep this conversation civil. Unprofessional rants don't get us anywhere.

[ClayDonaldsonSWCA]

Something to potentially suggest, though it depends on your company size, is working with virtual desktop infrastructure (VDI). This allowed us to have cheaper hardware, but log into desktop environments capable of running pro at recommended specs.

[MichaelVolz]

Clay:

Would you know if the virtual environment can have lower specs than a physical machine? 

This is what IT staff have said at my org when we asked for more RAM (32 GB compared to current 16 GB) and I was wondering if this was accurate or not, as the Pro experience has not been optimal thus far with lots of waiting for progress bars far more often than in ArcMap.

[BrandonA_CDPH]

My experience with VDI has been less than optimal. I ran into issues with our IT not being able to allocate the graphics memory to the virtual machine. They kept increasing the amount of processing power I was allocated, but the software would lag, crash, and freeze any time I did anything with graphics (like try to modify a layout). After some research and trial and error, it was an issue of graphics processing power, and I was issued a laptop instead. This was a few years ago and things may have changed.  Also, I'm not an IT person, so I don't know if this is a limitation in all VDI systems or just ours (or even just our IT being unwilling).

[BillFox]

maybe some analogies to other departments can help relate the need

for example,

a set of tires that meet the optimal requirements to support the work of a Fire Engine or Police Car

construction materials that meet the optimal requirements to build a highway bridge to support those Fire Engines and Police Cars

or the timeless "We Need A Bigger Hammer" ⚒

[CarlMorrison]

Does your company have a CAD department?  CAD workstations often have the horsepower necessary to run GIS as well, if you do, tell IT you want what they have.  This article may help https://www.cadalyst.com/design-related-technologies/workstations/workstation-minimums-2022-and-beyo... 

[AnthonyRyanEQL]

We have used time savings in processes/processing. For example, If the high spec machine is $3000 more and you have it for 3 years which is $1000/year. Your charge out rate is $100/hour so you need to find a savings of 10hours in a year which is approx. 15mins/per week or 3/mins a day. I assume there would be things you could improve.

Our company had a 3D extract tool for small areas of the Utility Network which took approx 3-5mins to run. I re-wrote it with an Esri Addin and reduced it approx 40secs. A person just needs to run it once/day and we got the savings, etc.

I know the pain and good luck

[BarryNorthey]

Not a rant, just the facts. Our organization was pushed into the managed desktop environment and IT switched from supporting the business to controlling it. My branch offered IT the money for upgraded workstations for our "power" GIS analysts who were working with large geodatabases, but IT still said no. We eventually prevailed by providing upper management with a show and tell that revealed how long it took to run a process on their approved design, sometimes taking over a day. We eventually got a test machine and something that took a day or two to run was completed in under 4 hours. We also provided emergency wildfire support and waiting hours instead of minutes for a product was not acceptable. In the end, IT and management had to see it for themselves.

CPU, RAM and storage space are cheap relative to people's time.

[DanPatterson]

Similar experience to Anthony's and Barry's comments.

Users should have a say in what is needed to perform their job, otherwise calls to IT may become more frequent to provide alternate solutions to bottlenecks.  This could lead to increased IT costs beyond that of a couple of gaming machines, or two lower spec machines to use for task co-processing/branching