Really, I guess the approach I want to describe encompasses any project that is going to take more than a few hours.
Break it down into easy to consume chunks, it creates a nice list that you can cross things off of. There are plenty of articles and blog posts out there that talk about how it gives you a sense of satisfaction and the feeling your making real progress. But it really does work, try it out.
When I am looking at estimating a project, the first thing I do is to break down the project into logical sections, then those sections into individual tasks. This will allow for the creation of fairly accurate estimates and provide a natural roadmap for the project.
Depending upon the size of the project and the number of players involved, the need to use software to track the tasks that provides dependency links and Gantt charts and all the really nifty and fancy project management tools is probably going to be required.
In regards to project planning, over the years I have taken to using a four hour estimate as the lowest number of hours, this generally is for producing new code, as that code will require me to test it as I write it, many times it will require documenting (I write a lot of API methods). Now sometimes, I am spot on and finish either exactly at the estimated number of hours, other times it goes a little bit over and in some cases the work is similar to something else I recently finished, so I can re-use some code and I finish in what seems like a crazy little amount of time.
There are times when I know that a task will only take me an hour, so I budget about 90 minutes, as to allow for room that something might go wrong. But the four hour task tends to be a good default when dealing with a coding task you are not intimately familiar with, the big issue is setting expectations for yourself, your boss and or your client.
I recently broke down most a project’s tasks, there are some more I need to do, but interlacing with the other tasks of doing of the day, ran out of time. But I followed the four hour concept, with the exception of one where the changes are a few lines of code here and there, simply altering a query return to include a new field.
But I wanted to make some more progress on my redux of my old Product Management paper, I need to break it down into tasks, since it is a writing project, generally I just call this an outline. I also have a project I am working on that I need to start defining the tasks for as well, I have designed most of the database, but I really need to break out the tasks and get a scope of the project, I have a feeling I might finish it by the end of fall.
Outline
- Overview
- The way it should be
- The way it probably is
- Don’t try to fix it, focus on common goals of all parties
- Right tool for the job