Hi everyone! We’re back from a summer break — no, not to go off to some vacation paradise. We were crunching away on our next big O’Reilly release, Head First C#. We’ll post more about it as we get closer to publication which, according to its Amazon page, is due out in just a couple of months.In the meantime, we’ll keep the new posts coming for our regular readers. We love you, readers! And we especially love readers who send us questions, because, as it turns out, Jenny and I get a lot of great questions sent to us. Here’s one we got a few days ago:

Dear Jenny and Andrew,

I’ve been told by a couple of people “business analyst” positions were safe locally in the near future. I found “Applied Software Project Management ” on the internet. I’m currently trying to improve some of my skills, in an effort to re-enter the local job market. I’ve been a developer, programmer, analyst for over twenty years. I love building new software. I know you have a number of books that would be helpful. I’m also reading some of the “Head First” books. Is “Applied Software Project Management” the best place to start to build these skills?

Thank you in advance for your time,

Eric D.
Clemmons, NC USA

Now, this is an especially good question because it lets us plug our first book, Applied Software Project Management. More importantly, it’s a topic that’s near and dear to my heart, since I spent a few years managing a really incredible team of business analysts a while back. I learned an enormous amount from them, and I feel lucky that I can share a little of that with you, too.

It was near the tail end of the Silicon Alley dot-com days, although I was working at a decidedly non-dot-com company. At the time, I’d already been managing a team of software engineers — developers, architects and the like — for a few years at a New York-based financial software company. I felt a lot like Miles Silverburg on Murphy Brown: a relatively fresh-faced manager with a team of seriously seasoned and talented people who, to be honest, knew a lot more about the job than I did. Luckily, I’m a quick study, and I had some really great people to learn from.

First and foremost, I learned a lot more about what makes a good business analyst. Very few people start out as a business analyst — they usually move into the field from another area. Some of my team members started off as software engineers, others started off on the business side. What they all had in common was a deep understanding of users and how to make sure their needs were met. Throw in a healthy dose of project management knowledge, add a pinch of quality engineering, and top it off with a solid background in software requirements engineering tools and techniques, and you end up with a well-rounded, highly effective business analyst.

So that’s a tall order — and I should know, since I had to hire a whole team of people who fit that bill. I’ve gotten a lot of skepticism over the years from people who don’t believe that you really need someone who has such a broad background. And I’m sure that there are plenty of people with the title “business analyst” who can barely do their jobs… because there are people with every title in every industry who can barely do their jobs. But why does it take so much to be a good business analyst?

Consider what the real job of a business analyst is in a software project. She’s got to talk to users and figure out what their needs are. That’s a tough job, because users have a tricky habit of asking for things that don’t necessarily fit their needs. Time and time again I saw the people on my team tease the real needs out of users who, to be honest, didn’t really understand what they wanted. And that’s a really tough job. It requires some very solid elicitation skills, and a good familiarity with software requirements engineering tools and practices (like this one, this one and this one). Because the other part of the business analyst’s job is taking those needs and turning them into a functional solution that can be implemented in software.

That’s one thing that Jenny and I spend a lot of time talking about in Applied Software Project Management. We go over exactly what it means to construct a functional specification, and how that’s different from designing software. Just as importantly — and this is where a good understanding of quality engineering comes in — you need to make sure the users actually understand that solution, which means holding lots of reviews.

Finally, a good business analyst needs to be able to work with the rest of the engineering team to make sure that those needs and requirements actually get built into software. And that’s where a good understanding of project management comes in. She’ll have to work with the team to make sure they understand everything that needs to be built, and she’ll usually play a big role in the estimation — which means she needs a good understanding of estimation practices [PDF].

So to answer Eric’s original question, where should someone start building skills to get a job as a business analyst? If you looked at any of those links, then it probably won’t surprise you that I’d recommend Applied Software Project Management to anyone who wants to get a head start as a business analyst. I also really like Karl Weigers’ book, Software Requirements (2nd Edition). That book was a huge help to me when I was first learning about requirements engineering. I also learned a lot from Software Requirements Engineering (2nd Edition), a compilation of classic IEEE papers edited by Richard Thayer and Merlin Dorfman — including the classic Jim Rumbaugh paper on use cases, which I consider one of the most important papers ever written about requirements engineering. The best book on use cases that I’ve found is Use Cases: Requirements in Context (2nd Edition) by Daryl Kulak and Eamonn Guiney. When I was hiring business analysts, I would definitely have been pleased with a candidate who was familiar with the concepts in these books.