How do you maintain a project schedule?

Question

One of the elements of the Joel Test is that you have an up to date schedule. What tools do you use to create and maintain your project schedule? How often is it updated?

Answer 1

I like to see things like technology roadmap diagrams: http://en.wikipedia.org/wiki/Image:Purpose_programme_planning.jpg One problem with scheduling is that it isn't usually contextualized into the business goals and when decisions have to be made about what to keep versus what to cut for a given release all the way down to testable subcomponents of the problem. Roadmap diagrams address this.

I would say that an update should happen anytime one reaches halfway through a scheduled item, no matter how small. This gives time for one to reevaluate before anyone is schedule to be done, saving face.

If you have to estimate percentages of task completion, the task isn't small enough. I've seen too much "logarithmic progress": week one 0.9, week two 0.99, week three 0.999 etc. Never leave anything unfinished unless it is cut.

If an item slips once, it's probably just a misestimate. If twice, break it down to root causes, because something important wasn't learned.

Answer 2

The standard way is to use tools like MS Project or some open source alternative like ganttproject to manage your tasks and milestones and have an overview in an nice gantt chart.

I prefer a lighter approach with basecamp. The update should be daily, but I'll do it at least once a week as part of my gtd review.

Answer 3

At the very minimum you need to maintain a list of prioritized tasks, each with an estimated effort (probably in hours). You need to track actual effort against each task, and have a time (effort) remaining - this includes updating the estimated effort or having a current estimate, should a task take more or less time than expected etc.

Tasks that exceed more than two or three days should be broken down to try and help you better understand the problem and provide more accurate estimates. Ask the developers how long they think the task will take and get them to regularly (every couple of days) update the spreadsheet with how complete they are with each task.

If in terms of tools, you mean software rather than techniques, then for a lot of projects tracking tasks in a spreadsheet is probably sufficient. The likes of MS Projects are often overkill, unless your project is large and has lots of people and dependencies. The simpler you keep your scheduling, the more likely you are to keep it up to date.

Answer 4

I recommend Painless Project Schedules:

http://www.joelonsoftware.com/articles/fog0000000245.html

Joel says that this is obsolete, but I suspect that's because he just wants us all to buy FogBUGZ 6 which has EBS (also sexy) built in:

http://www.joelonsoftware.com/articles/fog0000000245.html

The trouble with EBS is there aren't any nice free tools that can get you started. The painless method only requires a spreadsheet.

Answer 5

MS Project is a good place for the schedule to sit since many people know at least how to read it. Every one has there own way of maintaining schedules, but i would try to ignore the tools a bit and focus on delivery of your milestones.

However on the tools side, what i do is;

1) Using Excel on an overhead projector (or via GoToMeeting for virtual teams), take your list of deliverables and sit down with the team (1 on 1 or in groups) and work out what tasks need to be done to complete those deliverables and what tasks depend on what other tasks. Once complete assign IDs to all the tasks.

2) Next (could be after a break or a different session) work out how long it would take some reasonable person on your team to complete the tasks.

3) Next import all of this to MS Project, and with the minimal amount of fiddling put in peoples holidays and time off, and assign people to tasks based on who is available, whop can do the work etc. All your deliverables then become milestones, and chuck in some extra minor milestones at important points in the schedule such "UAT completed and signed off" or "Vendor approved and contracted".

5) From MS Project take a list of your Major and Minor Milestones and this is the schedule you will use for 99% of your communications. When you get your plan approved, use the Milestone to describe your schedule and the costs should relate to these milestones. This means your sponsor(s) can see the high level steps, effort and cost involved in getting what they requested.

6) During the project use MS Project to extract lists of task and assignments. The team will need this. However every project meeting and communication should be around the minor and major milestones. Which in my case ends up in MS Word, and the only time i pull out MS Project is when we need to re-schedule and re-budget.

I believe that if you are spending too much time in a project scheduling tool you are not spending enough time managing your project.

Answer 6

Joel Spolsky has good advices in his article Painless Software Schedules, but he marked this article obsolete in favor for an article about Evidence Based Scheduling. I like the painless method more, because the evidence based method needs tool-support.

But even the Painless Software Schedules can be made simpler. Here is what I use.

You need some program, to create a table, excel or gnumeric are cool, but wiki or word or even a simple text-editor are enough. I make my schedules at the moment in the wiki of the Trac we use at work.

Make a schedule for every milestone. Add a row for every issue, that should be solved in this milestone. You need at least 3 columns: issue, estimation and needed. Note in the first column the short description of your issue. If you can, note the number for the item in the issue-tracker. Note your estimation (in hours) in the estimation column and every time you work on this issue you note the time you worked on that. The star in the example marks a task, that you are working on, so the time needed will grow before you finish this item.

issue                                           est. real
issue 15: application crashes if i click next     5h   6h
implement new view                               25h   7h*
SUM                                              30h

Bigger items could be separated to make better estimations:

issue                                           est. real
issue 15: application crashes if i click next     5h   6h
implement new view
  refactor old view, to use a model              15h   7h*
  implement new view using the model             10h
SUM                                              30h

Possibly you want to add columns for priority, notes or other stuff. Do so, if you wish.

Add some buffer to the result estimation. That's some security for bugs, features that are more problematic than thought before and so on. 25% for security buffer is a good start, based on your experience with your estimation skills you can vary this value. If you unsure about a feature use more buffer.

If you talk with the project-leader about the release date, remember that you will not work fulltime at the project. There are meetings, you help another programmer to solve a problem, you have to answer telephone calls or you talk about yesterdays game. If you have a 40-hour work-week you can spend 30-35 hours on your project. EDIT: I've heard now, that only 60% of time can be used directly for work, the other time is for unplanned tasks (i.e. computer crash or telephone ringing) and for social contact (i.e. drinking coffee). So the 40-hour work-week leads to only 24 hours for the project. Take this into account if you decide about the release date.

Keep your old schedules. If you make a new one for the next milestone, you can look up the old one for the time you needed before on similar tasks.

If you encounter bugs while coding you can measure the time you use on them by adding a new line for the bug, without an value for the estimation. The buffer in the estimation makes up for the time you spent fixing the bug. And you get a record about how long you need to fix a bug of this type. This could look like this:

issue                                           est. real
issue 15: application crashes if i click next     5h   6h
implement new view
  refactor old view, to use a model              15h   7h*
  implement new view using the model             10h
bug 23: calculation is wrong if input is empty         2h
SUM                                              30h

As you can see, the new bug don't add anything to your estimation, but adds to the real time needed. Cases like that should be covered by the buffer (and help to explain management, why a buffer is needed).

Answer 7

ive used joels painless project schedule approach for a few years now. i know he has updated this to his evidence based approach, but i still think his original format is quite good.

i actually use google spreedsheets for scheduling now. i have an article on my blog which explains why if you are interest: http://pm4web.blogspot.com/2008/07/google-spreadsheets-for-project.html

Answer 8

Our team recently adopted scrum/sprint techniques to solve the need for scheduling and predictability. In brief it works as follows:

• every two weeks we have to sit down and plan the next 2 weeks. The dev team collectively assigns 'unit' estimates of 1,2,4,8 points of 'effort'. (Larger than that has to be broken into smaller tasks on the assumption that large tasks are inherently hard to schedule)
• all task estimates and planning should be inclusive of test, documentation, etc
• tasks are done in the order requested by management, but the team draws the line at what they think they'll get done (based on their previous estimates over time)
• tasks are designed to have a very clear 'end to end'. e.g. not 'design the database schema for orders' but 'enter a new order of very limited type and run a report showing the order'
• tasks cannot be altered once each period starts (changes are queued for the next sprint)

We've found the following pros and cons:

Pros:

• we catch bad estimates early
• we catch spec misunderstandings early
• we learn every 2 weeks how to estimate better
• management can change their mind often and the team can accomodate it

Cons:

• planning every 2 weeks is tedious (but less tedious than any other scheme we've used)