Argthtjtr

This is a partial solution I've used myself, and it assumes a few things:

• You access your clusters remotely through a connection (like other answers pointed, cloud servers or remote), so where you work isn't exactly the bottleneck.


• The software you use isn't OS dependent or has any special licenses


• You do not have a ton of things hooked up from serial ports to measuring equipment and whatnot.

One thing I've done in this situation is, when you finally grab a ticket from IT, ask them to install a virtual machine like VirtualBox and have them enable virtualization in the BIOS. Most processors allow this nowadays. Make sure they install it properly or they will ghost again.

This basically allows you to install any Linux distribution you want (you need Licenses for Windows images), so it is an operating system where you have all admin rights. This completely removes the IT middleman if your case is just coding and clustering the data crunching since you don't need their permission to do things in the VM, and also shouldn't impact performance significantly.

If IT is worth half a dime, they will appreciate the solution, since:

• It takes gargantuan effort to compromise the Host Machine through a VM if you are not malicious


• Resulting lack of tickets from you needing something updated/installed.

Worst case scenario you can still alternate between both Operating Systems, and do small things in the VM with your admin rights.

I think this is a fairly common occurrence in many companies. There is a big disconnect between the researchers trying to do their work and the IT staff who may be under-resourced, under-trained or limited by administrative policy. In my experience there is often lots of worry about researchers installing software without fully understanding the security implications. In short, I would not expect you to be able to change this policy and it may well be in place for sound reasons.

One solution that has been suggested to me is that academics can apply for time using different cloud compute solutions (e.g. Google compute https://cloud.google.com/edu/, Microsoft Azure https://azure.microsoft.com/en-us/education/, any many more). If successful you will be given compute time in a virtual machine where you will have appropriate administrative rights to install any software you want.

We had this issue with some Silicon Graphics machines - we removed them from the IT department's control, with the support of the supervisors whose budgets had paid for them, and then controlled everything ourselves.

It went much better; we had more uptime and fewer issues than any other group / team on campus.

We learnt a lot about compiling & installing etc.

Not sure if you can go that route.

Note, the software we were using was CFD and the IT dept had no experience of what was needed.

Whilst others have focused on giving you some technical advice on alternatives to using your institution's infrastructure, I want to note that your problems are not uncommon. In my practice I opted to installing the software myself (a lot of software packets I used do not need root privileges for installation, make sure that admin access for yours is really a must) or asked supervisor for help.

If you are on good terms with your supervisor, you can always ask him for help, going from as little as cc-ing him in software installation emails that you send to your IT department to directly asking him for help when those request emails are ignored. In many organizations it's not easy for junior members to be listened to and that's just something you have to get over with.

At many universities, you can actually go through a (rather secret) bureaucratic process that allows you to install your own software on the university computer, even though this is not the default option.

If this option exists, it will likely include signing forms that may limit (or even eliminate) future IT support for that computer. Basically, you are agreeing to be your own IT in exchange for flexibility. However, if you are constantly downloading software it is often worth it.

The University doesn't want to encourage this option, because it can be a perceived security risk, so you will have to directly ask administrators in your department and IT, if this option is available, as it likely won't be published online anywhere. And you may have to assertively push for it.

This process was available to me at two of the three universities I've been based at over the years (in the USA and Australia). The one that didn't allow it actually theoretically did, but the form also said that you would no longer be able to connect to the Universities wired internet network, which wasn't worth giving up for me. Read the forms very carefully before you go down this route to make sure you are comfortable with the tradeoff you are making.

Since you're not in a "tech-oriented PhD", I'm guessing the cluster is 10 machines or less? If so, consider setting up your own cluster on any of the big cloud providers. AWS and Azure come to mind, but Google and IBM are still trying to hang on in those markets.

Thoughts on pricing:

• You don't have to have the cluster up all the time, so you don't have to pay for 24hrs/day for a full month. You would have to figure out how to save/load the data and install some programs quickly (docker?), if you opt for shutting down some or all servers.


• If you have fellow students or professors who are in the same boat, consider sharing your cluster and its expenses.


• Depending on your research, you might (eventually) be able to get special pricing from some vendors.


• On AWS, reserved instances are cheaper than spot instances.

Look at how much your time is worth, and how much these delays are impacting your research. If IT delays cost you 1 week of delays every month, then it's probably worth setting up things yourself. (Remember to back things up, and test your backup strategy. Put your code and data in github)

And lastly, are you using their ticketing system for your requests, or just asking them verbally? If there's no ticket, it'll surely be forgotten 5 minutes after you spoke to them.

You should also be managing your requests.

I mean: track when you raised the request, ask for news after a reasonable period of time (two working days), repeat that max three times. In the first follow-up you can make it clear why this is important to you. For IT staff it might sound like 'I want this tool installed', but if you detail the deadline you have and why this ticket is crucial for your work, they might understand. After the third time, get your supervisor involved. Ask him/her to escalate the request in a conversation with an IT service manager.

Don't be happy with simply solving the ticket, try to see if IT can communicate what time of service level agreement they aim to respect. Maybe installing something requires internal permissions (release management) which, for instance, makes it impossible to install stuff on a Friday, or an afternoon, or if you don't have a rollback (meaning you have to backup the entire server setup before touching anything), etc.

Managing the request also means making sure your requirements are superclear. If you think you might need a package ask them to install it. Run these installations yourself in a VM that is identical to the production setup and provide them with the commands to actually install the tools. All these things you can manage.

At all times, and I must stress that, be nice. Just be nice. Unless you have reasons to suspect someone is trolling you, you have to give them the full credit for having to tackle many such requests at the same time. Being nice will get you further on the long run. It will also show to your supervisor that you are capable of creatively handling difficult situations.

Adding this since nobody's mentioned it yet: You could ask your supervisor about having a meeting between you, your supervisor and someone from IT. Maybe even invite them to lunch if it's appropriate to your institution and situation. In case they're overwhelmed by tickets and/or they feel like your tickets come in from a faceless ticket-generator, it could help to meet the real researcher behind them. And you can meet the real person handling the tickets, and see if there's any way you can make your tickets more straightforward for them.

Talk to your supervisor ("promotor"?) about the issue, and suggest that you should get a server that you manage. Depending on circumstances, you can agree on a physical server, an upgrade to you workstation / laptop to make it usable as a server, or even a server instance which is completely external to your institution, like Amazon AWS.

If your supervisor insists that you must use the existing IT infrastructure, send your support requests to them the next day after contacting IT. Don't wait for two weeks. Either helping you with these requests is not much of a burden, or your supervisor will grow tired of this and do something about it.

my.back had a good answer, and it sounds like this may be the way to go when working through a bureaucracy where some of the solutions which involve some variation of "use your own hardware" just aren't practical. To add to this, I've found the following technique useful when dealing with a department or person who is willing to help, but does things on their own time.

1. CC your supervisor on every request. This gives your supervisor a chance to give you feedback if you request something that you might not have realized was not necessarily what you need, or should be asking, but also lacking a response from your supervisor, it let's the person doing the thing that needs to be done know that your supervisor is aware of the request. (make sure you follow the advice given by my.back when making this initial request as far as why you need it, and when you need it)


2. When you don't get a response within a reasonable amount of time, send the request again, but make sure you that you put in the request itself "Second Request", making sure to again cc your supervisor on the request. This lets them know that you still do need this thing to be done, it tends to have an effect of increasing the urgency of the IT professional for your task. Repeat as necessary, making sure to put your request number in the request each time.

In my experience a second request is generally all that is needed when using this technique unless the department is just completely swamped. The tricky part is to figure out what time frame is reasonable to complete such a request, and since organizations differ, it's not one that can be answered here. I would suggest getting to know the folks who are completing your task, so that you can get an idea of what they go through, and so they can see you aren't just asking for ridiculous things and just being demanding all the time, because sometimes it's hard to see the world through other people's eyes without some context.

A simple solution, just always make the requests through your promotor. Maybe explain to them the pattern you have noticed if they ask why you are going through them consistently.

Alternatively maybe they are doing something different, ask them how they get the IT department to resolve the issues quickly.