Please let me know if this is off-topic, as this question deals with the
logistical or administrative side of IT rather than the technical.

This December, one of my colleagues and I are going to take two weeks during
the university's winter holiday to tackle a few projects including

updating our Radmind loadset to Snow Leopard

setting up a new NetInstall-based imaging scheme

cleaning up an in-house codebase

migrating a few services to different servers for security and
robustness

rebuilding two key servers from backups and bare metal for practice

None of these have defined objectives or good time estimates, so I'm at
a loss for how to even begin. Plus, both of us are students with no
formal IT training, so for the NetInstall and migration, we'll be
learning on the job.

In light of this, what kind of project plans should we be writing? I'm
not asking because I need to hand a formal proposal in, but rather
because I think preparing such a document would help me think about it
and organize the work. Basically, what should I be considering in
scheduling and prioritizing my work on a day-to-day basis?

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

4 Answers
4

When you are totally unsure, game it out. Break down the projects into as small chunks as you can possibly imagine and estimate the time each chunk takes. Go over in your mind the pieces that comprise the job and imagine you doing them. Proper time estimates come from making estimates, doing, then seeing where you are off.

As the others say, detailed planning is your friend. Maybe you'll still be unsure how long each task will take, but you will get a better idea than you have now and you'll have a better perception of how many tasks you have. Take the following example from your post:

migrating a few services to different servers for security and robustness

rebuilding two key servers from backups and bare metal for practice

What servers? What services? What is your success criteria?
Some services are more complex to move than others (e.g. DNS is easy to move, Open Directory is more complex than DNS, Exchange server would be very complex indeed)

Some servers are more complex to work with and backup than others.
What are you backing up? to use my example above, it can be increasingly more complex to back up and restore a database server than it is a simple file server.

How are they currently backed up? How hard is it to install the backup software? How much configuration does it need? How long does it take to restore a server? To back up a sever? (you'll need to do this at least once more than you probably planned to already as part of your test regime to ensure the system is restored correctly, for example). If these are key servers how long can they be offline? How will you mitigate the possibility that you can' restore them because there's a problem with the backups or hardware that only becomes apparent when you start working?

When you're sure it will take not more than 3 days -
on the 3rd day something happens.
Your Murphy.

Always use the maximum time you could imagine it will take within the range the client can call this "acceptable": he'll be happy when you finish earlier and you'll be proud, free, and ready to continue to the next task as soon as you feel like doing it.

But see, the client is me. I'm not generating an estimate for some client, I'm trying to figure out how to get some stuff set up so I don't spend the next quarter fixing it.
–
WangNov 25 '09 at 4:16

Assuming each task occupies more time you are not wasting it: you can start doing other things if you're ready with the previous one (with a bit of self-motivation), and also you'll never have deadlines :)
–
kolyptoNov 25 '09 at 10:20

As Blackeagle said, break the projects down into smaller steps that you can estimate. I wouldn't go so far as to say "as small chunks as you can imagine," but break it into small enough chunks that you can estimate the time for the chunks.

For the migration and rebuilding projects, the first chunks should be to document what's there already: how the services work, what's installed, where the install files are. For the rebuild, what's the hardware, what drivers are needed, what apps are installed, where are the install files.

If you're learning on the fly, I wouldn't expect to get all that stuff done in 2 weeks. I'd start with whichever project you understand the best, i.e. the one you can break down into sub-tasks the most confidently.

For scheduling, if you have the luxury of two weeks uninterrupted, I'd work on one project until it's done. Then go on to the next. While working on one project, you could start preliminary work on other projects, but I wouldn't do anything that's not easy to undo.

Document what you do and how long it takes as you go along so you can see what takes time and improve your estimating for the next time.