Data Requirements Gathering. In this lesson, we'll define data requirements gathering including determining required data, scope and level of detail. The first step of data requirements gathering is often interviewing subject matter experts or SMEs. Depending on the industry and the organization, you may be the SME. Requirements gathering is also about organizing the information into discrete subject areas. Translating technical language into business language and vice versa. Really good data analysts are able to straddle the fence between technical and business. In my humble opinion, the real value-add of analytics often is the ability to understand the technical and the business and build applications and solutions that speak to those two. Requirements gathering is all about ensuring stakeholder involvement. Hopefully as you're interviewing subject matter experts and business owners and key stakeholders, you're building consensus and buy-in for the project at all levels, from the sea level offices to the managers, to the associate. Clear and concise documentation. Many a project has gone wrong because of no documentation and many a project has been saved because of documentation. Requirements gathering in analytics is about working successfully with multidisciplinary teams. That means across the organization, up and down the food chain, inside the organization, vendors outside the organization. It's about hopefully building a holistic, comprehensive understanding and ability to speak to and service the analytics need at that level. Now, as I mentioned before, many a projects have gone wrong because of poorly executed data requirements gathering. First, no clear objectives. This is not uncommon. It's less common these days as analytics has matured at all levels of the organization. In the early days, analytics was a little bit less precise, less objective based. Stakeholders not defined, not understanding who's on the project, who's the owner, who's the contact, who's the decision maker, poor stakeholder communication. Again, depending on the size of the organization or the team, the ability to effectively communicate information, to get information can be a real challenge but it must be done effectively. No defined standards or processes. Again, in the early days of analytics, this was quite common. Now today, organizations that are inclined to standards and processes have adopted them for analytics. Unfortunately, those organizations that are not standards driven or process-driven will most likely implement analytics without standards and processes. As we've learned throughout this course, best-practice of analytics many times, in many cases, are well-served by good processes and standards. Poor business or technical performance. Both of those are mission critical failures. If your business isn't performing or your technical needs are not being managed properly, in today's world, technical performance is business performance. Poor project scoping, not uncommon unfortunately, but also indicative a little bit of analytics, meaning it's very easy for projects to creep in scope, shall we say? When you start to undertake certain efforts in the analytic space, you'll often unearth other problems or other issues or more work. Being able to have enough foresight and insight to plan for those sorts of things are very important. Lack of ownership, whether it's data requirements gathering or really any important mission critical initiative, if no one owns it, it most likely will not be managed properly. Again, lack of documentation. I've already preached the virtues and importance of documentation on several occasions but it is worth reiterating. No contingency or backup planning. We would like to live in a perfect world, we would like for best-laid plans to be successful but that's not always the case and not having a backup plan or the agility and foresight to be able to respond to that can be deadly. Think about it and engage in group discussion. Do you have experienced gathering requirements? What went well? What would you do differently? Share with the group.
