Internal Expectations

I've talked in the past about expectation setting with your users and how that is a good thing.  Internal to ITM, however, we have areas that provide support to other areas and there are expectations in this area as well.

Recently I had the privilege of being Yvonne's backup with regard to database administration work.  Most of it has been in the area of DeCo requests and the expectation of the end users has been, well, stunning, to say the least.  While some people did not seem to have a specific timeline in mind with regard to when the data fix needed to be done, other people, heck even the same people but for a different request, seem to have the expectation that if thirty minutes had passed since the request had been submitted then the request should be completed!!!

Is this reasonable?  Well, whether or not I think it is reasonable, it is what the end users are expecting because that is the level of service that Yvonne has been providing.  This makes it very difficult for anyone trying to even temporarily fill in for Yvonne as the odds are that this person is not trying to do Yvonne's job, just cover for her, which means that they still have another job that they have to do.  Unfortunately there is no simple solution to this as the expectations have been set and trying to claw them back now just isn't going to work.  In the long term we are looking at a solution that will allow for more self service in terms of data fixes while still maintaining the high level of auditability.  (Potentially higher, but if you want self serve then you will have to live with it.  :-) )

Conversely, however, there is an expectation on part of the DBA - OK, really just me in Yvonne's stead - that the SQL submitted for running actually, well, runs successfully!!!!I  If you submit a piece of SQL to be run as a data fix, and that SQL does not run successfully, do not expect the DBA to fix it for you.  Instead, what I am advocating to Yvonne, and what I will be following while in her place, is that if the SQL fails, immediately stop the deployment and reject the deployment request.  I mean, if we were implementing an application and the installation package failed, we would notify the coordinator and say fix it.  Why should we do something different with SQL than with an application?