Take the 2-minute tour ×

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?

share|improve this question
You could always just pick a random number like 6-8 weeks (meta.stackexchange.com/questions/19478/the-many-memes-of-meta/…) –  Zoredache Nov 25 '09 at 3:22

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.

share|improve this answer
+1. That sounds useful. Wish I had four more rep points so I could vote you up. –  Wang Nov 25 '09 at 4:16
Then multiply it by about 4 to account for all the stuff you don't know you have to do, and the over-optimistic estimates on the things you do know you have to do. –  womble Nov 25 '09 at 17:13

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?

share|improve this answer
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.

share|improve this answer
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. –  Wang Nov 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 :) –  kolypto Nov 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.

share|improve this answer

Your Answer


