It’s been a week since you started working on your project proposals. You should have a good idea of what you want to do and what it might take to do it. I want to take some time and share with you how I approach time management when planning programming projects here in MITH.
The two principles I work from when managing time are: we don’t want to get into a death march project, and we want the highest priority requirements to be met at the end of the project.
The first principle, that we don’t get into a death march, means that we only work forty hours a week or so and don’t work overtime. Studies have shown that working overtime too much leads to less work getting done than if you only worked a forty hour week for the same number of weeks. No use risking burnout if it means you’ll be turning out poor work.
If we want to limit ourselves to the time we have available for a project, then we have to know how much time we have, how much time we think we need for each thing we need to do, and the relative importance of each item so we know what we can leave undone if we run out of time.
For your project, you have fourteen hours, more or less, so you want to figure out how to fit your todo list into those fourteen hours and make sure you get the things done that will have the highest impact on your grade.
When we start a project at MITH that might take months to complete, we break it into a sequence of milestones that can take a week or more each. We have a rough idea of what needs to be done, but we recognize that we learn a lot along the way and don’t want to be too specific in the beginning about what we’ll be doing in six months if we’re going to have to redo the planning anyway because of stuff we learned during the earlier milestones.
You only have one milestone: your project and fourteen hours of work.
At the beginning of each milestone, we get together and walk through what we need to do to accomplish the milestone. This is our todo list that we will prioritize and check off as we do each item.
Beside each item, we write a single letter denoting how difficult we think the item will be: Quick, Easy, Moderate, or Hard. We assign each one a time: quick is 30 minutes, easy is an hour, moderate is two hours, and hard is four hours. If we think it’ll take more than four hours, then we know we need to break it down into simpler steps.
The reason for not allowing ourselves to take on anything that will take more than four hours to accomplish is so that we don’t have to stop in the middle of a task and go home, then come back in the morning and take time figuring out where we were. If we have a two hour block of time, we can pick something from the list that is moderate or easier.
Of course, you’re not working on this as part of an eight hour workday. Knowing how long you expect a task take will help you fill in those odd hours here and without having to stop in the middle of something and hope you can come back to it later.
Once you have your todo list and how much time it will take to do each item, you can prioritize the items. Which items are fundamental to your project? Which ones add flavor? Which are at the core and which are expanding on the central theme?
After prioritizing, you can run down the list adding up the time for each item. When you hit fourteen hours of work, you know what you can expect to have done by the end of the semester.
After you finish your project in December, you can look back and see how well you guessed your time requirements. Computer work is notoriously difficult to estimate, so don’t be surprised if you’re off. The rule of thumb is to double the estimate from an expert in the field.