One of the primary goals of planning is to determine how the project will be completed, the resources required, and the tasks involved in the project. Part of planning any project is to create a task list, which simply comprises the major steps required from the project’s origin to its conclusion. A task list is created after the technology has been selected and before you create the implementation plan. You don’t need to get too granular with the tasks, just provide a general overview of what needs to be done.

While the list is simple and direct, it allows the technical project to begin to take shape. It also allows the project manager to determine the type of talent, number of team members, and time commitment involved with the project.

If you are completing the majority of the planning phase with your project team, pay close attention to the amount of time the team invests. Quality research doesn’t come easily and takes a commitment of man-hours to produce quality results. However, too much time invested in research can lead to muddied results, meandering from topic to topic, and project burnout. It is always in your best interest to set a specific goal and deadline for the initial research.

To set a research goal, create a list of questions that you’ll need answered to manage your research time. On the CD-ROM within this book, you’ll find a document called Research Objectives. (You’ll be shown how to access this worksheet in exercises at the end of this chapter.)

If you are fortunate enough to have multiple people helping you research the project, don’t be tempted to micromanage. Assign research topics to the team members, give them objectives that their research should produce, and then give them a deadline. There is no need to watch someone research. Let your team complete their assignments, and wait for the results.

Once your team members have completed the research, create a way for the information to be compiled quickly and easily so it can be assessed and then decisions made. If you have the resources, and depending on the project researching, conduct a meeting and have the team members report their findings.

As the findings are being shared, have someone collect the notes and record any dialogue, controversy, or other information from the meeting. After the meeting, organize the collected data and disperse it to the team members. From the discussion on the collected research, the compiled report, and your own intuition, you should be ready to make an intelligent decision on how the project should move forward.

Every project needs at least one contingency plan. You may call these rollback plans, worst-case scenario plans, or disaster recovery plans. A contingency plan is a predetermined decision that will be enacted should the project go awry. If you ignore the creation of a contingency plan, you are tempting fate. A project that runs askew without a contingency plan will force your project to be late and most likely over budget.

Use if-then statements such as the following to compose most contingency plans: “If the software conflicts with our video driver, then we’ll write a driver that allows it to work.” While this seems simple, a series of if-then statements can allow you to create a quick and concise contingency plan.

One of the primary reasons for creating contingency plans during the research phase of the project is in preparation of the next phase: dealing with management. Management loves to play devil’s advocate. Some will swear they are the devil, but they aren’t—usually.

By having a documented, logical contingency plan for each facet of your project, you are working with management prior to the face-to-face meeting with them. This will build trust, confidence, and support of your project even before they say, “Make it happen.”