Starting New Projects

Defining the schedule

You'll need to know if there is a deadline for the documentation. You'll need to be able to judge whether you can complete the project on time or if you need to scale back the project to make a deadline. This will involve some article and you may not be given much room for negotiating the size of the project or the deadline. When it comes down to it though, you need to give your clients what they want when they want it. It's your job.

When discussing the schedule, you should determine who needs to approve the documentation and when. For example, you should find out if the stake holders want to approve your documentation before you create an online help file out of it. Who needs to approve the documentation and when they want to, or should, do it by depends on your working environment. It's generally a good idea to get approval for all technical content before anything else. It's easier on you and your editor.

You may want to set milestones for yourself. This will help you keep your project on track, and give your clients an idea of what they can expect by certain dates.

Any scheduling you do should be flexible. When it comes down to it, if you can get the documentation done by the due date, it doesn't really matter if you were off a couple of days on one of your milestones. Be warned now, nothing will derail a schedule faster than waiting for approval. When discussing any schedules, you need to make it clear that timing will be dependent not only on how fast you work, but also on how fast those responsible give their approval. Technical edits from subject-matter experts can cause considerable delays in any project. So, you need to be able to provide some sort of contingency plan if those who are responsible don't do their part on time.