Concepts:
In this edition of the text, the author shows us a pie chart on page 90, cut into three pieces that represent cost, scope, and time. It does not make the same point as the modified Venn diagram above. It means to tell us that a manager must monitor and manage these three elements of all projects. Cost and time are easy to understand. Scope may need some explanation. The scope of a project is measured by everything that it includes. If a project gets bigger as time goes by, that is called scope creep. It can kill a project by never letting you get to the end of it. So, in the face of all this despair, what does a project manager do? The text lists four major functions:
The text continues on the next several pages, discussing these four functions as elements that may occur during any of four project development steps:
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 authors choose to use the most familiar term, PERT chart, in their 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 different 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: 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. The text adds more vocabulary that might be defined differently by other texts and by any workplace. 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 can install the same 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:
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.
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.
On page 98, the text continues with a discussion of task boxes, which are templates for the information you should state about each task.
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 pages 99 and 100 of several task sequences. Note the language used to describe a task having multiple successors or multiple predecessors. On page 102, the text begins a discussion about critical paths. A little late. We have encountered this concept already. The diagram on page 103 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 103 is only a critical path if we believe that such a critical path defines 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. This is what might be called the duration path of the project. If your employer calls it a critical path, you need to know that. 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 103. 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 104. 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 111. 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 582. It discusses some CASE environments and tools that can be used to build systems. Review the summary on pages 595 and 596 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.
|
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.
The text also discusses two chart
types that can be useful in creating a work breakdown. It begins with a