Difference between revisions of "Final Report"
From PDP/Grid Wiki
Jump to navigationJump to search| Line 2: | Line 2: | ||
== Purpose of the final report == | == Purpose of the final report == | ||
| − | Project results should be accessible usable to | + | Project results should be accessible and usable to all PDP staff, and in some cases to external stakeholders. The results should be presented in standalone fashion. Detailed knowledge of the methodology and implementation should not be required to read the report. The report should refrain from jargon when explaining methods and recommendations. |
The report should follow the following form. | The report should follow the following form. | ||
| + | Summary: | ||
| + | # Introduction Basically the why of the project. | ||
| + | # Work Done How it was done and why this way. | ||
| + | # Findings This is how it is; this is what that means | ||
| + | # Recommendations This is what we should do; this is what will happen | ||
| + | # Limitations / conclusion This is how we could get better results | ||
| + | # Appendix Here are tables, graphs, config files, and everything else | ||
* Introduction | * Introduction | ||
| − | Briefly discuss the | + | Briefly discuss the background, motivation, and goals |
* Work Done | * Work Done | ||
| − | Talk about work done. In some cases this will be a summary of what was produced, in others a summary of methods and tests used. Remember, no | + | Talk about work done. In some cases this will be a summary of what was produced, in others a summary of methods and tests used. Remember, no jargon. Discuss why the approach chosen was the most appropriate given the motivation and starting situation. The discussion need not cover all work done in the project, focus on the work most directly relevant to the findings. |
* Findings | * Findings | ||
| − | A summary of the results. Include relevant numbers / conclusions and what they mean in the real world. | + | This section and the next should constitute the bulk of the report. A summary of the results. Include relevant numbers / conclusions and what they mean in the real world, relative to potential real-world applications of the project findings and results. Again, in the case of various approaches taken during the project, the main body of the report (in the Work Done or Findings sections) do not need to describe all of them; most important are the results that are most accurate and/or most relevant to the findings and recommendations. All other tests and results should go in an appendix. |
* Recommendations | * Recommendations | ||
| − | + | This section is where, based on the a) the original project motivations and goals and b) the work done, methods, and results/findings, recommendations are made for future activities or deployments. | |
* Limitations / conclusion | * Limitations / conclusion | ||
| − | Wrap things up. Talk about the limitations of the findings. | + | Wrap things up. Talk about the limitations or scope of the findings. |
* Appendix | * Appendix | ||
| − | + | Everything else goes here. It might be documentation of configurations, pointers to code repositories, detailed explanations of algorithms, details relevant to the final results and recommendations. Include the relevant tables and graphs to document how the final result was arrived at. appendi(x)(ces). Recommendation: do not write the appendix after you have finished the report. One approach is to treat it like a log or a field journal. That document becomes your appendix and will make it infinitely easier to write the final report, which summarizes the project. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
