A project hypothesis states the proposed purpose of a project, its expected outcome, and the major challenges to overcome. For an ML project, it connects a business problem to a plausible use of available data rather than assuming that ML will fix the problem. It gives the customer and delivery team a shared basis for deciding whether the work is valuable and feasible. section 3.1 section 2.3.2
Build the hypothesis from requirements, then test it with the people who must support and deliver it:
- Document the challenges and benefits stakeholders describe. Identify the business value that could justify the investment. section 3.1
- Check the proposed outcome against the available data, system architecture, and nonfunctional constraints. Record potential outcomes in light of what is known. section 3.1
- Use feedback to reach consensus with the customer and delivery teams. Communicate the agreed hypothesis clearly and document it in any contractual agreement. section 3.1
Pre-sales ticket PS10
Ticket PS10 turns the hypothesis into a deliverable: understand the core business problem, build a consensus statement, validate it with the customer and delivery teams, and carry it into the contractual documentation. The statement can then guide more specific requirements and user stories. section 3.1 section 2.3.2
Figure 3.1 The project’s drivers (Business Priority and Business Case), the supporting components (Sufficient Funding, Technical Means, and Data Resource), and enablers (Utilization Method).
Use the project-drivers diagram to check that business priority and business case are supported by funding, technical means, and data resources, with a way to put the result to use. section 3.1
The hypothesis is a pre-project decision tool, not a promise that the proposed ML solution will work. Once requirements have been expressed as an expected outcome and key challenges, the team can estimate effort using what it knows about the delivery environment and prepare a proposal for review and sign-off. section 3.0 section 3.7
