I’m writing this post as part of the T-SQL Tuesday #105. TSQL Tuesday is a monthly blog party on the second Tuesday of each month, and anybody can participate, the archive of previous topics and postings is at http://tsqltuesday.azurewebsites.net/ .
This month’s topic is about running up against brick walls and how to deal with them. Everybody gets them, they can be incredibly frustrating to deal with, and they bring out the best and worst in all of us.
The thing about brick walls is, you can plough through head on, climb over them or work round them. Brick walls help you develop innovation, increase your knowledge, free your creative side, build trust and team working skills because, hey, these problems are hard to solve by yourself.
One example I remember from my contract working days arose out of the blue on a project that was otherwise going smoothly. As usual, the difficulty came to my attention on a Friday afternoon.
A system that was designed by a third party to pay contractors, and which had just recently been commissioned had a serious glitch. On the first run, the contractors, who were paid a piece rate for work that they did, were all due to be paid in full the following Tuesday. This was despite the fact that some had not done any work for the company in that period. Not only had the system failed, and threatened to pay everybody, the process for checking that work had been done was not followed, nor was the payment run checked before payment approval.
This represented a very serious and complicated problem. Third party systems failure, poor testing, an incorrect process and insufficient checks and balances caused a problem without an immediately obvious solution. A brick wall, with a ticking time bomb on the other side.
Communicate the Problem
The first thing to do was to make sure that the supervisor and the director in charge of the payments were aware of the potential business impact of the difficulty, and the potential for delays to the wider programme of work.
Gathering data and information to evidence the problem allowed the business time to prepare for the bad news that was coming. Working against the clock, writing clear SQL queries allowed an initial assessment of size of the problem, and allowed the board to assess business impacts and their implication. Observation and communication bought all parties time to come up with a plan.
Get a Plan together
Whilst the business was discussing a politically acceptable solution to the problem, the technical team was tasked with working out how to develop and implement the code that would allow the planned overpayments to be retained, and work out subsequent payment runs correctly.
The legal team and the business had cancelled the payment run within the acceptable terms of the agreement, but we were still no closer to an acceptable way of re-calculating what was due to be paid out.
The third party were not able or willing to turn around a solution in sufficient time, so it fell to the in-house team to code a stored procedure that would cross check the work completed with the proposed payments to make an adjustment to the file before re-approval.
At the early stage all team members were included, to brainstorm and propose solutions. By working co-operatively a wide field of ‘possibles’ was drawn up, from which the most probable working solution was selected.
Once selected, considerable time was spent referring to books online, code forums, blogs and examples. It is amazing how many other people have been in the same position, or done the hard miles for you, even late on a Saturday night.
The key to the solution was found by inserting a SQL agent job between the third party application run, with a task to check the proposed file against a business verified spreadsheet of work completed, and a new manual input step was needed to approve the payments.
It was a working solution, not perfect or particularly elegant, but it met the requirements. The race against time to test and implement was now on.
Fuel the Machine
As well as having to arrange weekend working, it was important to reward those who gave up time to help out and come in. As any SQL Server professional knows already, pizza and cakes are an essential pre-requisite to problem solving, and the wide screen TV was re-purposed to watch the test match cricket, as missing this had threatened to be the deal breaker!
Knowing, understanding and treating others well is vital to oiling the wheels of a stressful situation.
By the time Monday came around, a very tired database development team had unit tested a workable solution to present to the business. The business analysts and board members were relieved to sign off the solution and the process workarounds, and the payment run was approved for later in the week.
The wall had been broken down, the time bomb successfully defused, and we could return to a near normal work week.
It was a potentially difficult brick wall situation that demanded a great deal of a team that did not cause the problem, but who responded positively to an obstacle thrown in front of them. They responded with calm, logical thinking and combined this with cross team working to ensure the solution was acceptable.
That brick walls spring up in front of us is an inevitable part of everybody’s working life. The way we choose to respond to these challenges the way we think, and allows us to grow as professionals. This experience was part of what prompted me to study for a PhD in Cybersecurity Management. If you are really enthusiastic about brick walls, postgraduate research is the ideal job for you!