A BA by Any Other Name?

Quick – what are the job titles of the people who attended the panel discussion Defining the Various Roles and Responsibilities of the BA Professional at the Project World / BA Summit in Palo Alto? If you answered Business Systems Analyst, Data Warehouse Analyst, IT Business Analyst, Systems Analyst, Process Analyst, Product Manager, Program Manager, Process Manager, Business Architect, Web Analyst, Requirements Analyst, Solution Architect, Business Business Analyst (really!), Application Architect, Operations Engineer, Operational Analyst, Information Architect and Business Analyst, you are correct!

And the one element common to those jobs, unanimously agreed by the attendees, is requirements management. Interesting. Not business analysis, but requirements management. For as the titles suggest (and as confirmed by several hours of job description investigation at monster.com), many of these jobs are defined within specific domains (business process, Web apps, data warehouse, etc.) and are connected to the domain of enterprise strategy by virtue of their contribution to the value chain.

Now some points to consider: 

• Given the above, it seems safe to say that not everyone who does requirements management is a business analyst. 
• The IIBA, the BABOK, IIBA chapters, and BA-related media and events are very interesting to anyone who does requirements management. 
• Excepting (perhaps) the Enterprise Analysis section, the BABOK presents a useful framework for any job involving requirements management.

The IIBA’s plans for the BABOK 2.0 (see the subsection “What changes are planned for version 2.0?” here) represent significant benefit to BAs as well as requirements management practices in general. The two changes that I think are vital in terms of their direction-setting nature are: 

• Requirements management tasks reframed as applicable toward iterative, agile, and maintenance activities 
• Applicability to business process based solutions as well as software solutions

I interpret these changes as a separation of content (business analysis, process analysis, data warehouse analysis, etc.) from process (plan/manage requirements, elicit, analyze, document, validate).

If the BABOK is broadened to include a general treatment of requirements management, does it strengthen or weaken the IIBA’s ability to professionalize the BA role? I say it strengthens it significant way. And I hope you come back in a couple of weeks to learn why.

---

Terry Longo

has more than 25 years of IT experience, including software development, system and network administration, and instructing, as well as being responsible for the requirements, project management, and delivery aspects of complex training solutions. He currently holds the IT Service Manager ITIL and is responsible for HP Education’s ITIL/ITSM, Project Management and Business Analysis curriculums in the US (see http://www.hp.com/education/sections/pm_bus_analy.html). Terry can be reached via email at [email protected]