Why it's hard to say no
Right now, we're going through a change in OIT. We're working to streamline everything that we do, so OIT can provide more and better services to our customers across campus. With the current economic and budget situation at the University, we can expect more departments to look to OIT for help in providing services.
But a critical component to ensuring we can meet those needs is to standardize on services. Nothing hurts us more than when someone in OIT, especially part of our own teams, makes a special "one-off" arrangement with a customer to deliver some service. Because when we do that, it sets a new standard that all of OIT needs to deliver on, or we risk other customers asking "why can't you do that for me?" - or worse, "you just said 'no' to me, but you're doing it for that other department."
I know it's hard for us to say no - it's sometimes hard for me, too. As IT people, we often measure our productivity by the things we've done or built. When we go home at night, it may not seem like we've done "work" if all we did was respond to server issues, or write a design document. (Yet, in an enterprise support role, we need to recognize the documentation of the work is just as important as the work itself.) As a result, when a customer contacts you and asks if you can work on some special "one-off" project, there's a tendency to say "yes" so that, at the end of the day, you can reference something as "I did that."
But it's important to realize that doing all these "one-off" projects is hurting OIT in the long run. The key behind simplify, standardize, automate is to run all our systems more or less the same. We manage over 1,100 servers across all of OIT - almost all of them supported directly through Operations & Infrastructure. That number will only grow; in a year, we may manage more than 2,000 systems. If those systems have the same or similar system setup - systems administration, databases, production automation, storage, etc. - and if we have the same expectations for customer roles vs. OIT roles, we will be able to effectively manage those servers. If they all have different configurations - different applications, different ways to manage storage, different expectations for the customer & OIT - then we will fail in meeting our mission to the University.
I'm asking for your help. If a customer asks you for a special configuration, or to take on an "application" task for them, consider what that means to the rest of your team, and to OIT as a whole. Avoid the temptation to say "yes" because you think that's what the customer wants to hear. Remember that every "one-off" project you commit to is another variation in how we support the University.