Develop Project Execution Plan


As shown in Figure 15.2, the development of a project schedule involves five steps. The development of a schedule for a project is best completed on an electronic whiteboard so that all participants in the RAP session can be involved. Also, the process is iterative and you'll generally need to loop through the five steps a number of times to get an appropriate schedule.

Figure 15.2. Developing a schedule

graphics/15fig02.gif

The key in scheduling is to understand that there is never one schedule. There will be many alternatives for scheduling a project and the optimum schedule depends on deadlines, the skill levels of the team members , and availability of people. Again, the advantage of team-based planning is that you'll have lots of people to help you work out the alternative schedules and to select the optimum one for your project, team, and stakeholders.

As we discuss later, the process of developing a project schedule (or project execution plan) involves further refining of your initial estimates and, in many cases, this process also leads to major estimation errors.

Step 1: Develop a First-Cut Network

This step requires the team to examine the tasks identified during the planning session and determining the relationship in terms of inputs and outputs.

There are two questions that need to be asked when developing the network:

  • Which tasks are dependent on other tasks' outputs for their input?

  • Can other tasks that are not dependent on the task currently being scheduled be commenced concurrently?

All PC-based scheduling tools will enable the diagram shown in Figure 15.3 to be created. The use of alternative relationships such as start-to-start becomes more important in later steps. The typical relationship in dependency is a deliverable dependency . For example, until the initial interviews with the business stakeholders are complete and an interview summary is produced, the initial analysis cannot start, as it needs the interview summary for input. You can also have a resource dependency ; that is, until one person finishes a task, another task cannot start, as he or she is going to do it.

Figure 15.3. Developing a first-cut network

graphics/15fig03.gif

A Dangerous Myth

A number of people believe that out of an eight- hour day, they can be productive for six hours (often stated as the 70% effort "rule"). The origins of this myth are lost in time but, based on our surveys, the amount of lost time in nonproject activities such as nonproject meetings, teaching newbies the ropes , fixing general things, answering useless e- mails and general switch time is around 50% of the day for many people. Measure it yourself just to be sure (see Chapter 17).

The key to the first step is brainstorming as many variations to the network as possible for optimizing in later steps.

Step 2: Adjust Estimates to Elapsed Days

The next step is to enter or load the network with the raw effort estimates developed during the RAP session. As discussed earlier, the estimated effort needs to be adjusted to include nonproject activities. In most scheduling tools, there are calendars for each person who is to be scheduled. The default setting in most tools is eight hours per day. Most organizations will have some guideline on productive time (e.g., five hours per day), so the calendars need to be modified to reflect five-hour, not eight-hour days.

You need to be very careful here. As we state in the sidebar, there are a number of nonproject activities that most people seem to seriously underestimate when converting the effort to elapsed days.

Step 3: Develop First-Cut Schedule

By entering the adjusted effort into the task entry screens in the scheduling tool, a first-cut schedule can be viewed . This step simply provides a schedule that assumes that only one person is completing the project. Figure 15.4 shows a loaded network and the first-cut schedule.

Figure 15.4. Developing a first-cut schedule

graphics/15fig04.jpg

The most important steps are the final two, in which the actual resources, their costs, and other factors such as resource dependencies where a person is undertaking two concurrent tasks or where a task depends on a person completing another task so that person can commence another because of his or her skills are factored into your plan.

Radical Scheduling

Steven Eppinger "The Speed of Information," Harvard Business Review , January (2001, pp. 149 “158) makes the point that traditional scheduling concepts such as PERT and critical path method (CPM) ignore feedback and other chaotic loops that are part of eXtreme proj ects. He developed a tool called the design structure matrix that addresses these and other failures of task dependencies. We strongly recommend his article and his approach.

As we cover later, this is where you start making assumptions about your team members and their skills and, of course, this is another cause of estimating error.

In addition, as discussed in the sidebar (Mythical Man-Month), you have to be careful when adding more than one person to a task, as the default in scheduling tools is that each person adds an equal amount of effort. That is, a two-day task for one person would be automatically scheduled for one day with two people. You'll have to adjust the person calendar option in the software.

Brooks's Mythical Man-Month

In his famous book, The Mythical Man-Month , Fred Brooks (1975) showed that the process of adding new people to a task actually leads to expansion of elapsed time and effort rather than shortening the elapsed time. This is often known as Brooks's Law, which states "Adding manpower to a late software project makes it later" (p. 25). In effect, adding people leads to lost effort through training, communication, administration, and other overhead. A rough rule is that for every person you add to a project subtract 10% accumulative from that person's effort. Adding a new person thus results in 90% additional effort and adding a second person results in that person adding only 80% effort, and so on.

Step 4: Schedule Actual Resources

This step involves the allocation of the actual people to the tasks identified in the schedule (see Figure 15.5). This step can be quite complex, as factors such as skill levels, costs, time lost through communication, and the specific nonproject activities of each person (as distinct from the organization norm) need to be calculated and reviewed. For example, Bill is a key analyst in the project but he is working on production support activities as well as supervising some new programmers. As a result, Bill may have only two hours per day to spend on the project, rather than the five hours assumed. The sidebar provides you with the typical guideline that we recommend when adding more than one person to a task.

Figure 15.5. Scheduling actual resources

graphics/15fig05.gif

In addition, there are many tasks (e.g., conducting interviews) that make adding people to the task increase the total effort (and cost) rather than shortening the duration.

These final two steps need input from the actual people, as the calculations and various combinations can be quite complex.

Step 5: Adjust the Schedule as Required

The final step involves optimizing the schedule to use the project people most efficiently and minimize the development duration.

The use of alternative dependencies (start-to-start, finish-to-finish , and start-to-finish ) and the more effective allocation of people to the same task are the type of activities that will be required (see Figure 15.6). Most scheduling tools will provide reports on overallocation of resources, resource conflicts, and similar information that can assist with this step.

Figure 15.6. Adjusting the schedule

graphics/15fig06.jpg

It should be noted that PC-based scheduling tools are becoming more feature-laden and that the learning curve can be quite considerable. Most Windows-based tools are more than capable of handling business and IT projects and the use of the real-time planning approach means that the complexity of tasks is limited. However, formal training courses are available for most tools and a professional project manager should complete these courses to ensure competency with some of the advanced features of the tools.

A Really Clever Tool

If we had any influence over Microsoft and the other companies that develop project scheduling tools, we would ask them to build an intelligent software agent into their tools. You see, many of these tools allow you to schedule your project into the Year 2020 and beyond and to manage thousands of tasks. Clearly, the developers of these tools live in another world than that of our projects and our clients . A really clever scheduling tool would check to see if you are developing detailed plans beyond three months into the future and a little dialog box (or talking Java Applet) would pop up and say "You must be joking! Do you think this is going to happen? Have you seen the latest organization restructure? Do a reality check, dude!"



Radical Project Management
Radical Project Management
ISBN: 0130094862
EAN: 2147483647
Year: 2002
Pages: 136
Authors: Rob Thomsett

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net