PM Nerd

Sharing ideas and stories about learning and professional development. The more we learn, the more we share, the more we grow.

About this Blog


Recent Posts

The Different Roles of Business Analysis

Trust Comes from Proper Traceability & Evaluation

Trust The Elicitation & Analysis Process

Identifying the True Need or Opportunity

My PMI Learning Community

The Different Roles of Business Analysis

I love the smell of a good book, especially a new one I can add to my library. Do you also smell the books you read? Am I the only one?

Anyways, back to the task at hand. This week I added Business Analysis: Best Practices for Success, written by Steven P. Blais. So far I have made it through five chapters and must say it is well written. Steven has a TON of experience and it feels more like listening to a mentor than reading a book. He has a great rhythm and provides a fantastic perspective on the profession.

Right away he lays out the justification for looking at the business analyst as a problem solver. When you step back it makes so much sense. The project manager is in charge of making sure the team delivers the solution. It only makes sense there is someone responsible for figuring out how to solve the problem and managing that process. 

There are many ways to describe a business analyst. The book provides the following examples:

  • Business analyst (general)

  • Business Process Engineer/Analyst

  • Data Analyst/Modeler

  • Product Manager/Functional Architect

  • Requirements Engineer

  • Systems Analyst

  • Usability/UX Professional

(Business Analysis: Best Practices for Success, Page 21)

The list provides a perspective on the different ways you can choose to solve a problem. The trick is making sure the solution solves the business and IT problems. People start their careers in either business or IT and carry that unconscious bias with them. So, you want the business analyst to balance both the business and IT requirements. That balancing act is a craft requiring practice and patience.

This means the business analyst must possess key skills and traits to be successful. The book provides the following:

  • Accepting ambiguity

  • Tolerance

  • Curiosity

  • Impartiality

  • Communication, Communication, Communication

  • Analysis

  • Technical and/or Business Knowledge

(Business Analysis: Best Practices for Success, Pages 41-44)

The skills help a business analyst play different roles depending on the circumstances. The book walks through the following list but I am sure you can think of a couple more to add:

  • Intermediary

  • Filter

  • Mediator

  • Diplomat

  • Politician

  • Investigator

  • Analyst

  • Change Agent

  • Quality Control Specialist

  • Facilitator

  • Process Improver

(Business Analysis: Best Practices for Success, Pages 45-84)

To give you an idea of the different roles, here is an image from the book describing the "filter" role:

(Business Analysis: Best Practices for Success, Page 61)

After reading that list, I bet you can imagine playing different roles simultaneously. That is what I mean when I say this is a craft. It requires practice, patience, and awareness.

Defining a business analyst as a problem solver makes so much sense. The project manager oversees the project and the business analyst oversees the solution.

In my current role, I serve in the role of project manager and business analyst. What I love about this book are the tips and tricks in navigating those conversations and roles. If you know a meeting requires a business analyst, you will be better prepared. If you have to switch between roles in a meeting, then you are a "Project Management Jedi."

Thank you for reading. 

Posted on: August 05, 2018 05:07 PM | Permalink | Comments (13)

Trust Comes from Proper Traceability & Evaluation

After 24 days I finally finished the Business Analysis for Practitioners: A Practice Guide. Studying for a certification while working full time is definitely no small accomplishment. It helps though to study for the sake of becoming a better business analyst and not to just earn the certification. Every project team struggles with requirements management so it never hurts to continue learning.

The next book will be Business Analysis: Best Practices for Success. It should arrive by the end of July, I am super excited. In the meantime, I signed up for the learning path on LinkedIn learning titled, Become a Business Analyst. I am planning on those classes and another learning path offered by Pluralsight titled Business Analysis - PMI-PBA to fulfill the education requirements for this certification. The LinkedIn learning path is free and Pluralsight offers a monthly subscription of $35/month which seems reasonable.

Click on the images below to be taken to the actual course.

Become a Business Analyst learning path offered by LinkedIn

Business Analysis - PMI-PBA course offered by Pluralsight

Now, back the chapters completed this week. Chapter five covered traceability & monitoring. Chapter six covered solution evaluation.

Traceability tracks requirements from the business case and objectives to the milestones and deliverables. You can obviously see the importance of proper traceability. It helps verify & validate each requirement is delivering proper business value, makes sure the solution is meeting customer expectations and helps manage scope. Proper traceability includes understanding relationships and dependencies between requirements, approving and baselining requirements, and managing change to the requirements. What I love most about this phase is you get to unveil the Requirements Traceability Matrix (RTM). Of all the project management tools the RTM is easily in my Top 5. Throughout the requirements life cycle, the RTM is the Rosetta stone for understanding the status of each requirement, why it exists, who is going to be excited when it is properly delivered, and anything else you can imagine. Traceability is too often overlooked. It is where you fulfill the promises you made to your customers and stakeholders. It is where you prove yourself and your team to be trustworthy and credible.

In order to gain your customer's trust, you also have to properly evaluate the solution. The evaluation should be objective and clearly define the acceptance criteria. How many times have you asked your team or customer, "What is the definition of done?" Well here is where you get to feel that conversation in action. You determine what the success metrics are and what allows a requirement to pass the Go/Go-go decision point. While determining the definition of success, you also take into consideration the long-term solution. It is one thing to make everyone happy on Monday but if the solution starts to break on Friday because of bad weather, then you have another problem on your hands.

Now with the Business Analysis for Practitioners: A Practice Guide behind me and my sights set on Business Analysis: Best Practices for Success I am looking forward to diving deeper into the field of business analysis. I have also been enjoying the first lesson in the Become a Business Analyst learning path on LinkedIn titled Business Analysis Foundations. It is taught by Haydn Thomas who is an outstanding coach. If you get the chance to sign up for this learning path, I recommend it.

Besides documenting my journey to earning the PMI-PBA certification, another goal is to discover affordable learning resources that help me earn this certification and enhance my professional development. Given my busy work schedule, I prefer self-paced learning resources where I can learn on my own schedule but also satisfy the requirements for professional development. Learning should always be exciting and affordable. So I hope you check out the resources on LinkedIn and Pluralsight and find them useful. If you discover other learning resources you find helpful, especially those pertaining to business analysis, please share them in the comments. Thanks.

Posted on: July 29, 2018 04:13 PM | Permalink | Comments (8)

Trust The Elicitation & Analysis Process

Hello and good day. This week, I was only able to make it through Chapter 4 of Business Analysis for Practitioners: A Practice Guide. It is 66 pages long and the longest chapter in the book. It focuses on requirements elicitation and analysis. At first glance, I thought it was going to be straightforward but I quickly found out there is a lot of depth and complexity to elicitation and analysis so in hindsight it makes sense why it took so long. 

Something else I wanted to share is an app called Bookly which I downloaded on my phone to help me track how long it is taking me to read these books and other stats that may prove to be helpful. You should definitely check it out, it is proving to be super helpful. Plus it will help justify the PDUs I will claim after reading these books. 

One fact Bookly pointed out right away is how slow I read so I shouldn't expect to finish this book soon. Plus the content in the book is not that easy to digest quickly. Currently, my reading speed is 2.5 pages/minute. The Bookly graph below also shows you I didn't read a lot after my last post on July 12. That is because I was spending time in my childhood home enjoying time with family and friends and a couple beers. So I hope you can forgive me. 

So with the excuses out of the way, let's talk about requirements elicitation and analysis. I made the mistake of thinking elicitation simply meant gathering and documenting requirements. What the practice guide reminded me is stakeholders often don't know what they want. To say you are just gathering requirements implies the stakeholders have already done this and you are simply transcribing those into an Excel sheet. A key role the business analyst plays is helping stakeholders define the problem or opportunity and determine what should be done to address that. The elicitation process is where the business analysis coaches the customer and stakeholders through the process of discovering what they really want and how the team is going to achieve that goal. 

So like any endeavor, elicitation requires a plan and a process. It is the business analysts job to create an elicitation plan and prepare for the work by determining what the objectives are, who will participate, and what the right questions are to ask. Then it is time to conduct the elicitation tasks through multiple techniques whether they are interviews, workshops, surveys, prototyping, etc. Once all that is done the business analyst documents the outputs of the process and analyzes the requirements. It is important to keep in mind that elicitation and analysis are iterative. The practice guide does a wonderful job reminding me to slow down and realize there is much more to each step than just tasks and checklists. After putting in all that work, further analysis may spark more questions which may require further analysis or elicitation. So again, don't forget to take a deep breath and make sure you do it right the first time. 

The next section which I think merits an entirely separate discussion is how to use models. The practice guide does a great job summarizing models by stating, "When the correct models are applied, analysis becomes simple relative to analyzing the information in pure text form, because the models help visualize and summarize complex information. The list below gives you an idea of the types of models available to the business analyst depending on the project lifecycle and solution. 

  • Scope Models - Structure and organize the features, functions, and boundaries of the business domain being analyzed. 
  • Process Models - Describe business processes and ways in which stakeholders interact with those processes.
  • Rule Models - Concepts and behaviors that define or constrain aspects of a business in order to enforce established business policies. 
  • Data Models - Document the data used in a process or system and its life cycle.
  • Interface Models - Assist in understanding specific systems and their relationships within a solution. 

Once the analysis is complete, then the business analyst documents the requirements. The requirements package is delivered to the project team in various formats depending on the project lifecycle. For a predictive lifecycle it may be very formal and almost 100% complete whereas for an adaptive lifecycle, it may only capture 50% of the solution. The important thing to keep in mind is the requirements should represent the solution based on the information available at that point in time. 

After capturing the solution requirements, the final steps are to validate, verify, and approve the solution requirements. And there you have it, elicitation and analysis is complete. 

My main goal is to study all this material so I can sit for the PMI-PBA certification exam. What I am finding more enjoyable though is reading the material to become a better business analyst in my day-to-day job and in the process earn the certification. I don't know about you but on every project I have been in charge of, I serve in the role of project manager/business analyst/scheduler/jack of all trades. So reading this book is not only enlightening in what I have to improve upon as a business analyst but it also is a great reminder that in order to move fast you have to slow down and trust the process.

Posted on: July 22, 2018 06:21 PM | Permalink | Comments (12)

Identifying the True Need or Opportunity

Hello, good day, and welcome back to my adventure in studying for the PMI-PBA certification. So far, I have made it through chapter 3 of the  Business Analysis for Practitioners: A Practice Guide. So I want to share with you what I have learned and where I am headed for next week.

Also, it amazes me how optimistic my planning has been. I thought I would have made it through this entire book which is 206 pages after two weeks but I am way behind that goal. I need to speed up my reading but also set more realistic expectations for the next task. That sounds like a good topic for a future blog post.

Now, back to the topic at hand, business analysis. The guide summarizes business analysis as the activities necessary to identify business needs and recommend relevant solutions. It also focuses on eliciting, documenting, and managing requirements. The business analyst focuses on the product requirements while the project manager focuses on the project requirements. I found this very interesting because as a project manager, I rarely find myself leading a team where I have a business analyst to lean on. So I have to act as both a business analyst and project manager. The guide reminded me of my responsibilities when wearing my business analysis hat and when wearing my project manager hat. This is an important distinction and there are explicit processes and activities for each situation. 

Now let us dive into each chapter a bit. Chapter 2 focused on needs assessment while chapter 3 focused on business analysis planning.

Needs assessment consists of:

  1. Identifying the problem or opportunity
  2. Assessing the current state of the organization
  3. Recommending actions required to address the business needs
  4. Developing the business case.

Business analysis planning consists of:

  1. Conducting or refining stakeholder analysis
  2. Creating a business analysis plan
  3. Planning business analysis work

What I loved after reading these chapters was the focus on a patient and methodical process. Too often we start running down the street without putting on our pants. In projects, we are so eager to solve the problem we forget what problem we are trying to solve. Understanding customer needs, solution scope, and stakeholder expectations are so important. So often I am reminded that to move fast you have to slow down and take a deep breath.

The goal for next week is to read chapters 4 and 5. They focus on requirements elicitation & analysis and traceability & monitoring. If I am lucky I will finish the book but as I mentioned, I need to learn how to be realistic, not optimistic.

Also, I have started a basic learning plan documenting the tasks as I complete them and any costs I accrue. For the tasks, I am capturing start and finish dates, duration and the amount of time it takes to read each book. I am hoping this will help me plan for the next certification I study for. Please check it out at the link below and let me know what you think:

PMI-PBA Learning Plan

Posted on: July 12, 2018 06:06 PM | Permalink | Comments (16)

My PMI Learning Community

Hello again, it has been a while and I want to sincerely apologize for the gap. After my last post, I didn't think I was adding a lot of value to this community but after re-visiting the site and looking through the comments, I realized I should have never taken that break. It also pointed out an important lesson I learned. 

Professional development is an interesting concept and seems to have a lot of different definitions depending on who you talk to. Some say the intent of professional development is to accumulate the necessary skills to earn a promotion or land that new job they have been interviewing for. What I struggled with after my last post was learning more project management skills after a long day of serving as a program manager at my job. It didn't sound too exciting. What I failed to notice though was that for me, and this, of course, may be different for you, was that learning provides a community where I can share ideas and stories with my colleagues and friends. What I realized was that the joy of learning, again for me, was not only learning something new but the simple act of sharing what I have learned is where the excitement comes from. 

So I decided to start a YouTube channel and share my project management professional development learning journey. I have been lucky to earn four certifications from PMI and now that I am over halfway there, I decided why not go for all seven and see what lessons I learn. So I have decided to study for the PMI-PBA certification and then move onto the PfMP and PgMP certifications. For the PMI-PBA certification, I don't have enough money saved up to pay for a course to earn the required 35 hours of business analysis education but I can start reading the books in the PMI reference list and start learning the old-fashioned way. Plus, my team at work has stood up a PMO and is working hard to create processes and templates to improve our scope management capabilities because like most companies, scope and requirements continue to be a struggle and if you don't get that under control, you are going to have a long day at the office. So not only am I hoping to share what I learn with you but also share what I learn with my team at work. 

I cannot say thank you enough to PMI and the community it has provided me to share and I hope this blog and the videos resonate with you. If you like or dislike what you watch or read, please let me know. 

Thank you again. 

Posted on: July 07, 2018 12:58 AM | Permalink | Comments (9)

"A thing worth having is a thing worth cheating for."

- W.C. Fields