The Team That Kept Redesigning
A five-person student-and-junior team is building a small autonomous cart for a competition. The rules require the cart to carry a 2 kg payload around a marked course in under 60 seconds, stay within a 400 mm width, and stop within 300 mm of a marked line. Six weeks in, the team has changed the drivetrain layout three times, the sensor suite twice, and the chassis material once. No version has been fully tested on the course. Two members are frustrated and have stopped attending. The competition is four weeks away. The team lead says the design "isn't good enough yet" and wants to switch to a different microcontroller and add a second sensor for redundancy. A faculty advisor asks for a plan that gets a working cart to the start line.
1. Diagnose what is going wrong in the design process, using the requirements as the anchor.
Read the worked answer
The team is stuck in concept churn because it has no agreed definition of "good enough." The requirements are measurable - 2 kg payload, under 60 s, 400 mm width, stop within 300 mm - but the team is optimizing against an unstated, moving standard. Each redesign resets testing, so nothing is ever validated, which makes the design feel "not good enough" and triggers another redesign. That is a loop, not progress.
The specific errors: (1) changing multiple subsystems at once, so no test isolates a cause; (2) no baseline that meets requirements, so there is nothing to improve from; (3) scope creep - a second sensor for redundancy is not required by the rules and adds integration risk with four weeks left; (4) the microcontroller swap discards working code and knowledge.
Root issue: no requirement-driven decision gate. The team needs a definition of done tied to the four measurable requirements, and a rule that changes are made only to fix a demonstrated failure against those requirements.
2. Propose a four-week plan with decision gates that gets a compliant cart to the start line.
Read the worked answer
Freeze the design and drive to a compliant baseline first, then improve only if time allows.
Week 1 - Freeze: lock the current drivetrain, sensor suite, and chassis. No new components. Build one complete cart to the frozen design. Define done: meets all four requirements on the actual course.
Week 2 - Baseline test: run the cart on the course, measure time, width, payload handling, and stopping distance. Fix only failures against requirements, one change at a time, re-testing after each.
Week 3 - Reliability: repeat runs to find intermittent failures; tune the stop distance and speed; make spares of critical parts.
Week 4 - Buffer and practice: full competition-condition runs, driver/operator practice, packing, and a contingency plan. Keep the last days as buffer, not new work.
Gate rule: a change is allowed only if a test shows a requirement is not met and the change is the smallest fix. The second sensor and new microcontroller are rejected unless a baseline failure proves they are needed. Re-engage the two absent members by giving them clear, bounded test or build tasks with visible ownership.
3. How should the team handle the lead's request for a new microcontroller and redundant sensor?
Read the worked answer
Treat it as a change request against requirements, not a judgment of the lead's instincts.
Ask: which requirement is currently failing, and what test shows it? If the answer is "none yet, it just feels risky," the request fails the gate. Redundancy and a new controller add integration and schedule risk with four weeks left, and neither is required by the rules.
If a real failure exists - e.g., the controller cannot handle the sensor update rate and the cart misses the stop line - that is a demonstrated requirement failure, and a targeted change may be justified. Even then, prefer the smallest fix (optimize code, adjust timing) over a platform swap.
Document the decision: the request, the evidence, the decision, and the rationale, so it is not re-litigated weekly. Give the lead a constructive role - owning the baseline test and the gate reviews - so the energy goes into validation rather than churn. This keeps the team aligned and protects the schedule.