First let me give you some background. I was a developer in the early part of my career and transitioned to a business analyst as the discipline was forming in many companies. The profession of business analysis continues to mature. I have 15 years of consulting experience and have been in many organizations. I have seen how they operate and utilize their business analysts, project managers, architects, developers and quality assurance teams on software development projects to help the business operate more smoothly. In most organizations where I have been, business analysts report to the information technology side of the house. However, I have been in organizations where they reported to the business side or reported to a separate entity within the organization (such as an enterprise PMO), and had business analysts on the business and technical sides of the house. So this article will come from a heavy IT perspective with empathy to the business stakeholder.
One thing I have noticed quite often is that business analysts, project managers and the entire technical team seem to forget that the main duty of business stakeholders is to run the business. You will hear technical team members complain about not being able to get needed time with a key business stakeholder to keep the project going, or that project business sponsors are disengaged. Whereas, the main duty of the technical team is to the project and delivering the solution of that project; let’s remember that the business stakeholder has a different priority. Business stakeholders, in particular subject matter experts (SMEs), are needed on projects to lend their business knowledge and collaborate on a solution. If the technical team was left to design the solution in a silo with no business input, the risk becomes that the solution delivered will be rejected by the business users. The technical team wasted their time delivering a solution that will never be utilized because there was no input, buy-in or ownership from the business. This doesn’t happen in every case, but it would happen at even more alarming rates if the technical team designed the solution without business input. At the same time you can’t get all the business stakeholders as fully dedicated to the project as the technical team is because there would be nobody left to run the business.
This is one of the reasons that the agile approach to software development has taken hold in many companies. By placing one business stakeholder, the product owner, completely dedicated to the IT project, it leaves business management in the engine room to run the business. It is important to the success of the solution that this project owner represents the desires of the business stakeholders well.
So let’s take a look at some case studies in the different organizational structures and the business analyst role in each. Which one is in use in your company? Is it optimal for business success?
Business Analyst reports to Information Technology In this structure the business analyst is viewed as a member of the technical team. From the business stakeholders’ perspective it is difficult to remove the “Us vs. Them” mindset that exists in many organizations because you are part of “Them”. In one organization I was at they talked about a business analyst that literally camped outside a key business stakeholder’s office door all day and still could not get their attention. However, in many organizations this structure works because the business analyst, just like the project manager, is seen as a key member of the project team that helps drive to the needed solution.
Business Analyst reports to the Business Organization
In this structure the “Us vs. Them” mindset works in the opposite direction; where the technical team sees the business analyst as a business stakeholder. I have seen this in two different scenarios; 1) where the business analyst is used as a proxy for other business stakeholders, and 2) where the business analyst is joined on project teams with additional business stakeholders. The perceived value of this structure is to reduce or remove the business stakeholders’ time involvement on software development projects leaving more time to run the business. In the scenario where the business analyst is a proxy for other business stakeholders, the business analyst better be tightly coupled with the business management of the line(s) of business that they are representing or it could spell disaster for the solution delivered. It is the business analyst’s neck that is on the line. The risk in this structure is that the business analyst is not tightly coupled with the technical team to help drive to the best solution to solve the business need.
Business Analyst reports to a Separate Entity within the Organization
This may be the best structure to remove the “Us vs. Them” mindset, as the business analyst is neither “Us” nor “Them”. The business analyst is often seen as a consultant to assist the project team, both business and technical, to come up with the best solution to solve the business problem. The outcome of this structure is often that even though the business analyst is an internal employee, they are seen as an outsider from both sides of the team. This can make it harder to have opinions heard, get recommendations accepted, and drive to consensus. In the situation where it is a PMO that the business analyst reports to, the project manager is likely in the same boat. The side effect of this structure is that it does not reduce the time commitment of the business stakeholders to the project, therefore leaves the question…Who’s Running the Business?
Business Analysts on the Technical Team and Business Analysts in the Business Organization
On rare occasions I witnessed a company going so far as having business analysts on the information technology side and on the business units of the organization. I have seen this structure work efficiently. The ‘business’ business analyst can do the enterprise analysis work to help business management identify business need, develop the business case for a solution to that need, and work the proposal through the project approval process to become an official project. Then there can be a hand-off from the enterprise business analyst to the technical analyst as the project initiates.The technical analyst will see the project through to deliver the expected value to the business. The enterprise business analyst can also serve as the business SME throughout the project to reduce the time commitment of other business stakeholders, thereby leaving someone at the helm to run the business.
So the lessons learned are that the technical team must remember that the business stakeholders’ main duties do not lie with the technical project, as theirs do. When it is difficult to get on the calendars of your business stakeholders, remember they are doing their job. Likewise, as a business stakeholder being asked to participate in a software development project, remember that without your proper level of engagement and dedication to the project the solution delivered may not be the best solution to deliver the greatest value to the organization.Your business team may be stuck with that solution for some time. There is no greater example of the need to collaborate to arrive at the best solution for all concerned.
Don't forget to leave your comments below.