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 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. But what about the role of the Business Analyst in SharePoint?
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 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!
