Final project deliverables

At the end of the construction phase, the EPC contractor will prepare the final project documents (Table 2.5) and submit them to the company. Generally, these will be split into engineering and vendor-related document dossiers. The project team will check the completeness and accuracy of the dossiers, and send comments so that EPC contractor can update these documents quickly. This activity is very important as these documents will be used for the entire life of the revamped plant and will also provide a basis for future revamp projects. 

---

The scope of the project includes not only the definition of the final product deliverable but the level of work effort required to complete this project. For example, a new pharmaceutical drug will be used to reduce long-term intractable pain, will be in an injectable form, and will use existing packaging configurations in defined concentrations and formulations. This is an initial, general definition of the product scope. The project scope, however, is much more time consuming and complex to develop and would include ... 

Archiving entails compilation and organization of appropriate project documentation and submitting it for filing in a designated repository. The project file should include at least the project definition, the project workplan/budget, copies of key deliverables, the final project status report, and the results of the project performance assessment. 

The ontology has been developed using various data sources. Globally, more than 100 references, of scientific, technical and regulatory nature, have been identified and systematically reviewed. After analysis, a portion of the sources turned out not to be useful for the ontology description. At the end 62 documents have been used to develop the final 22 sub-ontologies (reference list available inside the project deliverable). 

THO 13] Thomas P., Muhlrad N., Hill J. etal. Final Project Report, Deliverable 0.1 of the EC FP7 project DaCoTA, 2013. 

YAN 12b] Yannis G., Evgenikos P., Aarts L.,. Design and development of the road safety data warehouse - Final Report, Deliverable 3.7 of the EC FP7 project DaCoTA, 2012. 

E. Schoitsch, G. Sonneck, G. Zoffmann, AMSD-Project IST-2001-37553, Dependable Embeddded Systems Roadmap, Part I and II - Final deliverable V5.0 (www.am-sd.org)... 

As with most project plans, it is important for the VMP to include a definition of personnel roles and responsibilities. Numerous documents may need to come together to validate a system (e.g., specifications, SOPs, protocols), and team members must agree upon who will be responsible for specific deliverables, as well as approve the final documentation. 

In the case of method transfer, contracts should include specific milestones defining successful completion of parts as well as the whole project. As a minimum, the contract should contain the number of experiments and documentation requirements for the method transfer results. In addition, early definition of criteria for success and failure of experiments and responsibilities for repeating failed experiments, sets the stage for a smoother process throughout the project. The contract should also state, as part of the deliverables, the level of documentation of method protocols and content of the final report. 

The network includes 4 MS, 10 NMS and 3 ACC. Activities carried out in 17 countries need a timely and firm coordination. Therefore, the management of SAFEFOODNET is assigned to a specific work package (WP1). WP1 addresses the co-ordination of administrative and scientific areas of the project. It will assure a well-timed delivery of internal and official documents. WP1 has the task to create and maintain the administrative and technical archive of accounts, contractual record, and progress reports, intermediate and final deliverables. Moreover, the management will include organisation of project meetings communication with European Commission, circulation of documents to partners. 

The steering committee has a number of roles. It provides direction to the project reviews deliverables, as appropriate receives periodic reports regarding project progress, status, difficulties, and near-future activities helps clear roadblocks as they occur and provides final approval that the project has been completed satisfactorily. 

Time, cost, and quality performance are three key project parameters that should be subject to assessment. Time performance can be assessed by comparing the originally planned completion dates of deliverables, both interim and final, with the actual completion dates. Causes of any material schedule slippage should be determined and means for precluding them in future projects developed. A similar assessment of project cost can be conducted by comparing budgeted to actual expenditures and then examining any material favorable and unfavorable variances. 

Results Broadest and the longest in terms of ability to evaluate achievement Useful in defining services and products for future deliverables, downstream projects, or subprojects Most amount of latitude in terms of final product. "Perfect Order" as defined by selected metrics Bill of material cost reduction goal A goal for gaining new customers in an underserved segment... 

Design outputs should conform to design input requirements, which should be structured so as to be traceable to that purpose. Design output procedures should contain or make reference to acceptance criteria. These procedures are there to ensure that the outputs are adequate enough to evaluate functions of a product, which may include product subsystems, outputs from risk analysis, and final product specifications. It is necessary to specify and enumerate the design output as part of the roles and deliverables in the project plan, and then revise and update it whenever needed. Deliverables of outputs should, at least, include ... 

The safety case evidence report is the final deliverable of the assurance process. Since the safety argument should be designed to be abstract, it is possible for a single version of a safety argument to cover multiple software installations, or multiple deliveries of a phased-delivery project. However, the safety case evidence report will need to address a specific software version and a specific installation. The safety case evidence report will identify the unique set of relevant evidence for the safety case. It will need to refer to the baseline of the software (which may be addressed by standard documentation such as a release note) and it will need to relate this to the appropriate set of safety evidence, including system level evidence. Each installation may have unique evidence specific site constraints a unique history of field experience perhaps using previous versions of the software, and different experiences of commissioning. 

During the third week share a draft of Chapter 1 of the report with project team members and ask for input, then share a revised version with the faculty and outside sponsor and continue this pattern. The frosting on the cake with the suggested start on Day 1 approach is that you and your team are much more likely to produce a final report whose quality reflects or matches the quality of the underlying work. Why Because you avoid last minute rushed report preparation and the inevitable errors and omissions. Sadly, such rushing often produces a mediocre document about an excellent project and the document, not the actual work, communicates project mediocrity to the readers. Clearly, the start on Day 1 advice can be applied to other deliverables such as plans and specifications. 

Firstly, with each WP is associated an effort, measured e.g. in the number of person-hours (estimated or actually) required to perform the work (this may be subdivided into disciplines). This provides a relationship between resourcing and duration of the WP. Secondly, besides manpower, many WPs will require other resources, such as computer time, manufacturing facilities, construction equipment, test facilities, and so on. Thirdly, with each WP we can associate a risk profile in terms of the maturity of the technology employed, the experience of the allocated personnel, etc, and there are numerous other fields that can be added to this project data base. Finally, as each WP is defined in terms of its outputs and the inputs required to deliver these outputs, this defines the interfaces between the WPs (and the interaction of the project with its environment, in the form of project inputs and deliverables). This then provides the description of the work as a system, i.e. as a set of elements with particular interactions and thereby a particular structure. This, and not the hierarchical structure of the WBS, is the structure of the work as a system, and the temporal aspect of this structure is what is usually called the project program. 

---