The BA-Effect on SharePoint Change Management

Moving from a product organization back into consulting has reminded me of one very important truth: every SharePoint project begins as a Business Analyst activity. I’ve written on the topic a number of times, and advised every company I’ve ever worked with on the subject, and yet when it comes to planning for a SharePoint deployment, whether on premises or in the cloud, people still have this idea that they can simply roll out the default version of the platform, and somehow, miraculously, people will figure it out and the business will instantly achieve value.

Spend an hour, or a day, with a senior Business Analyst and you will get value, because they will help you to:

• Understand what your business actually does (the workloads) and how it operates (your business processes)
• Begin to identify gaps in processes, and to document opportunities for improvements and automation
• Generate your technical requirements, and prioritize them based on impact, cost, and time to implement

That’s right — a good BA can help you with all of that. And if you keep them around a bit longer, they can even help you to implement the new solutions, document what was delivered and why, help you figure out how to measure the impacts of what was delivered and what to monitor for future changes, and how to make all of that a repeatable process. Because at the center of a BA’s role is to make sure your change management processes are healthy and running. What would software development be without change management? The two are inseparable. And whether you have SharePoint on premises and heavily customized, or partake of the packaged goodness that is Office 365 with minimal customizations (because minimal is all you can do with O365), you need solid change management. To successfully develop and deliver your business solutions, you must put in place the tools and processes and knowledge required to successfully perform change management. Period.

Remember: A BA is not a PM, and a PM is definitely not a BA. In my experience, there seems to be a lot of confusion between the BA function and the project management function. Think of it this way: BAs are all about planning and business alignment, while PMs are about execution. Yes, I realize that in YOUR company there is one role, and they handle all of this. But there’s a good reason to separate these roles, not just volume of work and the size of your company, which may force a division of labor. It’s also because — and this is, again, in my experience — these are very different skill sets. And it is a BA function to operate your change management model, helping to define the tactical actions that your PMs need to execute.

Change management is all about managing the increasing complexity of a project, plain and simple. Your team must understand how to manage the complexities of an ever growing, always expanding list of customer demands, enhancements, and features. Sounds like a BA role to me.

Increasingly, SharePoint has become a platform for change management. To successfully build and deploy a change management platform, you need to understand how it fits into your company. What are you current processes? How strictly are they adhered to?  Who needs access to this information, and where are they located? You may all be centrally located in one office now, but what are your company’s plans for growth? The actors (roles) will tell who will use your change management system, and help you to model out the flow of communication necessary for a successful system.

Yes, with automation and a powerful feature set, you can do much more with fewer people in SharePoint. 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.

Tackling something as huge and culturally impactful as change management is no small effort. Many companies take on large process or standards initiatives like this without having a clear understanding of how much time and effort these things will take to fully implement – or how long it will take to reap the benefits that these initiatives can provide. Many times these efforts fall short because there isn’t a clearly defined business owner or executive sponsor. Get one (or two). Don’t start without them. Without someone at the helm of the ship, driving standards for implementation, and how closely the new change management system adheres to company standards, most of these implementations fail.

Is this a post on the Business Analyst role? Or is it a rant on the need for Change Management? Well, both, really. The key is understanding what all of this looks like in your own organization (your existing BA, PM, and CM definitions and activities), being clear on your business goals and expected results (what does this all look like if we are successful?), identifying an owner (is your CEO on board? If so, have her/him participate in the launch), and working with your various stakeholders so that everyone has visibility into what is being built and deployed and their role in the change management process. There’s nothing out-of-the-box about change management. It’s a knock-down, dragged-out and dirty effort to get up and running, but the organizations who do it well have a HUGE competitive advantage because it helps them to see the road ahead more clearly, and respond more quickly when change does occur.