I am wondering how many people, after reading that title and my biography, think that I am going to suggest that business analysts should run the business. If you think that is the path that I will take here, you will be sadly disappointed. The Business Analyst’s task is to identify the business problem and get the group of involved stakeholders to collaborate on the solution to that problem. The business analyst is rarely the owner of the solution.
First let me give you the perspective that I come from. The early part of my career I was a developer
and transitioned my career to 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, so I have been in many organizations
and see 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 that I have seen,
business analysts report to the Information Technology side of the house. However, I have been in organizations where
they reported to the business side of the house, 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 that 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 project to lend their
business knowledge and collaborate on the solution that best solves the
business need. 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 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 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
the optimal for business success?
Business Analyst
report 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
report to the Business Organization
In this structure the “Us vs. Them” mindset works in the
opposite direction; where the technical team sees you 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 addition 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; and it is
the business analyst’s neck that is on the line. The risk in this structure is that there is
not a business analyst tightly coupled with the technical team to help drive to
the best solution to solve the
business need.
Business Analyst
report to 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 there 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, he/she is seen as an
outsider from both sides of the team.
This can make it harder to have your opinions heard, get your
recommendations accepted, and drive to consensus toward the end goal. 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
I have seen on rare occasion where a company has gone to the
lengths of having business analysts on the information technology side and
throughout the business units of the organization. However, I have seen this structure work to
great efficiency. 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 as the project
initiates from that enterprise business analyst to the technical analyst who
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 here is that the technical team must
remember that the business stakeholders’ main duties do not lie with the
technical project, as theirs do. When, at times, 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; and 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.
