Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
In a predictive development approach is there any time when the project manager no longer collects requirements?
If so, what is this moment? Saving Changes...
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
Collecting requirements is a continuous process that is done by default through stakeholders management and engagement so until the project is formally closed, in my humble opinion, this remains a continuous process.
Being a predictive lifecycle doesn’t mean you should stop gathering requirements because a requirement might indicate a major an important change to the project. Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
Certainly, though, does not mean they will be incorporated into the current execution iteration unless a change order is submitted and approved. Additionally, with progressive elaboration, requirements would be continuously gathered for the upcoming phases. Saving Changes...
While the volume might flow down to a trickle towards the latter part of a project, a good PM remains vigilant for the emergence of new needs & wants which could result in a better outcome for their client. While they may not be the prime role for requirements management if a BA is on the project, they are still responsible for facilitating the decision making related to changes to the requirements. Saving Changes...
For our organization, requirements are collected into an official document called "Statement of Requirements", and then these are transmuted into another official document called (Statement of Work) which forms a part of the contract. Requirements can be changed throughout the project/ equipment life-cycle process, but are officially recorded and approved, as there could be impacts to scope, cost and schedule. There are provisions to accept equipment that does not meet specific requirements using waivers and deviations through the configuration management process. Saving Changes...
Wade HarshmanScrum Master| GDITIndianapolis, In, United States
I've never been on a project where requirements and change requests stopped coming in. Not until the very end, at least, when people finally understand the cost of their requests. Saving Changes...
Yes, requirements is an ongoing thing. It can come in at anytime during the project lifecycle of the project. It is part of progressive elaboration and should be documented in a central repository tool like TFS or a Document Management system related to the projects.
We will need to prioritize and execute the key vital requirements first and the remaining should be looked at in the form of new change request for the project. In doing so, very important also to ensure the timeline and cost are kept incheck with customer expectations. Saving Changes...
Paul AzanorProject Consultant| Lagos NigeriaIkoyi, Lagos, Nigeria
In a predictive development approach,the Scope, Cost and Schedule are determined early in the project.(PMBOK Guide). If requirements are continuously collected then this is no longer predictive.Once all planning is completed, the project progresses into execution after which any new requirements will be handled via a structured change management system where the impact of cost and schedule will be taken into account. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Yes.
The PMBoK process of collecting requirements is executed "once or at predefined points" of the project. Predefined points may be backlog refinement/grooming sessions or in a phased approach reviews of prerequisites.
(PMBoK is applicable to waterfall and agile life cycles, as it focuses on project management tasks, not developer work).
Besides this, change requests may come up at any time, mostly out of stakeholder engagment activities. Saving Changes...
Requirements will continue to evolve beyond the delivery of a product. That is the nature of program management. In a project environment however, at some point in time a stable baseline is required if you ever expect to deliver the product.
As the enterprise level process SME on this subject, I will offer this from a classic Systems Engineering perspective when dealing with mandatory gated reviews:
At Preliminary Design Review (PDR) where development changes from conceptual architectural design, to detail level design where your technical people are adding the details to the concept, requirements should be complete and well understood. If significant new requirements are discovered beyond that point, there is a risk that the product architecture will change requiring major rework.
At Critical Design Review (CDR), the detail design starts to become a physical product where the cost of changes increase by an order of magnitude. Fixing paper errors are much cheaper than reworking a mechanical device. Finding significant new requirements at this point is a very high risk and may prevent the project from passing the next gate.
That is not to say that a product won't evolve for its entire lifecycle, which can be decades after first delivery. To get the project itself complete and the Unit #1 delivered, at some point you must draw a line on what requirements are in the baseline, of you never have a deliverable product. Unit #2 may have new requirements incorporated. That's fine and why we have configuration management and lists of things to incorporate when it is efficient to do so. Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
And let's not forget that you will have product requirements and project requirements. While you will need to set your baseline on product requirements, you probalby have more flexibility with project requirements. Saving Changes...
Community Champion
