Chapter 2: Project Management
On 7 September 2019, in a control room in Bengaluru, the signal from the Vikram lander stopped about two kilometres above the surface of the Moon. Chandrayaan-2’s orbiter was healthy and would go on working for years, but the landing had failed. The hardware was sound, the science was sound, and still the machine did not do the one thing it had been built to do.
What followed is the part worth studying. The team did not simply build the same lander again. They went back over every stage of the project, asked what could go wrong at each one, and designed for those failures: sturdier landing legs, a far larger patch of ground the lander was permitted to come down on, extra fuel in hand, and far more testing on the ground before anything flew. On 23 August 2023, Chandrayaan-3 set Vikram down near the lunar south pole.
Photograph
Fig. 2.0-1 – the Chandrayaan-3 lander module during integration or testing, with engineers in cleanroom suits working around it; the lander’s legs and body must be clearly visible, and at least two people must be in frame so the scale of the team effort reads. Sourcing note: an official ISRO mission photograph is preferred. An artist’s rendering of the lander on the Moon is unusable here — the picture must show the machine being built and checked by people, not the finished mission.
Notice what this story is not about. It is not about one brilliant idea. It is about the ordinary discipline of running a project: stating exactly what the machine must do, listing what it needs, naming the risks before they arrive, working to a date that cannot slip, testing each part on its own before joining it to the next, and reviewing honestly at the end. Your own robot will be smaller — a chassis, a controller, two motors, a handful of sensors, five weeks — but the discipline is the same one.
This chapter will answer each of these questions as it goes.
2.1 Project Management in Robotics
A robot is never built in one sitting. Parts have to be chosen and bought, a frame has to be cut, circuits have to be wired, code has to be written and tested, and all of it has to come together by a date that somebody has already promised. Somewhere between the idea and the working machine, a great deal can go quietly wrong.
That gap between an idea and a finished machine is what this chapter is about. The subject that fills it is called project management, and it is as much a part of engineering as soldering or coding.
2.1.1 What Project Management Means
Not all work is a project. Charging the laboratory’s batteries every Friday is a routine — it repeats, and it has no finish. Building a robot that can carry files across a school office is different: it has a clear objective, a beginning, an end, and a limited supply of money, time and people.
That is what engineers mean by a project. It is a piece of work undertaken to produce a defined result, carried out once, within limits of time and resources.
Project management is the deliberate handling of that work so that the result actually arrives. It means deciding exactly what is to be built, breaking that into tasks, working out what each task needs, putting the tasks in a sensible order against a calendar, watching what really happens, and correcting the plan when reality disagrees with it.
Notice the four things in that definition that a finished project is judged against — the goal it was meant to achieve, the time it took, the money it consumed, and the quality of what came out. These four pull against one another. Rushing a robot to finish a week early usually costs either money or quality, and a team that only chases the deadline will hand over a machine that works once, on a good day, in the workshop.
Two more words are worth fixing now, because they appear in every project document you will ever read. A deliverable is a specific, finished item the project must hand over — a wired chassis, a tested program, a user manual. A stakeholder is anyone with a genuine interest in the outcome: the team, the teacher supervising the laboratory, the school that paid for the components, the person who will eventually use the robot.
2.1.2 Why a Robotics Project Demands It
Three subsystems, one machine
A robotics project is unusually exposed to disorder, and the reason is structural. A robot is not one system but three working as one: a mechanical subsystem of frames, joints and wheels; an electrical subsystem of batteries, drivers, motors and sensors; and a computing subsystem of controllers, algorithms and code. A subsystem is a self-contained part of a larger system, doing one job within it.
Each of the three is usually built by different people, at the same time, on different benches. They meet only at integration — the stage at which separately built subsystems are joined and made to work together. Integration is where projects are won or lost, as suggested by the arrangement in Fig. 2.1-1.
Diagram
Fig. 2.1-1 – three parallel horizontal tracks labelled mechanical subsystem, electrical subsystem and computing subsystem, each running left to right across a week scale from Week 1 to Week 5; short task blocks drawn on each track; all three tracks converging into a single block labelled integration and testing in Week 5, with arrows from each track into it; a dashed vertical line labelled “an agreed date by which the chassis must be ready” cutting across all three tracks
The trouble is that the three subsystems are not independent. The chassis cannot be drilled until somebody knows the footprint of the motor driver. The code cannot be finished until the pin assignments are fixed. A delay of four days in one place does not stay in that place; it moves along every track that was waiting on it.
Failures here are physical
There is a second reason, and it is particular to this subject. In a purely software project, a mistake produces an error message. In robotics, a mistake produces a burnt motor driver, a stripped gear, or a battery that will not take charge — and a replacement part may take a week to arrive. The cost of a careless afternoon is measured in components and in days, not in a recompiled program.
So the effort a team spends on planning is not paperwork. It is the cheapest way to find, on paper, the problems that would otherwise be found in hardware. Table 2.1 sets out the failures that robotics teams meet most often and the management activity that heads each one off.
2.1.3 The Three Phases at a Glance
Every robotics project, from a five-week school build to a lunar mission, moves through three phases: planning, execution, and monitoring and control.
In planning, the team decides what will be built, what it needs, what could go wrong, and by when each part must be ready. In execution, the plan is turned into hardware and software — parts are assembled, circuits are wired, code is written, subsystems are integrated. In monitoring and control, actual progress, spending and performance are measured against the plan, and the plan is adjusted where the two have parted company.
The relationship between the three is shown in Fig. 2.1-2. Note the arrow that returns from monitoring to execution — that return path is the whole point of the third phase.
Diagram
Fig. 2.1-2 – flow: planning → execution → monitoring and control, drawn left to right as three labelled blocks with forward arrows; a feedback arrow curving back from monitoring and control to execution labelled “corrective action”; a second, lighter feedback arrow returning from monitoring and control to planning labelled “revised plan”; a small caption under each block naming its output — a written plan, a working subsystem, a measured result
Each of these three phases is taken in turn in the sections that follow, and then applied end to end to a single robot in the case study at the close of the chapter.
2.2 The Planning Phase
Planning is the phase in which nothing is built and almost everything is decided. It is also the phase students are most tempted to skip, because a page of tasks feels less like progress than a wired breadboard.
The temptation is worth resisting for a plain reason: a decision changed on paper costs a rubber and five minutes, and the same decision changed after the chassis is drilled costs a new sheet of acrylic and a week.
Throughout this section a single running example is used — a small garden watering robot for a school kitchen garden. It drives along a bed, senses the moisture of the soil at each plant, and runs a pump for a short time wherever the soil is dry. Five planning activities turn that sentence into a project.
2.2.1 Defining the Project Objectives
The first task is to say exactly what the machine must do. That sounds obvious, and it is where most teams quietly go wrong, because “build a smart watering robot” means something slightly different to each of the four people who nod at it.
A project objective is a statement of what the finished system must accomplish, written so precisely that two people reading it would build the same machine. Where possible it is written with numbers and units, so that at the end of the project it can be tested rather than argued about.
Compare these two attempts at the same objective.
- Weak: “The robot should water the plants properly and be reliable.”
- Usable: “The robot shall travel a 3 m bed, stop at each of six marked plant positions, measure soil moisture at each, and deliver water for 4 s wherever the reading indicates dry soil, completing one pass in under 5 minutes.”
The second version can be checked with a stopwatch and a measuring tape. The first cannot be checked at all, which means it can never be declared finished.
Alongside the objective the team fixes the scope — the boundary of what the project will and will not include. Scope is stated in both directions, and the negative half matters more than students expect. For the watering robot: it will follow a marked path, and it will not navigate an unmarked garden; it will run from a rechargeable pack, and it will not draw water from a mains-powered supply.
Each objective is then broken into deliverables and, wherever possible, given a specification — the set of measurable values the finished item must meet, each with its unit and the condition under which it is measured. A specification such as “response within 0.5 s at a walking pace of 0.3 m/s” tells the electrical team what to buy and the software team what to write.
2.2.2 Resource and Budget Allocation
Once the team knows what it is building, it can work out what that will take. Resources in a robotics project come in four kinds: hardware, software, people and money.
Hardware means the physical items — controllers, sensors, actuators, batteries, frame material, fasteners. Software means the tools the work is done with, such as the Arduino integrated development environment (IDE) for writing and uploading programs, or a simulation environment such as Gazebo where a design is tried before it is built. People are counted by skill, not by number: a team of five with nobody who can solder is short of a resource. Money ties all three together.
The Bill of Materials
The central planning document for hardware is the Bill of Materials (BOM) — an itemised list of every component the build requires, with the quantity, an indicative unit cost and, critically, the time each item takes to arrive.
Table 2.2 is the BOM for the watering robot. The costs shown are indicative school-laboratory prices in rupees and will differ between suppliers and years; a real BOM is priced from current vendor quotations, not from memory.
The lead time column — the delay between ordering an item and receiving it — is the one beginners leave out and then regret. The laser-cut chassis takes seven days. If the team orders it in week three, the mechanical work cannot start until week four, and every task that depends on a drilled chassis moves with it. Lead time is why procurement decisions belong in planning and not in the week the part is first needed.
The base budget and its contingency
Adding up the BOM gives the direct component cost. It does not give the budget, because something in every project costs more than expected — a burnt driver, a second sheet of acrylic after a bad cut, a pump that turns out to be too weak. Sensible teams therefore add a contingency: a reserve, usually stated as a percentage of the base cost, held against unplanned expense.
2.2.3 Risk Assessment
A risk is something that has not gone wrong yet but might, and that would hurt the project if it did. Risk assessment is the planning activity of naming those possibilities in advance, judging how likely and how damaging each would be, and deciding now what will be done about it.
Two judgements are made about every risk: how likely it is, and how badly it would hurt. A risk that is likely and damaging is dealt with first; a risk that is unlikely and trivial is noted and left alone. The response itself is called a mitigation — an action taken in advance that either makes the risk less likely or makes its consequences smaller.
The result is written down as a risk register, as in Table 2.3. It is a living document: risks are added as the team learns more, and each is reviewed at every progress check.
Notice that most of the mitigations cost almost nothing and all of them are actions taken early. That is the point of the exercise: risk assessment converts an expensive surprise in week four into a cheap precaution in week one.
2.2.4 Timeline and Milestones
The team now knows what it is building and what it needs. What remains is when.
Scheduling begins by breaking the project into tasks small enough to be estimated honestly. The usual tool is a Work Breakdown Structure (WBS) — a tree that splits the whole project into major pieces of work, each piece into tasks, and each task into something one person can finish in a day or two. Fig. 2.2-1 shows the top of the watering robot’s WBS.
Diagram
Fig. 2.2-1 – a Work Breakdown Structure drawn as a tree; single top box “Garden watering robot”; three second-level boxes below it labelled “Mechanical”, “Electrical” and “Software”; under Mechanical, three task boxes — “chassis drawing”, “cut and assemble chassis”, “mount pump and tank”; under Electrical, three task boxes — “wire motor driver”, “wire moisture sensors”, “wire and test power”; under Software, three task boxes — “sensor reading routine”, “drive and stop routine”, “watering decision logic”; connecting lines drawn from each parent box to its children
Tasks are then placed on a calendar. Some can run side by side — the software team can write the sensor reading routine while the mechanical team waits for acrylic. Others cannot: nothing can be wired until the chassis exists. A task that must wait for another is said to depend on it, and dependencies are what turn a list of tasks into a schedule.
Along the way the team fixes milestones. A milestone is not a task but a checkpoint — a dated point at which a defined deliverable must exist, used to judge whether the project is where the plan says it should be.
Reading a schedule as a picture
A table of dates tells you what is due. It does not show you what is happening at the same time, or what will collapse if one task slips. For that, project teams draw the schedule as a Gantt chart — a chart with tasks listed down the left and time running across the top, each task drawn as a horizontal bar spanning the days it occupies.
Diagram
Fig. 2.2-2 – Gantt chart for the garden watering robot; task names listed down the left in order: requirements and specification, order components, chassis drawing, chassis assembly, motor and driver wiring, sensor wiring, software development, sensor calibration, integration, final testing; a week scale from Week 1 to Week 5 across the top; each task drawn as a horizontal bar spanning its weeks, with the software development bar overlapping the chassis assembly bar to show parallel work; five milestone markers drawn as diamonds at the week ends, labelled from Table 2.4; a dependency arrow drawn from the end of chassis assembly to the start of motor and driver wiring
The picture answers questions a list cannot. It shows at a glance which weeks are crowded, which teams are idle, and which bars sit end to end in a chain where any delay pushes everything after it. A related chart, the Program Evaluation and Review Technique (PERT) chart, shows the same tasks as a network of dependencies rather than as bars against a calendar; both are used for the same purpose.
2.2.5 Technical Documentation
The last planning activity is to write down the design itself, before it is built. Three documents are prepared at this stage, and all three are drawings or text rather than hardware.
The first is the system architecture — a block diagram naming every subsystem and showing what passes between them, whether power, signal, data or command. It is the document the whole team argues over and then agrees on, and it is the reason the electrical and software teams end up building compatible things. Fig. 2.2-3 is the architecture for the watering robot.
Diagram
Fig. 2.2-3 – block diagram of the garden watering robot; blocks labelled Lithium Polymer battery, Arduino UNO, motor driver module (L298N), two BO motors, submersible pump, two soil moisture sensor modules; thick arrows labelled “power” from the battery to the Arduino UNO and to the motor driver module; thin arrows labelled “sensor signal” from each soil moisture sensor module to the Arduino UNO; thin arrows labelled “control signal” from the Arduino UNO to the motor driver module; thick arrows labelled “drive current” from the motor driver module to each BO motor and to the pump; a dashed line labelled “common ground” joining the battery, the Arduino UNO and the motor driver module
The second is the set of preliminary algorithms — the methods the robot will follow, written as ordered steps in plain words before any code exists. An algorithm is a finite, ordered sequence of steps that solves a stated problem. Writing it in the planning phase forces the team to decide what the robot will actually do at a dry patch, at the end of the bed, and when a sensor gives an impossible reading. The matching flowchart, a diagram of the same logic drawn with standard boxes and arrows, is often prepared alongside it.
The third is the record-keeping arrangement itself, of which the most important piece is version control — a system that stores every revision of the code and design files so that any earlier version can be recovered and so that two people’s changes do not overwrite one another.
With the objective fixed, the resources costed, the risks named, the schedule drawn and the design documented, the team has something to build against. What it does with that is the subject of the next section.
2.3 The Execution Phase
Execution is the phase in which the documents become a machine. Acrylic is cut, motors are bolted down, wires are stripped and pushed into headers, code is written and uploaded, and by the end of it something on the bench moves.
It is also the phase in which the plan is tested, because reality now gets a vote. The pump turns out to be noisier than expected; the sensor leads are 40 mm too short; the chassis has no room for the battery where the drawing said it would go. Execution is not the mechanical carrying out of a plan — it is the disciplined adjustment of a plan against hardware that answers back.
2.3.1 Team Coordination
Three groups of work now run at the same time. The mechanical work produces the frame, the mountings and the moving parts. The electrical work produces the wiring, the power distribution and the driver circuits. The software work produces the routines that read the sensors, decide, and drive the actuators.
Because the three run in parallel, they must agree on their boundaries before they meet. The point at which two subsystems join and must match each other is called an interface, and every interface is also an agreement between people.
Table 2.5 lists the interfaces the watering robot’s team has to settle early. Each row is a decision that costs nothing while it is a line in a document and a great deal once both sides have been built to different assumptions.
Roles are assigned by skill and interest, not by rank, and every task on the Work Breakdown Structure carries the name of one person answerable for it. That last point matters more than it sounds: a task owned by “the team” is a task owned by nobody, and it is reliably the one that is still unfinished in week five.
Photograph
Fig. 2.3-1 – a school robotics team at a workbench during a build, with a partly assembled small wheeled robot in front of them; one student holding a multimeter probe on a driver module, another working at a laptop, a teacher supervising; the bench must show the chassis, loose wiring and a component tray so the stage of the build is legible. Sourcing note: an ordinary school or workshop setting with a mixed group of students. An advertising-style image of a polished commercial robot, or a stock photograph with no visible work in progress, is unusable here.
2.3.2 Subsystem Integration
Integration is the moment the three parallel tracks converge. It is worth planning as carefully as anything else in the project, because the way it is done decides how hard the faults will be to find.
The wrong way is to build all three subsystems separately for four weeks, connect everything on one afternoon, and switch on. If the robot then behaves strangely — and it will — the fault could be in any of a hundred connections, in any routine, or in the interaction between two of them. Nothing has been eliminated, so everything must be searched.
The right way is incremental: join two subsystems, prove that pair works, then add the third, as shown in Fig. 2.3-2. Each time something is added, the search space for a new fault is only what was just added.
Diagram
Fig. 2.3-2 – flow: controller alone, powered and running a test program → controller plus motor driver and motors, driven at fixed speed → controller plus motors plus soil moisture sensors, readings printed → controller plus motors plus sensors plus pump, full watering cycle → complete robot on the bed; each stage drawn as a labelled block with a forward arrow; under each arrow a small label reading “test and record before adding the next”; a return arrow from any stage back to the previous one labelled “fault isolated to what was just added”
2.3.3 Implementation of Algorithms
The preliminary algorithms written during planning are now turned into working routines. The order is deliberate and it never reverses: the method is settled first in words, then written as code.
For the watering robot, the central method is what happens at one plant position. It has to read a sensor whose output varies, decide whether the soil is dry, act for a fixed time, and then move on — and it has to behave sensibly when the sensor returns something impossible.
Code is then written module by module, matching the subsystems: one routine to read and average the sensors, one to drive and stop, one to run the pump for a measured time, and a short main routine that calls them in order. Written that way, each routine can be tested on its own — which is exactly what the next stage requires.
2.3.4 Testing and Debugging
Testing during execution happens at two levels, and the lower one comes first.
At the lower level, each subsystem is tested alone against its own specification. The motors are driven forward and backward and checked for equal speed. The soil moisture probe is read in a sample of dry soil, in a sample of watered soil, and in air, and the three values are written down. The pump is run for a measured time into a beaker and the delivered volume is recorded. None of these tests involves the robot as a whole.
Only when each subsystem has passed its own test are they combined and tested together. At that point a new class of fault appears — faults of interaction rather than of components, such as sensor readings that become unstable only when the pump is running.
Debugging is the work of locating and removing such faults. It is a search, and like any search it is efficient only if each step eliminates possibilities.
2.3.5 Communication During Execution
A robotics project runs for weeks and depends on decisions that are made in passing. Somebody moves the sensor from pin A0 to pin A1 because a wire would not reach. If that decision lives only in one person’s memory, the software written that evening is wrong and nobody knows why the robot is blind.
Three habits prevent most of this. The first is a short, regular meeting — ten minutes, at a fixed time, in which each person states what was finished, what is next, and what is blocking them. Its purpose is not reporting but exposure: a task blocked for three days is visible on day one.
The second is that every decision which crosses an interface is written down where the whole team can see it — the pin map, the connector types, the mounting positions. The written version is the one that counts, and it is updated the moment the hardware changes.
The third is that code and design files are kept under version control, so that a change made on Tuesday can be undone on Thursday, and two people editing the same file do not silently erase each other’s work.
Execution ends with a robot that runs. Whether it runs well enough, on time, and within its budget is a separate question, and answering it is the work of the third phase.
2.4 The Monitoring and Control Phase
Monitoring answers one question, asked repeatedly while there is still time to act on the answer: is the project where the plan said it would be?
The question is asked about four things — progress, money, quality and performance — and it is asked in that order because each depends on the one before it. A team that is behind schedule usually starts spending to catch up, and a team spending to catch up usually starts cutting tests.
2.4.1 Progress Tracking
Progress tracking compares what has actually been finished against what the schedule said would be finished by now. It is done against milestones and tasks, not against feelings, because a task described as “nearly done” has a way of remaining nearly done for a fortnight.
The comparison is easiest to read as a picture. In Fig. 2.4-1 the planned bar for each task is drawn with the actual bar underneath it, so that a task running late shows as a bar extending past the one above.
Diagram
Fig. 2.4-1 – progress tracking chart for the garden watering robot at the end of week 3; task names down the left — order components, chassis assembly, motor and driver wiring, sensor wiring, software development, sensor calibration; a week scale from Week 1 to Week 5 across the top; for each task, two bars drawn one above the other, the upper labelled “planned” and the lower labelled “actual”; the chassis assembly actual bar shown extending four days beyond its planned bar; the motor and driver wiring actual bar shown starting later than planned; a vertical line at the end of Week 3 labelled “date of this check”
Table 2.7 is the same check written out. Notice the last column: a status without a decision attached is only a complaint.
The chassis delay in that table did not stop the project, and the reason is worth naming. Some tasks have spare time built into them — a task can start late or run long without pushing anything after it, because the task that follows it is not waiting. That spare time is called slack, and a schedule with no slack anywhere is a schedule where every small delay becomes a project delay.
Tasks with no slack sit in a chain where each one waits on the one before, and any delay along that chain moves the finish date directly. Those are the tasks a project leader watches most closely, and they are the ones where extra help is worth spending.
2.4.2 Budget Management
Money is tracked the same way as time: what was planned, what has actually been spent, and what the difference means. The difference between the two is called a variance, and a variance is investigated rather than absorbed quietly.
Fig. 2.4-2 shows the usual way of watching it — cumulative planned spending drawn against cumulative actual spending, week by week.
Diagram
Fig. 2.4-2 – line chart of cumulative spending for the garden watering robot; horizontal axis Week 1 to Week 5; vertical axis rupees from 0 to 3500; one line labelled “planned cumulative spend” rising in steps as components were scheduled to be bought; a second line labelled “actual cumulative spend” following it closely to Week 2 and then rising above it from Week 3; a horizontal dashed line labelled “base budget ₹3168”; the point where the actual line crosses the dashed line marked and labelled “budget exceeded”
Two unplanned costs arrived in this project: a motor driver module was destroyed during wiring, and the chassis had to be cut a second time after a hole spacing error. Both are ordinary robotics costs, which is exactly why a contingency was set aside for them in planning.
An overrun of this size does not end a project, but it does force a decision, and the decision belongs to the team and its supervisor rather than to whoever happens to be at the shop counter. The choices are the usual three: find the extra money, remove something from the scope, or accept a lower specification somewhere. Choosing knowingly is management; discovering the overrun at the end is not.
2.4.3 Quality Assurance
Quality assurance is the set of activities that establish, with evidence, that the finished system actually meets its specification — not once, but dependably, and under the conditions it will really face.
Three activities carry it. The first is systematic testing: each requirement in the specification is turned into a test, and the test is run enough times for the result to mean something. The second is calibration — setting a sensor or an actuator against a known reference so that its readings or its output can be trusted. The third is documentation: every test, every reading and every adjustment is recorded, so that the result can be reproduced by someone who was not there.
Table 2.8 is the watering robot’s quality record after twenty trial passes along the bed.
Two requirements are marked as not met, and printing that honestly is the point of the table. A record that shows only successes tells the team nothing and cannot be used to decide what to fix next.
2.4.4 Performance Review
Alongside the measurements, the team meets at fixed points to review the project as a whole. A performance review is wider than a progress check: it looks at status against milestones, at spending, at the technical problems that have appeared, and at the risk register, which is reread and revised rather than filed away.
Reviews produce two useful things. One is a decision — extra help on a late task, a specification relaxed with reasons, a risk newly judged serious. The other is a short status report for the people outside the team who are answerable for it: the supervising teacher, the department that released the funds.
A status report is brief and factual. It states what has been completed since the last report, what is due next, what is late and by how much, what has been spent against budget, and what the team needs a decision on. Anything longer tends not to be read.
2.4.5 Adjustment and Feedback
The purpose of all this measuring is the correction it makes possible. Monitoring without adjustment is bookkeeping.
Adjustments are made continuously and while they are still small: a probe re-mounted 10 mm lower after calibration shows an unstable reading, a threshold changed after a wet-soil test, a person moved from a task with slack to a task without it, an order placed early because a lead time proved longer than the vendor quoted.
Changing the plan in this way is not an admission of failure. The plan was a set of best estimates made when the team knew least about the project, and revising it against measured evidence is the plan working as intended. The Chandrayaan-3 team’s larger permitted landing area and extra fuel were exactly such revisions, made after evidence from an earlier attempt.
There is, however, one kind of change that must be resisted, and it arrives dressed as enthusiasm. Halfway through, somebody suggests adding a camera; a week later, a mobile phone application to control the robot. Each addition sounds small and none was in the objective. This uncontrolled growth of what the project is expected to deliver is called scope creep, and it is a common way for a nearly finished project to become an unfinished one.
Monitoring, then, keeps the project honest week by week. The next section takes the four things it measures — the goal, the schedule, the budget and the quality — and asks how each is actually held.
2.5 Meeting the Goal, the Schedule, the Budget and the Quality Standard
A project is judged on four things at once, and they pull in different directions. Adding to what the robot must do stretches the schedule. Compressing the schedule usually costs money or quality. Cutting the budget forces a cheaper component and a longer debugging session.
This is not a defect in project management; it is the shape of the problem. Fig. 2.5-1 shows the usual way of picturing it.
Diagram
Fig. 2.5-1 – a triangle with each side labelled: one side “scope — what the robot must do”, one side “time — when it must be ready”, one side “cost — what may be spent”; the word “quality” written inside the triangle at its centre; a small caption reading “changing any one side moves the other two”; a short arrow drawn outward from the scope side labelled “an added feature”, with dashed arrows showing the time and cost sides lengthening in response
The practices that follow are the ordinary means by which teams hold all four. Table 2.9 sets them out together before each is taken in turn.
2.5.1 Clear Goals and a Written Plan
Everything in this chapter rests on the objective being clear and written, because every later judgement is made against it. A deliverable that cannot be traced back to a stated objective is either a misunderstanding or somebody’s private enthusiasm, and both are expensive.
Once the plan is complete, it is reviewed and approved before execution begins — in a school project, by the supervising teacher; in industry, by the project leadership. The approved version is then fixed as the baseline: the agreed plan against which all later progress, spending and change is measured.
The baseline is what makes the phrase “we are late” mean something. Without it, a team compares today’s work against yesterday’s intentions, which are themselves already revised, and every slip is quietly forgiven. A baseline can be changed, but only deliberately, through a change request that states what is being added, what it needs, and what will move to make room for it.
2.5.2 Holding the Schedule
Schedules are held by reviewing them often and acting early. A weekly or fortnightly check finds a slipping task while the response is still small — reordering two tasks, moving one person, starting a long-lead order sooner.
The spare time in tasks that nothing is waiting on is the project’s shock absorber, and it is spent judiciously. Using slack to absorb a genuine delay is good management; using it to allow a comfortable start is how a project arrives at week five with nothing left to absorb anything.
The lesson for a robotics team is not that help never helps. It is that help arrives usefully only where the task can genuinely be split, and only if it arrives early enough for the newcomer to become productive before the deadline.
2.5.3 Tracking the Budget
Budgets are held by comparing actual spending against projected spending at every review, and by explaining every variance rather than absorbing it. An unexplained variance is a symptom: it usually means either the estimate was wrong or something failed, and both are worth knowing early.
Spending is optimised, but never by trading away quality without saying so. A motor driver bought for a third of the usual price and destroyed twice during testing is not a saving; it is a slower project with a worse result. The useful question is not which component costs least, but which delivers the required specification most cheaply — and whether the cheaper one meets the specification at all.
Two habits keep a small project’s budget honest. Every purchase is recorded against a BOM line as it is made, not reconstructed from receipts at the end. And the contingency is treated as a reserve to be drawn on with a reason, not as extra money to be spent because it exists.
2.5.4 Applying Quality Control
Quality is not inspected into a robot at the end. It is built by checking at every phase: components tested before they are integrated, software modules checked as they are written, and the whole system tried under the conditions it will really meet.
Two checks are made on every module and they are not the same. Verification asks whether the thing was built to its specification. Validation asks whether the thing, correctly built, actually does the job in the real setting. A watering routine that switches the pump on at exactly the threshold in the code is verified; it is validated only when the bed is properly watered in a real garden, in real soil, at the end of a real battery charge.
Alongside the assurance activities of Section 2.4.3 sits quality control — the inspection and testing of the actual items produced, to catch the ones that do not meet the standard. The distinction between the two is drawn in Table 2.10, and it is one students are regularly asked to state.
Final validation deserves a note of its own. A robot validated only on a smooth workshop floor, under workshop light, on a fresh battery, has been tested in the easiest conditions it will ever meet. Real validation is deliberately unkind: uneven ground, a half-discharged pack, the surface the robot will actually work on.
2.5.5 Managing Risk Through the Project
The risk register written during planning is not a planning document that is then filed. It is reread at every review, and it changes as the project does.
Three things happen to it. Risks that have passed are closed — once the chassis has arrived and fits, the lead-time risk is over. Risks that have grown are re-rated, and their mitigations strengthened. And new risks are added as the team learns what this particular build is really like, which is usually the largest of the three groups.
Where a risk is serious enough, the mitigation is backed by a contingency plan: a decided response, written in advance, for what the team will do if the risk arrives anyway. A spare driver on the shelf is a contingency plan. So is a decision, taken calmly in week two, that if the pump proves inadequate the team will reduce the watering specification rather than redesign the tank.
2.5.6 Final Evaluation and Lessons Learned
When the robot works, the project is nearly over. What remains is the review that turns one project’s experience into the next project’s competence.
The final evaluation compares outcomes against the original objective, item by item: what was specified, what was measured, and where the two differ. It reports honestly on time and cost as well, since a robot delivered three weeks late and at twice the budget is a result worth understanding rather than hiding.
The output is a short post-project report, and its most valuable part is the record of lessons learned — the conclusions the team would want a future team to have before it starts. Written well, these are specific and actionable: not “we should have planned better”, but “a 10 % contingency was too small for a first build, and every laser-cut part should be ordered in week one”.
That record is what closes the loop shown in Fig. 2.5-2. It is also, in the end, what separates a team that has built one robot from a team that can build robots.
Diagram
Fig. 2.5-2 – flow: project objective → planning → execution → monitoring and control → final evaluation → lessons learned recorded; a long feedback arrow curving from “lessons learned recorded” back to “planning”, labelled “better estimates, better risk register, better specification next time”; the arrow drawn crossing outside the main sequence so it clearly returns to the start of a new project
Together with the handover items — the final documentation, the wiring record, the calibrated thresholds, the test results and the code — the report is what allows someone who was not on the team to pick the robot up six months later and understand it. A robot nobody can maintain has not really been delivered.
2.6 Case Study: A Line Following Robot Project
The three phases have been treated one at a time. This section runs a single project through all of them from end to end, so that the joins are visible: how an objective becomes a component list, how a component list becomes a schedule, and how a measured result sends the team back to a mounting bracket.
The project is a line following robot — a small wheeled machine that detects a black line on a light floor and drives along it without a person steering. It is the standard first robot of a school laboratory, and it is standard precisely because it exercises every subsystem: a frame, a drive, sensors, a controller and a decision made many times a second.
2.6.1 Planning the Robot
The objective and the specification
The team’s first draft of the objective was “a robot that follows a line reliably”. That is untestable, and rewriting it took most of the first session.
The agreed version reads: the robot shall follow a 20 mm wide black line on a light-coloured floor around a 6 m closed track that includes straight sections and curves of not less than 200 mm radius; it shall complete one lap without leaving the line; it shall begin correcting within 0.2 s of the line moving off centre; and it shall complete at least five consecutive laps on one battery charge.
Every clause of that sentence can be checked with a tape measure, a stopwatch and a track drawn on the floor. The scope was also stated negatively: the robot will follow a marked line, and it will not navigate an unmarked floor, avoid obstacles, or be steered remotely.
Choosing the components
Component selection follows from the objective, and each choice was recorded with the reason for it and the limitation it brings. Table 2.11 is that record.
The physical arrangement that follows from these choices is shown in Fig. 2.6-1. Note where the sensors sit: at the front, below the chassis, ahead of the wheels, so that the robot senses the line before the wheels reach it.
Diagram
Fig. 2.6-1 – top view layout of the line following robot on its acrylic chassis; three IR sensor modules drawn in a row across the front edge, labelled left, centre and right, mounted on a plate below the chassis; two BO motors with 65 mm wheels mounted symmetrically on the left and right sides at the middle; one castor wheel at the rear; Arduino UNO mounted centrally; motor driver module (L298N) mounted beside it; lithium polymer pack mounted over the rear axle line; a dashed centre line drawn front to back through the chassis showing the sensor array centred on it; a side-view inset showing the sensor plate held a small fixed height above the floor, with that height marked as an adjustable dimension
Schedule and risks
The build was scheduled across five weeks: requirements and component specification in the first, procurement and breadboard trials in the second, chassis assembly and wiring in the third, software and sensor calibration in the fourth, and integration and testing in the fifth. The chassis drawing was sent for cutting in week one, because it carried the longest lead time on the list.
Four risks were entered in the register. The sensor plate might sit at the wrong height or drift out of alignment, which would make detection unreliable — mitigated by designing the plate with slotted holes so the height can be adjusted after testing. Ambient light might shift the readings between a sunlit corridor and an indoor track — mitigated by planning calibration as a scheduled task, not an afterthought. The motors and controller sharing one pack might cause the controller to reset when both motors start together — mitigated by measuring the voltage under load early. And the correction rule might be too coarse, causing the robot to weave across the line — mitigated by allowing time in week five for iterative adjustment.
2.6.2 Building and Integrating the Robot
Assembly
The chassis arrived cut to the drawing. The two motors were mounted symmetrically about the centre line, since a differential drive with unequal wheel positions steers slightly even when both motors are commanded equally. The castor was fitted at the rear, the driver module and controller were bolted to the deck, and the pack was placed over the rear axle line so that the sensor plate at the front was not pushed down by the weight.
The sensor plate was fitted last, on slotted mountings, exactly as the risk register had required.
Writing the decision logic
The method was settled before any code was written. With three sensors in a row, the robot’s position relative to the line can be read directly from which sensors see dark.
Integrating in stages
The subsystems were joined one at a time, in the order established in Section 2.3.2. The controller was tested alone; then the driver and motors, with the robot on blocks, checking that each wheel turned in the commanded direction; then the sensors, with their readings printed while a strip of black tape was passed under each in turn; and only then the whole robot on the track.
Calibration was done at this last stage and recorded. The three sensors were read over the white floor and over the black tape, and a threshold was set midway between the two groups of readings — with a note in the log that the numbers held for that surface and that lighting, and would be checked again for any other.
2.6.3 Monitoring, Testing and Improving
Testing began on a simple oval and moved to the full track with its tighter curves. Each run was recorded, not just watched, and the record is what made the problems solvable.
Photograph
Fig. 2.6-2 – a small three-wheeled line following robot on a track of black tape on a light floor, photographed from a low angle so that the front sensor plate and its height above the floor are clearly visible, with the tape line running under the robot; the chassis, wheels and wiring must be visible. Sourcing note: an ordinary student-built robot in a workshop or classroom is preferred over a commercial kit product photograph, and any image in which the sensor plate is hidden from view is unusable here.
Table 2.12 is the change log from the fifth week — the problem observed, the cause found, the change made, and the result. It is the most useful single page the team produced.
Twenty laps were then run in three sessions, on two different floors and at two states of charge. Eighteen were completed without the robot leaving the line; the two failures both occurred on the same tight curve at the higher speed, which told the team something specific rather than something general.
Final evaluation
Measured against the objective, the robot met the track, the line width and the battery endurance clauses, and met the correction-time clause comfortably. It did not meet the clause requiring every lap to be completed without leaving the line, since two laps of twenty failed at the tightest curve. That was reported as it stood.
The lessons recorded for the next team were specific: order laser-cut parts in week one, design every sensor mounting to be adjustable before you know you need it, schedule calibration as a task with a slot rather than as something done while testing, and expect the last week to be spent on the boundary cases — the lost line, the low battery, the sunlit corner — rather than on the behaviour that worked on the first afternoon.
2.7 Summary
What project management is
- A project is a piece of work with a defined objective, a definite start and finish, and a limited allowance of time, money and resources. Routine repeating work is not a project.
- Project management is the systematic use of knowledge, tools and techniques to plan, carry out and complete a project so that it meets its objective, on time, within budget and to the required quality standard.
- A finished project is judged on four things at once — the goal achieved, the time taken, the money spent, and the quality of the result. These four pull against one another, and quality is the one most often sacrificed silently because it carries no date and no invoice.
- A deliverable is a specific finished item the project must hand over. A stakeholder is anyone with a genuine interest in the outcome.
Why robotics projects need it
- A robot is three subsystems working as one — mechanical, electrical and computing — usually built in parallel by different people and meeting only at integration.
- The subsystems are not independent, so a delay in one travels along every task that was waiting on it.
- Mistakes in robotics are physical. A wrong connection produces a burnt driver and a week’s wait for a replacement, not an error message, which is why finding a problem on paper is far cheaper than finding it in hardware.
The three phases
- Every project moves through three phases: planning, execution, and monitoring and control.
- Planning decides what will be built, what it needs, what could go wrong, and by when. Execution turns the plan into hardware and software. Monitoring and control measures actual progress, spending and performance against the plan and feeds corrections back into the work.
- Monitoring is not the last stage. It runs alongside execution from the first day, because a deviation caught early is cheap to correct and a deviation caught at the end is not.
The planning phase
- The project objective states what the finished system must achieve, written precisely enough to be tested at the end. An objective without a quantity, a unit or a pass-or-fail test can never be declared met.
- Scope is stated in both directions — what the project includes and what it deliberately excludes.
- Resources come in four kinds: hardware, software, people and money.
- The Bill of Materials lists every component with its quantity, cost and lead time. Lead time — the delay between ordering and receiving — decides when procurement must start, not when the part is first needed.
- A contingency is a reserve held against unplanned expense. The base budget is the component cost plus that reserve: \(B = C + R\).
- Risk assessment names in advance what might go wrong, judges each risk by likelihood and impact, and fixes a mitigation for each. Most mitigations are cheap actions taken early, and they are recorded in a risk register.
- A Work Breakdown Structure splits the project into tasks small enough to estimate honestly. Milestones are dated checkpoints at which a defined deliverable must exist.
- A Gantt chart shows tasks as bars against a calendar, revealing overlap, crowding and dependency in a way a list cannot. A PERT chart shows the same dependencies as a network.
- Technical documentation prepared before building includes the system architecture block diagram, the preliminary algorithms and flowcharts, and the version control arrangement.
The execution phase
- An interface is the defined boundary at which two subsystems meet — a pin map, a mounting pattern, a connector type. Every interface is also an agreement between people, and it is fixed before the two sides are built.
- Every task carries the name of one person answerable for it; a task owned by everyone is owned by nobody.
- Integration is done incrementally — join two subsystems, prove the pair works, then add the next — so that any new fault belongs to what was just added. Connecting everything at once leaves the whole machine as the search space.
- Method comes before code: the algorithm is settled in words, including what happens at boundary cases such as an impossible sensor reading, and only then written as routines matching the subsystems.
- Testing happens at two levels. Each subsystem is first tested alone against its own criterion; only then are they combined, where faults of interaction appear.
- Debugging is a search, and it is efficient only if one thing is changed at a time.
- Communication is held by short regular meetings, by writing down every decision that crosses an interface, and by keeping code and design files under version control.
The monitoring and control phase
- Progress is tracked against milestones and finished, testable deliverables — not against hours worked or a percentage that feels right.
- Slack is the spare time in a task that nothing is waiting on. Tasks with no slack sit in a chain where any delay moves the finish date directly, and those are watched most closely.
- Spending is compared with planned spending at every review, and every variance is explained rather than absorbed. An overrun forces a deliberate choice: find more money, reduce scope, or accept a lower specification.
- Quality assurance establishes with evidence that the system meets its specification dependably. It rests on systematic testing, on calibration against a known reference, and on documentation that lets someone else reproduce the result.
- One successful run proves only that the robot can work. Repeated trials, in varied conditions and at different states of charge, are what show that it does.
- Performance reviews look at status, spending, technical problems and the risk register together, and produce decisions and a short factual status report.
- Monitoring without adjustment is bookkeeping. Revising a plan against measured evidence is the plan working as intended.
- Scope creep is the uncontrolled growth of what the project is expected to deliver. Any addition is treated as a change request stating what it adds, what it needs, and what will move to make room.
Holding the four constraints
- Scope, time and cost bound a project, and quality is decided by how the three are balanced. Changing one forces a change in at least one other.
- The baseline is the approved plan, kept fixed so that progress and change can be measured against a stable reference. Without it, “we are late” means nothing.
- Schedules are held by frequent review and early action, and by spending slack judiciously. Adding people to a late project tends to make it later, because newcomers must be brought up to speed by those already busiest.
- Budgets are held by recording each purchase against its BOM line as it is made and by treating the contingency as a reserve drawn on with a reason. The useful question is which component meets the specification most cheaply, not which costs least.
- Verification asks whether the item was built to its specification; validation asks whether the correctly built item does the job in the real setting. Quality assurance attends to the process, quality control to the items produced.
- The risk register is reread at every review — risks that have passed are closed, risks that have grown are re-rated, and new ones are added.
- Final evaluation compares outcomes with the original objective, and reports time and cost honestly. Its most valuable output is a record of specific, actionable lessons learned, which feeds the planning of the next project.
What the case study showed
- An untestable objective — “follows a line reliably” — became a testable one only when line width, track length, curve radius, correction time and battery endurance were written with numbers and units.
- Every component choice was recorded with its reason and the limitation it accepts: IR sensors shift with ambient light and mounting height, a differential drive limits traction, a driver module drops some voltage, acrylic is brittle.
- A sensor threshold is a property of a particular floor, mounting height and lighting, not a number that can be copied from elsewhere.
- The last week of the project went on the boundary cases — the lost line, the sunlit corner, the voltage dip at start-up — rather than on the behaviour that worked on the first afternoon. That is the normal shape of a robotics build.
2.8 Key Terms
- Algorithm — a finite, ordered sequence of steps that solves a stated problem; written in words before it is written as code.
- Baseline — the approved version of a project’s scope, schedule and budget, kept fixed so that later progress and change can be measured against a stable reference.
- Bill of Materials (BOM) — a complete itemised list of the components a build requires, giving for each its quantity, cost and lead time.
- BOM — Bill of Materials.
- Calibration — setting a sensor or actuator against a known reference so that its readings or its output can be trusted.
- Change request — a stated proposal to alter the baseline, giving what is added, what time and money it needs, and what will move to make room.
- Contingency — a reserve of money, usually a percentage of the component cost, held against unplanned expense.
- Debugging — the systematic process of locating the cause of a fault and removing it, by narrowing the search until one cause remains.
- Deliverable — a specific, finished item that the project must hand over.
- Differential drive — a drive arrangement in which steering is achieved by running two wheels at different speeds, with no separate steering mechanism.
- Execution — the phase in which the plan is turned into hardware and software: parts assembled, circuits wired, code written, subsystems integrated.
- Flowchart — a diagram of a method’s logic, drawn with standard boxes and arrows.
- Gantt chart — a schedule drawn with tasks listed down the left and time across the top, each task shown as a horizontal bar spanning the days it occupies.
- Goal — what the project set out to achieve, and the first of the four things a finished project is judged against.
- Integration — the stage at which separately built subsystems are joined and made to work together.
- Interface — the defined boundary at which two subsystems meet, specified precisely enough that each side can be built independently and still fit the other.
- IR — infrared.
- Lead time — the delay between ordering an item and receiving it.
- LED — light-emitting diode.
- Lessons learned — the specific, actionable conclusions recorded at the end of a project for the benefit of the next one.
- Milestone — a dated checkpoint at which a defined deliverable must exist, used to judge whether the project is where the plan says it should be.
- Mitigation — an action taken in advance that makes a risk less likely or its consequences smaller.
- Monitoring and control — the phase in which actual progress, spending and performance are measured against the plan, and corrections are fed back into the work.
- PERT — Program Evaluation and Review Technique; a chart showing scheduled tasks as a network of dependencies rather than as bars against a calendar.
- Planning — the phase in which the objective, resources, risks, schedule and design documentation are fixed before building begins.
- Project — a piece of work with a defined objective, a definite start and finish, and a limited allowance of time, money and resources.
- Project management — the systematic use of knowledge, tools and techniques to plan, carry out and complete a project so that it meets its objective, on time, within budget and to the required quality standard.
- Project objective — a precise statement of what the completed system must achieve, written in terms that can be tested at the end of the project.
- Quality assurance — the systematic checking of a system against its specification, through planned testing, calibration and recorded evidence, so that its performance is shown to be dependable.
- Quality control — the inspection and testing of the items actually produced, to catch those that do not meet the standard.
- Risk — a possible future event that would damage a project’s objective, schedule, budget or quality.
- Risk assessment — the activity of identifying such events in advance, judging each by likelihood and impact, and preparing a response to each.
- Scope — the boundary of what a project will and will not include, stated in both directions.
- Scope creep — the uncontrolled growth of what a project is expected to deliver, without matching changes to its schedule and budget.
- Slack — the spare time in a task that nothing else is waiting on, which can absorb a delay without moving the project’s finish date.
- Specification — the set of measurable values a deliverable must meet, each with its unit and the condition under which it is measured.
- Stakeholder — anyone with a genuine interest in a project’s outcome, including the team, the supervisor, the funder and the eventual user.
- Subsystem — a self-contained part of a larger system, performing one job within it.
- System architecture — a block diagram naming every subsystem and showing what passes between them, whether power, signal, data or command.
- Threshold — the value that separates one sensed condition from another, such as a dark-line reading from a light-floor reading; fixed by calibration for a particular surface, height and lighting.
- Validation — the check that a correctly built item actually does its job in the real setting, under the conditions it will meet.
- Verification — the check that an item was built to its stated specification.
- Version control — a system that stores every revision of code and design files, so that earlier versions can be recovered and two people’s changes do not overwrite one another.
- Work Breakdown Structure (WBS) — a tree that splits a project into major pieces of work, each into tasks, and each task into work one person can finish in a day or two.
- WBS — Work Breakdown Structure.
2.9 Objective Questions
- Which of the following best describes a project?
- Any technical work carried out by a team of engineers
- Work with a defined objective, a definite start and finish, and limited resources
- Work that repeats at fixed intervals and has no planned end
- Any activity in which a robot is built or repaired
- A team records, against each component in its list, the number of days between placing the order and receiving the part. This figure is called the
- contingency
- slack
- lead time
- milestone
- Fill in the blanks.
- The approved version of a project’s scope, schedule and budget, kept fixed as a reference for measuring progress, is called the ____________.
- The uncontrolled growth of what a project is expected to deliver, without matching changes to time and money, is called ____________.
- The defined boundary at which two subsystems meet, such as an agreed pin map, is called an ____________.
- State whether each statement is true or false.
- Monitoring begins only after the execution phase is complete.
- A task with slack can run late without moving the project’s finish date.
- A sensor threshold calibrated on one floor can be used unchanged on any other floor.
- Verification asks whether an item was built to its specification.
- Match each item in Column A with the description in Column B that fits it.
| Column A | Column B |
|---|---|
| a. Gantt chart | i. A tree splitting the project into progressively smaller tasks |
| b. Bill of Materials | ii. A dated checkpoint at which a defined deliverable must exist |
| c. Work Breakdown Structure | iii. An itemised component list with quantity, cost and lead time |
| d. Milestone | iv. A record of possible failures with their likelihood, impact and planned response |
| e. Risk register | v. Tasks drawn as bars against a calendar, showing overlap and dependency |
- Assertion (A): In a robotics project, subsystems are integrated one at a time rather than all at once. Reason (R): Integrating one subsystem at a time keeps any newly appearing fault confined to what was just added.
- Both A and R are true, and R is the correct explanation of A.
- Both A and R are true, but R is not the correct explanation of A.
- A is true but R is false.
- A is false but R is true.
- Write the full form of each of the following abbreviations: BOM, WBS, PERT, IDE.
2.10 Check Your Concepts
Define project management, and name the four things against which a completed project is judged.
A robotics team writes the objective “the robot should move smoothly and detect obstacles accurately”. Explain why this objective cannot be used to decide whether the project has succeeded, and rewrite it so that it can be tested.
Explain why lead time is recorded against every item in a Bill of Materials. Support your answer with one example of what goes wrong in a five-week build when lead time is ignored.
Differentiate between quality assurance and quality control, giving one activity that belongs to each in a robotics project.
A school team has drawn up the following component list for a small obstacle-detecting robot.
| Item | Quantity | Unit cost (₹) |
|---|---|---|
| Controller board with cable | 1 | 700 |
| Ultrasonic sensor module | 2 | 150 |
| Motor driver module | 1 | 200 |
| Geared motor | 2 | 180 |
| Wheel | 2 | 60 |
| Castor wheel | 1 | 40 |
| Laser-cut chassis | 1 | 400 |
| Battery pack | 1 | 520 |
| Jumper wire set | 1 | 120 |
The team’s standard contingency is 12 % of the component cost. a. Calculate the component cost, the contingency and the base budget to be requested. b. In week four a motor driver module and one geared motor are destroyed and must be replaced. Calculate whether the contingency covers this, and state the amount by which the base budget is exceeded or the amount remaining. c. State the three courses of action open to the team if the base budget has been exceeded, and say who should take that decision.
- A five-week robot build reaches the end of week three with the chassis assembly four days late, the wiring not started, and the software ahead of schedule. Explain the actions available to the team, justify the one you would take, and state clearly why simply adding two more people to the wiring task may not recover the time.
2.11 Diagram, Circuit & Output Reading
- The table below records a progress check at the end of week 2 of a five-week robot build.
| Task | Planned finish | Actual position | Task that waits on it |
|---|---|---|---|
| Order components | Week 1 | Finished, week 2 | Chassis assembly, wiring |
| Chassis drawing | Week 1 | Finished, week 1 | Chassis cutting |
| Chassis cutting (7-day lead time) | Week 2 | Ordered at the end of week 2 | Chassis assembly |
| Sensor test routine | Week 3 | Finished, week 2 | Nothing until integration |
| Chassis assembly | Week 3 | Not started | Wiring, integration |
- Identify the task that has slack, and the task whose delay will move the project’s finish date.
- State the consequence of the chassis being ordered at the end of week 2 rather than in week 1.
- Suggest one corrective action the team should take at this check, and say what it protects.
- The steps below are a team’s first draft of the decision logic for a robot with three line sensors.
1. Read the left, centre and right sensors.
2. If only the centre sensor sees dark, drive both motors forward.
3. If the left sensor sees dark, slow the left motor.
4. If the right sensor sees dark, slow the right motor.
5. Return to step 1.- State what the robot will do when the line passes out of range of all three sensors, and explain why.
- Write the additional step or steps needed to correct this, and say where in the sequence they belong.
- Name one further condition, not covered above, that the logic should test before acting on a sensor reading.
- The table below records twenty trial runs of a completed robot against its specification.
| Requirement | Target | Measured over 20 runs |
|---|---|---|
| Completes the track without leaving the line | Every run | 17 runs complete; 3 failures, all on the same tight curve |
| Correction begins after the line moves off centre | Within 0.2 s | 0.08 s to 0.12 s |
| Runs on one charge | 5 consecutive laps | 7 consecutive laps |
| Stops at the finish marker | Every run | Every run |
- State which requirements have been met and which have not.
- The three failures all occurred on the same curve. Explain what this tells the team that a simple success percentage would not.
- Name the one change you would test first, and state how you would judge whether it worked.
- A team’s risk register contains the following entry.
| Risk | Likelihood | Impact | Mitigation planned |
|---|---|---|---|
| Battery discharges before a full test run is complete | High | High | Recharge the battery when it runs down |
- Explain why the mitigation as written is not a mitigation, and rewrite it so that it is.
- State one additional mitigation for the same risk that costs nothing and can be carried out in the planning phase.
- State what should happen to this entry at each progress review during the project.
2.12 Case-Based Questions
- A school workshop team of five is given six weeks and ₹4000 to build a robot that carries small tools along a marked path between two benches. Their draft objective reads: “a robot that delivers tools quickly and safely”. Their component list totals ₹3200 and they have set aside a 10 % contingency. The laser-cut chassis carries a seven-day lead time, and one member of the team can solder while the others cannot. In week four, the motor driver module is destroyed during rewiring.
- Rewrite the draft objective as a testable objective, using at least three measurable quantities with their units, and state one thing you would deliberately place outside the scope.
- Prepare a milestone schedule for the six weeks, naming for each milestone the deliverable that must exist by then, and justify the week in which you would order the chassis.
- Calculate whether the contingency covers the destroyed motor driver module at ₹200, and state two mitigations that should have appeared in the risk register for the soldering skill held by only one member.
- A team is building a robotic arm for a science exhibition with a fixed opening date five weeks away. At the end of week three, the arm lifts and places blocks correctly, and the team has spent 70 % of its budget. Two suggestions are then made: to add a camera so the arm can find blocks by itself, and to add a mobile application so visitors can control the arm. The supervising teacher asks the team to decide.
- Using the relationship between scope, time and cost, explain what each suggestion would cost the project, and state which of the four things the project is judged on is most likely to be sacrificed if both are accepted.
- State how each suggestion should be handled formally, and what information the team must state before either can be accepted.
- The exhibition takes place and the arm works. Describe what remains to be done before the project can be called complete, and give two examples of the kind of specific lesson the team should record for next year’s team.