Increasingly, information workers are tasked with translating between the business and technology teams. If you were brought on as a Business Analyst, your role is likely to help your organization both streamline business processes and also automate -- which will include a great deal of ownership of the company's SharePoint environment. And if your company is like the vast majority of organizations out there, as you begin to review critical systems and processes and get to know the broader team, you'll probably notice a general lack of accountability around these activities, resulting in adoption and engagement issues with the platform.
I often tell audiences about one of my favorite blog post images of all time -- The Suck Threshold, created by Kathy Sierra on the now defunct (but still fantastic and very relevant) Creating Passionate Users blog. The entire idea behind the post is that the longer you take to deliver what end users need, the less likely they'll accept what you deliver….even if you eventually give them exactly what they've asked for. I view this as a key aspect of the role of a BA: streamlining the IT team's ability to assess what the end users want, and whether what is being delivered is meeting customer expectations or business goals.
If you're spending an inordinate amount of time documenting systems and processes, but very little time working with stakeholders across various divisions to find ways to improve the business, then you're doing it wrong.
The Business Analyst is one of the most underappreciated roles in IT, but if well utilized, this person can be one of the most critical functions in your organization. If you've ever sat through one of my presentations, you'll hear me say that every new project begins as a BA activity. You're capturing requirements to ensuring compliance and regulatory standards are being met, and working closely with engineering to ensure that what is being delivered is correct and will meet stakeholder expectations.
To accomplish these tasks, regardless of your title, you need to at the very least think more like a BA. In simplest terms, the role is centered around the continual effort to build a shared understanding of what is to be delivered, how it is to be accomplished, and how the end result will benefit the business. Your job is to make the connection between "requirements" and "actionable plan."
The BA function is not a glorified note-taker, but a senior planning and strategic role. You are an enabler of success. You help your team to capture and organize discrete activities, content, and knowledge from across the organization. You then identify insights, patterns, and actionable strategies from these artifacts.
If you haven't properly defined the problem, you're not going to build the right solution, plain and simple. We need more people thinking like a BA. If we did, our systems would suck a whole lot less.