Using Application Software Packages to Plan a Project

Before I begin discussing the tools, templates, and processes needed for project planning, I want to spend some time on the software packages and why you might or might not use them. I have always been an advocate of using the appropriate tools to plan a project. My experiences have ranged from the back of the napkin to the use of sophisticated modeling and prototyping tools. The size and complexity of the project has a lot to do with your choice of software packages. The larger the project, the more you will need to depend on software packages. But what about small projects or projects that are done in some incremental or iterative fashion? The answer is not always clear, but the following section describes my approach.

Determining the Need for a Software Package

Project management software packages (at least those priced under $1000 per seat) are both a boon and a bust to project teams. On the boon side of the ledger, they are great planning tools and allow the project manager to investigate several alternatives without the accompanying labor of having to manually adjust the planning parameters. On the bust side, they have not been very helpful in managing resources and in fact have had some rather bizarre results.

Schedule updates are also a troublesome area. The problem lies in getting reliable estimates of percent complete and estimated time to completion from each task manager. Garbage in, garbage out. These data are essential to maintaining the project plan. On balance, the project manager has to be aware of the time savings, the time drains, and the reliability of the schedule updates in deciding whether to use a package or not. It all comes down to the value that is added for the effort that is expended. The smaller the project, the less likely it is that you will find added value in using the software package. Clearly for large or even medium-sized projects, software packages are a must.

For the types of projects that this book deals with, the answers aren't all that obvious. In these cases, project software packages can make the task of building the initial project plan a bit less labor-intensive than manual alternatives are. But even that is a matter of choice and preference. You can just as easily move sticky notes across a whiteboard as you can drag and drop task nodes across a Project Evaluation and Review Technique (PERT) chart. PERT is a graphical tool that displays the relationship between dependent tasks. For schedule updating, I have a clear preference for whiteboards and sticky notes. My reasoning is that I can get the entire team involved in the exercise, and everyone can see the alternatives much easier on the whiteboard than they can on the computer screen. For distributed teams, some compensation can be made by using web-based tools to communicate sticky note information electronically.

The best testimony I can give you is from my own experiences managing a three-year, $5M project. All I used were the planning tools discussed in the next section. That agile project was completed nine months early, successful beyond client expectations, and significantly under budget.

Project Planning Tools

The list here is very short: sticky notes, marking pens, and plenty of whiteboard space. I don't want you to think that I have taken a step backward to a time when there were no automated tools. Quite the contrary: I do use automated tools for project planning but not for execution. The tools I just mentioned happen to be my choice for some incremental, most iterative, all adaptive, and all extreme projects. These are introduced in Chapter 9 and discussed in detail in Chapters 10, 11, and 12. Agile, Extreme, and Emertxe projects account for more than 80 percent of all projects. The reason I use such simple tools is simple. These projects all proceed in short cycles of two to four weeks. You don't need a sledgehammer to kill a mosqufito! If you really have to depend on software tools, go ahead. Just remember that if you create the plan using software tools, you have to maintain it.

Sticky Notes

Sticky notes are used to record information about a single task in the project. The information that you might want to record on a sticky note includes the following:

• Task ID
• Unique task name
• Task duration
• Task labor
• Resource requirements
• Task leader
• Calculated values such as earliest start (ES), earliest finish (EF), latest start (LS), and latest finish (LF)
• Critical path (calculated)

Color-coded sticky notes offer a number of alternatives for the creative planner. For example, you can use a different color to represent each of the following:

• The type of task (critical, for example)
• Specific parts of the WBS (design, build, test, and implement, for example)
• A position on the team (a critical or scarce skill, for example)

Using sticky notes in this way is not only visually appealing, but it's very informative during resource scheduling and finalization of the project plan. With experience, the color coding becomes intuitive.

Marking Pens

For the purposes of project planning, you will need dry-erase marking pens. They come in several colors, but you will only need the black and red ones. They are used to visually display the dependencies (black marking pens) that exist among and between the project tasks or the critical path (red marking pens).

Whiteboard

The whiteboard is indispensable. Flip charts are not a good alternative. For large projects, you need to have a minimum of about 30 linear feet of whiteboard space for planning purposes. The room that provides this space will become the team war room and, if possible, should be reserved for the exclusive use of the team for the entire project. It will need to be a secure room as well.

The whiteboard will be used to create, document, and in some cases post the following:

• Project Overview Statement (POS)*
• WBS*
• Dependency diagram*
• Initial project schedule
• Final project schedule*
• Resource schedule*
• Issues log*
• Updated project schedule*

The items shown with an asterisk (*) are permanently posted on the whiteboard and updated as required.

Portable electronic whiteboards can be used when a dedicated space is not available.

How Much Time Should Planning Take?

This is one of those “it all depends” questions. This is not a question that is easily answered because a number of variables will affect planning time. The most important variables are project complexity, solution clarity, and the availability of the team members and the client for planning meetings. The actual labor involved in building a plan for the typical small project is about one workday. Ideally that would occur in one calendar day, but peoples' schedules might make that impossible. When you have difficulty scheduling the planning team, don't revert to planning by walking around. That just doesn't work. Trust me — I learned the hard way!

As a rule of thumb the following estimates of planning time are a good guide:

Further complicating estimating planning time are the APM, xPM, and MPx projects. For all of the PMLC models in those three quadrants planning is done iteratively over time. If you still need an estimate, here is the best I have to offer. If you know the total number of iterations involved, then consider each iteration as a very small project and multiply the number of iterations by 1/2 day.

Running the Planning Session

Consider the ideal situation first. All of the following activities are part of the planning process, and all of them are completed in one workday. This section gives you a high-level look at what these activities are. In subsequent sections, you'll learn the details of how they are to be accomplished.

In a one-day planning session for a typical small project, the planning team performs the following major activities:

• Reviews the POS for clarity
• Creates the complete WBS, including the Activity List
• Estimates task duration and resource needs
• Constructs project network diagram
• Determines critical path
• Revises and approves project completion date
• Finalizes resource schedule
• Gains consensus on the project plan

The project manager can run the planning session for small simple projects. For larger or more complex projects, it pays to have someone other than the project manager facilitate the planning meetings. To complete this planning session in one day, the project manager will have to tightly control the discussion and keep the planning team moving forward. Any briefing materials that can be distributed ahead of time will help reduce briefing time in the actual planning meeting. There should be a timed agenda, and everyone must commit to sticking to it. Ground rules need to be put in place. One time-saving alternative is to have the project manager and the client complete the Conditions of Satisfaction (COS) and Project Overview Statement (POS) ahead of time and circulate these documents to the planning team prior to the meeting.