Friday, July 30, 2010

Adventures in Scheduling: two weeks


Two weeks ago I posted about my new attempt to actually make a work schedule of some form, instead of figuring out my work tasks each hour as issue erupt. I've been doing it for eleven work days, and this is an update on what I have learned.

It's hard to trust the schedule, but I must. The challenge is that with ten or so ongoing projects, it's always hard to believe that task number 6 is truly important enough to be working on it right now. The other nine tasks call to me from my conscience. But the point of making a schedule is to intentionally and consciously ensure fairness among the tasks: I.e. Every project will get some time, and critical projects will get the extra time they need.

People schedule meetings without asking me when I can meet with them. This one has been hard ti take. Often that scheduled meeting punches a big hole in my focus on another in-depth development project. It's really tough to work for one hour on software then do a 30 minute call, then another 90 minutes back on software.

Rescheduling for the future is key. In these two weeks I have had two instances of planning work, but being stymied by the customer's network. In those cases I have had to just drop the project until a future date. My desire would be to push everything around for the sake of this customer, but that approach has failed me many times before.

gahk! Don't forget to add meetings to my calendar. I goofed up and ended up working a lot last Saturday because I forgot the time of a meeting, and I had a day of planning to do before that meeting.

Switching between software projects is painful. Three of my projects are software development. I'm mostly doing two of them: A and B. I'll work for 3-4 hours on A on one day, then 3-4 hours on B the next day. This switching does ensure some fairness, but it's been very tough to get into the work each day. Also, 3-4 hours isn't enough time to even finish some smallish changes, so I'm sometimes forced to comment out big blocks of unfinished code to get the thing to compile. (All my projects share some common library code that is under development.)

All in all, it has helped make more fun, but the scheduling still needs sime work. I need some ways to deal with being drafted into meetings at times that prevent work on other projects, in particular.

Monday, July 19, 2010

Adventures in Scheduling


I always like to plan my work, but it's remarkably hard for me.

  • How long will a task take?
  • What emergencies will erupt, requiring my immediate attention?
  • What tasks will get delayed by the customer?
  • What tasks will be impossible because of technical issues?


But I went crazy this morning: I made a schedule included some time for all of my 10 projects.

Some new things I did:

  • Included time every day for planning.
  • Included some short gaps every day for extra stuff that comes up.
  • Included two large (3 hour) gaps every week for stuff that has to be moved around.
  • Planned work two weeks out.

When I have a scheduling problem, I'll move things around airline-style: if I have to move a task, I'm just going to move it to some distant date in the future. I'm not going to try to push back every other item on the schedule.




Results from Day 1 (Monday):

  • I've already partly filled my large gaps for the week. (A project that I learned of last week requires some time for this week.)
  • My large project for today wasn't completed. I wasn't able to get the software installed on the server quickly enough to get everything done before my 4pm meeting. That means I'll have to reschedule it for some future day or week.