Difference between revisions of "Final Report"
From PDP/Grid Wiki
Jump to navigationJump to search| Line 4: | Line 4: | ||
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. | 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. | ||
| − | + | ||
| + | == Report Format == | ||
| + | |||
;Introduction : Basically the why of the project. | ;Introduction : Basically the why of the project. | ||
;Work Done : How it was done and why this way. | ;Work Done : How it was done and why this way. | ||
| Line 12: | Line 14: | ||
;Appendix : Here are tables, graphs, config files, and everything else | ;Appendix : Here are tables, graphs, config files, and everything else | ||
| − | + | === Introduction === | |
Briefly discuss the background, motivation, and goals of the project. Include a one-or-two-sentence summary of the overall result(s)�kind of like an abstract. | Briefly discuss the background, motivation, and goals of the project. Include a one-or-two-sentence summary of the overall result(s)�kind of like an abstract. | ||
| − | + | === 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 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. | 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 === | |
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. | 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 === | |
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. | 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 === | |
Wrap things up. Talk about the limitations or scope of the findings. | Wrap things up. Talk about the limitations or scope of the findings. | ||
| − | + | === 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. You can reference the appendix in the report, but do not depend on it�most readers external to the project should be able to know everything he or she wants to know without ever looking at the 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. | 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. You can reference the appendix in the report, but do not depend on it�most readers external to the project should be able to know everything he or she wants to know without ever looking at the 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. | ||
