There are a number of design approaches, but for the majority of projects a validation and verification requirements matrix (VVRM) is a useful model to map against the user requirements and system design.
In order to facilitate the project assurance process, compliance with requirements may be achieved by linking the VVRM two tests, trials, demonstration, analysis and inspections within the relevant plan and then to the project schedule.
Key review points should be identified, for example preliminary design review, or critical design review, where certain requirements must be met before the project proceeds any further.
At these your views, requirements and acceptance criteria should be validated prior to testing to ensure that they are still appropriate. If not, they can be amended to the relevant change process.
The VVRM should be updated as requirements are met to their acceptance criteria. Handover and closeout of all requirements and assumptions should be captured in a formal acceptance process.
The works information is split into two parts: employers and suppliers:
Employers information specifies the works to be carried out by the supplier, including technical information specifications, system requirements, drawings, and any constraints relating to the supplier for example safety requirements and consents required, and so forth.
Suppliers will respond with details of how they propose to deliver the works in line with the customer’s requirements unless agreed otherwise. In some industries, the suppliers response is known as the statement of work, as distinct from the works information.
Each work information team must be linked to the formal requirement that generates it. This is to ensure that scope creep is not generated by the creation of the works information, or indeed that scope gaps do not appear.
The schedule must contain all the works identified in the works information.
A statement of work (SOW) explains in clear language the customer’s needs and requirements, and is therefore often initially drafted at the bid stage of a project by the customer to facilitate the preparation of proposals from multiple potential contractors.
It is often developed in line with the business case, and the SOW will then form the basis of contract or selection and contract administration.
The SOW defines all the work that is required to be undertaken in order to develop or produce the outputs of the project, along with work performance requirements for the project. For example this could include service levels, minimum downtime, specifications of building safety, structure, size, and so forth.
The SOW includes qualitative and quantitative design and performance requirements that can be measured to determine project success.
Once a contract has been awarded to a supplier and a project commences, the project team often breaks the top level SOW into individual or work package SOW’s, creating a more detailed and lower level WBS structure than that which was submitted a bid stage.
This facilitates clearer definition of the work packages, as the SOW requirements can be traced through the WBS structure, and ownership can be clearly assigned to the work packages.
Relevant parts of the SOW’s which are referenced in a WBS Dictionary are then considered alongside the constraints, risks, assumptions, interfaces, dependencies and opportunities.
This produces the scope baseline for the project team to estimate work schedules and costs.
As schedules are worked up, the basis of estimates for duration of activities and cost estimates is recorded for both project audit purposes, and schedule and cost risk assessment activities.