Ahmed KhalilEx. Chief Projects Officer & Current COO & GM | FFS LLCDubai, Dubai, United Arab Emirates
Introducing Collect Requirements process was a very good step in the right direction.
But isn't it time to take it to a higher level emphasizing on the importance of requirements management for projects success.
Introducing a new knowledge area in the PMBOK called "Requirements Management Knowledge Area" isn't it the right time?
Isn't it adopted by most practitioners in most of the projects most of the time which qualify it to be part of a standard when its recognized, documented and approved. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Collect requirements is not a knowledge area. And I do not agree about introduce requirement management. First of all, we need to understand that we are talking about project requirements. Project requirements is about to Project scope. So, all related to Project requirments have to be included inside project scope, in my opinion. Saving Changes...
Ahmed KhalilEx. Chief Projects Officer & Current COO & GM | FFS LLCDubai, Dubai, United Arab Emirates
Thanks Sergio for your opinion.
Letus see others input.
And here is my input for project requirments life cycle:
- Initial info about requirments are in the project charter
- Then we must plan for Requirments management and accordingly we get requirments managment plan part of over all project managment plan.
- Then we need to execute what we have planned and conduct our workshops or interviews .. etc .. and document requirments then approve it.
And further steps to follow under controling and closing .. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
There is a lot of information outside there from standards (IEEE for example) to PMI´s "Requirements Management Practice Guide". So, in my case, I allways tried to not reinvent the wheel and adjust all the information to my actual initiative need. Saving Changes...
Avinash KharePM II| MAP-IT Consultant Project ManagementAmbernath (East), Maharashtra, India
I agree with Sergio, Scope as a knowledge area and a whole take care of the requirements management. Saving Changes...
Maybe some of the Knowledge Areas, can be improved or update. Maybe the PMI institute will do in the next edition, but anyway, Requirements management is not a knowledge area, I'm agree that is included in Scope Management.
You can think backwards, in order to understand, you have this ¨new KA¨Requirements Management, if you try to fit in the different process groups:
This is not a detailed example, only a fast review.
Initiating: Already covered by develop project charter
Planning: Included in plan scope management, collect requirements, define scope and WBS
Executing: Same as Project Integration management.
Monitoring and Controlling: Validate & Controlling Scope
Closing: Same as Project Integration management.
As you can see, if you include your new KA you'll be duplicating information . Saving Changes...
As pointed out by my colleagues, requirements management is a subset of scope management. When you look at the current knowledge areas, none of them is a complete subset of another. For sure, there is overlap but each one has its own set of particularities, perks and processes.
Put it another way: if you did have a knowledge area for requirements management, what would be left in scope management? Saving Changes...
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
I totally agree with Sergio and my other fellow colleagues. Requirements Management is built into the scope management and other KA's. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Agree with the comments.
Like benefits management is part of the Program Management Standard, requirements management is in depth described for the Business Analyst and as Sergio points out in other Guides.
While I agree that PMs sometimes have to dig in deeper in both requirements and benefits (or get specialists on board), I would suggest not duplicate definitions. Saving Changes...
I think it might be necessary to consider Requirement Management more critical based on the specific domains applicable and which might use more frequently the Requirement Management. PMBOK is the guide to be applied in majority of application areas.
However, like separate KAs between Communications and Stakeholders Engagement, if majority of practitioners agree that necessity of separate approaches between project scope and product scope might be more viable, then Requirement Management for only product scope might be possibly separate. Now it is true that there might be confusion that project scope generally include product scope in the project scope statement. Saving Changes...
Thomas CooperPMP, CSPO| State of Tennessee Department of Health Care Finance and Adminstration PMONashville, Tn, United States
Perhaps 'Requirements Gathering' has become so critical to project success because most projects involve software development. The single greatest cause of failure is in 'requirements identification'. Even well executed requirements gathering often require changes and we accept this as commonplace where change requirements for procurement or quality or resources are not as disruptive, expensive or time consuming. Saving Changes...
Community Champion
