T-SQL Tuesday #13 – What the Business says is not what the Business wants

Steve Jones, editor at large of SQL Server Central is this month hosting the latest T-SQL Tuesday and luckily I have managed to be organized enough to make a note in my Calendar so that I may finally contribute. A big thank you also goes to Steve who gave plenty of notice for this iteration of T-SQL Tuesday. If you don’t already know, the idea behind T-SQL Tuesday was created by Adam Machanic to improve the sharing of ideas and co-operation between SQL Server Professionals and if you would like to know more then you should check out Adam’s first ever post or track back to Steve’s post by clicking on the T-SQL Tuesday graphic above.

Beware of Business solutions to Technical problems

The official topic for this month is “What issues have you had in interacting with the business to get your job done”, and I whilst I think that the experience of most DBAs talking to the Business will usually have resulted in lots of hair pulling (perhaps I am wrong), it is probably quite important to point out that when you are communicating to them this is YOUR ideal opportunity to get a particular message across. For instance if you are discussing the potential implementation of a new system that is going to cause your backup window severe lack of available time to complete, then now is your time to think about your current capacity and plan ahead for the future. I would suggest that if you cannot cope with extra unexpected load now, then you are failing to allow for future growth and communicate this across to the relevant people. I believe it is always important to provide the Business with an alternative solution rather than simply feeding back to them that a proposed implementation will not work. More importantly I think that it is necessary to give a detailed projection of what value your solution will add to the Business and why. The key word here is value and needs to be communicated from a Business perspective so that it can be understood, value is one concept the Business is very familiar with.

The bottom line is that if you fail to convince the Business from a technical front of the rights and wrongs of a new system, you may well have their solution enforced on you. Obviously their solution may have been designed by somebody technical -whether it be a third party supplier or even someone internally, but it will still be their solution.

Be careful in your approach

Something I have just mentioned is also very important to remember, the concept of ownership of a solution. Remember that if you are going to disapprove of a request or proposal from the Business it is important to keep in mind that this requirement and possible solution will be loosely owned by somebody (or even many people) and you will be more influential in your negotiation if you are mindful of this and tactful in your approach.

Another point I would like to make (which is I believe one of the things Steve has already pointed out) is that a requirement or proposal may have been arrived at due to a limited amount of knowledge of what is possible. It is entirely feasible that the Business may have changed their expectations and requirements in order to accommodate what they believe is deliverable. This may result in a request that is fundamentally wrong. Always try to understand what key requirement is at the root of their request in order for you to separate the wheat from the chaff. It is possible that a very expensive and complicated upgrade to a system could be avoided simply be asking the right questions and being able to provide and deliver functionality that may already be present (or possible) in your existing system .

Have the courage to speak up

So how do you get to the stage where you are discussing your concerns with the Business? One sure fire way to avoid this scenario is to blindly follow instruction irrespective of any concern you might have and this is a recipe for disaster. I cannot tell you the number of times I have witnessed IT professionals (and I’m using that term loosely here guys) complaining about something they have been asked to do which in their opinion is fundamentally wrong or flawed and yet will not vocalize their concerns to someone who can action change or prevent it happening altogether (should good reason exist) for fear of coming across as a “trouble maker”. If you do not vocalize your concerns and blindly perform the action then you are complicit to any problems that may arise from doing so. Ask yourself this “what actions would cause you to speak up? If your line manager asked you to drop your companies internal Accounting database, would you just do it?”. There is obviously a skill to raising concerns in a constructive manner and I guess it can sometimes be quite hard to do – I certainly don’t pretend I’m an authority on this, but I can at least appreciate when I could have done it better. I would far rather speak up and flag my concerns and get it wrong from time to time than be quiet and get it wrong ALL of the time.

The only certainty is: change is constant

I remember one particular problem related to a data refresh that had started to fail on a regular basis and was taking longer and longer to succeed. I had initially created the transfer in response to a very basic Business request which was only going to be used by a single person for reporting and the transfer was deemed as “unimportant” and therefore if the job failed overnight it could simply wait to attempt a run the next day. I had designed the job to use a mixture of T-SQL and (it was a very early adoption of) SSIS and it worked very very well for a matter of years.

Something changed though over the years, the job started to fail more frequently and the Business surprisingly started to get more and more irate every time it failed. During important periods support staff were assigned the task of monitoring this job throughout the night (at no cost to the Business!) and things continued this way for a little while longer. My protests regarding the whole purpose of this job, why it had been put there and the original agreement were conveniently ignored since what was deemed more important was accommodating and supporting the Business requirement rather than understanding why this job had become so important and the focus for much frustration.

Finally, a crunch meeting with the Business was arranged and I and some senior people from the Business and a few others who were involved in the Business Processes got around a table and talked.

One thing that became blatantly apparent to me was that the Business did not understand that this job was and always had been “non-critical”. Another thing they had not appreciated was that even though they were being given the impression that we were providing a 24×7 service supporting this job by individuals of varying seniority, I had to make it clear to them that this wasn’t actually the case and that without a formalized service level agreement this could never be the case. I also explained that due to the length of time that the job was taking to complete (by this time a grand total of 9 hours), should any failure occur during the transfer and assuming the failure was successfully picked up by someone immediately then the job would still not have time to complete for the window in which they wished the dataset to be available.

One very surprising and alarming thing that came out of this discussion from the other direction was that my humble transfer had now become the center of a huge SSAS reporting process involving other third party systems. This is something that happened over a long time and occurred in part due to the complex and diverse release mechanisms that existed in my place of work. I can assure you that I could say more about this and why it shouldn’t have happened, but that would be a different T-SQL Tuesday discussion!

I could also talk a very long time about what happened next, but I have already rambled for far too long. I really want to conclude by saying that the net result of the discussion was that the Business agreed to a short term and medium term strategy for the transfer. Namely I would make short term improvements straight away so that at very least we could try to get the job to resume from key stages in its execution should it fail, secondly on failure the previous days dataset would remain intact allowing the dependent Business analytics to still function from it. These changes alone overcame nearly all of the short term problems but I also ensured that the Business understood that we would make best efforts in the short term to ensure that the job succeeded but a rewrite was necessary and a formalized SLA stating exactly what their expectations and our deliverables were was required. The medium term strategy involved flagging the job as part of a Business critical process and it was assigned to a team of people allocated a number of man hours to improve the transfer where possible and putting it into a formalized support strategy.

Most of the time in any company where the Business and I.T. departments are experiencing difficulties, they are normally occurring not because of any unsolvable problems but usually because of a lack of communication from both sides. Over a very long period of time as demonstrated by my example this can result in a very exaggerated misunderstanding and lack of value in the I.T. deliverables on many levels. If this sounds like your organization don’t delay and get talking!

1 thought on “T-SQL Tuesday #13 – What the Business says is not what the Business wants

  1. Pingback: T-SQL Tuesday #13 Roundup « Voice of the DBA

Comments are closed.