Creating an Approach | IT Project Management: On Track from Start to Finish, Third Edition

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 begins.

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 development.

Here s a basic guide to determine how much planning time you can expect for the type of projects you ll manage:

Project Type	Attributes	Planning Time
Add/Move/Change	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 planning
Micro Project	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 planning
Macro Project	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 planning

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 List

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.
1. Test with Windows 98 laptops.
2. Test with Windows NT 4.0.
3. Test with Windows 2000 Professional.
4. Test with Windows XP.
Resolve and document any bugs or glitches from the testing phase.
Create installation methods for each OS.
1. Batch files
2. Logon scripts
3. SMS server packages
Test rollout methods and document.
Roll out to pilot group of users.
Begin offering training of software to population.
1. Instructor-led training
2. Web-based training
3. Documentation for users
Finalize rollout plans and documentation.
1. Roll out software to users as they complete training class.
2. Work with help desk to answer support calls.

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.

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 flowchart.

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 management software.

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.

Manage the Planning

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 objectives.

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.

Contingency Plans

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 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.