Business Analyst role in development process

Question

I work as a business analyst and I currently oversee much of the development efforts of an internal project. I'm responsible for the requirements, specs, and overall testing. I work closely with the developers (onshore and offshore).

The offshore team produces all of the reports. Version 1.0 had a 9 month development cycle and I had about 4-5 months to test all the reports. There was the usual back and forth to get the implementation right.

Version 2.0 had a much shorter development cycle (3 months). I received the first version of the reports about 3 weeks ago and noticed a lot of things wrong with it. Many of the requirements were wrong and the performance of the queries was horrendous at 5x - 6x longer than it should have been.

The onshore lead developer was out and did not supervise the offshore development team in generating the reports.

Management knew about the performance issues and I also told them I was trying to find a way to improve performance; they did not explicitly approve of sending test queries, but they were also not concerned with the fact I was doing that. I took a look at the SQL in the reports and was able to improve performance greatly (by a factor of 6x) which is acceptable for this version.

I sent the updated queries as guidelines to the offshore team and told them they should look at doing X instead of Y to improve performance and also to fix some specific logic issues.

I then spoke to my managers about this because it doesn't feel right that I was developing SQL queries, but given our time crunch I saw no other way. We were able to fix the issue quite fast which I'm happy with.

Current situation: the onshore managers aren't too pleased that the offshore team did not code for performance. I know there are some things I could have done better throughout this process and I do not in any way consider myself a programmer.

My question is, if an offshore team that works apart from the onshore project resources fails to deliver an acceptable release, is it appropriate to clean up their work to meet a deadline? What kind of problems could this create in the future?

Update: So far management is upset with the offshore team, but have not "reprimanded" me in any way, so I'm not sure in their eyes if what I did was wrong, but I think their main source of frustration was the offshore team was not able to come up with a solution and I was, especially since this sort of performance issue had come up in the past. I am not defending my actions, but I want to give context so that the picture is a little clearer. I accepted the answer that most criticizes my actions I agree it's not something that should be done by someone in my position.

Answer 1

No, it's not acceptable to clean up their work.
There are a number of reasons as to why.

1) v2.0 had a development cycle that was 1/3rd of the original cycle, and the report validation period was shrunk from 50% of the cycle to less than 30% of the cycle.
It's okay to contract a development cycle, but unless the quantity of reports was significantly smaller, the validation window should have remained proportionate. Since the reports were significantly more complex, it would not be unreasonable to expect continuous validation of the reports throughout the entire dev cycle.

2) By taking things into your own hands, you broke the chain of command and you failed to notify management in a timely fashion of the significant problems with the report. Those performance and requirements issues represented risks to meeting the schedule, and that's something the management team has a right to be aware of. While you think you know what would have been done to resolve the matter, you don't know for certain since it wasn't your decision to make. Management's role is to weigh the pros / cons of one path vs. the other and to accept responsibility for the consequences. You short-circuited that process by presuming the answer and assuming that what the onshore team was working on was a higher priority. For all you know, there may have been someone with capacity to fix the issue or a different solution could have been found.

3) You also broke out of your Area of Responsibility. Normally, this is not an issue in my book as I'm in favor of everyone contributing where they can and growing their skills. However, you most likely were not the most skilled person to resolve the matter. By taking this on without notifying others, you denied the opportunity to get the issue resolved more quickly. It's possible that the offshore team could have quickly fixed the issues once they had been notified of them. What would the onshore team lead have said to you had he not been on vacation and knew what you were doing?

Complicating all of this is the invetiable tension between onshore and offshore teams. You inadvertently walked straight into a hornet's nest of political issues.

The right thing would have been to notify your management immediately of the problem and then offer that you knew SQL and would be happy to tackle the challenge. That puts another option on the plate for resolving the matter, but still allows management to pick the best approach for fixing the issue.

Answer 2

It is always appropriate to fix what is broken, and to get things to work as close to the spec as possible as close to the deadline as possible.

It is also appropriate for you to document all that you had to fix in order to make the stuff work. It is important to know if your offshore resources are delivering acceptable code that fits your specification. If they are not, it is appropriate to send them the documentation of the differences between your specifications (particularly re: performance) and to demonstrate that what they delivered was NOT what is in the spec. This can be used by your managers to negotiate future work, or to limit what you pay for what you got.

Answer 3

When many people are involved in a task, roles must be clearly defined and measures must be set in place. If the code you get is bad, you tell them that it did not meet the expected performance standards set. If no performance standards set, then you could point out that it can be made better, but I don't think you should change it yourself. Personally, I would not accept someone to change my code without discussing it with me first.

When different organizations are involved boundaries must not be crossed without careful considerations because people (and mostly managers) don't like this. After all this is what managers are for (or at least part of the reason).

This is not to say to let the opportunity of enhancement go away, instead make the management decide the approach if it is not already set.

It is very common to have offshore teams do strange things from what you consider acceptable because the nature of the contracts these companies sometimes take as well as many other reasons.

Answer 4

The number one rule of software development is to make it work, everything else is secondary. If you are running up on a deadline and having problems they need to get fixed now. You will have plenty of time later to dissect the problem and figure out who failed to do what or what needs to be improved in the process for the future. If it becomes a common occurrence that you constantly have to fix problems you shouldn't have to, then that is a different issue and that shows a lack of management doing their job to identify and fix problems with the process.