Phase 1: Project Initiation
Deciding what is being built, for whom, and how anyone will know it works.
On this page
Project Initiation is the phase where the idea gets written down in a form that engineers can work from and that the owner can hold them to. It is short, inexpensive compared with everything that follows, and the most frequently skipped step in the whole process. Almost every expensive surprise later on traces back to a question that should have been answered here.
What the phase is for
The question this phase answers is: what is being built, for whom, and how will anyone know it works? The answer takes the form of two things:
- A shared understanding. The owner, and whoever is going to do the engineering, agree on what the product is for, who it is for, what it must do, what it must not cost, and what "finished" looks like.
- A first written set of requirements. Usually called a requirements document, a product requirements document (PRD), or a functional requirements specification (FRS). The name varies; the purpose does not.
Nothing is designed in this phase. That is deliberate. Designing before the requirements are written produces a design that answers the wrong question.
Discovery
The work of this phase is usually called discovery. It is a structured conversation, often spread over a couple of weeks, in which an engineer asks questions and the owner answers them. The questions cover:
- The user. Who uses the product, where, and how often. What they do today instead.
- The job. What the product must do, in plain words, before any technology is chosen.
- The constraints. Target price, target size and weight, environment (indoors, outdoors, wet, hot), safety and regulatory needs, and any standards it must meet.
- The business. Whether the goal is to license the idea, raise money, or build a company. These need different amounts of development, and the answer changes the plan more than most people expect.
- The unknowns. What nobody knows yet. A good discovery produces a list of open questions, not just a list of answers.
The output is the first requirements document. It will be wrong in places, and that is expected. It is a living document that gets revised at every phase gate.
Key takeaway The requirements document is worth more than any quote. A quote is one firm's guess at one moment. A requirements document can be taken to any firm, and it makes their quotes comparable, because they are all pricing the same thing.
How a requirement is written
A requirement is a single sentence that says what the product must do, not how. Engineering convention uses two words with specific meanings:
- Shall means mandatory. "The housing shall survive a 1.5 m drop onto concrete."
- Should means preferred. "The housing should be available in two colors."
Every "shall" is a cost lever. Each one adds engineering, testing, or parts. Understanding which requirements are real needs and which are wishes is the owner's main source of control over the budget.
A useful test for any requirement is whether it is:
- Specific. It names one thing.
- Unique. It does not repeat or contradict another requirement.
- Unambiguous. Two engineers would read it the same way.
- Positive. It says what the product does, not what it does not do.
- Verifiable. There is a way to check it: by analysis, inspection, test, design review, or similarity to a known product.
"The flashlight shall be bright" fails most of these. "The flashlight shall produce at least 500 lumens on its highest setting, measured per ANSI/PLATO FL1" passes all of them, and an engineer can now price it.
What comes out
At the end of Project Initiation there should be:
- A requirements document, version 0.x, with every known requirement and a list of open questions.
- A rough idea of which phases the project needs. A licensing play may stop after Proof of Concept. A company-building play goes all the way to Production.
- A sense of the biggest risks, which is what Feasibility will investigate next.
- A decision: proceed to Feasibility, rework the idea, or stop.
Typical cost and duration
Discovery is often sold at a fixed price because its scope is predictable. It is the cheapest phase by a wide margin, and the one with the best return, because every hour spent clarifying a requirement here saves many hours of engineering later.
Common mistake Collecting quotes from several firms before any requirements exist. Each firm fills the gaps with different assumptions, so the quotes describe different products and cannot be compared. The low quote is usually the one that assumed the least.
What to ask a firm about this phase
- "What does discovery produce, and can it be taken to another firm?"
- "Is this phase fixed price or hourly?"
- "What do you need from me before the first meeting?" (The planning kit is built to answer this.)
Try this (15 minutes) Write five requirements for the product, each starting with "The product shall." Then apply the five tests above to each one. Rewrite any that fail. Most first attempts fail "verifiable."