Tacit knowledge includes the knowledge that business stakeholders possess that isn’t codified or written down anywhere—and information they don’t even know they possess. The challenge for business analysts is that it is essential to get at this type of information in order to write requirements.
Adrian Reed is a consulting lead business analyst and principal consultant and director at Blackmetric Business Solutions, where he helps organizations solve their pressing problems. Adrian also speaks internationally, trains, and consults on business analysis and business change-related topics. Read his blog at adrianreed.co.uk.
All Stories by Adrian Reed
Among business analysts, there is often a real reluctance to model data as it is seen as a technical activity rather than a business-focused activity. Adrian Reed explains why data models are important, and how they can help map out and understand the problem domain to avoid misunderstandings.
Often organizations have multiple information systems with different systems performing different functions. Adrian Reed highlights the importance and benefits of applying common business rules where there are multiple systems.
Adrian Reed highlights the importance of creating solid requirements in order to create a good user experience. Techniques discussed include engaging users early in the requirements cycle; stakeholder identification, categorization, and management; and process identification and modeling.
In a time when many projects span organizations, countries, and time zones, an appreciation of culture—including national culture—is of paramount importance. Adrian Reed explains how cultural guides, comparisons, and observations can be extremely useful for your projects.
Stakeholders often have different views about a software project—the scope, what requirements to include and their priority, and possible solutions. To get the best requirements, you need to talk with and understand the worries, fears, challenges, and ideas of as many stakeholders as possbile.
Adrian Reed makes the case that there is no such thing as an IT project—there are only business projects that implement, impact, change, or interface with IT. This sounds like a subtle distinction, but it’s deceptively important.