How do you determine who needs to concur with a change to requirements?
Justin FuSenior Systems Engineer| ParsonsBristow, Va, United States
How do you determine who needs to concur with a change to requirements? Saving Changes...
Sort By:
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Putting this in terms of PMI´s roles (and something I am using today and I used from years ago) the Business Analyst is the "owner" of requirements in terms of managing them. But you have product requirements and project requirements. The last ones are defined from the first ones. Project manager is the "owner" of project requirements. So, when a change on product requirements emerges the business analyst work with project manager to define all related and needed information to present it to steering committee or the name you use to call people that will take the decision for moving forward or not with the change. Take into account that a change not only impact on the specific project. Saving Changes...
It really depends on your scope change management process which was tailored and defined for the needs of your project. I'm assuming you are referring to a situation where requirements have changed after they have been approved.
In a project following an adaptive life cycle, the stakeholders most directly involved with the requirements being changed should be engaged but there may not be a formal approval of the change so long as the impacts of the change don't cause you to exceed your cost, schedule and other approved baselines.
On a project following a predictive life cycle, a more traditional scope change management process would likely be followed with a review by the affected stakeholders (upstream and downstream) prior to approval by the appropriate governance bodies.
The impact analysis performed by the delivery team will usually help in identifying who needs to be engaged in the review process...
One factor is how your project organization is structured. On a smaller project, it may just be the sponsor that needs to approve the change. On a larger project, you may have a Change Control Board.
Another factor is timing, or the stage of the project. If you're still early in Initiation, you may be dealing with a different group of people than you would be later in the project. Approval for requirements can also change as you get closer to launch. For example, when we were upgrading SAP ERP, as launch drew nearer, the types of changes we would accept and the level of approval needed both got more strict, to the point that in the final weeks before launch, changes had to be approved by the senior director. Only break/fixes and minor, low impact changes would be approved. Saving Changes...
It should be part of your requirements management plan as the approval depends on the requirements.
Regulatory requirements may include input from affected industries before any new or changed requirements, and may have sweeping impacts across enterprises.
Customer driven requirements may affect contracts and may include larger decisions such as whether to implement a change to only the one customer or apply them to the baseline.
Project requirements may fall under the authority of the PMO. Beyond a certain threshold, they may require higher executive approval.
Product requirements also vary by impact and authority since requirements are constructed as a hierarchy, and are often linked to affected product definition. A new or changed requirement may or may not require a change board approval depending on the level of the requirement within the hierarchy. Saving Changes...
Peter RapinSubject Matter Expect; Project Delivery| Independent ConsultantOntario, Canada
Is this not one of the purposes of a Project Charter, to define what it is the project is to achieve (scope, cost, time) and establish protocols for any changes to that objective. That being the case, the parties who signed the Charter would need to concur with any change to the project objective(s).
As to the Project Plan, this defines how the project is to be delivered and any changes to the 'how' is in the purview of the Project Team as long as it does not impact on the project objective. Saving Changes...