business analysis
 |
Dodging the Requirements Hazard 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. |
|
 |
Hiring Technology Product Managers: The Latest Scott Sehlhorst looks at an analysis of how companies are posting requirements for hiring new technology product managers in the US—including the trend of placing more importance on domain experience than product management experience. |
|
 |
Business Analysts—Don't Hide from the Data Model 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. |
|
 |
The Importance of Consistent Business Rules 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. |
|
 |
Become a Better Product Manager: Your Project Deserves It Becoming a better product manager is something you never stop doing. As you get better, your work will improve, your satisfaction with your work will increase, and opportunities to do even better work will come. Scott Sehlhorst sums up how to invest in becoming a better product manager. |
|
 |
Why Cultural Differences Matter to Project Stakeholders 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. |
|
 |
Cast a Wider Net to Get the Best Software Requirements 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. |
|
 |
There's No Such Thing as an IT Project 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. |
