Welcome to this IBM Rational podcast, Do you. Have What it Takes to be a Successful Business Analyst? I'm

Size: px

Start display at page:

Download "Welcome to this IBM Rational podcast, Do you. Have What it Takes to be a Successful Business Analyst? I'm"

Gervais Page
5 years ago
Views:

1 [ MUSIC ] Welcome to this IBM Rational podcast, Do you Have What it Takes to be a Successful Business Analyst? I'm Kimberly Gist with IBM. The role of business analyst changes day by day, and the opportunities are even more exciting when you begin to consider the increased business value that a business analyst can deliver to the organization. So, when you think about your strengths, do you think you have what it takes to be a successful business analyst? Well, today George DeCandio, Distinguished Engineer for Requirements Definition and Management Tools for IBM Rational joins us to discuss a few key competencies for the business analyst role. George, welcome to the Rational Talks to You podcast series. Thank you for joining us. I'm looking forward to the discussion today. DECANDIO: Thanks, Kimberly. It's a pleasure to be here. Absolutely. Well, first, why don't you give us some insight into how the role of business analyst is expanding. DECANDIO: Well, yes. So, let me start out by saying -1-

2 that, indeed, I do believe that the role of the business analyst is expanding. You might hear from some others that Agile development has reduced the role of the business analyst, but from what I'm seeing and working with our clients, nothing could be further from the truth. It's true that as the Agile methodology and Agile delivery processes for software have changed the industry, that almost 50 percent of teams now developing software are using Agile techniques. But in my experience, business analysts are needed even more on Agile teams, and their roles have changed and they have expanded. Successful analysts no longer just work with business stakeholders and create requirement specs at the front end of the development process in isolation. Today's analysts must understand and get involved in the details of the software implementation. They need to know the Agile process, the Agile methodology. They need to adapt and become part of the expanding Agile team. Requirements management is really different in an Agile process. Not only are there different artifacts that are created -- for instance, analysts will likely create only high level requirements early in the process and elaborate them more at implementation time as the development team gets ready to implement them. -2-

3 They'll likely move from long requirement docs to more user story based requirements that can be more easily consumed by the development team. But they'll have much more collaboration with developers, and in some cases they may even do some of the development work themselves. Not in coding but in creating wire frames, creating prototypes, helping with UI specs. Oftentimes we see modern day analysts working with architects picking up the software that is being developed day to day and verifying business requirements. So, as the developer role has changed as Agile has taken hold, so has the analyst role. And it's not only changed, but it's expanded, in my experience. Well great, George. It's a great overview of just how Agile has really taken hold of the process across the board in so many areas and how essentially the business analyst is, at this point, being directly affected by those changes in the industry. So, our second question today would be how would you say the role of business analyst is now becoming a more strategic role? DECANDIO: Well, to answer that question, I think the BA role has always been critical for project success. And -3-

4 today's projects are no different, it's getting even more critical. As release times get shorter and the pressure to deliver business value gets higher and higher, understanding requirements and how requirements map into the solution becomes even more important, or as you may say, becomes strategic. Countless studies that I've looked at have shown that understanding and framing the business problem properly is critical for a project's success. And as we all know, that's the primary role of the analyst. In some studies I've seen, they've even said that framing the business problem correctly is 70 percent of the solution. So, just understanding the problem and framing it in the right light, scoping it, is one of the harder parts of coming up with a viable solution, and the analyst plays a critical strategic role in that. Increasingly, analysts are part of more senior teams in an organization. They have credibility with business colleagues and IT leaders. This is mostly gained by experience on previous projects. And being a BA actually can be a reasonable starting point for quite a fruitful career within many organizations. As I've worked with clients, I've seen that some of the best -4-

5 analysts have previous experience in roles like accounting, production planning, procurement, and have developed an interest in business applications along the way and have decided to take on the analyst role. Increasingly, on the job learning is king in the analyst trade, and analysts right out of college often struggle and need to get more experience in the actual business before they can become an analyst. The business analyst role is definitely expanding. It's moving out from just the project teams and becoming a more strategic role within the entire IT and business organizations that they operate in. Wow, one of the key things you just mentioned there was how framing the business problem correctly is a huge percentage of the success of the solution. And with that obviously comes with working with various departments across the board. How would you say communication and collaboration across stakeholders is becoming even more critical then? DECANDIO: Clearly strong communication and collaboration skills are a key tool of the trade for business analysts and that's always been the case, and I believe they always will be. They form the basis of a good business analyst. Increasingly, what I see, however, is that analysts play this bridge role between the business and IT. And this can -5-

6 often require quite a genial personality. The best analysts that I've seen are really people persons. To be successful they need to be available. They need to be sought out by the Agile development leads, architects and developers and brought into the Agile process. If they're not approachable, if they're seen as a curmudgeon-ey businessperson, then the development teams aren't going to pull them in. And it's very important for the development teams to pull them in so they stay involved throughout the whole Agile process. Analysts really act as translators and negotiators. They find common grounds, and they're pretty much objective. They're always trying to balance the conflicting needs of business and IT. And they have to understand both sides, and more importantly, be able to speak the language of both sides, and they oftentimes have very different terminologies. In reality, it can be a rather tricky role, and good communication skills, good collaboration skills, it's vital for a successful analyst. So, we talked about collaboration and communication. You also identified that curmudgeons need not apply, that you definitely need to be congenial, and that helps. But you also touched on this earlier, and I -6-

7 think this is really important for the business analyst role, the fact that time to market has become such an important factor in how the Agile process works. So, how would you say that the time to market process for the business analyst has become even more important even when applications are becoming so much more complex? DECANDIO: Yes, so that's a really good question. As you say, in today's Agile world, applications aren't getting any simpler, and we're being asked to deliver them from years of cycle time down to months, weeks and now into continuous delivery, particularly for hosted solutions. So, applications are definitely getting more complex, but they're being built in smaller cycles that Agilists call sprints. We're seeing in Agile delivery that increasingly analysts have to start breaking down their thinking as well, so they can no longer design and spec out the requirements for the entire system at once; they need to start thinking about how they're going to do this a piece at a time. And this oftentimes will need to change as we go through the process. We'll talk about this a little later when we talk about change management. But Agile methodology specifies you always deliver shippable software at the end of the sprint. And in order to do that, -7-

8 compromises will need to be made along the way. So an Agile analyst needs to be working with the architects and the development team to help hammer out these compromises. They need to continue to validate these compromises with the stakeholders and they may need to make changes to their requirements to meet the needs of the schedule or the development team's constraints. Again, staying involved with development teams is an important part of this from the very initial inception of the project all the way through to the end of testing of the project. The best analysts will pick up early builds of the software and iterate with the developers. They're constantly making sure what's being developed meets the intended business goals, and they really in some ways become the first customer of what's being developed. So what's happening here is we're going from analysts working with stakeholders, creating all the requirements, to analysts working with stakeholders, developing high-level requirements for a sprint, elaborating those during a sprint into Agile stories, working with development, all the time thinking about how they're going to do the high-level requirements for the next sprint and the sprint after that. -8-

9 So, it's this continual cycle they need to get into to fit into the Agile team that's very different than some of the more traditional analysts have been used to doing. But it's still a very critical role if not the most critical role of Agile software development. Okay, George. I feel like we're dealing with building blocks here. We've talked about requirements management and establishing a strategy and the importance of communication, collaboration. And then, how you are able to actually manage the complex changes that are going on as multiple iterations are coming out and they're coming out faster. So, that leads me to what you mentioned earlier about change management. How important is it for a business analyst to be able to manage change on that project? DECANDIO: Well, yes, as I've hinted to earlier, it's absolutely critical. So, I'll start off by saying we've been talking a lot about Agile, but in regulated environments, change management is of critical importance. It's a matter of survival. Changes to requirements in regulated environment need to be managed very carefully and often need a very regulated and -9-

10 checked process to ensure that changes are traceable and that any changes made continue to adhere to the compliance and regulations that are in place for that organization. So, this has always been the case in these regulated environments, and this hasn't really changed. And oftentimes when we talk to analysts in the regulated environment, they have very, very formal change management processes and so much so that they have to use tools. This is where you'll start seeing the enterprise requirements management and change management tools are really a critical success factor for these types of environments. In Agile environments, however, change is also critical. If you read any of the Agile literature, you'll see that the change is really central in Agile. Responding to change and iterating changing as you learn more from the small sprints that you deliver and get feedback from stakeholders, change is critical. In an Agile process, however, the change management tends to be much less formal. The good analysts are the ones that are leading this change. They recognize the need for change based on stakeholder feedback, and they embrace it. -10-

11 Oftentimes, this means that they need a change process is very lightweight and focuses more on communication with the stakeholders and with the development teams than it does on lots of documentation or even strong tooling. Agile is all about the entire team communicating frequently and testing out running software, feeding back on that running software and then making changes based on that feedback. And the analyst needs to be a part of this feedback loop and this feedback process in order to be successful. And again, this is oftentimes very, very different from what the traditional analyst role has been. So, what we find is some analysts can't make these changes, and they fall out of favor in the Agile processing or sometimes even ignored by the Agile teams. The best ones do recognize that they need to change the way they work to be Agile as well and to fit in with the team. And when that happens, we've seen really great successes. And that's when Agile really works well. Well, thank you, George. A great overview of the key capabilities that a solid business analyst needs to have and/or develop in this new Agile environment. We sincerely appreciate you taking the time to join us and share your expertise. -11-

12 DECANDIO: You're very welcome. It was my pleasure. That was George DeCandio, Distinguished Engineer, requirements definition and management tools for IBM Rational, with some excellent insights for today's podcast event, Do you have what it takes to be a successful business analyst. To hear this specific podcast or to browse additional topics check out our Rational Talks to You podcast page at ibm.com/rational/podcast. [END OF SEGMENT] -12-

Welcome to this IBM Rational podcast, Bringing. Application Lifecycle Management to IBM i with Rational and

IBM Podcast [ MUSIC ] Welcome to this IBM Rational podcast, Bringing Application Lifecycle Management to IBM i with Rational and ARCAD. I'm Kimberly Gist with IBM. Companies are realizing that they must