The Habits of Effective Business Analysts

Business analysis is a specialized skill. These practices and behaviors can help a business analyst contribute to project success.

Man photo created by stockking — www.freepik.com

Software managers sometimes assume every skilled developer can also interview customers and write requirements, without any training, resources, or coaching. This is not a reasonable assumption.

Regardless of who on the team does the work, business analysis has its own skill set and body of knowledge. Analysts who come from a user background may lack deep technical understanding. Those who migrated into business analysis from the development side might not understand the user’s business domain. Business analysts also need the right personality and soft skills for this people-centric job. It’s not for everyone.

A business analyst provides a specialized capability that can make the difference between a project that succeeds and one that struggles. Every software organization should develop a cadre of trained and experienced BAs. Let’s see some of their key skills and activities.

Create a Collaborative Environment

Software projects sometimes experience strained relationships among customers, developers, managers, and marketing. The parties might not trust each other’s motivations or appreciate each other’s needs and constraints. A win/win outcome means customers love the product, the organization achieves its business objectives, and team members are proud of the work they did.

A business analyst contributes the most to software success when she helps to forge a constructive and collaborative relationship with customers. Identify key individuals who could serve as the voice of the customer for each of your system’s user classes. I call these people “product champions.” Also, identify who your decision makers will be for resolving requirement trade-offs and priority conflicts and the decision-making processes they will use. Do this before the project team confronts its first major decision.

Customers and their managers sometimes are reluctant to spend time on requirements discussions. You might remind them of problems on previous projects that arose from inadequate user…