It’s my honor today to introduce you to David Sullivan, a Senior Business Analyst from Madison, Wisconsin. David jumped in to lead his team of business analysts shortly after participating in The Business Analyst Blueprint® program.
What I love about David’s story is how he has jumped in and tackled so many big challenges…from an agile transition to a highly technical project to leading his team.
In this interview, you’ll discover:
- The skills David has relied on to be successful on highly technical projects, even though he doesn’t have a coding background.
- How and why David made the jump into a leadership role.
- How important it is to understand the customer need and the value of the solution you are providing.
- The business analyst techniques David leverages in an agile environment.
- Why even with 16 years of experience, moving into a new BA role at a new company can be a challenge, and how David stepped up to excel.
For those who prefer to read, here’s the full-text transcript of the interview:
Laura Brandenburg: Hello, and welcome. I’m here today with David Sullivan from Forte Research in Madison, Wisconsin. Hey, David.
David Sullivan: Hi. How are you?
Laura Brandenburg: Good, I’m great. Thank you so much for being here. David was a participant in the Fall 2018 session of The Business Analyst Blueprint®. We’ve connected a few times since the program. I actually got to meet him when I was speaking out in Madison and he helped get me on to the speaker roster there, which I was really grateful for.
He’s done a lot of really cool things with his career since that time and so I wanted to share a little bit about some of the goals he’s been filling and what he got out of The Blueprint program as well. So, thank you so much, David.
David Sullivan: No problem. My pleasure.
Laura Brandenburg: Yeah, if you could just take us back to before you joined with us. What kind of role were you in? I believe you were already in a business analyst’s role. What were you hoping to achieve through the program?
David Sullivan: Absolutely. Just to give you background on me, I had been a business analyst in one capacity or the other for probably better part of 16 years, but had never really been a true business analyst. I’d been maintaining systems and just kind of keeping up.
I had the opportunity to take a job with this company in a business analyst capacity and I quickly realized that even though I’d been a business analyst for a long time, my business analysis skill set wasn’t kind of where I wanted it to be with regard to what this company’s needs were and I happened to come across Bridging the Gap. Made a connection with Laura based on some testimonials I’d heard from other people; enrolled in the course and got some really great resources out of it.
The training was exceptional and it was something I could leverage pretty much every day in my current role, and it led to some really exciting opportunities here. I work in the healthcare software industry and what’s happened in probably the course of the last year is not only did I excel as a business analyst on our one product, but I was able to actually leverage my expertise onto a secondary team.
In addition to that, we made a lot of changes internally, so I’ve been helping out in other capacities where I think the Bridging the Gap content really kind of helped me get those doors open.
Laura Brandenburg: Right. And when I met you in Madison, you were leading a small team. Were you already doing that before you joined The Blueprint, or was that something that came up afterward?
David Sullivan: No, I was not. I’d never led a team before in my life. I had always been a part of a team and always looked to other folks. But the opportunities presented themselves, and I really felt like a lot of the things I learned in Bridging the Gap translated really well into sort of that leadership, that team role where I could kind of guide and direct and provide feedback, support, servicing education, and surfacing information up the chain so everyone was staying on top of things.
By the time we met in Madison, I went from effectively being a BA on a team to really stepping into, kind of, a leadership role within the team. Very fortunate to bring you to Madison to have you do some speaking engagements with other BAs.
Laura Brandenburg: Yeah, that as a ton of fun. It was so nice to meet you and your team. I felt like I had somebody to sit with at the table.
David Sullivan: I was so pleased we got to connect there.
Laura Brandenburg: Yeah, that’s a big shift. So you went from kind of feeling like I’ve been doing this for a long time, but this role is requiring me to operate at a different level so, then, emerging as a leader within that organization. That’s pretty amazing.
David Sullivan: Absolutely.
Laura Brandenburg: Tell me a little bit, so we covered the business process, use cases and wireframes, data modeling. Did any one of those modules, in particular, stand out to you in terms of how you were able to apply them right away?
David Sullivan: I mean this may sound like a cop-out, but every single process that I went through with Bridging the Gap I completely leveraged within the role. I was already doing wireframes, but I’ll be honest, I was doing them, literally, back in the napkin; really rough ideas.
A lot of the wireframe techniques that were in Bridging the Gap were not things that I was leveraging. A lot of the directional lines as far as information’s going into play and coming out; this is conditionally applying to everything. Taking that, if I took that alone, that really helped in getting people on board.
The other component was just the real level of the definitions of everything. We’d never done Table of Contents before. Unfortunately, something as simple as a table of contents leads to a lot of confusion. I say one term, but somebody interprets it as another and the customer interprets it as another, or vice versa.
They have one terminology for something, but in the software, it’s completely different. Leads to a lot of confusion and chaos. Having all those word definitions in there, a Table of Contents where folks can really drive down and find information that pertains directly to them, it speeds up the process and makes for better requirements.
Laura Brandenburg: Yeah, so kind of just those little tweaks that you were able to apply to take what you knew but do it in a little bit more structured way.
David Sullivan: Absolutely.
Laura Brandenburg: Some of the results that I heard you share were like getting easier buy-in from the stakeholders. So, your projects were going a little bit more smoothly. How did that leadership opportunity come about? People always like to hear about how that happens for people. Did you do something specific that made that happen?
David Sullivan: I’d love to stand here and toot my own horn and tell you, you know, that I did something out of this world. But the honest to God truth was the person that was operating in our leadership space moved on to another organization and I would say that I quickly recognized with that person moving on, we were kind of going to be left to our own devices and somewhat adrift. There’s a lot of responsibility that comes in that leadership role.
So I went to Senior Leadership and said, “Hey, I’m recognizing a gap right out of the gate. Here’s my suggestion for solving it. Move me into that space.” I will continue to operate as a business analyst, but I will also function in that space until a replacement is found, or I moved into that space permanently, or whatever decision is made. But I think, probably, the biggest component out of all of that was seeing that gap, taking the business analyst’s approach, looking at what you’re trying to accomplish, looking at where the deficits may come from, and then really addressing them and having that, walking into a senior leadership office with a solution is probably the biggest advice I could give to anybody.
It’s easy enough to point out the problem, but if they’re like anybody else, if you’re not coming to me with a solution, the solution’s on me. If you’re really great; if you have something in your pocket.
Laura Brandenburg: Right.
David Sullivan: I did that. Was able to move into that leadership role and really provide guidance. It allows the team to operate in their own capacity. So my quality assurance folks don’t have to worry about getting this information over to the doc team or connecting with the sys administration team. My engineers can focus on engineering; their data development and that aspect.
I don’t know if you want to touch on it at all, Laura, but we also moved into an agile environment. So if you want me to expand on that, I’m happy to.
Laura Brandenburg: Yeah. And before you – I do want to hear all about that because I think that’s really interesting for people – before, I just want to affirm. You said, “I wish there was a story,” but there wasn’t.
But you actually did, you called this a problem, the gap, but you actually capitalized on that opportunity and took the action of presenting a solution, so the reverse that often happens, just kind of coaching for everyone, is like, “Oh, management’s not filling this role. This is a problem.” That doesn’t get you to that opportunity. But going in and actually volunteering for it, that’s a big boost. That took a lot of confidence. That’s pretty incredible. The role has continued to evolve over the last year.
David Sullivan: Correct. In addition to those changes, we also went through a software development change. We decided to adopt the agile development lifestyle. We are a Scrum team. We leverage SCRUM. A little bit in there. I guess you could call in CONScrum or ScrumBON.
I was tasked to be the SCRUM master, so I went ahead and got certified as a SCRUM master. And then my team decided that we will all take on a product over shift. What I do in the SCRUM Master role is effectively, I look at the work ahead of us. I plan accordingly. I work with the team to make sure that their needs are met and that we’re moving forward.
So every two weeks, we produce software that is testable, it’s usable, some aspect. It’s basically just a ton of smaller mini releases. And then we release the major software three times a year. The major release, the upgrades, is three times a year. It’s been really advantageous to take the skills that have come through Bridging the Gap to build that confidence, to manage that amount of work, and leverage all of those skill sets; apply it to our Scrum design, work within the teams, and just move forward from that.
Not to keep iterating over and over, but there is one additional piece, and this is directly to the skills that I learned in Bridging the Gap. I’ve also been leveraged as a business analyst, so additional change to write very technical requirements. That’s probably one thing I will speak to.
When I took this role, I was not what you’d consider a technical BA. No Com Sci degree. I haven’t been a programmer for 100 years or anything like that. I recognized right away that I needed a skill set that would enable me to be a successful business analyst in a very technical space by using methodologies and techniques that break things down to much more understandable pieces. The stuff I learned in Bridging the Gap really helped that.
Going back to the wireframes and the table of contents, and the data dictionary, that stuff really exposes a lot. What you find out is even though it’s a very technical space; there is a strong need for that additional communication level so people can understand what the requirements are.
Laura Brandenburg: And you said you didn’t have a technical background. So what was your background before you started as a business analyst?
David Sullivan: My background was, effectively, more of the UI pieces of the software. You know when you click on the drop-down; it’s going to present you with this. The orders are going to be bolded. The letters are going to be Calibri 12.5. That sort of thing.
Laura Brandenburg: Got it.
David Sullivan: Functionality, when you do this, conditionally, it’s going to do that. Now I’ve moved into a space where I’m helping re-write our API interface. We’re moving from one very technical soap-based interface to Rest API. I’m working on additional interface archetypes, fire; we have some customizable interfaces and writing requirements for that. Working with my development team; I’ve got 9 engineers on a team that I work with. I’m really finding a need for fleshing out what these requirements need to look like, what the expected behaviors are, what the API should support, what it shouldn’t support; really kind of streamline things so that the customer needs are met, but there’s also an amount of work that’s reasonable for our own organization.
Laura Brandenburg: What are some of the techniques that you’re leveraging there to get to those requirements?
David Sullivan: yeah, so a lot more elicitations. I go back to, you know…
Laura Brandenburg: Yeah, I would have thought you were going to say data modeling. So, no.
David Sullivan: The crux of the BA is the five whys? Why are we doing this? And it really goes back to that is that customer elicitation.
Now, for me, my customers are all internal. I’m writing for an engineering team and interfaces team and I really need to understand what their needs are. I can sit there all day and say, “Oh, create something that does this.” But if that’s not feasible, or if that doesn’t align with what the boundaries are of development, there’s no use to it. Honestly, the biggest help is iterating that elicitation.
Now, yes, there is a fair amount of data modeling because we have one interface that we’re replacing with another. So, to that end, I’m comparing. I’ve got the other interface specs. I look at what’s in there, and then it’s a lot of, just like in any data modeling between two products, whether it’s term products or a third party product, and your product, you want to make sure you’ve got things as simple as naming conventions.
If it’s a “Recruited by” field, you want to make sure that “Recruited by” translates perfectly to “Recruited by ID” in another application. So, it’s really documenting what those key points are and making sure that everybody’s on the same page with that has been really crucial.
Laura Brandenburg: Yeah, I can see that. I did want to just go back a little back to your agile work too because we kind of moved from agile to the interfaces pretty quickly. We get a lot of questions about this. In an agile role, what are the BA techniques that we still need to use? Or how do we use some of those business analysis techniques? So, could you kind of speak to that? I think you said you’re still using all those techniques, but how does that actually play out day to day? Would you analyze a business process and then turn that into user stories? What are you actually doing today?
David Sullivan: Some of the agile processes that align perfectly for BAs, you kind of touch on them at the very end there, is user stories, workflow is a real key component, and then acceptance criteria. I’ll kind of go through them one-by-one.
The user story in the agile BA realm is super crucial for nothing more than establishing a scope of what you’re trying to accomplish. As a user, I need this so that I can do that. It paints a real clear picture of that right out of the gate. I understand what the customer request is and it gives you the clear picture of where this effort is going, where this initiative is going.
It also has the tendency to really start opening up a lot of other ideas and questions. I work very heavily with our quality assurance folks. They do all the testing. As a BA, I lean on them heavily. I would encourage anybody that has quality assurance people to lean on them heavily for understanding initiatives and work whether it be in an agile environment or waterfall environment, or whatever you’re working in because they consider things that might not be best practice, and you might overlook it. You’re only as knowledgeable as you understand what it is that you’re working on.
The next piece comes down to the workflow. Understanding a customer’s workflow really drives requirements in so far as getting down on paper, or whatever you use, a real succinct understanding of what it is that they need and what they want out of it, what they want to accomplish; what the actual software or whatever it is that you’re working with should allow them the ability to do. It helps you determine value. It helps you drive forward with that initiative. It may also even open up additional components of design. It exposes things that might not have been considered by a consumer.
And then the final piece is really part of the agile development life cycle, but as BAs, it’s really crucial writing acceptance criteria. And I’ll be honest with you. I think acceptance criteria are a challenge. I don’t ever think it’s done the same way twice. There’s no boilerplate approach to it. There might be a few things as far as making sure permissions are correct, and if you don’t have them, this shouldn’t be allowed to be done.
But writing acceptance criteria as a BA and really defining what it is, that component of work, that initiative or project should accomplish really pays dividends because if you’re in an environment where you may review this before the efforts are ever taken, looking at what expectations are as a final result can really expose a lot of gaps and save a lot of time down the line as far as development, as far as testing. You don’t want things coming back around having to be rebuilt once you’ve set it in motion. So having that complete picture really provides a lot of opportunity.
Laura Brandenburg: Yeah, thanks for sharing that. And I can see how the skills that you learn kind of overlap with, now, what you need to be creating, too.
Any last tips that you would like to share with somebody that’s seeking to follow in your footsteps?
David Sullivan: Sure. I don’t want to sound cliché, but just kind of keep plugging away. I would say, probably, the biggest advice I’d give to anyone that’s looking to advance their career or even just start out as a BA – I’ve known plenty of people who have been in that BA role or capacity, but at the same time, really effectively operating in that capacity. They might have been in product support. They might have been in some sort of customer relations.
But they were able to identify here’s a need; I’ve recognized a need for a customer, and this is how it would bring value. Recognizing how it brings value to whatever it is that you’re working on. And then properly documenting that. There’s no bullet point format for that, but getting that down and getting in front of folks that know will get you noticed. Then just kind of taking the initiative to keep going at it, going after it, recognizing those gaps.
Don’t be afraid to reach out and ask questions of folks within your industry, maybe attend a conference. Plenty of BA resources online as far as where conferences are. A lot of times there are user groups that meet in your regional area. Those are really good resources. Not to give a nicely timed plug here, but I will say that Bridging the Gap really provides some of the best content I’ve ever been exposed to.
Like I said, I’ve been a BA for a long, long time in several jobs. That was all I’d ever done for the last 16 or so years. But the content that was in Bridging the Gap was really eye-opening and I’ll be honest, even though I’m a year removed from it, I’m still going back to my documents, my worksheet documents every single week just to say, hey, is there something that I’ve missed? Is there something I could do a little bit better? How am I going to alleviate questions or confusion around here? That’s a big BA responsibility; taking that confusion, that misconception, that lack of understanding and making it clear; making it so that everyone can understand.
Laura Brandenburg: That’s awesome. Thank you for sharing that. Just one final question for you. If you hadn’t chosen to move forward with The Business Analyst Blueprint®, where do you think you might be today?
David Sullivan: I’ll be honest; it was a big list to come to a new organization. I’ve learned all new processes. I’m learning all new technology. I can’t honestly say that I’d where I am right now. There’s a chance I might have had to move on. There is a chance that I would still be sort of mired in the learning phase and really getting up to speed. But I’m very confident that the efforts of Bridging the Gap, the content and the efforts of your staff were all so accommodating and were so quick to respond to questions and correct my papers and correct my submissions and provide feedback, that sort of thing.
Not to mention all the additional components that you make available, all the conference calls; many a times I sat there over the lunch hour with my little headphones on listening to presenter after presenter. I’m not certain without all of that that I’d be where I am. So, I highly recommend tuning your skills. Keep working on your toolset. And just don’t get mired in the doubt, fear, and the confusion. Move forward. Any effort forward is going to be advantageous. So take action. I appreciate everyone taking that action.
Laura Brandenburg: And just to acknowledge for you, too, that awareness that you had and the decision that you made to make that investment. It’s a big step to just say I need something different to succeed in this situation, and then you made the most of it every step along the way.
David Sullivan: Yes.
Laura Brandenburg: Thank you so much. I learned a ton of things about what has been going on for you, which is always really fun for me to hear. I just really appreciate your time in sharing and all the great work that you’re doing as a business analyst, as a Scrum master and a product owner, and a leader, and probably a few other hats that I missed. Thank you.
David Sullivan: Thank you so much, Laura. I appreciate the opportunity. I wish you the best.
Laura Brandenburg: Thank you.
David Sullivan: Take care.
About The Business Analyst Blueprint®
When you join The Business Analyst Blueprint® certification program, you’ll learn all 12 of the industry-standard techniques and the business analysis process framework – to build your confidence in the best practices of business analysis.
You’ll create validated work samples and be a credentialed business analyst as a recipient of the Applied Certification in Business Analysis™ (ACBA).
