Gathering Requirements

I was going to post an article on gathering requirements. I went through the PMBOK 3rd Edition & followed up on the 40 or so references to requirements. I solicited requirements gathering tips from various groups. Then I read Chapter 5, section 1 of the new PMBOK 4th Edition. There's not much left to blog about as far as gathering requirements go. This is one of the best written, most comprehensive & informative PMBOK entries I have ever read.
Last month I wrote an article about Software Development Stakeholders. I even invented a spreadsheet of stakeholders, their interests & influences. Lo & behold, the new PMBOK shows a Stakeholder Register as in input to the Gathering Requirements process. This register is defined in section 10.1 & has most of the attributes present in my stakeholder list. Indeed, almost evey topic I had come up with was covered in the Gathering Requirements section.
I did get some userful responses to my queries. Vincent Chiew (ITIL FFCP ISP CISSP CSSLP PMP PEng) , reminded me of that public sector projects may have thousands of stakeholders & that made surveys & public meetings one of the few ways to obtain requirements from large groups of stakeholders. Epifanio (Jun) Bucao (PMP)(BAS), whis both a PM & a Business Analyst, recommended Rapid Requirements Discovery as a method for gathering requirements, which brouoght up the whole subject of Business Analysts. In my own personal case, we don't have Business Analysts per se, but their function is performed by our own Software Consultants, who have considerable industry experience & contact with our customers.
David Gilbert, D.Sc. PMP, introduced me to the BABOK, the Business Analyst's Book of Knowledge. Now I have another book to read. It's clear to me that Business Analysts have a place in defining the real business needs, and that they have an advantage in doing the root cause analysis of the business case. I'd love to have them analyse prosective projects before they even get to me, so that I don't have to spend an inordinate amount of time finding the real problem to be solved.
Kit Johnson, PMP, reminded me to focus on the need & not on the project. The Business Objective & Goals are much more important than the design. As in everything to do with PM, it's aways important to remember that people are what make successes.
I never did get a list of standard questions to ask in an interview, which was one of the things I had asked for. I guess there are no shortcuts, every project must be approached as a single unique problem, so there's no magic list of standard questions, even for applications development. I always ask if the project is replacing an existing app or process, & if so, why does the user want to change what they already have. A series of 'Why?' questions usually leads to the root cause. If there is an existing system, I try & watch it in use & talk to both the user & the customer about the system.
In closing, the new PMBOK's requirements section is magnificent. I'm so impressed by the document, that I've signed up for a course on the differences between this edition & the last. This course is given in conjunction with the South Florida PMI Chapter. I'll report on that when it's done.