CIS 251 - System Development Methods

Chapter 3: Managing Systems Projects

Objectives:

This lesson discusses material from chapter 3. Objectives important to this lesson:

  1. Project management
  2. Gantt and PERT charts
  3. Work breakdowns
  4. Task patterns
  5. Critical path
  6. Monitoring and control
  7. Reporting
  8. Risk management
  9. Assignments for the week
Concepts:

The chapter begins with a statement that IT projects are similar to projects in other industries, and that they can be managed with similar tools. We are advised that we have to balance the elements of a project, notably the budget, the time it takes, the scope of the project, and the quality of the work, in order to have a successful project. Many truisms tell the story that we can't have everything.

  • Cheops' Law: nothing ever gets done on time or under budget.
  • You can have it fast, cheap, or good: pick two.
    Notice that there is no point in the figure on the right where all three colors overlap.
    (See the testimony of Lucas Martell. Yes, an animation project is an IT project.)

 

So, in the face of all this despair, what does a project manager do? The text lists four major functions:

  • planning - identify project tasks, estimate total cost, estimate time to completion
  • scheduling - set a timetable for all tasks that displays dependencies and critical tasks, schedule staff, prepare project charts
  • monitoring - managing staff and work, checking progress, changing priorities and assignments
  • reporting - regular status reports to stakeholders, to enable informed decisions about the project

In figure 3-5, the text displays these four functions as elements that may occur during any of four project development steps:

  • Creating a work breakdown structure
  • Identifying task patterns
  • Calculating critical paths
  • Managing the project

The text continues, discussing two chart types that can be useful in creating a work breakdown. It begins with a Gantt chart, which is described as a horizontal bar chart in which the bars represent tasks to be done in specific time spans.

The image on the right is from a lesson from Microsoft that shows how to make Gantt chart in Excel 2002. This link leads to a lesson on YouTube by Dr. Eugene O'Loughlin. It shows how to make a Gantt chart in Excel 2010, which may be more useful to you. Follow the link and watch his short lesson.

In a Gantt chart, time is shown on the horizontal axis. Often, actual start and end dates are given for each task. As the text explains, however, time can be shown as a number of days (weeks, months, etc.) from an arbitrary start date that has yet to be defined. This is a common usage when start dates have not been determined, such as when projects are still in the proposal stage. Once a project begins, a Gantt chart becomes more useful when two colors are used, as in the example, to show percentage of completion of a task. Note that the display of completion is independent of the display of time: tasks may be finished ahead of schedule or may run past the allotted time.

The text moves on to discuss Program Evaluation Review Technique (PERT) charts, also called Critical Path Method (CPM) charts and PERT/CPM charts. The text chooses to use the most familiar term, PERT chart, in its discussion. The text tells us that PERT charts are made with a bottom up technique: first you must list all the tasks to be done in a project, then you allocate timelines to them, and order them in the chart. This is seemingly the reverse of the method you would use to construct a Gantt chart, but as a practical matter either can be made this way.

The example of a PERT chart in the text resembles the corresponding Gantt chart shown above it, but there are some differences. In the PERT chart, the first three tasks are shown on the same horizontal line because they follow each other on the timeline. In the Gantt chart, those three tasks are shown on separate lines because that is the convention in Gantt charts, even if the tasks follow each other in time. This makes the Gantt chart resemble a waterfall chart. The use of color in the PERT example demonstrates a useful feature, the display of a critical path. This phrase can have two diffferent but related meanings.It can mean the chain of tasks necessary to complete the project, or it can mean the tasks whose delay will change the completion date of the project. More on this in a moment.

In the example chart, color does not mean completion. Color may mean this is a task that must be accomplished in order to complete the project. Note the four tasks shown in vertical column in the PERT chart. Only one is shaded pink, marking it as one of the critical path tasks. This may tell us that as long as this task is completed, the project may continue, regardless of the status of the other three tasks shown as concurrent. (Depending on the definition of critical path.) Likewise, this implies that the other three concurrent tasks need not be completed in order for the project to be completed. Think of the chart as a project for a new game or a new operating system version: there are four features we would like to have ready by the date we must take the game to market, but we will still go to market if only the most important one is ready. In the PERT chart, date information, if shown, is shown as text in the boxes for each event, instead of as positional information on the timeline of a Gantt chart.

The text adds more vocabulary that might be defined differently by other texts and by other workplaces. We can accept that task and activity are the same things, words for a definable part of the project that has a start and an end, and that requires some assets or resources to accomplish. Typically it produces some kind of change or output.

When planning a project you will have to identify and schedule tasks. Figures 3-9 and 3-10 show three versions of the same statement of tasks. All three specify an order and what is to be done. Only the third version, a numbered list, makes it clear that there are seven tasks and that they are to be done in that particular order, as opposed to some being done simultaneously.

The text continues to discuss duration of tasks. If you are going to assign tasks to people, even if you do not use the charts that are recommended, you must have a plan for a timeframe for each task. The text presents the concept of a person-day, which may present you with options. If one person can do a task in two days, can two people do the same task in one day? This is sometimes true, sometimes not. The text points out that more people may install a given number of computers more quickly (assuming similar skill) but assigning more people to interview a single stakeholder will be unlikely to speed up the process.

The text presents a formula for calculating duration of a task. It has a potential for being wrong because it relies on someone to make accurate estimates of three durations:

  • best-case estimate (B) - if everything goes perfectly, how long the task should take
  • probable-case estimate (P) - based on your experience, how long you think the task will take
  • worst-case estimate (W) - if everything goes wrong, how long the task may take (you are not allowed to say "forever")

The formula is to add the best-case duration, the worst-case duration, four times the probable-case duration, and divide your sum by six.

(B+4P+W) / 6

This gives your value for P more weight than the other two estimates. If your estimates are only guesses, this formula may give a number that is inaccurate.

Now that the text has warned you about the importance of duration estimates, it discusses four factors that should be considered in making them.

  • project size - If you fail to identify all of the tasks needed at the outset of the project, you will be forced to add tasks to the plan (project creep), rethink your dependencies, and formulate new durations estimates.

  • human resources - The text hints at, but does not state, some useful observations. First, no two staff members will perform identically. Second, if you add new staff later in the project, they will take time to learn about the project itself, and will not be immediately productive. Adding staff, adding specially skilled staff, and losing staff will affect the project. Since giving a principle a name makes it more memorable, refer to Brooks' Law on page 124, which says that adding staff to a project that is late will make it later. Maybe so, but it may also make possible to finish it, if the project simply had insufficient staff.

  • relevant experience - People who have experience in the kind of project you are doing, the kind of system you are creating/updating, and the environment in which the system will exist are quite valuable. They are less valuable and productive according to their lack of each of these three qualities.

    The text does not mention what it probably considers standard qualities of a good employee, but they are also important. Ability to think, to communicate, to show up to work, to actually produce output. People who can't do those things won't advance your project.

  • constraints - These are the characteristics of the project that you cannot change. They may include limits on staff, a specific budget, a specific due date, or new requirements that a planner cannot anticipate before the project begins.

On page 110, the text continues with a discussion of task boxes, which are templates for the information you should state about each task.

  • Tasks should be given names and ID numbers. Numbers are needed because some names may be repeated.
  • Tasks must be given start dates, end dates, and durations. The text warns you to be careful calculating durations. If a task begins and ends on the same date, that is still a duration of one day. The day on which a task ends is the last date to count in its duration.
  • In the system used in the text, tasks are assumed to begin at the start of a day and end at the end of a day.
  • If task 2 cannot start until task 1 is completed, task 2 is dependent on task 1. The text's system shows task 1 ending on day x, and task 2 beginning on day x+1. In this case, task 1 is a predecessor to task 2, and task 2 is a successor to task 1.
  • Tasks may have multiple predecessors on which they are dependent. Likewise, they may have multiple successors that are dependent on them.

The text confuses the reader by talking about task patterns. This phrase only means the sequence that the project tasks must follow. Read the descriptions given on page 112 of several task sequences. Note the language used to describe a task having multiple successors or multiple predecessors.

On page 113, the text begins a discussion about critical paths. A little late. We have encountered this concept already. The diagram on page 114 uses red arrows to indicate what the author believes to be the critical path for this project. This illustration is incorrect because all tasks in this project are critical, since the last task cannot begin until all previous tasks have completed. The illustration on page 114 is only a critical path if we believe that such a path dictates the duration of the project. To calculate this duration we add the durations of tasks 1 and 2, because they are sequential, add the duration of task 4, because tasks 3 and 4 run concurrently and task 4 has the longer duration, then add the duration of task 5, which cannot start until tasks 3 and 4 are both completed.

The text elaborates that it calls tasks 1, 2, 4, and 5 the critical path because any delays in them would delay the project as a whole. This is true, but it is also true of task 3. Should it be delayed longer than the actual duration of task 4, the project would be delayed as a result. So which tasks are actually part of the critical path depends on what your development team believes is the meaning of that phrase.

The text moves on to discuss monitoring and control on page 114. By monitoring, the text is referring to a continuing series of checks to see if the project is keeping up with the plan. Control is not defined well. What the text means is taking corrective action when the various checks (reviews and walkthroughs) show that changes need to be made to get back on track.

Reporting is mentioned on page 115. Two versions of reporting are mentioned, status meetings and status reports. A meeting may not seem like a report at first, but the intent of such a meeting is to present stakeholders with updates on the project, as you would do in a status report.

The text presents some procedural examples on the following pages, showing steps to use in constructing PERT charts, Gantt charts, and a network diagram. Go over this material, and use it as a guide when making such charts for your assignments.

The text discusses risk management on page 121. It is rather brief. This discussion of risk is different from what you may have seen in other classes, as it only addresses risks involved in the project at hand. As such, it seems quite trivial compared to the risks involved in protecting an information system. Remember that risks should be identified and managed. Management usually means making a mitigation plan.

Part B of the Toolkit starts on page 648. It discusses some CASE environments and tools that can be used to build systems. Review the summary on page 664 to become familiar with some of the vocabulary about this concept. It is beyond the scope of this course to teach you the use of any particular CASE tool, but you should be aware of some of the ones presented in this chapter.