Attendees of last month’s webinar “The Project Manager as Business Analyst” had a lot of great questions for PMP-certified Global Knowledge instructor and webinar host, Dan Stober. So great, in fact, we decided to share them, along with Dan’s great answers.
Q: Speaking of building something that doesn’t meet the business need, can you talk about how this fits in the Scrum/Agile method?
A: Many times, especially in software development, the finished product doesn’t look anything like the original vision. Usually this comes from either expanding scope or poor initial requirements development. What we want, in the end, is to build a product that meets the business need. But, many times after every stakeholder get his/her wish list into a product, we find that many of the features/functions are not a business necessity.
Q: If the project manager (PM) writes the requirements charter, how does it give them authority? That’s like writing your own blank check (considering you know nobody will actually read it until they need to reference it).
A: A requirements charter is not a project charter. The requirements charter only outlines the work of the requirements team. It is not authorization to begin a project.
Q: I work in an organization where we are currently developing templates for our PMO. Do you suggest including the requirements charter as a template for our PMO?
A: I do suggest that organizations standardize templates to the greatest extent possible. So, yes, I would suggest making a requirements charter template.
Q: What is the hierarchical relationship between the PM and the business analyst (BA)?
A: Normally, the PM is responsible for the project as a whole, and the BA is accountable for the requirements effort. They must work together, but the PM is overall in charge of delivering value to the stakeholders.
Q: If a strong PM who is not trained to do the BA role was to be burdened to do requirements development, then they may not do a good job as compared to an experienced BA, so the project may not be a success due to poor requirements. My suggestion is that the company should recruit a BA just like they did a PM. What are your thoughts?
A: I agree completely. Investing in a trained BA on the front end will save heartache (and money) on the back end.
Q: Who should primarily be writing the requirements charter?
A: The BA should be writing the requirements charter with input and oversight from the PM.
Q: Is there a good requirements charter template and sample that we can use available on the Internet somewhere?
A: I don’t want to endorse any one particular template, but there are plenty available on the Internet.
Q: What is the most fundamental knowledge domain that a BA should have?
A: BAs should be familiar and proficient in the six BA knowledge areas outlined in “A Guide to the Business Analysis Body of Knowledge” (BABOK® Guide) by IIBA. I am a believer that elicitation is one of the most important elements – getting stakeholders to tell us what it is that they really need.
Q: Do you see BAs struggling with the responsibility but not the authority issues that a lot of PMs deal with?
A: BAs should not be held responsible for project success or failure; that is the PM’s burden. But they should be held accountable for thorough requirements development.
Q: What influence does the BA/PMI have on the type of tools that are needed to develop the product when working in a large organization? Often to deliver a good product, new tools and optimizing tools are necessary. Who assumes this role?
A: It is an organizational responsibility to develop organizational process assets (tools/templates, etc.) PMs and BAs should always contribute to the organizational knowledge base, but they are not single-handedly responsible for developing that knowledge base, unless they are in a PMO type of role.
Q: If the boundaries are not clearly defined,there will be conflicts between BA and PM. What are some pointers on resolving these conflicts?
A: Handle the conflict professionally and at the lowest level. Roles should be delineated up front on all projects, and doing so is the responsibility of the PM. She or he must do this as part of the human resource management plan (part of the PM plan).
Q: What are the dangers of overstepping the PM role and becoming the requirements manager or BA?
A: The danger is that, when untrained, the PM can be out of his or her league. Turning elicitation results and stated requirements into functional and nonfunctional requirements is not easy and can be easy to get wrong. The danger is that the wrong product gets built or that requirements development takes far longer than it should.
Q: In the military, many times the communications officer becomes the BA and requirements manager. Is this a conflict of interest or a more efficient way?
A: In the army, the S6 is the SME on all matters of all forms of communication. I don’t see this as a conflict of interest because at the end of the day, he or she has to analyze what the commander’s communication needs are, determine what assets are available, and figure out how to balance all of the competing priorities. The S6 has to manage the requirements and perform the analysis of how to get the commander from his or her current state to the desired future state. I find it to be highly efficient.
Dan Stober, PMP, has spent the last 17 years exploring and implementing transformative leadership and effective project management techniques into multiple organizations. Often, the difference between good and great is the quality of leadership that is displayed by those who are in charge. At Project First, we focus on advancing the leadership skills of your executive and management team, teaching effective project management, and engaging your staff toward a single, collective goal: success.
This article was originally published in Global Knowledge’s Business Brief e-newsletter. Global Knowledge delivers comprehensive hands-on project management, business process, and professional skills training. Visit our online Knowledge Center at www.globalknowledge.com/business for free white papers, webinars, and more.
© Copyright 2014, Global Knowledge. All rights reserved.