Michael Rodriguez Raises His Level of Thinking, and Affirms He is Doing Things Right as a Business Analyst

When Michael Rodriguez joined The Business Analyst Blueprint™, he had quite a bit of experience (like 10-15 years of experience) gathering requirements as a software development lead. He is a highly skilled and competent professional, and was looking to take his business analysis skills to the next level.

Michael shares many tips with us in his interview, and I’ll call your attention to a few juicy tidbits:

  • The importance of communication skills, and how they can help you ask questions that probe deeper into stakeholder assumptions and thinking.
  • How analyzing the business process can raise your level of thinking, particularly when you are typically very focused on software requirements.
  • How important it is when you are expanding and growing your career, to know with certainty that you are performing business analysis techniques the right way.

Connect with Michael Rodriguez on LinkedIn here

Click the play button below to listen in, or skim past to read the full text.


For those who like to read instead of listen, here’s the full text of the audio:

Laura Brandenburg: Hello, and welcome. I am here today with Michael Rodriguez, who was a participant in the 2018 The Business Analyst Blueprint™ session. Hi there, Michael.

Michael: Hi Laura, how are you doing?

Laura: Great, great. Thank you. Thank you so much for being here and being willing to share a bit about your experience with the community.

So, we were chatting a little bit before we started the recording and I know you mentioned that it happened to be your first official business analyst training. So, could you just kind of back up a little bit, though, and kind of share when we came into contact together in November or December of last year.

Where were you in your career? I know you have a fair bit of business analysis experience as well.

Michael: Right. So, just to provide a quick background, I started out as an application developer and I worked my way up the different levels up to being a lead developer. For the most part, in the last 15 or 20 years or so, I’ve been working, mainly, on projects where either I was the lead developer on a very small team, or I was, basically, the primary developer on the project.

And, so, as a developer and, obviously, maintaining or building a system, you have to interact with your client, the customer, to gather requirements. And, so that’s, when I first, really, started getting into, obviously, at that point, purely requirements gathering and just going through those tasks and eliciting requirements in order to develop a solution.

Throughout that whole process, I never took a formal business analysis training course. Like I said, it’s purely requirements analysis. That’s how it progressed the last 10 years or so. I started to interact more not with just a specific set of stakeholders to develop a system, but more organization-wide to talk about overall business processes. That’s when I came to a realization.

About a year ago, I would say, I started becoming more involved with the IIBA DC Chapter. I started attending some of their events and started looking into the IIBA website and other supporting sites within there to see what kind of classes I should be taking. And now you see there’s a lot of information out there.

I came to run into the Bridging the Gap website and I what I liked about that was it was straightforward. It provided what I was looking for. That’s where I discovered The BA Blueprint last year, and I decided to sign up for it in hopes to get the units for the class and start preparing for certification. Basically, the overall plan was to tighten up on the BA foundations that I have and getting the certification, getting the foundational skills to go along with it.

Laura: So, you’ve moved from development to lead development, to requirements analysis, and started tackling some bigger more complex projects.

Michael: That’s correct. Yeah, that’s right.

Laura: And let the BA skills get amped up on a more complex project like that. Were there any challenges that you were experiencing, specifically, in that?

Michael: Yes. I can go back to a project about 15 years ago. I was a lead developer and our director asked me to start talking to the different divisions/organizations and ask them what they’re looking for and trying to improve in their processes. That was the first time. I was stumped because it wasn’t a requirements gathering to produce a certain system. It’s more ask them what they’re looking for, how to improve their business process. To be honest, at that point, I didn’t have a clue how to start.

Laura: That was 15 years ago, right?

Michael: Yeah. Correct. I was doing my research just to see how to approach these different groups in the organizations, and my director would give me advice. He would tell me, “Mike, we are not looking to just ask first and second order questions.” This advice he kept telling me over and over. He said we need to ask 4th, 5th order questions to dig deeper into their processes. That’s how we figured out what they’re doing and what could be done better. Stuff like that.

I started getting advice from folks that I worked with, even taking a software development training class. I remember, vividly, my trainer telling us one day, he said, “I know this is a software development class, but you’ve got to remember when you’re out there and you’re gathering requirements from your stakeholders, the requirements gathering is 80% of this process. The 20% is all the mechanics.”

Once you gather your requirements, once you learn the software, 20% is the mechanics of understanding requirements and putting that to play into the software that you’re developing.

These little tips and advice that I’ve picked up throughout the years.

Challenges came in to play as I started interacting with larger groups of people, more higher level folks, management level folks that are looking to improve their business processes. Tying back into the Blueprint class, what I enjoyed most about the materials that were provided were the little things, like the meeting agenda, the opening script which, if I had 15 years ago, would have helped tremendously.

Laura: It’s amazing how those little tools can be useful.

Michael: Right.

Laura: At that point of late last year, you started tackling these more complex projects and you took the plunge and you joined The Business Analyst Blueprint™. What were your expectations for joining?

Michael: My expectations, definitely, were to, and like I said, the BA skills that I acquired on my own throughout the years, I just wanted to put it all together and just have better guidance as to how things flow and work during the whole BA environment. I wanted to put it all together and listen to everyone’s guidance and the materials and put everything I learned and find out the things that I’ve been doing right, and the things that I’ve been doing wrong, and make sure I’m able to put it all together and help me move forward.

Laura: Right. It’s nice, even with that background, to get that outside validation at times.

Michael: Yes.

Laura: And you also have a certification goal, correct? You’re looking to get your CBAP?

Michael: Correct. When I started looking at the IIBA materials for CBAP certification a year or so ago, that’s when I started thinking before I proceed studying for the CBAP, I need the foundational skills first. I needed to take a class in order to do that. Not just for the units, obviously, but learning from the class. The units will come with it. Then, from there, proceed with studying for the certification.

Laura: Right, and that makes a lot of sense. It can be difficult to tie the BABOK together.

Michael: Yes, looking at that first, I was like, “Wow,” it’s a lot of information here.

Laura: There is a lot of awesome information. Thank you for that.

I know you had some really good results as you went through the program. Did you start with the Business Analysis Process Module, or did you jump right in at the beginning, or did you start in a different place?

Michael: I definitely started right away with the Business Process Analysis Module. For me, that was good to have, actually, right off the bat because, previously, doing the BA work and the development work, I wasn’t too concerned about just overall business process improvement. The goal was get your requirements and make sure they’re correct requirements, and make sure that you’re building the correct tool for the customer.

But the business process was great because that helped me raise my level of thinking. Instead of not just this particular tuition, but how it helps the stakeholder, the organization, in general. That helps me think more broadly in terms of connecting with the client, stakeholders in my current projects, but also in the future. That was a lot of help, actually,

Laura: Did you apply? Did you analyze a process on a project you were working on as a business analyst?

Michael: Yes. I’m in the middle of a big project right now. We’re well into the second iteration of this software tool. Now, we’re digging deeper into other areas where we can improve. We’re not just looking into new areas that we haven’t built into the software yet, but looking into what we’ve built currently and how it’s helping the customer, and what else we can do to improve it. I was able to pick a certain functionality, business process domain. I was able to use that for the class.

Laura: Awesome. What was the result of you doing that work?

Michael: The result, and what is great about the class is the practical work that we were doing there. I’m able to apply that right away to my real job here. What was great about that, I was able to uncover outlining the business process going through the materials and the assignments that we had, that definitely helped me uncover a few more details that, I think, overlooked previously. Now, just looking at it more closely, a little bit more different lens, that helped. Uncovered a few more, while it’s minor, it helped shape this functionality a little better in the end.

Laura: Yes, I can imagine coming from that development background. The temptation and the tendency is to start with the software requirements. That’s where a lot of the details are. The raising your level of thinking, of thinking it through in a different way, allowing the software requirements to fall out of that by looking at the business process, I can see that helping you interact with those higher level stakeholders as well.

Michael: Definitely. I’m grateful for the materials that you provided the class – the meeting agenda, the opening scripts, the guidelines that you provided in each class, those were great. Those are things that I have handy now that I can refer to when I need it. I remember, I think it was four or five years ago, I had organized this meeting. I wanted to review a process flow with stakeholders and I thought I was ready. I had the process flow diagram down in Visio and thought I had my handy notes ready to kick off the meeting. I invited a big group of people to go through this. Right off the bat, it just went downhill.

Laura: We’ve all had meetings get away from us.

Michael: And I said, “Oh my God.” Looking back, when I first saw that business process module and all those materials that were there, I was like, oh my gosh, I wish I had that a couple of years ago when I had that meeting. That meeting always reminds me to just no matter what, be prepared to face whatever happens.

Laura: Yes, and just how important it is how you open a meeting and prepare for a meeting like that.

Michael: Yes, your opening scripts are definitely very helpful. I have that handy all the time.

Laura: That’s awesome. Thank you. Let’s talk about use cases and wireframes. I’m guessing those were, maybe, more familiar, for you.

Michael: Yes, I’m definitely more familiar. Definitely more familiar with the wireframing part. So, I said developer, previous user. I prototyped rights within the tool that I was developing, or I would create a very simple markup or wireframe. We started using Axure here a few years ago. And, so, I would use that, the wireframing tool, to kick off every requirement gathering that I had. Just showing them what we have so far and this is what we talked about last time, and this is I think what you want. That’s, from my experience, how I can get more information from stakeholders by having a wire frame handy.

The use cases, I use a little bit here and there. But I think now that I’ve had more of the foundational training, I’ve seen how useful it is, I walk through the basic flow and the exceptions and capture these events, how helpful it is to go along with the wireframes that I was more familiar with.

Laura: Use cases, you’ve done before, but maybe not as frequently. Do you have any takeaways from going through that process?

Michael: Previously, as I was learning things on my own, I would look into the UML process and all that stuff before. I would write very simple use cases just to walk through with a user. But, again, just following the materials that were provided in this class. It just brought up, for me, the other details that I wasn’t capturing, previously. That’s only introducing it to the overall use case process and then partnering that up with the wireframe index that I’ve been doing. That helps a lot.

The practice, the assignments that we did and used that same functionality that I took in the business process module, building on that functionality and going through those meetings to the stakeholders. That brought out another level of deeper understanding of the process.

Laura: Data modeling. Anything you want to share about that?

Michael: The data modeling is also something that I’ve been familiar with. As a developer, obviously, at first, you want to know what outputs they’re looking for, what inputs users are looking to put into the system and to come up with the outputs that they’re looking for.

I remember us, in the same project, four or five years ago, we had a session as we were building the first version of this system and gathered all these requirements from the different groups. And I started lifting up the glossary, basically. We made an inventory of all the fields based on my wireframing sections and the markups, and I discovered that Field A sounds like C or B. It’s called different, but it looks to be the same.

We set up the user group. We all decided to set up, have everyone in there, block out two hours, I think it was three hours, actually, and we went through each field and determined who owns that field and what the other groups intend, or how they intend to use that same field now that we’ve determined that Group A owns it.

That kind of exercise I’ve done. Again, having the data modeling module affirmed with me the things that I was doing right, and making sure that I’m able to put everything together a lot smoother going forward. The ERD, that’s something that’s applied. It didn’t do as much before. I saw that as somewhat technical, but a tool that I was able to use every now and then.

But I think now that I’ve taken this class, I think I’ve seen the importance of making that a part of the whole data modeling process.

The data dictionary, the ERD, the system context diagram, that I’ve also used before. It’s great to see these things that I’ve done before be in these modules that we have. That told me you’re doing things right. Just use the materials to move up another level and improve on how I did use things.

Laura: What would you consider your biggest win over the last few months?

Michael: The biggest win, definitely, is completing this module. It’s a win. Even though I had these business process already in place and going through them again through these modules and highlighting the things that I didn’t discover previously. Those, I think, were the big wins as far as looking at each module.

The, overall, for me, having a sense of confidence that I was doing things right, and now being able to add these other scales that you went over in each module and putting it all together. I know I keep saying that, but that’s what it’s done for me. Just put everything together and make sure that all the steps that we’ve gone through are meshed together and helps me move forward.

Laura: Yes, sometimes that putting it all together, I like that. All the different perspectives.

Michael: Before, I felt that even looking at how I study for the certification? There’s all this information captured in the day. Am I doing my job properly? Even though I had picked up all of these BA skills on my own, previously, it definitely helps to have guidance along the way. I think it was the perfect time for me.

Even now, this project, and I’m still in this small team, even though I’m the business analyst, I’ve been wearing different hats. But I think the business analyst skill helps in the other areas also, not just the technical stuff. Even as I do security compliance and risk management, all of those areas I’m able to apply these BA skills in all these other areas.

Laura: Yes, that’s a great point because we focus about the specific role, but those skills that you build, especially the communication pieces of it are relevant across many different roles.

You shared so much awesome stuff with us. Thank you. I have one last question. If you hadn’t decided to invest in the Blueprint, where do you think you’d be today?

Michael: If I had not invested in Blueprint, it took me a while to scour the IIBA and all the training sessions that were provided. I think I was looking for something practical, and I think I found that in The Blueprint. If I hadn’t taken this, I think the other classes were more, okay, you read the materials, you learn the theories, but I think the practical side of it is what I liked the most.

I was able to use my current project and apply it to our assignment in each module. That helps the learning even more, not just learning about how to create a process, or a diagram, or how to create data dictionary. Rather than just going through those at the surface level, I was able to apply both in practice and that was great. Without Blueprint, I think I would just be still at that surface level where I’m still wondering, I read about that already, but I just wanted to make sure that I was doing it right.

Even the assignments, the feedback from the instructors was helpful to have. I remember Doug. Just having feedback on my assignments from the different instructors was great.

Laura: Yes, that’s perfect. Taking it from the surface level to that deeper level. Thank you.

Anything else that you’d like to share before we wrap things up?

Michael: No, I think I’ll just end it with I’ll always go back to my previous director from 15 years ago where he says, “Mike, don’t just ask 1st, 2nd order questions, as the 3rd, 4th, or 5th order questions.” Throughout the years, I’ve learned to do that. It helps you dig deeper, but I think, overall, all the materials presented in BA Blueprint was able to help me communicate better and I’m looking forward to using all the skills that I’ve learned going forward at work.

Now, I’m going to get to work studying the BABOK and hopefully get certified in the next few months here.

Laura: Awesome. Thank you. Just to apply the work and the investment you made, taking the time to work through all those practical exercises as well, that is what got you the result that you were looking for. Thank you for sharing that.

Michael: You’re welcome.

Laura: Thank you, Mike, and have a great rest of your day. Good luck with your CBAP.

Michael: Thanks, you too, Laura.

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.