Susan Hall spoke with Glenn Brule, executive director of Global Client Solutions for ESI, about the skills required in its Top 10 trends for 2011 in requirements management and development. (See slideshow.) ESI offers training in project management, program management, business analysis, business skills and contract management. This is the second of two parts.
Top 10 Business Analysis Trends for 2011
A better balance between technical and soft skills will separate the leaders from the rest of the pack.
Hall: I noticed when you were talking about scrum, you said the organizations that have the most success will be those that acknowledge the skills of both project managers and business analysts. Do their roles kind of overlap? Don't they need clearly delineated responsibilities?
Brule: That's a real challenging question to answer because it's a shift in the way we view the world. Two years ago I would have said the role of the project manager is to draw a line around the sandbox and say, "Thou shall operate within this box." And the role of the business analyst is to say, "Here are all the pieces of the puzzle that fit inside that box." So PMs are saying, cost, time resources and the business analyst is plugging in the business requirements. It's shifting in that we both have our respective disciplines, and they're critically important to the success-and I'm saying this deliberately-the success in the delivery of goods and services.
But in a scrum world, we have the scrum master, who is essentially removing any impediments, say if we need more resources, we need more space or whatever The rest of the scrum team, yes, they have their particular areas of expertise, but they're all expected to pitch in. When I did my scrum certification, my expertise was business analysis and a guy sitting next to me was a software developer and then we had a graphic designer and so on. But when it came to uncovering the requirements, we all pitched in. When it came to graphic design, we all pitched in. In fact, there I was drawing pictures and doing storyboards and stuff like that.
In the context of scrum, everybody is expected to contribute to the tasks at hand, regardless of your area of expertise.
Here's another way to explain it: I compare the scrum world to the fireman, policeman, paramedic scenario. If the fireman were walking down the street and saw someone getting mugged, he could wrestle the mugger down. But he couldn't necessarily negotiate a hostage situation. Or if a policeman could put a fire out in a garbage can, but couldn't fight a five-alarm blaze. Nevertheless, when everybody's on the scene, they're all pitching in and helping out wherever possible.