Planning a robotics development project

1. Agree the problem and its owner

Describe the task, the intended user and the reason to change the current method. Identify who can decide between competing priorities. NASA's design guidance separates stakeholder expectations from the technical requirements developed to meet them. Keep that distinction visible when a preferred technology starts to dominate the discussion.

• Record essential outcomes, constraints and exclusions.
• Name the buyer, operator and technical decision owner.

Reference: NASA Systems Engineering Handbook: System Design Processes

2. Establish what already exists

List the equipment, software, drawings and evidence available at the start. Describe their condition and ownership. An existing prototype may shorten some tasks while creating extra work around undocumented interfaces. Mark information as confirmed, provisional or missing so that an estimate does not quietly depend on an untested assumption.

• Separate reusable items from items needing assessment.
• Give each important unknown an owner and next action.

3. Make the first stage a useful assessment

Choose the smallest investigation that can resolve the most consequential uncertainty. It might be an interface review, power measurement, operator walkthrough or mounting study. Agree the output before starting. The decision may be to proceed, revise the approach or stop; each can be valuable when supported by clear findings.

• Define the question, method and required output.
• Record what the result permits the team to decide.

4. Assign the interfaces and changes

Name an owner for each mechanical, electrical, data and operator interface. Agree which documents describe the baseline and how changes reach everyone affected. Include external dependencies such as supplier documentation, site access and equipment availability. A schedule should show these dependencies alongside engineering tasks, with uncertainty stated openly.

• Record inputs needed before each task can begin.
• Review cost, evidence and schedule effects before accepting a change.

5. Plan integration and trials together

Decide how important requirements will be checked before committing to a detailed design. NASA's product-realisation guidance connects integration with verification against requirements and validation against user expectations. For a small project, a concise evidence table can connect those activities without creating unnecessary paperwork.

• Identify bench checks, controlled trials and required facilities.
• Agree readiness conditions, acceptance criteria and evidence owners.

Reference: NASA Systems Engineering Handbook: Product Realization

6. Review results before extending the scope

At each review, compare the result with the question agreed for that stage. Keep incomplete tests, limitations and unexpected findings visible. Decide what can proceed and what requires more evidence. Avoid treating a successful demonstration as permission to add functions, environments or operating modes that were outside the assessment.

• Record the decision, its evidence and remaining conditions.
• Update the next-stage scope and resource estimate.

7. Define the handover from the beginning

Agree what the receiving team needs to operate, maintain and update the delivered configuration. Include instructions, configuration records, relevant drawings, software access, licences and support boundaries. RCDEN is developing robotic systems; the project should state whether its endpoint is an assessment, prototype, trial configuration or another agreed development stage.

• Identify the receiving person and required training.
• List evidence, known limits and responsibilities after handover.

Further reading

• NASA Systems Engineering Handbook: System Design Processes
• NASA Systems Engineering Handbook: Product Realization