Skip to content

Report

The Discovery Report if the deliverable for the Discovery Project.  Everything that was learned, created and quoted belongs in this document with external links, if needed.

1. Executive Summary - The executive summary section

1.1 - Project Process 

This section should contain material about our development process and SDDR (Software Development Done Right).  This is regular boilerplate for our quotes.

1.2 - Project Overview

This section should outline the original project overview in the Discovery Project SOW.  If it is still germane to the Discovery Project, then it can simply be copied from the SOW.  If not, it should reflect the outcome of the project.

1.3 - Original Requirements

This section should outline the original requirements in the Discovery Project SOW.  If it is still germane to the Discovery Project, then it can simply be copied from the SOW. If not, it should reflect the outcome of the project.

1.4 – Team

This section is simply a list of the team members that actually worked on the project and their position within Lab651.  It is not necessary to call out what engineer did what task.

2. Budget Review

This section will go over the original Discovery Project budget and compare it against the actuals.  The goal here is expose where we spent our time and the client’s funds.

2.1 - Estimated Budget

This is the original budget from the Discovery Project SOW

2.2 - Budget Actuals

There are the actuals for the project formatting in the same fashion as the Discovery Project SOW.

2.3 - Budget Analysis

This is an analysis of any differences in the estimated and actual budget.  The goal is to explain why we came in under or over.  The reasons should be listed here.

3. Product Assessment

This section should contain an overview the product itself that we defined during the project.  It should give an overview of the product that is to be created including motivation and any market research or discovery exercises that were completed.  

4. UI Assessment

This section should contain any UI that was designed during the projects.  It should include call-outs and explanations of all details in the UI.  If there is no UI, this section should be removed.

5. Workflow Assessment

This section should contain any workflow diagrams and workflow explanations for how the system will work.  This should include any/all components that are part of the workflow, including cloud providers and the components in the cloud, if being used. If there is nothing that needs to be explain, this section should be removed.

6. Technical Assessment

This section should contain any technical details that are part of the project including hardware schematics/diagrams.  It should also include an overarching architecture diagram.  Even if the project is just an app on the phone, it still has external connections.  And, in the rare occurrence that there is not external connections of an app, the architecture should include the phone resources being used (e.g. local storage for settings, etc…)  If there is nothing that needs to be explain, this section should be removed.

7. Risks and Assumptions

This section outlines any risks and assumptions for the project going forward.  This is important when the project relies on special connectivity to a resource or custom hardware, or the project relies on software technology that is EOL’d or in alpha/beta phase.

8. Ongoing Cost Assessment

This section should contain any ongoing costs that will be incurred by the client.  For example, if AWS is being used, what will the cost of the components be and what are the components being used?

9. Quote

This section should contain the quote for the project.  This document is not the document that will be signed for the SOW, so a new SOW for the work will need to be created.  It’s important that the fidelity of the quote from Lab651 is recorded, so if quoting changes, do it in the new SOW and not this document.

10. Summary

This section should be a summary or project, but since this document is quick complete, it can be left out if there is nothing left to write.  

There is a template for this here.

  • Estimation — estimate fidelity and quoting rules