One of the most underappreciated (in my estimation) roles in IT is
the Business Analyst, and yet it should be one of the most critical
functions in your organization. Within many companies, a BA is
viewed as being junior to project managers, with all BA's aspiring
to the PM role. This should not be the case -- the BA and PM are
two very different roles, and at some companies, the BA is a much
more senior function. I've spent a good portion of my career
managing PM and BA teams, spinning up project management
organizations (PMOs), and working with both as an outside
consultant. The roles are distinct, the skill sets are
different.
In presentations on migration and planning best practices for
SharePoint, I often remark that every new SharePoint project begins
as a Business Analyst activity. What is the role of the Business
Analyst, and how does it fit into a successful SharePoint strategy?
While there are different kinds of Business Analysts (Requirements
Analyst, Business Process Analyst, Organizational Analyst, IT
Business Analyst, Systems Analyst, Reporting Analyst, etc) the core
functions of this role remain fairly consistent.
The role of the business analyst is to:
Understand what the business does, how it operates
Examine existing business processes
Identify gaps in processes, opportunities for improvements and
automation
Capture requirements, create mockups
Generate technical requirements, proof of concept solutions
Help implement the new processes, features and tools
Document improvements, measure, repeat the process
Now extend this understanding to how you staff your SharePoint
deployment. Experience has shown that few organizations properly
staff their administration team, much less provide the SharePoint
team with a dedicated -- or even a part-time -- Business Analyst
resource. SharePoint is generally grossly understaffed.
[As an example, my good friend Virgil Carroll (@vcmonkey) from High
Monkey Consulting was presenting in the UK and asked the audience
whether anyone was running SAP in a large company, and how many
people managed it. One gentlemen raised his hand, and stated that
his company of 80,000 employees used SAP with a staff of 40. Virgil
then asked whether SharePoint was also being used company-wide, and
how many people maintained it. The man shared that yes, SharePoint
was company-wide, but with only a staff of 4 running it, two of
them part-time]
Yes, with automation and a powerful feature set, you can do much
more with fewer people in SharePoint. However, I think Microsoft's
marketing was a bit too good in this respect. Proper staffing is
critical to successful deployment and ongoing maintenance of
SharePoint. Your BA function may be filled by the same
person/people that administer the platform, but it is important to
understand -- and drive accountability -- for these activities. I
would venture that a lack of understanding of key business
processes, and the gaps between what SharePoint provides
out-of-the-box and what it is capable of doing is at the heart of
most end user adoption issues.
If you haven't properly defined the problem, you're not going to
build the right solution, plain and simple. And that's why the
Business Analyst function is so critical to SharePoint.

One of the most underappreciated (in my estimation) roles in IT
is the Business Analyst, and yet itshould be one of the most
critical functions in your organization. Within many companies, a
BA is viewed as being junior to project managers, with all BA's
aspiring to the PM role. This should not be the case -- the BA and
PM are two very different roles, and at some companies, the BA is a
much more senior function. I've spent a good portion of my career
managing PM and BA teams, spinning up project management
organizations (PMOs), and working with both as an outside
consultant. The roles are distinct, the skill sets are
different.
In presentations on migration and planning best practices for
SharePoint, I often remark that every new SharePoint project begins
as a Business Analyst activity. What is the role of the Business
Analyst, and how does it fit into a successful SharePoint strategy?
While there are different kinds of Business Analysts (Requirements
Analyst, Business Process Analyst, Organizational Analyst, IT
Business Analyst, Systems Analyst, Reporting Analyst, etc) the core
functions of this role remain fairly consistent.
The role of the business analyst is to
- Understand what the business does, how it
operates
- Examine existing business
processes
- Identify gaps in processes, opportunities for
improvements and automation
- Capture requirements, create mockups
- Generate technical requirements, proof of concept
solutions
- Help implement the new processes, features and tools
- Document improvements, measure, repeat the process
Now extend this understanding to how you staff your SharePoint
deployment. Experience has shown that few organizations properly
staff their administration team, much less provide the SharePoint
team with a dedicated -- or even a part-time -- Business Analyst
resource. SharePoint is generally grossly understaffed.
[As an example, my good friend Virgil Carroll (@vcmonkey) from High Monkey Consulting was
presenting in the UK and asked the audience whether anyone was
running SAP in a large company, and how many people managed it. One
gentlemen raised his hand, and stated that his company of 80,000
employees used SAP with a staff of 40. Virgil then asked whether
SharePoint was also being used company-wide, and how many people
maintained it. The man shared that yes, SharePoint was
company-wide, but with only a staff of 4 running it, two of them
part-time]
Yes, with automation and a powerful feature set, you can do much
more with fewer people in SharePoint. However, I think Microsoft's
marketing was a bit too good in this respect. Proper staffing is
critical to successful deployment and ongoing maintenance of
SharePoint. Your BA function may be filled by the same
person/people that administer the platform, but it is important to
understand -- and drive accountability -- for these activities. I
would venture that a lack of understanding of key business
processes, and the gaps between what SharePoint provides
out-of-the-box and what it is capable of doing is at the heart of
most end user adoption issues.
If you haven't properly defined the problem, you're not going to
build the right solution, plain and simple. And that's why the
Business Analyst function is so critical to SharePoint.
This article by Neil Christian Buckley, Axceler was
orginally posted on EndUserSharePoint.com
Why not keep up to date with the latest SharePoint content
by joining our community or by
following us on twitter or Facebook!