Author: Terry Longo

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]

Terry Longo’s Monthly Blog

During two of the three recent Project Summit / Business Analysis World conferences, I had the privilege of moderating a roundtable discussion whose topic was “The Dual Role of Project Manager and Business Analyst: Is it Possible?” It is, of course, no surprise that it is not only possible, but very common. (In my informal polls of audiences at my presentations, it seems that roughly 10-30% of the people in the audience are playing both roles).

The underlying question of course is “Can it be done well, and what are the benefits, costs, and risks?” And, in light of our intensifying efforts to professionalize the business analyst role, this question is vital, for it has significant implications for the organization relative to:

• Job definitions 
• Career paths for people aspiring to or in PM- or BA-related roles 
• The manner in which stakeholders engage with requirements teams and solutions teams 
• The nature and rigor of the requirements-related language present in the organization’s culture 
• The design of processes, policies, and tools underpinning PM and BA activities 
• The practitioner’s ability to distinguish between requirements-related change and risk and project-related change and risk

As far as the factors that make it workable with acceptable results, the two I hear about most are: 

1. Small projects 
2. The absence of compliance-related documentation requirements. This is interesting, since being in a compliance environment demands so much in the way of documentation of project and requirements activities, that it can be overwhelming for one person.

The questions in my mind now are (a) if there are other factors in favor of the dual role assignment, what are they, and (b) if there are no advantages on larger projects, why are we (the collective we, of course) doing it to ourselves?

Much of the answer lies somewhere in the current recognition of the role of the Business Analysis Center of Excellence, a part of the charter of which would be to understand more deeply the dynamics of the dual role, and only support it where it is justifiable in terms of risks and benefits.

Without that risk/benefit view, it seems to be, well, risky.

---

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, Project Management and Business Analysis curriculums in the US. Terry can be reached through http://www.hp.com/education/section/pm_bus_analy.html or at [email protected]