If you’re a good SharePoint Administrator, this should be your default answer for most requests that you receive. No, I’m not crazy, and yes, I’m serious. Don’t believe me? Let me ask some basic questions:
What is the single most important job of any System Administrator? (Hint: It’s not installing the software.)
Let me ask a different way: What is the one thing that an end users expects of a system more than anything else?
(seriously… think about it…)
The System Administrator for ANY system, including SharePoint, is very simple: Keep the system up, available, and usable, and secure. It doesn’t matter what the system is… end users expect it to be there for them when they need it (and they always need it now). It’s not installing more software, providing TPS reports (yellow only, please), answering phone calls, sending/responding to emails, updating facebook/twitter, or reading Slashdot or XKCD. If you’re the Sys Admin, you have one job… protect the system. In general, this means maintaining existing functionality.
There are two evil, rogue groups of people (joking) that are your arch enemies in your one purpose in life: Business Users (including management), and Developers. Lets compare…
Or, to put it another way:
Trying to increase use while decreasing investment without any change in expectation.
Trying to introduce new system functionality without regard to existing configuration, performance impacts, testing, or architecture.
Trying to maintain existing functionality and performance despite a constantly changing baseline.
You could think of it this way: The business users and developers are constantly trying to do more with less, while the SharePoint Administrator is being held accountable for any negative experiences the end user may experience… regardless of cause. The goals of the business users and developers are fundamentally opposed to those of the SharePoint Administrator.
This also means that a good SharePoint Administrator (or really any system administrator) has one job: SAY NO. At least initially. :)
“I can’t say No” you might be saying. I understand… and you might be right. Saying “No” outright can be a “career-limiting decision”. So, instead of outright "No”, it may be possible to help others come to your own conclusions… though you’ll have to do your homework first. In some instances you may find that “Yes” is really the right answer anyway. As you review what you’re being asked to do or implement, document the answers to the following questions:
What the business understands boils down to one simple statement: Increased Cost ($$$). If you can describe what the financial impact will be to the system and the company for the change being requested, the business can make a better decision about whether to move forward with that change. The business usually views this strictly from the view point of licensing, developer time, or the initial purchase… but in truth, there’s almost always an operational impact to deploying a change. Our job is to quantify that operational impact, in dollars, so that the business can decide whether the new functionality is worth it. If the business decides it is worth it, then you can say yes because you’re going to receive enough funding to compensate for the change. If the business isn’t willing to fund at the level necessary to support the change, then the business is effectively telling you that they don’t want the change, or they are willing to accept a reduction in the level or quality of service. If someone says they are willing to accept the reduction of service, you should point out that you’re going to quantify and advertise the reduction in service to all of the end users. The goal here isn’t to be a jerk… but rather to either set expectations appropriately with the end user community, or to make the acknowledge that they’re not really ok with a reduction in service.
The main point is, if the business is willing to back up their request with funding such that you, the administrator, can meet the current and ongoing expectations of your end users, then by all means, say yes. More often though, when faced with the financial reality of the request being made, many business will simply say “never mind” and move on or find a different way. Occasionally someone else will say yes without factoring all of this in. Look for the person that’s afraid to take a vacation and is constantly complaining about the business making unreasonable requests of them… that would be where the request landed. :P
Well said, Mr. Mullendore! I think one of the insidious challenges here is for people in a dev-ops role where the system administrator is also the developer! Not every business has figured out that these need to be or should be separate roles!
Great post. I'm explaining this a lot as well. A good parallel to draw is that a SharePoint support team is really a service provider.