Software projects can be managed in terms of 4 variables ● Time ● Scope ● Resources ● Quality

Example: Water filtration plant on a space station The plant has a control panel with four dials, labeled Time, Scope, Resources, and Quality

The Time dial Adjusts the amount of time spent filtering water (available time for you to spend on researching, writing code, writing a paper, etc.) The Time dial is a limiting factor. If the other dials remain constant, running the plant for a week will produce a greater amount of quality water than running the plant for only a day.

The Resources dial Changes the amount of equipment used to filter the water. (How much guidance can you find to assist you in your project. Algorithms, mentorship, books for resource, software examples, etc.) This is dial is also a limiting factor. If the other dials remain constant, running the plant with ten filters produces more quality water than only one filter.

The Scope dial Adjusts the amount of good water the plant will produce. This is an enabling factor. If half the filters are down, the scope must be reduced by half capacity unless time is increased or quality is decreased. If the scope is increased, time or resources must increase or quality must decrease.

The Quality dial A more complex dial. Few projects ever decrease quality directly. Increasing scope without increasing time or resources, or reducing time or resources without decreasing scope tends to decrease quality indirectly. Increased pressures on time or resources eventually force quality downward. Increasing quality (you have an inspired day of programming) can decrease pressure on time or resources.

Tendency to increase scope Many projects concentrate on time and resources, assuming the quality will stay fixed. If scope ever changes, it's usually increased. But time and resources are often reduced, or at best are kept constant. The only remaining adjustment point – quality – slips downward.

Strategy ● Agree on an acceptable level of quality ● Agree that time and resources are fixed ● The only remaining question is that of scope. ● What will be delivered, and when? ● The software will always be kept in a releaseable state ● Adjust scope regularly

Values ● Communication – Honest, regular communication allows you to adjust to change ● Frequent feedback – Asking questions, learning from the answers ● Simplicity – Build only the system that needs to be built. Solve only today's problems today. Complexity costs a lot and predicting the future is hard.

“Courage” ● Courage – Making the hard decisions when necessary – If a feature isn't working, fix it – If some code isn't good enough, improve it – If you're not going to deliver everything you promised on schedule, communicate this – Decide what you can deliver and do it

Assuming sufficiency ● Given sufficient time and resources, how would you develop software? ● Rather than scrambling to meet an impossible deadline, work at your normal pace ● The amount of work you can do is constant – the question is which work to do ● Adjust scope to fit the schedule to the available time

For October 1 ● Draft of Project Proposal ● Decide on a prototype code that is “releaseable” ● “Iteration 1” ● Communicate, review your progress with the class