When you begin to do your planning, you need a plan of
attack. How much time will you commit to this phase of the project? What, or
who, will be your resources? What is the goal of the research? Who else will be
assisting you? These are all questions you should answer as your research
The size of the project can help you determine how much time
you’ll need for planning. Of course, not all planning happens in one big chunk.
You’ll have some up-front planning and you’ll revisit the planning process
throughout the project. For example, if your project team is creating an
application, you’ll meet with the stakeholders to determine their needs, create
an approach to creating the application, and so on. As it moves into execution,
your team may need additional planning time to solve problems within the
Here’s a basic guide to determine how much planning time you can
expect for the type of projects you’ll manage:
Generally smaller projects that, as the name implies, add,
move, or change some element within an organization.
Ten percent of the project time allotted to
These projects take less than 2,000 hours of implementation
and/or less than $250,000 to complete.
Twenty-five percent of the project time allotted to
These projects take more than 2,000 hours of implementation
and/or more than $250,000 to complete.
Thirty percent of the project time allotted to
It’s easy to get bogged down in planning and hop
from resource to resource rather than focus on a specific objective. While
quality research takes time, an organized approach will allow you to find the
information you’re seeking in less time.
Create a Milestone
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.
There are multiple approaches to creating a task list. In Chapter 5 we’ll
focus on creating the Work Breakdown Structure (WBS), a cornerstone of project
management. The WBS is a deliverables-oriented collection of the project. The
WBS provides a true reflection of all the deliverables the project will create,
and using this, you can create an accurate and complete task list. In this early
phase of your project, you’ll likely need a task list to ascertain how long the
project may take, what types of resources are needed, and even how much the
project will cost. One of the best and most direct approaches is a simple
outline of what needs to be accomplished and in what order. For example, if you
are creating a task list for the installation of new software on every
workstation, your task list may look like this:
Test the software in our lab.
Test with Windows 98 laptops.
Test with Windows NT 4.0.
Test with Windows 2000 Professional.
Test with Windows XP.
Resolve and document any bugs or glitches from the testing
Create installation methods for each OS.
SMS server packages
Test rollout methods and document.
Roll out to pilot group of users.
Begin offering training of software to population.
Documentation for users
Finalize rollout plans and documentation.
Roll out software to users as they complete training
Work with help desk to answer support
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 outline approach, as just demonstrated, is not always the best
method. Some of the tasks in the preceding scenario can be completed
simultaneously rather than sequentially. In these instances, a flowchart can
really be beneficial. Using the same scenario, Figure 2-6 shows how the project would look in a
Figure 2-6: A flowchart
can help you visualize multiple steps of a project.
Another approach is to use a software program such as Microsoft
Project. Project allows you to enter tasks and then edit them in more detail as
the project develops, as shown in Figure 2-7. If you are using Microsoft Project, or
other project management software, you may want to consider starting your entire
project planning stages with the software. Certainly, there is nothing wrong
with creating an outline or flowchart and then transferring it into your project
Figure 2-7: Microsoft
Project is an excellent project management tool.
Of course, planning starts very broad. You may have to do
some initial planning and present your results to management so they may
determine if the project should be chartered. Once the project has a charter,
you’ll revisit planning to map out the milestones to complete the project. With
the milestones in sight and with your WBS, you’ll determine the activities to
get from milestone to milestone. Planning is iterative. You’ll be visiting the
planning processes throughout your 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.)
While this worksheet is simple and direct, it can keep you focused
on resolving fundamental issues and then branching into more detailed
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
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.
As you complete the research and the foundation for your project
develops, think about how you will react if any phase of the project falters. As
most IT projects will certainly have multiple steps to completion, there are
plenty of opportunities for things to go wrong. And they will. Figure 2-8 shows how contingency
plans are used and built into a successful project.
Figure 2-8: Contingency
plans are “in case of emergency” decisions.
As part of the project planning process, record
reported troubles; document any conflicts with other technology, and bookmark
any articles or web sites that offer warnings on the technology you’re
implementing. Researching the negative possibilities of your technology can keep
the love of the implementation from overriding reason, and heighten the
awareness that any technology can have flaws.
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
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.”