As a business analyst (BA), what would you say during the initial conversation with your project manager (PM)? First, do not assume that the PM knows what to expect from a BA. In fact, this is your opportunity to set expectations and explain your value added to the project.
The purpose of this article is to provide an example of the initial conversation between a PM and a BA. Note that the BA is an experienced analyst and uses many terms that may be unfamiliar; I recommend you seek definitions and explanations from the example references provided.The article also highlights key words in bold that you can search for additional insight.
The Situation
Executive management has recently assigned a project manager (PM) to a new software development project. By new, I mean executive management has just issued the project charter to the PM. The project is of some significance: multiyear, million-dollar budget, and many stakeholders. In addition, executive management has assigned a BA to the project that is experienced and familiar with the business domain of interest.
The Initial Conversation
The venue is the PM’s office. The PM is expecting the business analyst (BA) to start a dialogue on setting expectations for the new project. When the BA arrives, the PM stands-up and offers a chair. After some brief introductions, the project conversation starts:
| PM: |
“So, my understanding is that you are on this project to ensure its success.” |
| BA: |
“It’s business success. Yes, you are correct. Let me explain. My main concern is that this project realizes the expected benefits, as opposed to project success (i.e., completing the scope, within budget and on-time delivery). Don’t get me wrong. My intent is to help you maintain the triple constraint, but within the context of a business success. For example, I will ensure that we stay within scope by using a traceability1 technique and remind stakeholders that all scope additions will need to include a dialogue on the associated time and money. ” |
| PM: |
“I like the collaboration. I am planning a kick-off meeting next week to set expectations with the team and stakeholders.” |
| BA: |
“Sounds good. In terms of the Project Life Cycle (PLC) methodology, I assume we will follow the standard provided by our PMO, but what about the Solution Development Life Cycle (SLDC)2 – waterfall, agile, or some form of hybrid?” |
| PM: |
“My experience is limited to waterfall, but I have certainly heard of agile. I have not given the SLDC much thought. Do you have any suggestions?” |
| BA: |
“I recommend that you schedule a vision and scope meeting3 after the kick-off. I can help you facilitate4 that meeting. The purpose of the meeting is to describe what the software product will look like via brainstorming5 and set a boundary for the project,essentially, what we will do and not do on the project. Our deliverable will be an initial list of prioritized software features. I suggest we use a technique called “user stories6” to document these features. From this information, characteristics of the project team and what we learn about the stakeholders, we can determine the appropriate SDLC.” |
| PM: |
“Aren’t user stories an agile technique? Doesn’t this mean we will use the agile approach?” |
| BA: |
“Not necessarily. Regardless of the SDLC, we need to define the vision and scope and user stories are just a good way of writing the software features.” |
| PM: |
“OK, I follow you. I was going to have a planning meeting with the team members after the kick-off. But, perhaps the vision and scope meeting should go first.” |
| BA: |
“I agree. After the vision and scope meeting, I suggest two planning meetings: one for the entire project and one for the analysis. The result of the analysis meeting is the Requirements Work Plan (RWP)7.” |
| PM: |
“What goes into the RWP?” |
| BA: |
“Well, it depends on the SDLC. Let’s say this project uses a waterfall SDLC. Together with my analysis team, we will build a Work Breakdown Structure (WBS)8 of all the analysis tasks from identifying and interviewing stakeholders to modeling the AS-IS and TO-BE9 business environment. The deliverable is a Business Requirement Document (BRD)10 signed by the project sponsor. From the approved BRD, the IT system experts translate the business requirements into technical specifications, which programmers later transform into software code and finally test.
If this project uses an agile approach, we still need to plan, but it takes a form of releases and iterations. There is no BRD; in fact, there is minimal documentation. In this case, I will work with the stakeholders and project team together to elicit the software requirements using the user stories as the basis. As we elicit the requirements, the project team writes and tests the software code directly.”
|
| PM: |
“Which is the better SDLC approach?” |
| BA: |
“Actually the question is, which SDLC is best for this project? As I said, the SDLC is determined after the vision and scope meeting.”
| The best SDLC is the one that matches the characteristics of the project, the stakeholders, and the project team. |
|
|
| PM: |
“OK, I get it. The SDLC depends on the characteristics of the project, the stakeholders, and the project team. By the way, I am very familiar with the WBS tool; I can help you with your planning effort assuming the waterfall approach.” |
| BA: |
”That would be great.” |
| PM: |
“Are there other tools and/or techniques that you will use?” |
| BA: |
“There are several techniques and best practices. Besides expanding the user stories into detailed use cases11, I will be developing various models12 to represent business data, rules, and processes. The important thing is that we produce documents that the team members can use throughout the project. Our goal, of course, is to realize the benefits of a working product.”
| Documentation is not the end goal, the benefits of a working product is. |
“For instance, use cases will be our basis for writing test cases and, in fact, will facilitate developing our test plan prior to coding the software. This is an extreme programming technique called test driven development13.”
|
| PM: |
“This conversation has really helped me understand what to expect during the analysis phase. I definitely want to participate in your WBS and integrate your RWP into the project plan.
Let’s look over our schedules and set dates for the kick-off and the vision and scope meeting. After these meetings, we can decide on the appropriate SDLC together.”
|
Summary
Can this conversation happen? Yes, of course. Notice that it is unclear who set up this PM/BA meeting on setting expectations. If you are the BA, take the
initiative to start a dialogue (not a discussion*) with the PM.
| * The word “discussion” comes from the Latin to dash to pieces or take apart like a debate, where a “dialogue” is more of an exchange of ideas. |
Note that the conversation started with the inference that the PM chooses the SDLC; this is the correct position. The PM controls the project. However, after
the PM learns about the collaboration intent and value added of the BA, the PM shares the SDLC selection decision with the BA. Of course, implied in all of this is that there is a conscious decision on the SDLC. Moreover, regardless of the SDLC choice, there still needs to be a vision and scope meeting with follow-on planning.
I noted several example references to Modern Analyst articles to facilitate further insight. Also, I have highlighted key words (in bold) for you to use in the search feature on the Modern Analyst website or other sources to obtain other articles, white papers, and blogs for even more information on the techniques mentioned in the above conversation.
Post Script
I was unable to find an article reference for Work Breakdown Structure (WBS) in Modern Analyst. This surprised me since it is quite renowned as the tool in project management. There are plenty of references for WBS on the web; however seeing the void in Modern Analyst, I will make this the subject of my next article.
Example References on Modern Analyst
1. Connect the Dots with Requirements Traceability, Part 1 and 2
2. An Example of Choosing a Hybrid SDLC using BPMN and the Decision Model
3. Requirements by Collaboration: Getting it Right the First Time
4. The Twelve Shades of the Business Analyst (BA) Facilitator
5. Using the Brainstorming Technique in Business Analysis
6. Developing Effective Agile Requirements Relies on Both User Stories and Use Cases
7. Effective Requirements Planning
8. No reference in Modern Analyst via search engine; see above post script
9. Structuring AS-IS and TO-BE Process Improvement Discussions using the Fishbone Diagram
10. Requirements Reviews - When You Want Another Opinion - Part 1 and Part 2
11. End-to-End UML: Use Case Diagram
12. Some Alternative Requirements Views
13. A Proposal for an Agile Development Testing V-Model
Author: Mr. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) by the Scrum Alliance, and certified in BPMN by BPMessentials. He holds an Advanced Master’s Certificate in Project Management (GWCPM®) and a Business Analyst Certification (GWCBA®) from George Washington University School of Business. Mark is also a member of the Association for the Advancement of Cost Engineering (AACE) International and the International Association of Facilitators (IAF).
Mark is the President of Monteleone Consulting, LLC and author of the book, The 20 Minute Business Analyst: a collection of short articles, humorous stories, and quick reference cards for the busy analyst. He can be contacted via – www.baquickref.com.