A Good BA has a product management approach to their role, partnering with stakeholders to define the very best solution. A Good BA is the subject matter expert of the project requirements. They are viewed by both Creative and Tech teams as one of their own while in reality serving neither, only the client’s project goals. A Good BA has patience to learn from the client, educate the client, and push back when needed.
A Bad BA acts as a note taker, documenting what other people tell them with no vested interest in the quality of the product being built. A Bad BA is a gofer and assistant for the tech team. They document just enough for client sign off.
A Good BA pushes decisions and detailed design understanding early. They focus clients away from bells & whistles and back onto solutions that drive project goals, and when necessary are not afraid to remind the client of agreed upon scope. A Good BA communicates as well in written form as they do verbally. They create great requirements documentation that tells the story of the product. Their documents flow in a logical way from feature to feature, big idea to detailed specifications. A Bad BA is distracted by other people’s jobs (user experience or tech solutions) losing focus on their own (documenting the What).
A Good BA ensures all sections of their documents add value. They flush out and define detailed requirements organized and aligned to business goals and scope. A Bad BA fills out a template. They write down disjointed meeting notes from stakeholder interviews and call them requirements.
A Good BA defines accretive requirements. A Bad BA uses words like may, shall, and should. A Good BA includes notes and supporting information in their documents for increased reader understanding. A Bad BA does the bare minimum, forcing conference calls to explain written requirements.
A Good BA is organized and manages open item trackers for their documents. They can accurately communicate work remaining and blockers to closure. They anticipate design challenges and drive clarity through their requirements. A Bad BA lets the tech team do their work for them by flushing detail through tech design questions.
A Good BA partners with the Client to ensure they are prepared for User Acceptance Testing. They ensure the client understands what was documented and categorizes appropriate UAT defects as Change Requests. A Bad BA assumes the client is organized and prepared. They flood the tech team with duplicate, unclear, and as-designed defects
A Good BA is viewed as a critical member of the team’s success. They do their best regardless of whether or not someone is going to read the document. A Bad BA cuts corners and is a replaceable with well-annotated wireframes.
Don't forget to leave your comments below.
Read 2844 times Last modified on Friday, 15 August 2014 14:53