Building on Jeff's blog post titled Vampires (Programmers) versus Werewolves (Sysadmins)
From my perspective, the whole point of the company is to talk about what we're doing. Getting things done is important, of course, but we have to stop occasionally to write up what we're doing, how we're doing it, and why we're even doing it in the first place -- including all our doubts and misgivings and concerns.
So, what are some questions you ask your software developers when they request a server?
Generally speaking I ask software developers the same question I would ask anyone else: "What are you trying to accomplish here?" and How can I help?.
To break that down a little more and give you some ideas to start you out:
Ideally you should start at the highest of high-level overviews:
What is the purpose of the company?
Next the question that starts to make this relevant to a sysadmin:
How can technology help achieve that purpose? and What technologies will be used?
Now you can start talking about details. The detail questions vary depending on the technology, but common ones are:
What operating system(s) will we need to run? (lots depends on that too)
What additional software beyond the base OS is required?
How reliable does the system have to be? (Uptime & redundancy considerations)
How many users will you have? and other workload-related questions
Then there are the process questions:
How often will we deploy new versions of the software?
How will we get those new versions? (source code to build? pre-built packages? commercial?)
What kind of test suites are available?
How can we monitor the software? (key indicators, checks that can be automated, etc.)
Finally there are the production maintenance questions:
What kind of routine maintenance does the software require? (If the answer to this question isn't "None" you need to determine how much manpower will be needed)
What kind of problems may arise? and How can we resolve them?
Voretaq7's top two bulletpoints are something that, ideally, every person in a company should be considering. The IT people (whether Devs, Sysadmins, Helpdesk, Deskside deployment team, etc) must have some understanding of the first answer, and should be able to talk to each other about how everything they're doing works towards the second question.
That's the high flying overview.
Beyond that, platform requirements (this is a 'both directions' thing - there should be no surprises on either side on deployment day as it should be discussed beforehand). If your app requires .net 4 framework then give me some notice. If there's a reason why the production servers can't be upgraded to .net 4 just yet then you shouldn't hear that for the first time when I'm saying "No, sorry" on deployment day.
You should agree things like uptime requirements, support routes (both directions), app dependencies, test cases for making sure it all works properly.
One thing I want to empathise is the word agree. This should be a three-way dialogue. The sysadmins, devs, the helpdesk (who do need to be involved in this too as they're going to be getting phone calls about this and if the only answer they have to give angry users is "WHAT $foobar app? Those @£$%£$%!!!!'ing devs and sysadmins have been changing stuff and not telling us again" then guess what, you all look bad) all need to agree what is happening before it happens.