Schedules

This is not about the real-time operating systems or traveling on the train, bus or airplane. It's about the problem you face when trying to come up with a reasonable schedule for a project and specifically for the case when you want to do the project and the company is not enthusiastic about the project.

So, there you are - you are asked, "How long will it take you to do this project?" Of course it's impossible to give an exact answer. Also, you cannot be absolutely impartial. You are faced with a true dilemma. If you give a schedule that is too fast, you risk being late on the project. If you give a schedule that is too slow, you risk that this will be used as an excuse to not do the project or that they get someone else to do it.

The answer is to be as honest and impartial as you can. Using the length of the schedule to decide whether a project should be done should not be your concern (and it's a pretty stupid move on the part of your company if that is their criteria for doing the project or not). Besides the schedule itself, you should be able to offer innovative options. You should be able to show your excitement for the project. You should take the time to develop a well thought out schedule which includes as many ways around sticking points as possible. The schedule should include as large a collection of milestone events as possible.

Perhaps in a future message I'll be able to go into more specific examples.