Docstoc

SM 2.02.31 Handouts POM

Document Sample
SM 2.02.31 Handouts POM Powered By Docstoc
					    Part 2: INTRODUCTION TO MICROSOFT PROJECT

1. WHY SHOULD WE USE MS PROJECT?

MS Project is scheduling and planning tool for project managers, providing easy-to-use
for putting together a project plan and assigning responsibilities but it also gives you
powerful tools to carry you through to the end of the project.

Once you have defined the goals for your project, you can start putting MS Project to
use. Project is an invaluable planning tool for:

                 Organizing the plan and thinking through the details of what must be done
                 Scheduling deadlines that must be met
                 Scheduling the tasks in the appropriate sequence
                 Assigning resources and costs to tasks and scheduling tasks around
                  resource availability
                 Fine-tuning the plan to satisfy time and budget constraints or to
                  accommodate changes
                 Preparing professional-looking reports to explain the project to owner, top
                  management, supervisors, workers, subcontractor, and the public.


B. STARTING MICROSOFT PROJECT FOR WINDOWS
        Double-click the Microsoft Project icon
C. INPUT DATA

 Step      Data                                        Guideline
   1       + Start Date                                File - Project Info
           + Current Date                              Or File - New
   2       + Working Day                               Tools - Change working time
           + Non-Working Day
           + Working Time From...to ...
   3       + Hours Per Day                             Tools - Change working time –Options -
                                                       Calendar
           + Hours Per Week
                                                       Or Tools - Options - Calendar
   4       + Date Format                               Tools - Change working time -Options -
                                                       View
                                                       Or Tools - Options - View
   5       + Task Names                                View - Gantt Chart
           + Durations
           + Predecessors
           + Resource Names
   6.      + Salary                                    View - Resource Sheet
   7       + Critical Path                             Format - GanttChartWizard - Critical Path

Note: Before finding solution, check the requirements of a problem again




                                                                                                   1
D. OUTPUT

                       Requirement                                           Guideline
1   + How many total hours are worked on the entire      File - Project Info - Statistics
    project?
    + How much does the whole project cost?
    + When does the project start or finish?
2   + What is critical path? What are non-critical       View - Gantt Chart
    activities?
    + When does an activity A start or finish?
    + Which activities are being worked on particular
    date/ month/ year?
3   + How much total slack is on an activity A?          View - Gantt Chart- Table - Schedule
4   + Who is working on particular date/ month/ year?    View - Resource Usage - See Calendar
                                                         Or View - Report - Custom - Who Does What
                                                         When
5   + Who is paid the least or the largest salary?       View - Resource Usage - Table - Summary
    + How much is employee X paid overall?
    + How many hours does employee X work in the
    whole project?
6   + How much does an activity A cost?                  View - Gantt Chart - Table - Summary / Work
    + How many total hours are there on an activity A?
7   + Which resource is over-allocated?                  View - Resource Usage - See Red Color
8   + How many working hours are in the week             View - Report - Custom - Task Usage
    beginning the particular date/ month/ year?
9   + How much are spent in the week beginning the       View - Report - Custom - Weekly Cash Flow
    particular date/ month/ year?




                                                                                                       2
E. EXAMPLES

Example 1:

Step 1: Set the calendar so that the project operates 7 days a week form 8am to 4pm with no breaks and
no holidays.
                                                           th
Step 2: Set the project starting date 30/3/1996 (that is 30 March 1996)
Step 3: Set options so that the working week is 56 hours, the working day is 8 hours.
Step 4: Input the details belows:

ID    Task Name                                    Duration         Predecessors        Resource Names
 1    Design module1                                  7d                                  DP manager
 2    Allocate programmers                           14d                   1              DP assistant
 3    Deliver written specs                           6d                   1              DP assistant
 4    First staff meeting                             1d                  2;3
 5    Order and Testing                              15d
 6        Order computers                             3d                   4              Purchasing
 7        Order printers                              3d                   4              Purchasing
 8        Order modems                                3d                   4              DP manager
 9        Test hardware                               8d                 6;7;8            DP assistant
10        Test software                               4d                   9                Alison

Step 5: The employees‟ wages are: + DP manager: $50/hr              +Purchasing: 20/hr
                                             + DP assistant: $32/hr        + Alison: $35/hr
Step 6: As a checkpoint, see that the first staff meeting is on Saturday 20/4/1996

                                      Question                                                Answer
1. How many hours are worked on the whole project?
2. On what date does the project finish?
3. What is the total project cost?
4. How many hours are worked in the week beginning 14/4/1996?
                          nd         th
5. Who is working on 22 and 29 April 1996?
6. Which resources are over-allocated?
7. Which activity is not on the critical path?
8. How much total slack is on the task “Deliver written specs”?
9. How much is the DP assistant paid overall?




                                                                                                         3
Solution of Example 1:

Question                                                                                                Answer
1. How many hours are worked on the whole project?                                                      384 hours
                                                                     File - Project Info - Statistics
2. On what date does the project finish?                                                                5/5/96
                                                                     File - Project Info - Statistics
3. What is the total project cost?                                                                      $ 13,248
                                                                     File - Project Info - Statistics
4. How many hours are worked in the week beginning 14/4/1996?                                           48 hours
                                                          View - Report - Custom - Task Usage
                                                     th
5. Who is working on Monday 22/4/1996 and 29 April?                                                     - DP manager,
                                                 View - Resource Usage – See Calendar; Or               Purchasing;
                                         View - Report - Custom - Who Does What When                    - DP assistant
6. Which resources are over-allocated?                                                                  DP assistant     –
                                                                                                        Purchasing
                                                   View - Resource Usage – See Red Color
7. Which activity is not on the critical path?                                                          Task 3
                                                                               View - Gantt Chart
8. How much total slack is on the task “Deliver written specs”?                                         8 days
                                                      View - Gantt Chart - Table – Schedule
9. How much is the DP assistant paid overall?                                                           $ 7,168
                                                 View - Resource Usage - Table – Summary


Example 2:

1.   Set a project start date on 5/2/96. Set the current date on 5/2/96.
2.   Choose TOOLS_OPTION_CALENDAR so that hours per day are 11 and hours per week are 55.
3.   Change working times such that the working week is 8am to 7pm Monday to Friday, with no breaks.
4.   Lan is paid $20 per hour; Minh: $30/hr; Phan: $40/hr
5.   Enter the following details of tasks:

ID                    Task Name                           Duration        Predecessors              Resource Names
 1     Stage 1                                              52d
 2     Evaluate tenders                                     3w                   -                         Lan
 3     Contact winning bid                                   2d                  2                        Minh
 4     Purchase materials                                   2w                   2                        Phan
 5     Train user                                           4w                  3;4                     Lan, Minh
 6     Receive final job                                     3d                  5                        Phan
 7     Testing                                               4d                  6                        Phan




                                                                                                                         4
6. As a check, see that “Contract winning bid” starts on 26/2/96 at 8 am and finishes on 27/2/96 at 7pm.

Question                                                           Your Answer              Solution
2. When does the whole project finish?                                                       16/4/96
3. What is the project‟s total cost?                                                        $22,440
4. What day of the week does “Testing” begin on?                                        Thursday 11/4/96
                                 th
5. Who is working on March 13 , 1996?                                                      Lan, Minh
6. How much does Phan get paid over the whole project?                                       $7,480
7. What is the critical path?                                                              2-4-5-6-7
8. Who is over-allocated?                                                                   Nobody
9. What are the total work hours on the project?                                           814 hours
                                       th
10. In the week beginning Monday 18 March, how many                                        110 hours
    hours are worked?
                                       th
11. In the week beginning Monday 18 March, how many                                           $2,750
    dollars are spent?




                                                                                                           5
   CHAPTER 10:


   Monitoring and
   Information Systems
       In this chapter, perhaps more than in any other, it would be helpful if we could consider everything at
   once. How is it possible to discuss monitoring without specifying what is to be controlled? On the other
   hand, how is it possible to specify a control system without understanding what aspects of a project are
   subject to measurement and how the measurement is to be accomplished? As a matter of fact, one could
   just as easily argue that evaluation, the primary subject of Chapter 12, should precede both monitoring
   and control. The placement of these chapters is arbitrary, and readers may feel free to read them in any
   order they wish. Irrespective of the order in which one considers these subjects, however, their
   interdependence is clear.
       Our fundamental approach to evaluation and control of projects is that these activities are, at base, the
   opposite sides of project selection and planning. The logic of selection dictates the components to be
   evaluated, and the details of planning expose the elements to be controlled. The ability to measure is
   prerequisite to either.
       Monitoring is collecting, recording, and reporting information concerning any and all aspects of project
   performance that the project manager or others in the organization wish to know. In our discussion it is
   important to remember that monitoring, as an activity, should be kept distinct from controlling (which uses
   the data supplied by monitoring to bring actual performance into approximate congruence with planned
   performance), as well as from evaluation (through which judgments are made about the quality and
   effectiveness of project performance).
       First we expand on the nature of this link between planning and control, including a brief discussion of
   the various aspects of project performance that need to be monitored. We also examine some of the
   problems associated with monitoring a project. Finally, we report on several computer software packages
   that can greatly increase the speed and effectiveness of project monitoring.
       This book is addressed to practicing PMs as well as students of project management. Students resist
   the idea that PMs do not have immediate access to accurate information on every aspect of the project.
   But PMs know it is not always easy to find out what's going on when working on a project. Records are
   frequently out of date, incomplete, in error, or "somewhere else" when needed. A hospital executive of our
   acquaintance carried out a project that was designed to generate a major improvement in profitability by
   altering the patient mix. The hospital's accounting system could not report on the results of the project
   until six months later.
       Throughout the chapter, our primary concern is to ensure that all parties interested in the project have
   available, on a timely basis, the information needed to exercise effective control over the project. The
   other uses for monitoring (e.g., auditing, learning from past mistakes, or keeping senior management
   informed), important as they are, must be considered secondary to the control function when constructing
   the monitoring system. The key issue, then, is to create an information system that gives project
   managers the information they need to make informed, timely decisions that will keep project performance
   as close as possible to the project plan.
       One final note. In this chapter we frequently refer to a "project monitor," a "project controller," or even
   to the "group" responsible for monitoring. These individuals and groups do in fact exist on most large
   projects. On a small project, it is likely that the person in charge of monitoring is the same person as the
   project controller-and the same person as the PM. That is, when we refer to the project monitor and
   controller, we are referring to roles needed in project management, not necessarily to different individuals.


   Project Management in Practice:

   Using Project Management Software
   to Schedule the 1988 Olympic Winter Games in Calgary
    The XV Olympiad in Calgary involved nearly 2000 athletes from 57 countries in 129 competitive events,
attracted over 1,500,000 spectators, was covered by over 5000 journalists, and was run by a staff of 600
professionals complemented by 10,000 volunteers. For those 600 responsible for organizing, planning,
scheduling, coordinating, and handling the information requirements for the 16-day extravaganza, the task
was overwhelming. The top managers of the organizing committee thus turned to a Computer Based Project
Planning and Scheduling (CBPPS) system for scheduling and managing the 30,000 tasks organized into 50

                                                                                                                6
   projects, the first time this had ever been done. (Although tried in the 1984 Los Angeles Games, the attempt
   was dropped when the scheduled completion was found to be late 1986.)
       The goal for the Calgary Games was to provide the best games ever, but within the budget. The
   philosophy employed was to let each project manager plan his/her own project but meet firm completion
   dates and budget limits. This made a lot of additional work for the upper managers since each project's
   reports and needs were different from every other project's. However, two major features of the project
   helped make this a success: (1) Knowing that the Games would happen on the scheduled date regardless of
   whether they were ready or not, and (2) Being such a high-visibility, challenging project that demands
   exceptional focus on the task.
       To schedule the entire Winter Games, the 129-event, 16-day Olympics was broken down into 15-minute
   periods, except for short-track speed skating which was segmented into 1-minute intervals. There was a
   printout for every day by venue, minute by minute, and a complete set of drawings of every site, building, and
   room. Meticulous scheduling was necessary to ensure that the 2500 or so competitors, members of royalty,
   and government officials were at the right place at the right time. Support staff, including medical and security
   personnel, were also carefully scheduled for each event as crowds shifted from competition to competition.
   Transportation600 buses-also had to be scheduled, oftentimes on short notice. The biggest concern was the
   weather, and sure enough, the Chinook winds forced the rescheduling of over 20 events, some of them twice!
       Yet, the 1988 Calgary Games were the best yet, and organized better than ever before. Moreover, as
   compared to the budget overruns of many other cities, this Olympiad was completed under budget!

   Source:    R. G. Holland, "The XV Olympic Winter Games: A Case Study in Project Management," PM Network, November 1989.




10.1   THE PLANNING-MONITORING-CONTROLLING CYCLE
           Throughout this book we have stressed the need to plan, check on progress, compare progress to the
       plan, and take corrective action if progress does not match the plan. The key things to be planned,
       monitored, and controlled are time (schedule), cost (budget), and performance (specifications). These,
       after all, encompass the fundamental objectives of the project.
           There is no doubt that some organizations do not spend sufficient time and effort on planning and
       controlling projects. It is far easier to focus on doing, especially because it appears to be more effective to
       "stop all the talk and get on with the work." We could cite firm after firm that incurred great expense (and
       major losses) because the planning process was inadequate for the tasks undertaken.

              A major construction project ran over budget by 63 percent and over schedule by 48 percent
               because the PM decided that, since "he had managed similar projects several times before, he
               knew what to do without going into all that detail that no one looks at anyway."
              A large industrial equipment supplier "took a bath" on a project designed to develop a new area of
               business because they applied the same planning and control procedures to the new area that they
               had used (successfully) on previous, smaller, less complex jobs.
              A computer store won a competitive bid to supply a computer, five terminals, and associated
               software to the Kansas City office of a national firm. Admittedly insufficient planning made the
               installation significantly late. Performance of the software was not close to specified levels. This
               botched job prevented the firm from being invited to bid on more than 20 similar installations
               planned by the client.

           The planning (budgeting and scheduling) methods we propose "put the hassles up front." They require
       a significantly greater investment of time and energy early in the life of the project, but they significantly
       reduce the extent and cost of poor performance and time/cost overruns. Note that this is no guarantee of
       a trouble-free project, merely an improvement in the risk of failure.
           It is useful to perceive the control process as a closed loop system, with revised plans and schedules
       (if warranted) following corrective actions. We delay a detailed discussion on control until the next
       chapter, but the planning-monitoring-controlling cycle is continuously in process until the project is
       completed. The information flows for such a cycle are illustrated in Figure 10-1. Note the direction of the
       flows, information flowing from the bottom toward the top and authority flowing from the top down.
           It is also useful to construct this process as an internal part of the organizational structure of the
       project, not something external to and imposed on it or, worse, in conflict with it. Finally, experience tells
       us that it is also desirable, though not mandatory, that the planning-monitoring-controlling cycle be the
       normal way of life in the parent organization. What is good for the project is equally good for the parent
       firm. In any case, unless the PM has a smoothly operating monitoring/control system, it will be difficult to
       manage the project effectively.




                                                                                                                             7
Designing the Monitoring System
     The first step in setting up any monitoring system is to identify the key factors to be controlled. Clearly,
the PM wants to monitor performance, cost, and time but must define precisely which specific
characteristics of performance, cost, and time should be controlled and then establish exact boundaries
within which control should be maintained. There may also be other factors of importance worth noting, at
least at milestones or review points in the life of the project. For example, the number of labor hours used,
the number or extent of engineering changes, the level of customer satisfaction, and similar items may be
worthy of note on individual projects.
     But the best source of items to be monitored is the project action plan-actually, the set of action plans
that describe what is being done, when, and the planned level of resource usage for each task, work
package, and work unit in the project. The monitoring system is a direct connection between planning and
control. If it does not collect and report information on some significant element of the plan, control can be
faulty or missing. The action plan furnishes the key items that must be measured and reported to the
control system, but it is not sufficient. For example, the PM might want to know about changes in the
client's attitudes toward the project. Information on the morale of the project team might be useful in
preparing for organizational or personnel changes on the project. These two latter items may be quite
important, but are not reflected in the project's action plans.
     Unfortunately, it is common to focus monitoring activities on data that are easily gathered-rather than
important-or to concentrate on "objective" measures that are easily defended at the expense of softer,
more subjective data that may be more valuable for control. Above all, monitoring should concentrate
primarily on measuring various facets of output rather than intensity of activity. It is crucial to remember
that effective PMs are not primarily interested in how hard their project teams work. They are interested in
achieving results.
     The measurement of project performance usually poses the most difficult data gathering problem.
There is a strong tendency to let project inputs serve as surrogate measures for output. If we have spent
50 percent of the budget (or of the scheduled time), we assume we have also completed 50 percent of the
project or reached 50 percent of our performance goal. In general, this assumption is in error, Further,
one must be aware of the fact that it is common to specify performance to a level of precision that is both
unnecessary and unrealistic. For example, a communications software project specified that a telephone
"information" system had to locate a phone number and respond to the querier in 5 seconds or less. Is 5.1
seconds a failure? Does the specification mean 5 seconds or less every time, or merely that response
times should average 5 seconds or less? Is the specification satisfied if the response time is 5 seconds or
less 90 percent of the time?
     The monitoring systems we describe in this chapter, however, focus mainly on time and cost as
measures of performance, not specifications. While we are most certainly concerned with keeping the
project "on spec," and do consider some of the problems of monitoring output, the subject is not fully
developed here because the software designed to monitor projects is not constructed to deal with the
subject adequately. The matter will get more attention in Chapter 12 when auditing is discussed.
     Given all this, performance criteria, standards, and data collection procedures must be established for
each of the factors to be measured. The criteria and data collection procedures are usually set up for the
life of the project. The standards themselves, however, may not be constant over the project's life. They
may change as a result of altered capabilities within the parent organization or a technological
breakthrough made by the project team; but, perhaps more often than not, standards and criteria change
because of factors that are not under the control of the PM.
     For example, they may be changed by the client. One client who had ordered a special piece of audio
equipment altered performance specifications significantly when electronic parts became available that
could filter out random noises.
     Standards may also be changed by the community as a response to some shift in public policy-witness
the changes in the performance standards imposed on nuclear power installations or automotive exhaust
systems. Shifts in the prime rate of interest or in unemployment levels often alter the standards that the
PM must use for making project related decisions. The monitoring process is based on the criteria and
standards because they dictate, or at least constrain, the set of relevant measures.
     Next, the information to be collected must be identified. This may consist of accounting data, operating
data, engineering test data, customer reactions, specification changes, and the like. The fundamental
problem is to determine precisely which of all the available data should be collected. It is worth repeating
that the typical determinant for collecting data too often seems to be simply the ease with which they can
be gathered. of course the nature of the required data is dictated by the project plan, as well as by the
goals of the parent organization, the needs of the client, and by the fact that it is desirable to improve the
process of managing projects.
     Perhaps the most common error made when monitoring data is to gather information that is clearly
related to project performance but has little or no probability of changing significantly from one collection
period to the next. Prior to its breakup, the American Telephone and Telegraph Company used to collect
monthly statistics on a very large number of indicators of operating efficiency. The extent of the collection
was such that it filled a telephone-book-sized volume known as "Ma Bell's Green Book." For a great many

                                                                                                               8
of the indicators, the likelihood of a significant change from one month to the next was extremely small.
When asked about the matter, one official remarked that the mere collection of the data kept the operating
companies "on their toes." We feel that there are other, more positive and less expensive ways of
motivating project personnel. Certainly, "collect everything" is inappropriate as a monitoring policy.
    Therefore, the first task is to examine the project plans in order to extract performance, time, and cost
goals. These goals should relate in some fashion to each of the different levels of detail; that is, some
should relate to the project, some to its tasks, some to the work packages, and so on. Data must be
identified that measure achievement against these goals, and mechanisms designed that gather and store
such data.
    Similarly, the process of developing and managing projects should be considered and steps taken to
ensure that information relevant to the diagnosis and treatment of the project's organizational infirmities
and procedural problems are gathered and collected. A reading of the fascinating book The Soul of a New
Machine [24] reveals the crucial roles organizational factors, interpersonal relationships, and managerial
style play in determining project success.

How to Collect Data
Given that we know what type of data we want to collect, the next question is how to collect this
information. At this point in the construction of a monitoring system, it is necessary to define precisely
what pieces of information should be gathered and when. In most cases, the PM has options. Questions
arise. Should cost data be gathered before or after some specific event? Is it always mandatory to collect
time and cost information at exactly the same point in the process? What do we do if a specific item is
difficult to collect because the data source (human) fears reporting any information that might contribute to
a negative performance evaluation? What do we do about the fact that some use of time is reported as
"hours charged" to our project, and we are quite aware that our project has been charged for work done
on another project (but for the same customer) that is over budget? Are special forms needed for data
collection? Should we set up quality control procedures to ensure the integrity of data transference from
its source to the project information system? Such questions merely indicate the broad range of knotty
issues that must be handled.
    A large proportion of all data collected take one of the following forms, each of which is suitable for
some types of measures.

   1. Frequency counts           A simple tally of the occurrence of an event. This type of measure is
      often used for "complaints," "number of times a project report is late," "days without an accident,"
      "bugs in a computer program," and similar items. The data are usually easy to collect and are often
      reported as events per unit time or events as a percent of a standard number.
   2. Raw numbers Dates, dollars, hours, physical amounts of resources used, and specifications are
      usually reported in this way. These numbers are reported in a wide variety of ways, but often as
      direct comparisons with an expected or standard number. Also, "variances" are commonly reported
      either as the difference between actual and standard or as the ratio of actual to standard.
      Differences or ratios can also be plotted as a time series to show changes in system performance.
   3. Subjective numeric ratings These numbers are subjective estimates, usually of a quality, made by
      knowledgeable individuals or groups. They can be reported in most of the same ways that objective
      raw numbers are, but care should be taken to make sure that the numbers are not manipulated in
      ways only suitable for quantitative measures. (See Chapter 2 for comments on measurements.)
      ordinal rankings of performance are included in this category.
   4. Indicators When the PM cannot measure some aspect of system performance directly, it may be
      possible to find an indirect measure or indicator. The speed with which change orders are
      processed and changes are incorporated into the project is often a good measure of team
      efficiency. Response to change may also be an indicator of the quality of communications on the
      project team. When using indicators to measure performance, the PM must make sure that the link
      between the indicator and the desired performance measure is as direct as possible.
   5. Verbal measures Measures for such performance characteristics as "quality of team member
      cooperation," "morale of team members," or "quality of interaction with the client" frequently take the
      form of verbal characterizations. As long as the set of characterizations is limited and the meanings
      of the individual terms consistently understood by all, these data serve their purposes reasonably
      well.




                                                                                                           9
   Drug Counseling Program
    A social service agency applied for and received funding for a special project to counsel male drug addicts
between 18 and 24 years of age, and to secure full-time employment for each client (or part-time employment
for clients who were still in school). To qualify for the program, the addicts must have been arrested for a
crime, but not be classed as "repeat offenders." Further, the addict must be living with at least one member of
his family who is a parent or guardian. Among other conditions placed on the grant, the agency was asked to
develop a measure of effectiveness for the counseling program that was acceptable to the funding agency.
    The primary measure of effectiveness adopted by most drug programs was "rate of recidivism." A
recidivistic incident is defined as any rearrest for a drug-related crime, or any behavior that resulted in the
individual reentering the social service system after completing the program and being discharged.
    While a "rearrest" is most surely recidivistic, there were several cases in which former clients contacted
the agency and asked to be readmitted to the program. These voluntary readmissions resulted when a
former client either began to use drugs again or was fearful that he would begin again. It seemed to the
agency professionals that voluntary readmissions were successes, not failures.
    A new measure of effectiveness was developed to replace "rate of recidivism." It was composed of scores
on three different measures, combined with equal weighting.

   1. Number of successive weeks of "clean urines."
   2. Number of successive months of satisfactory employment (or schooling) experience.
   3. Number of successive months of satisfactory behavior at home.

   Scores on the second and third measures were based on interviews with employers, teachers, and
parent(s).


       After data collection has been completed, reports on project progress should be generated. These
   include project status reports, time/cost reports, and variance reports, among others. Causes and effects
   should be identified and trends noted. Plans, charts, and tables should be updated on a timely basis.
   Where known, "cornparables" should be reported, as should statistical distributions of previous data if
   available. Both help the PM (and others) to interpret the data being monitored, Figures 10-2 and 10-3
   illustrate the use of such data. Figure 10-2 shows the results of a count of "bugs" found during a series of
   tests run on a new piece of computer software. (Bugs found were fixed prior to subsequent tests.) Figure
   10-3 shows the percent of the time a computer program retrieved data within a specified time limit. Each
   point represents a series of trials.
       The PM can fit a statistical function to the data shown in Figure 10-2 and make a rough estimate of the
   number of tests that will have to be run to find some predetermined number of additional bugs in the
   program. By fitting a curve (formally or "by eyeball") to the data in Figure 10-3, the PM can estimate the
   cost and time (the number of additional trials and adjustments) required to get system performance up to
   the specified level.
       The nature of timeliness will be amplified below, but it is important that the PM make sure that the
   PERT/CPM and Gantt charts in the project war room (office) are frequently updated. Monitoring can serve
   to maintain high morale on the project team as well as to alert team members to problems that will have to
   be solved.
       The purpose of the monitoring system is to gather and report data. The purpose of the control system
   is to act on the data. To aid the project controller, it is helpful for the monitor to carry out some data
   analysis. Significant differences from plan should be highlighted or "flagged" so that they cannot be
   overlooked by the controller. The methods of statistical quality control are very useful for determining what
   size variances are "significant" and sometimes even help in determining the probable cause(s) of
   variances. Where causation is known, it should be noted. Where it is not known, an investigation may
   be in order. The decisions about when an investigation should be conducted, by whom, and by
   what methods are the prerogative of the project controller, although the actual investigation may
   be conducted by the group responsible for monitoring.
       The Emanon Aircraft Company example presented in Chapter 7 is a case in point. While the study
   team collected and analyzed a great deal of cost information during the process of finding the problem, the
   method used for the analysis was actually quite simple. The team compared forecast or estimated cost,
   F(t), with actual cost, A(t), for each batch of output from the manufacturing system. This analysis was
   done for each cost center. The ratio of actual cost to estimated cost was calculated and plotted as a time
   series, as in Figure 10-4. * Note that A(t)/F(t) < I when the cost forecast for a cost center is greater than
   actual. In this case, the cost involved was "material cost." Though careful statistical analysis was not
   necessary in this specific case, the application of standard quality control techniques has wide application
   to project management (see any book on statistical quality control, 11 31 for example). Time series
   analysis can often give the PM an early warning of problems.


                                                                                                             10
       At base, this provides a management by exception reporting system for the PM. But management by
    exception has its flaws as well as its strengths. It is essentially an "after-the-fact" approach to control.
    Variances occur, are investigated, and only then is action taken. The astute PM is far more interested in
    preventing problems than curing them. Therefore, the monitoring system should develop data streams
    that indicate variances yet to come. Obviously, such indicators are apt to be statistical in nature, hinting at
    the likelihood of a future problem rather than predicting it with certainty. An example would be a trend in
    the data showing a system heading out of control. Interested readers are referred to the "2-5-7 Rule" (see
    1361, quality chapters). The PM may waste time and effort trying to deal with trouble that will not actually
    occur. This may be frustrating, but the costs of dealing with some nonproblems is usually minor when
    compared to the costs of dealing with real problems too late.
     * Actual data were not used in constructing Figure 10-4, but the figure reflects the consultants' findings.

        In creating the monitoring system, some care should be devoted to the issues of honesty and bias.
    The former is dealt with by setting in place an internal audit. The audit serves the purpose of ensuring that
    the information gathered is honest. No audit, however, can prevent bias. All data are biased by those
    who report them, advertently or inadvertently. The controller must understand this fact of life. The first
    issue is to determine whether or not the possibility of bias in the data matters significantly. If not, nothing
    need be done. Bias finding and correcting activities are worthwhile only if data with less or no bias are
    required.
        The issue of creating an atmosphere that fosters honesty on a project is widely ignored, but it is of
    major importance. A set of instructions to the PM on how to do this is not beyond the scope of this book,
    but if such instructions exist, we do not know of them. We do, however, have some advice to offer. The
    PM can tolerate almost any kind of behavior except dishonesty. Projects are vulnerable to dishonesty, far
    More vulnerable than tne ongoing operations of the parent organization.            Standard operations are
    characterized by considerable knowledge about expected system performance. When the monitoring
    system reports information that deviates from expectations, it is visible, noteworthy, and tends to get
    attention. In the case of many projects, expectations are not so well known. Deviations are not
    recognized for what they are. The PM is often dependent on team members to call attention to problems.
    To get this cooperation, the PM must make sure that the bearer of bad news is not punished; nor is the
    admitter-to-error executed. On the other hand, the hider-of-mistakes may be shot with impunity-and then
    sent to Siberia.
        There is some tendency for project monitoring systems to include an analysis directed at the
    assignment of blame. This practice has doubtful value. While the managerial dictum "rewards and
    punishments should be closely associated with performance" has the ring of good common sense, it is
    actually not good advice. Instead of motivating people to better performance, the practice is more apt to
    result in lower expectations. If achievement of goals is directly measured and directly rewarded,
    tremendous pressure will be put on people to understate goals and to generate plans that can be met or
    exceeded with minimal risk and effort.

10.2 INFORMATION NEEDS AND THE REPORTING PROCESS
        Everyone concerned with the project should be appropriately tied into the project reporting system.
    The monitoring system ought to be constructed so that it addresses every level of management, but
    reports need not be of the same depth or at the same frequency for each level. Lower-level personnel
    have a need for detailed information about individual tasks and the factors affecting such tasks. Report
    frequency is usually high. For the senior management levels, overview reports describe progress in more
    aggregated terms with less individual task detail. Reports are issued less often. in both cases, the
    structure of the reports should reflect the WBS, with each managerial level receiving reports that allow the
    exercise of control at the relevant level. At times it may be necessary to move information between
    organizations, as illustrated in Figure 10-5, as well as between managerial levels.
        The relationship of project reports to the project action plan or WBS is the key to the determination of
    both report content and frequency. Reports must contain data relevant to the control of specific tasks that
    are being carried out according to a specific schedule. The frequency of reporting should be great enough
    to allow control to be exerted during or before the period in which the task is scheduled for completion.
    For example, efficacy tests of drugs do not produce rapid results in most cases. Thus, there is no reason
    for weekly (and perhaps not even monthly) reports on such tests. When test results begin to occur, more
    frequent reports and updates may be required.
        In addition to the criterion that reports should be available in time to be used for project control, the
    timing of reports should generally correspond to the timing of project milestones. This means that project
    reports may not be issued periodically-excepting progress reports for senior management. There seems
    to be no logical reason, except for tradition, to issue weekly, monthly, quarterly, etc., reports. Few projects
    require attention so neatly consistent with the calendar. This must not be taken as advice to issue reports
    "every once in a while." Reports should be scheduled in the project plan. They should be issued on time.
    The report schedule, however, need not call for periodic reports.

                                                                                                                   11
     Identification of project milestones depends on who is interested. For senior management, there may
be only a few milestones, even in large projects. For the PM there may be many critical points in the
project schedule at which major decisions must be made, large changes in the resource base must be
initiated, or key technical results achieved. The milestones relevant to lower levels relate to finer detail
and occur with higher frequency.
     The nature of the monitoring reports should be consistent with the logic of the planning, budgeting, and
scheduling systems. The primary purpose is, of course, to ensure achievement of the project plan through
control. There is little reason to burden operating members of the project team with extensive reports on
matters that are not subject to control-at least not by them. For example, overhead costs or the in-house
rental cost of the project war room are simply not appropriate considerations for a team member who is
supervising a research experiment in polymer chemistry or designing the advertising campaign for a new
brand of coffee. The scheduling and resource usage columns of the project action plan will serve as the
key to the design of project reports.
There are many benefits of detailed reports delivered to the proper people on a timely basis. Among them
are:

    Mutual understanding of the goals of the project
    Awareness of the progress of parallel activities and of the problems associated with coordination
     among activities
    More realistic planning for the needs of all groups and individuals working on the project
    Understanding the relationships of individual tasks to one another and to the overall project
    Early warning signals of potential problems and delays in the project
    Minimizing the confusion associated with change by reducing delays in communicating the change
    Faster management action in response to unacceptable or inappropriate work
    Higher visibility to top management, including attention directed to the im@ mediate needs of the
     project
    Keeping the client and other interested outside parties up to date on project status, particularly
     regarding project costs, milestones, and deliverables.

Report Types
    For the purposes of project management, we can consider three distinct types of reports: routine,
exception, and special analysis. The routine reports are those issued on a regular basis; but, as we noted
above, regular does not necessarily refer to the calendar. For senior management, the reports will usually
be periodic, but for the PM and lower-level project personnel, milestones may be used to trigger routine re-
ports. At times, it may be useful to issue routine reports on resource usage periodically, occasionally on a
weekly or even daily basis.
    Exception reports are useful in two cases. First, they are directly oriented to project management
decision making and should be distributed-to the team members who will have prime responsibility for
decisions or who have a clear "need to know." Second, they may be issued when a decision is made on
an exception basis and it is desirable to inform other managers as well as to document the decision - in
other words, as part of a sensible procedure for protecting oneself. (PMs should be aware that overuse of
exception reporting will be perceived by top management as sheeplike, overly cautious behavior.)
    Special analysis reports are used to disseminate the results of special studies conducted as part of the
project or as a response to special problems that arise during the project. Usually they cover matters that
may be of interest to other PMs, or make use of analytic methods that might be helpful on other projects.
Studies on the use of substitute materials, evaluation of alternative manufacturing processes, availability
of external consultants, capabilities of new software, and descriptions of new governmental regulations are
all typical of the kinds of subjects covered in special analysis reports. Distribution of these reports is
usually made to anyone who might be interested.

Meetings
    Thus far, we have implicitly assumed that "reports" were written and disseminated by hard-copy or E-
mail. More and more often, however, all three types of reports are delivered in face-to-face meetings, and
in telephone conference-calls. For a large majority of managers, meetings are as welcome as bad checks
or unmentionable diseases. The main complaints are that they are interminably long, come to no con-
clusions, and waste everyone's time.
    There is no doubt, though, that meetings of project teams are necessary and helpful. Indeed, there is
no particular reason why meetings should be run in such a way as to cause attendees to hate them with
such passion. A few simple rules can remove most of the onus associated with project meetings.

    Use meetings for making group decisions or getting input for important problems. Avoid "show-and-
     tell" meetings, sometimes called "status and review meetings." If the latter type of meeting has been

                                                                                                          12
       used to keep project team members informed about what others are doing on the project, insist that
       such information be communicated personally or electronically by the relevant individuals to the
       relevant individuals. Only when there is a clear need, such as informing senior management of the
       project's status, and it is difficult for team members to "get together" on their own, are status and re-
       view meetings appropriate.
      Have preset starting and stopping times as well as a written agenda. Stick with both, and above all,
       do not penalize those who show up on time by making them wait for those who are tardy.
      Make sure that you (and others) do their homework prior to the meeting. Be prepared!
      If you chair the meeting, take your own minutes. Reality (and the minutes become reality as soon
       as the meeting is over) is too important to be left to the most junior person present. Distribute the
       minutes as soon as possible after the meeting, not later than the next work day.
      Avoid attributing remarks or viewpoints to individuals in the minutes. Attribution makes people quite
       wary about what they say in meetings and damps creativity as well as controversy. Also, do not
       report votes on controversial matters. It is, for example, inappropriate to report in the minutes that
       the project team voted to send a "Get Well" card to the boss; 4 yea and 3 nay.
      Avoid overly formal rules of procedure. A project meeting is not a parliament and is not the place
       for Robert's Rules of Order, though courtesy is always in order.
      If a serious problem or crisis arises, call a meeting for the purpose of dealing with that issue only.
       The stopping time for such meetings may be "When the problem has been solved."

   Some types of meetings should never be held at all. A large, diversified manufacturing firm holds
monthly "status and review" meetings in each ot its divisions al which the managers of all projects report to
a Project Review Committee (PRC). The divisional PRCs are made up of senior managers. At least one,
and we are told more than one, of the PRCs apparently models its meetings on "Hell Week" at a nearby
university fraternity. Hazing and humiliating the project managers who must report to the committee is
standard practice. The results are to be expected. Projects are managed defensively. Creativity is
avoided. Project managers spend time printing and distributing reïsumeïs. The best PMs do not stay
long.

Common Reporting Problems
    There are three common difficulties in the design of project reports. First, there is usually too much
detail, both in the reports themselves and in the input being solicited from workers. Unnecessary detail
usually results in the reports not being read. Also, it prevents project team members from finding the
information they need. Furthermore, the demand for unnecessary, highly detailed input information often
results in careless preparation of the data, thereby casting doubt on the validity of reports based on such
data. Finally, the preparation and inclusion of unnecessary detail is costly, at the very least.
    A second major problem is the poor interface between the project information system and the parent
firm's information system. Data are rarely comparable, and interaction between the PM and the
organization's accountants is often strained. In our experience, the PM may try to force a connection. It
rarely works well. The parent organization's information system must serve as the definitional prototype
for the project's information system. In effect, this means that the parent's accounting, engineering,
marketing, finance, personnel, and production information systems should be used as the base on which
the project's information system is built. Obviously, different types of reports must be constructed for
managing the project, but they can be built by using standard data for the most part. The PM can feel free
to add new kinds of data to the information base but cannot insist that costs, resource usage, and the like
be reported in the project differently from how they are reported in the parent organization.
    The third problem concerns a poor correspondence between the planning and the monitoring systems.
If the monitoring system is not tracking information directly related to the project's plans, control is
meaningless. This often happens when the firm's existing information system is used for monitoring
without modifications specifically designed for project management. For example, an existing cost
tracking system oriented to shop operations would be inappropriate for a project with major activities in the
area of research and development. But as we noted just above, the option of running the project from a
different database is generally not viable. The PM's problem is to fit standard information into a reporting
and tracking system that is appropriate for the project.
    The real message carried by project reports is in the comparison of actual activity to plan and of actual
output to desired output. Variances are reported by the monitoring system, and responsibility for action
rests with the controller. Because the project plan is described in terms of performance, time, and cost,
variances are reported for those same variables. Project variance reports usually follow the same format
used by the accounting department, but at times they may be presented differently.

The Earned Value Chart


                                                                                                             13
    Thus far, our examples have covered monitoring for parts of projects. The monitoring of performance
for the entire project is also crucial because performance is the raison d’ãtre of the project. Individual task
performance must be monitored carefully because the timing and coordination between individual tasks is
important. But overall project performance is the crux of the matter and must not be overlooked. One way
of measuring overall performance is by using an aggregate performance measure called earned value. A
history of earned value from its origin in PERT/Cost to its culmination in C/SCSC (Cost/Schedule Control
System Criteria) together with its techniques, advantages, and disadvantages is reported in a series in
PMNetwork starting with 11 61.
    A serious difficulty with comparing actual expenditures against budgeted or baseline expenditures for
any given time period is that the comparison fails to take into account the amount of work accomplished
relative to the cost incurred. The earned value of work performed (value completed) for those tasks in
progress is found by multiplying the estimated percent completion for each task by the planned cost for
that task. The result is the amount that should have been spent on the task thus far. This can then be
compared with the actual amount spent.
    Estimating the "percent completion" of each task (or work package) is nontrivial. If the task is to write a
piece of software, percent completion can be estimated as the number of lines of code written divided by
the total number of lines to be written-given that the latter has been estimated. But what if the task is to
test the software? We have run a known number of tests, but how many remain to be run? There are
several conventions used to aid in estimating percent completion. The most popular seems to be the 50-
50 estimate. Fifty percent completion is assumed when the task is begun, and the remaining 50 percent
when the work is complete. Other conventions include the 0-100 percent rule which allows no credit for
work until the task is complete, or assignment of credit according to the amount of a critical input that has
been used.
    A graph such as that shown in Figure 10-6 can be constructed and provides a basis for evaluating cost
and performance to date. If the total value of the work accomplished is in balance with the planned
(baseline) cost (i.e., minimal scheduling variance), then top management has no particular need for a
detailed analysis of individual tasks. Thus the concept of earned value combines cost reporting and
aggregate performance reporting into one comprehensive chart.
    We can identify three variances on the earned value chart. The time variance is the difference in the
time scheduled for the work that has been performed (STWP) and the actual time used to perform it
(ATWP). The cost or spending variance is the difference between the amount of money we budgeted for
the work that has been performed (BCWP) to date and the actual cost of that work (ACWP). The
schedule variance is the difference between the budgeted cost of the work performed (BCWP) to date and
the cost of the work we scheduled to be performed to date (BCWS). * In compact form,

             STWP - ATWP = time variance (TV, delay is negative)
             BCWP - ACWP = cost variance (CV, overrun is negative)
             BCWP - BCWS = schedule variance (SV, behind is negative)

Typically, the variances are defined in such a way that they will be negative when the project is behind
schedule and/or over cost, though this practice is not universal either in the literature or in practice. The
variances are also often stated as ratios rather than differences so that the TV ratio = STWP/ATWP, the
CV ratio = BCWP/ACWP, and the SV ratio = BCWP/BCWS, malperformance being indicated by a ratio
less than one. Use of ratios is particularly helpful when an organization wishes to compare the
performance of several projects-or project managers. As we just noted, however, the accuracy and
usefulness of these performance measures are dependent on the degree to which estimates of percent
completion reflect reality.
      * A fourth variance can be found. It is the difference between the cost the project budget says should have been expended to
date (BCWS) and the actual cost incurred to date by the project (ACWP). BCWS - ACWP is what we call the resource flow variance.
(Note that the resource flow variance is not a "cash flow” variance)

    Cost and schedule variances are most commonly used. A short example illustrates this. Assume that
operations on a work package has been scheduled to cost $1500 to complete the package. It was
originally scheduled to have been finished today. As of now, however, we have actually expended $1350,
and we estimate that we have completed two-thirds of the work. What are the cost and schedule vari-
ances?
                                       cost variance = BCWP - ACWP
                                                      = $1500(2/3) - 1350
                                                      = - $350
                                schedule variance = BCWP - BCWS
                                                      = $1500(2/3) - 1500
                                                      = - $500

   In other words, we are spending at a higher level than our budget plan indicates, and given what we
have spent, we are not as far along as we should be (i.e., we have not completed as much work as we
should have).
                                                                                                                               14
       If the earned value chart shows a cost overrun or performance underrun, the PM must figure out what
   to do to get the system back on target. Options include such things as borrowing resources from activities
   performing better than expected, or holding a meeting of project team members to see if anyone can
   suggest solutions to the problems, or perhaps notifying the client that the project may be late or over
   budget.

   Cost/Schedule Control System Criteria (C/SCSC)
       C/SCSC was developed by the U.S. Department of Defense in the late 1960s and is generally required
   for defense projects. Fundamentally, it is an extension of earned value analysis. C/SCSC, as its name
   implies, spelled out a number of standards of organization, accounting, budgeting, etc., that firms must
   meet if they are to be considered acceptable for government contracts. For an excellent extended
   discussion of C/SCSC together with the process for accomplishing it, see 1261.
       As usual, if remedial action is contemplated, it is important to make the analysis at the lowest feasible
   level of the action plan or WBS. The need to keep project performance, cost, and schedule related when
   monitoring projects has been emphasized in this chapter. This emphasis will be reinforced in Chapter I 1.
   For purposes of control, it is just as important to emphasize the need to relate the realities of time, cost,
   and performance with the project's master plan. C/SCSC takes just such an approach, but there is a
   major caveat that must be heeded: The set of project action plans (the project master plan) must be kept
   up to date. These plans contain descriptions of each task together with estimates of the time and
   resources required by each. The plans are therefore the primary source of the STWPS, BCWSS, and
   BCWPs and the framework within which the ATWPs and ACWPs are collected.
       Differences between work scheduled and work planned can develop from several different causes; for
   example, official change orders in the work elements required to accomplish a task, informal alterations in
   the methods used to accomplish specific tasks, or official or unofficial changes in the tasks to be
   accomplished. Similarly, cost variances can result from any of the above as well as from changes in input
   factor prices, changes in the accounting methods used by the project, or changes in the mix of input
   factors needed to accomplish a given task. If the plan is not altered to reflect such changes, comparisons
   between plan and actual are not meaningful.
       Figure 10-7 shows a budget for the Career Day project described in Chapter 5, Section 5.3. This
   budget was generated as a standard report from Microsoft Project@. (A similar report is available through
   Time Line@, and most other PC project management packages.) Note that the project is reported on at
   the work package level. The first two tasks, Contact Organizations and Banquet and Refreshments have
   been completed, and the third task, Publicity and Promotion is currently underway. The first four work
   packages under Publicity and Promotion have been completed, but the fifth and seventh are only partially
   finished. The sixth has not been started, nor has the fourth task, Facilities, been started. A compressed
   Gantt chart is shown on the right side.
       The three columns of data on the right, BAC, FAC, and Variance, are "Budget at Completion,"
   "Forecast at Completion" and the Variance or difference between BAC and FAC. For all activities that
   have been completed, BAC = BCWP and FAC = ACWP. The work packages that have not been
   completed, however, tell a different story. Advertise in college paper is 50 percent complete, and
   Organize posters is 45 percent complete. (The percent complete data are from another report.) Class
   announcements has not yet been started. Note that for Advertise in the college paper, the BCWP is 50
   percent of the BCWS, which is to say that $82.50 is 50 percent of the BAC and FAC. Similarly for
   Organize posters, with $335.25 being 45 percent of BAC and FAC ($335.25/.45 = $745.00). When the two
   work packages are completed, however, and if there is still a cost variance, then BAC and FAC will no
   longer be equal. For a completed work package, the cost variance (BCWP - ACWP) = BAC – FAC


   Project Management in Practice:

   Applying the BCWP Concept
   at the U.S. Environmental Protection Agency
   Over a period of eight years, the R&D laboratory of the EPA developed, implemented, and revised a
project management system (PMS) that attempted to incorporate the budgeted cost of work performed
(BCWP) concept. In the mid-1970s, a project team was formed to help R&D manage a subcontracted set of
environmental control projects totaling $40-60 million. The technical staff of 45 engineers and scientists thus
had over a million dollars worth of projects to oversee, per person. The PMS project objectives were
identified as:

   -   To provide contractor progress reports to the laboratory director.
   -   To provide project officers information on cost and schedule to better manage their contracts.
   -   To relieve project officers of the burden of preparing monthly progress reports.
   -   To facilitate data input and updating of the integrated information system by standardizing reports and

                                                                                                             15
           formats.
       -   To collect pertinent data for identifying schedule slippages.

       The concept of the PMS was to have each contractor disaggregate project costs by the lowest level of
   detail in the work breakdown structure. Then, the schedule of tasks to be completed would give the budgeted
   cost of work scheduled (BCWS) and actual schedule and cost progress, shown as the BCWP and ACWP,
   respectively, which could be compared monthly against the BCWS to identify cost and schedule variances. A
   number of performance indexes, such as cost (BCWP/ACWP), schedule (BCWP/BCWS), percent spent, and
   percent complete, were to be calculated and reported monthly as well to give project managers and
   administrators a quick way to identify projects needing attention.
       In implementation, however, the project team found that the data collection forms were not being properly
   or uniformly filled out. Upon investigation, it was realized that the project officers considered PMS as a top
   management monitoring system rather than as a tool to help them better manage their projects. Thus, they
   did not even check the forms from the contractor, and the contractors, in turn, simply gave them to their ac-
   countants, who were not in touch with the progress of each project, to fill out. Three flaws in the system were
   then identified: (1) feedback from the supervisor of the R&D project officers was missing since the reports
   bypassed this level of management; (2) as noted above, the project officers considered this a system for top
   management; and (3) the project officers had no involvement in designing the system and thus no interest in
   using it, seeing it as a reporting system being forced upon them. Yet, the project officers believed that the
   basic concept in PMS was a good one and necessary for sound oversight of their projects.
       In the next phase, top management of the R&D laboratory changed and the system was discontinued for
   three years. After seven years since the original PMS project began, the system was reintroduced as a set of
   tools for project officers to use and adapt as they found useful. The evaluation of project officers was
   changed to a system whereby they would be evaluated by their supervisors based on results achieved
   instead of the use of project management tools. Training in the use of PMS was provided and the system is
   now receiving much wider acceptance.
       Source: C. B. Oldham, C. T. Ripberger, and J. E. Cook “Project Management in a Federal Research and Development Laboratory: An Application of
               the Elusive Budgeted Cost of Work Performed," Project Management Journal, Sept. 1986.




       Milestone Reporting
           We referred earlier to milestone reports. A typical example of such a report is shown in Figure 10-8a,
       b, and c. In this illustration, a sample network with milestones is shown, followed by a routine milestone
       report form. A model top management project status report is illustrated in the next chapter. When filled
       out, these reports show project status at a specific time. They serve to keep all parties up to date on what
       has been accomplished. If accomplishments are inadequate or late, these reports serve as starting points
       for remedial planning.
           Figures 10-8a and b show the network for a new product development project for a manufacturer. A
       steady flow of new products is an essential feature of this firm's business, and each new product is
       organized as a project as soon as its basic concept is approved by a project selection group. If we
       examine Figures 10-8a and b closely, we see that the sign-off control boxes at the top of the page
       correspond with sequences of events in the network. For example, look at the bottom line of the network
       in Figure 10-8a. The design of this product requires a sculpture that is formed on an armature. The
       armature must be constructed, and the sculpture of the product completed and signed off. Note that the
       sculpture is used as a form for making models that are, in turn, used to make the prototype product. The
       completion of the sculpture is signed off in the next-to-last box in the lower line of boxes at the top of the
       page.
           A careful examination of Figure 10-8b reveals that it is a continuation of the previous page. Figure 10-
       8a is primarily concerned with product design and Figure 10-8b with production. The expected times for
       various activities are noted on the network, along with the various operations that must be performed.
       Figure 10-8c is a summary milestone report that covers several concurrent projects-four, in the case of
       this page. Each project has a series of steps that must be completed. Each has an original schedule that
       may be amended for use as a current schedule. Steps are completed in actual times. This form helps
       program managers coordinate several projects by trying to schedule the various steps to minimize the
       degree to which the projects interfere with one another by being scheduled for the same facilities at the
       same time.
           The next section of this chapter, which discusses computerized project management information
       systems, contains several other examples of project reports.

10.3   COMPUTERIZED PMIS (PROJECT MANAGEMENT INFORMATION
       SYSTEMS)


                                                                                                                                                 16
    The project examples used in Chapters 8 and 9 were small, so that the concepts could be
demonstrated. But real projects are often extremely large, with many hundreds or thousands of tasks and
hundreds of thousands of work packages. Diagramming, scheduling, and tracking all these tasks is
clearly a job for the computer, and computerized PMISs were one of the earlier business applications for
computers (e.g., see [44]). Initially, the focus was on simple scheduling packages, but this quickly
extended to include costs, earned values, variances, management reports, and so on.
    The earlier packages were typically written in FORTRAN and ran on large, expensive mainframe
computers; thus, only the larger firms had access to them. Still, the use of these packages for managing
projects on a day-to-day basis was not particularly successful, except perhaps in construction and
contracting firms. This was because of the inability of project managers to update plans in real time,
mainframe computers typically being run in a batch rather than online mode. With the development and
proliferation of microcomputers, and the corresponding availability of a wide variety of project
management software, project managers are showing a renewed interest in PMIS.
    These new microcomputer-based PMIS are considerably more sophisticated than earlier systems and
use the microcomputer's graphics, color, and other features more extensively. The systems are available
for small, medium, and even large firms. They also offer much more support capability. The current trend
in PMIS is integration of software, including spreadsheets, databases, word processing, communications,
graphics, and other such capabilities. In this section, we briefly describe a few of the larger, more complex
software packages and then we proceed to a discussion of packages for small- and medium-sized
projects. Finally, we illustrate two of the more popular micropackages.
    This area is developing so rapidly that any information given must be considered dated by the time it
reaches print. The reader interested in current capabilities would be wise to refer to recent annual or
monthly software reviews, such as 127, 30, and 591, and those in PM Network (e.g., May and Aug.,
1994). Finally, it is worth noting that these systems can be misused or inappropriately applied-as can any
tools. The most common error of this type is managing the PMIS rather than the project itself. This and
other such errors are described by Thamhain [52] and listed below.

    Computer paralysis. Excessive computer involvement with computer activity replacing project
     management; loss of touch with the project and its realities.
    PMIS veriflication. PMIS reports may mask real project problems, be massaged to look good, or
     simply verify that real problems exist, yet are not acted upon.
    Information overload. Too many reports, too detailed, or the distribution of reports, charts, tables,
     data, and general information from the PMIS to too many people overwhelms managers and
     effectively hides problems.
    Proiect isolation. The PMIS reports replace useful and frequent communication between the
     project manager and top management, or even between the PM and the project team.
    Computer dependence. PM or top management wait for the computer reports/results to react to
     problems rather than being proactive and avoiding problems in the first place.
    PMIS misdirection. Due to the unequal coverage of the PMIS, certain project subareas are
     overmanaged and other areas receive inadequate attention; symptoms of problems are monitored
     and managed (budget overruns, schedule slippages), rather than the problems themselves.

Large PMIS Capabilities
    Current PMISs that run on mainframes and minis are intended for large, complex, engineering-based
projects such as major defense or aerospace contracts. In these situations, the firm is a prime contractor
or major subcontractor and is facing years of work involving thousands of tasks, perhaps millions of labor-
hours, and multiple interfaces with many subcontractors. The entire project must be well coordinated and
tightly controlled if performance requirements are to be achieved and schedules met.
    The first step in such projects is to scope out the work in a major work phase diagram. Such a chart is
illustrated in Figure 10-9. The scope document is usually a RFP (Request for Proposal) or the firm's
proposal in response to an RFP. From this, phase I of project definition is initiated. This includes
constructing a summary WBS for the project, laying out the major project milestones, and getting an
estimate of the general order of magnitude of the project in terms of total labor-hours required.
    The next phase (11) is the definition of the work package in more detail. This involves determining
exactly what must be done (the WBS), when, who will do it, and how much it will cost. Following this,
baseline input data requirements are specified in phase 111. This includes such items as estimates of
activity durations, budgets, labor requirements, constraints, and the other items listed in Figure 10-9.
    Phase IV is ongoing monitoring where input data on project status are collected through system
modules for schedules ' costs, cash flows, and so forth. The final phase (V) is the definition of output
management reports for the control function. This consists of defining the data analyses that must be
conducted and report formatting and generation. Example outputs would be exception, earned value, cost
status, schedule status, variance, and other such reports described earlier and in the following chapter.
    The chores that must be handled when managing a large project are not significantly different in
concept from those involved in small projects. The difference in size, however, increases the complexity
                                                                                                          17
of the job by orders of magnitude. PMISs for mainframe and minicomputers retail for somewhere between
$2000 and $500,000. Most run on IBM and DEC hardware and software, but sometimes on Hewlett
Packard, Data General, and others. Two of the most widely used are Artemis@ and Project/2@. There is
also TRAK@ which, in spite of its claim to be "a fully integrated on-line Project Management system," is
mainly an excellent. integrated, project database, data management, and reporting device.
    Rather than discussing the various things that these large systems can do, we simply advise the user
who needs a large system to investigate several of them carefully. When such investigations do take
place, they usually involve several individuals from the computer department. While we have no prejudice
against including software/hardware specialists in the search for a good product, it is even more important
to include people who have considerable experience in project management, and who understand what
the software can and will be asked to do.
    It is clear that large, defense-type, engineering projects require the use of a mainframe or minicomputer
to handle the mass of data. Also, customer requirements for complex reports are easily handled by these
packages. Note, however, that the lion's share of projects are not so large-even though they do require
the same rigorous and extensive planning, scheduling, costing, monitoring, and control capabilities.
PMISs for these projects can fit on a microcomputer.

Small PMIS Capabilities
    An explosive growth in PMISs has occurred in the area of small- to medium-sized PMISs intended for
microcomputers. There are now over 500 packages on the market and the number continues to grow.
These packages come in a wide variety of capabilities and prices. Several packages cost less than $50
and a few cost several thousand dollars, with one or two above $25,000. Our interest here is in
reasonably priced ($500-$2000 list-priced) software that is capable of applying reasonably sophisticated
project management techniques (e.g., resource leveling, C/SCSC-type budget reports, project tracking,
and updating) to projects of reasonable size ( >5000 activities per project) with multiproject capability, and
with a reasonable set of reporting options (such as Gantt and PERT/CPM charts, WBS or action plans,
resource reports, cost reports, etc.). We assume the ability to import and export data and reports to the
standard word processing and spreadsheet packages. We also assume reasonably good graphic
capabilities.
    Based on these criteria, and based on a number of software ratings made by magazines devoted to PC
users [15 among many others], software rating firms [37, for example], and individuals (consultants and
academics) writing for project management journals or books [for instance, 14, 21, 28, 30, and 42], we
have selected two packages to illustrate a few types of output that are typical of the genre: Microsoft
Project for Windows@ 3.0 and Time Line@ 5.0. Both list for just under $700, and both are widely available
at prices less than $450, sometimes considerably less. Both are widely used, probably being the two most
popular pieces of project management software. Both can be used on a LAN-as can most of the popular
project management software.
    Our approach here will be to describe PMIS's needs briefly and generically. We then illustrate some
typical outputs available with our chosen packages. It is worth noting that many of the articles rating
project management software are written by software authorities rather than project managers, and the
judgments expressed in such articles may not be particularly relevant for experienced PMs. Likewise,
Avots 121 maintains that package reviews and comparative evaluations in computer trade journals are not
a dependable basis for comparing PMISS. Our discussion of user needs is based largely on two surveys
[49, 58] conducted on PMs.

      Friendliness. For the novice user, this included clear and logical manuals, help screens, tutorials,
       a menu-driven structure, easy editing, and so on. For the advanced user, this meant well-
       documented and easy-to-program commands.
      Schedules. Gantt charts were mandatory, as well as automatic recalculation with updates of times,
       costs, and resources. Plots of earliest start, scheduled start, slack/float, latest finish, planned
       finish, and actual finish times were desired.
      Calendars. Either a job shop and/or calendar dates are necessary, plus the ability to indicate
       working days, non-working days, and holidays.
      Budgets. The ability to include a budget for planning, monitoring, and control was deemed
       necessary. Especially desirable was the ability to interface this with a spreadsheet program.
      Reports. Individualizing of report formats was considered most desirable. Again, having the
       ability to interface the reports with a word processing package was highly desired.

   While half the respondents mentioned the desirability of the following additional features, in our opinion
these features would also be considered mandatory today.

      Graphics. The ability to see the schedule and interactions was especially important.


                                                                                                           18
      PERT/CPM Network. The depiction of the network was deemed desirable by those familiar with
       this mode of project presentation.
      Charts. Charts for responsibility and histograms for resources were deemed particularly useful.
      Migration. The ability to migrate other software systems such as databases, spreadsheets, word
       processing, other project management packages, the organization's mainframe programs, graphics
       programs, and engineering and manufacturing software to and from the PMIS was considered
       valuable. Furthermore, general telecommunications and the ability to upload and download were
       deemed useful as well.
      Integratiowcomplexity. Akin to user friendliness, an appropriate level of onekey-does-it-all
       integration and package complexity was considered important. Extensive integration makes errors
       difficult to correct, and overcomplexity, while adding capability, makes the PMIS less easy to use.

   A number of respondents also mentioned the desirability of the PMIS supporting appropriate output
devices (color printers, plotters, high-speed printers), having windowing capability, allowing three-time
PERT estimates, and including precedence relationships and activity-on-arrow diagrams. There is one
item missing from the survey list of desired and mandatory features that we consider critically important,
the ability to update all data based on actuals. Unless the software allows updating both schedule and
resources, it is only useful for planning and cannot be used to monitor and control projects. With the
exception of three-time PERT and AOA networks, many current PC project management computer
packages will support all these capabilities.
   It is important to remember that no one package will meet all needs. Numerous trade-offs exist not
only between price and capability but also between functional capability, ease of use, complexity, and
speed. in general, there are five areas of PMIS internal capabilities, separate from the ability to migrate
data and communicate externally, that should be considered. These are project planning, resource
management, tracking/monitoring, report generation, and decision aiding. We discuss each below.

   Project planning. In this initial area, consideration should be given to the number of activities per
   project, the use of various calendars and time units, data recording and organization, time estimation,
   graphics generation, Gantt chart and PERT/CPM chart capabilities, early and late starts, and the ability
   to handle subnetworks (i.e., nested networks). Of particular interest in this category is the ability to
   reschedule/update automatically.
   Resource management. The issues here are similar and include the number of resource types, the
   number of resources per project, sharing of resources, resource leveling, scheduling by resource load,
   resource updating, resource usage conflicts, multiproject resource analysis, resource planning and
   analysis, cost estimating, and financial modeling and analysis.
   Tracking/monitoring. This area includes critical path analysis, subnetwork analysis, early warning
   systems, baseline and actual schedule updating and display, resource updating and display, and
   similar items.
   Report generation. This topic includes project status summaries, computer-assisted report generation,
   sophisticated data evaluation, resource lists and histograms, schedule lists, task detail, updating of
   report periods, resource detail, resource assignments, and current Gantt and PERT/CPM diagrams.
   Decision aiding. This area includes a number of capabilities, some involving external software
   packages. Generally, what-if analysis, expert system capability, multiproject tracking with cross
   analysis and other such types of capabilities are useful.

   The potential purchaser of a PMIS would be wise to consider the intended use of the package, the
background and needs of all the potential users, and the organizational setting where the package is to be
employed, including the needs and orientation of those who will be receiving the reports and graphics. In
terms of need, for example, is it really necessary to monitor costs or update schedules or resource usage?
Are we dealing with large projects, or ones with large numbers of critical resources? How complex are the
activity interrelationships? All these questions need to be addressed before selecting a final package.
   A general PMIS selection process based on Levine's excellent work [30] is as follows:

   1. Establish a comprehensive set of selection criteria, considering the questions and five areas of
      capabilities detailed above.
   2. Set priorities for the criteria, separating "must have" items from "nice to have" items and "not
      needed" items.
   3. Conduct a preliminary evaluation of the software packages relative to the criteria using vendor-
      supplied data, product reviews, and software surveys.
   4. Narrow the candidate packages to three and obtain demos of each, evaluating the vendors at the
      same time in terms of interest, software maintenance, and support.
   5. Evaluate each package with a standard project typical of your current and projected future needs.
      Make note of any weaknesses or strengths that are particularly relevant to your situation.
   6. Negotiate on price, particularly if you are making a volume purchase or contemplating a site license.
      Include descriptions of vendor support, training, and product maintenance in the contract.

                                                                                                        19
       Figures 10-10 through 10-18 illustrate some typical outputs available from Microsoft Project for
   Windows@ 3.0 (MPW) and Time Line@ 5.0 (TL). These packages, along with a great many others, are
   competent products, not difficult for computer-literate PMs to learn. Each has its strengths and
   idiosyncrasies. MPW, for example, has excellent graphics. TL is an excellent resource leveler.
       Figure 10-10 shows the MPW version of a small software evaluation project plan. Note that the display
   shows WBS identification numbers at two levels of the action plan. Included are scheduled start and finish
   dates together with a Gantt chart. Figure 10-11 is the MPW project calendar for December. There is
   room on the calendar to note project meetings and other dates of importance. Figure 10-12 shows the
   same project in a TL draft version. The WBS code is more detailed and the resources are shown along
   with task and work package durations. The Gantt chart is also displayed. Figure 10-13 is TL's
   PERT/CPM network for the project. Note that three levels of work are shown with the appropriate WBS
   numbers and are surrounded on the network with dotted lines. In both MPW and TL versions, summary
   activities (tasks) are also shown on the Gantt charts.
       In another project devoted to the production of a video tape, Figure 10-14 shows the TL network, with
   the critical path highlighted. Figure IO- 1 5 shows a TL Gantt chart, customized to show the action plan,
   start dates, resource needs, and finish dates with slack. Again, the critical path is highlighted. Figures 10-
   16 and IO17 show the same project with MPW outputs. The critical path is shown on the Gantt chart and
   on the network. The network was customized to show scheduled starts and finishes, and durations. Both
   software packages give the PM considerable latitude to customize output, as do almost all current
   software packages in this and higher priced categories. For example, Figure 10-18 shows a TL Gantt
   chart that includes both baseline data and predicted "actuals" for the construction of a house. The project,
   in this example, was updated on September 28 at which point the "Foundation/Lot" task was late. The
   predicted impact on the rest of the project is shown. Also note that "percent achieved" is shown using the
   0/100 percent convention. Finally, note that "Concrete" and "Grading" were scheduled to start on
   September 29, but actually were completed when the update was performed on the 28th. Figure 10-7,
   appearing earlier in this chapter, shows one version of an MPW budget display. Figures 9-8a and b show
   typical TL resource-usage histograms.
       As we have noted several times, there are many project management software packages from which to
   choose. When decision time comes, the user must read current product review materials. Fortunately,
   these are plentiful. Finally, the user must always be aware that no piece of software will do all things. At
   times, the user must be inventive and "force" the software to accomplish the desired ends. When suffer-
   ing from the frustrations that inevitably accompany learning any new software, the user must also
   remember that managing any but the smallest of projects is nearly impossible without the computer's help.
   The information contained in a PMIS is interesting, but its real value comes when it is used to plan and
   control the project, helping it to reach its goals.


   Project Management in Practice:

   Developing an Integrated Project Management System
   at Lederle Laboratories
   The Medical Development Section (MDS) of Lederle Laboratories is responsible for conducting clinical
drug studies, monitoring adverse drug reactions and complaints, preparing clinical supplements and
submissions, producing brochures and publications for professional and promotional use, and developing
exhibits for booth displays at scientific meetings. In the 1970s, MDS was using a set of four independent
systems to conduct their work:

      Clinical Study Administrative information:          includes investigator data, a study description, study
       design and protocol variables, personnel resources, and milestone planning and completion dates.
      Study Grants Financial Information: Includes study identification, total grant cost, payments to date,
       estimated payments, and monies returned.
      Task Management System: Provides information on progress toward utilization of clinical data and
       includes task identifiers, task manager, objectives, and estimated and actual dates.
      Automated Project Management System: Provides project analysis capability to plan and control
       projects.

    These four systems were developed independently and did not intercommunicate. The result was
duplicate data entry, data inconsistency, incomplete reports, and user confusion, all of which resulted in a
lack of confidence in MDS and its work. Thus, MDS designed a single-entry Medical Development
Information Management System (MDIMS) that would integrate the information supplied to MDS and return
results to administrative databases for ultimate reporting. The user requirements were identified as:

      Eliminate duplicate data entry.
                                                                                                               20
       Eliminate contradictory data.
       Develop data standards.
       Standardize data collection procedures.
       Consolidate schedule estimates.
       Enhance existing databases.
       Integrate all independent systems,
       Create unified turnaround and output reports.
       Extend automated project planning to all project teams.

    An MDIMS project team was created and accomplished the above requirements within the first year. The
last requirement was solved by creating generic work packages for each project, including any activities and
constraints usually associated with it. In this way, a project manager can quickly create a project plan by
simply fetching the generic work packages needed and assembling them into a larger plan.
    As MDIMS was put into service, users identified weaknesses in the system and asked for the following
additional features, which are being added:
   1.   Standardize project names to facilitate communication among users and administrators.
   2.   Redesign the turnaround reports to facilitate user updates as well as administrative data changes.
   3.   Add two new financial reports that combine project and study cost information.
   4.   Delete half of the work packages and focus on milestones instead to better manage projects.
   5.   Add the capability for users to view their own grant reports.
   6.   Add query capability to the system.
   7.   Provide uniform training to all system users.
Source: F. P. Funk, “The Development of an Integrated Project Management System in the Medical Development Section of Lederle
        Laboratories," Project Management Journal, September 1989.




    SUMMARY
        In this chapter we reviewed the monitoring function, relating it to project planning and control, and de-
    scribed its role in the project implementation process. The requirements for monitoring were discussed, in
    addition to data needs and reporting considerations. Last, some techniques for monitoring progress were
    illustrated and some computerized PMISs were described.
        Specific points made in the chapter were these:

         It is important that the planning-monitoring-controlling cycle be a closed loop cycle based on the
          same structure as the parent system.
         The first task in designing the monitoring system is to identify the key factors in the project action
          plan to be monitored and to devise standards for them. The factors should concern results, rather
          than activities.
         The data collected are usually either frequency counts, numbers, subjective numeric ratings,
          indicators, or verbal measures.
         Project reports are of three types: routine, exception, and special analysis.
         Project reports should include an amount of detail appropriate to the target level of management
          with a frequency appropriate to the need for control (i.e., probably not weekly or other such regular
          basis). More commonly, reports occur near milestone dates.
         Three common project reporting problems are too much detail, poor correspondence to the parent
          firm's reporting system, and a poor correspondence between the planning and monitoring systems.
         The earned value chan depicts scheduled progress, actual cost, and actual progress (earned value)
          to allow the determination of spending, schedule, and time variances.
         There currently exist a number of computerized PMISs that are available for PMs, the greatest
          growth occurring in microcomputer PMISs.
         Project managers' preferred PMIS features were friendliness, schedules, calendars, budgets, and
          reports, with graphics, networks, charts, migration, and integration also frequently being mentioned.
         The five areas of internal PMIS capabilities are project planning, resource management,
          tracking/monitoring, report generation, and decision making.

       In the next chapter we move into the final phase of project implementation, project control. We discuss
    the different types of control and describe some techniques useful to the PM in controlling the project.




                                                                                                                          21
                                   The Use and Management of
                                     Teams: A How-To Guide
Choosing the right type for your projects



           By       Richard L- Ratliff, Stephen M- Beckstead, and Stewen H. Hanks

  The use of teams has become a key fixture in today„s organizations. Managers of many
organizations have realized the significant benefits of teams. Others, however, have only
become frustrated.
  The authors' observations of hundreds of teams in numerous organizations on four continents,
including many world-class companies, have suggested some simple guidelines for the effective
use and management of teams in any kind of organization.
  This article presents a basic team framework designed to answer the following questions that
managers must consider:
  1. What conditions call for the use of teams? Are there conditions when teams are not
     beneficial? If so, what are they?
  2. What types of teams should be formed? Are there conditions that guide this decision?
  3. How should teams be managed? What factors influence team size and team duration?
     Should different types of teams be managed differently? If so, how?
When to use teams: Four enabling conditions
  The authors' observations suggest that four enabling conditions give rise to the need for teams.
  Condition 1: When there is more work to do, usually of one kind, than one person can do in the
allotted time
  Condition 2: When a single job is best performed in sequence of tasks and is required to be
completed faster than a single person can do it
  Condition 3: When a single job requires the coordination and integration of different roles or
expertise
  Condition 4: When the solution to a problem require the combination of more knowledge than
one person possesses

   In situations where one or more of
these conditions exist, managers
should give careful consideration to
 forming a team to accomplish the
work at hand. When one of the
enabling conditions is present, jobs
and tasks should be assigned to
individuals.
   Teams used in the absence of these
conditions        usually     end      in
disappointment for all concerned, with
team members getting in each other's
way and productive members being
resentful of those who do not con-
tribute.      Morale, efficiency, and
productivity all tend to suffer. There is
little, if any, benefit in employing
teams when none of the enabling
conditions is present.

    Four basic kinds of teams
 The authors' research has identified

                                                                                               22
four
 basic types of teams:
   1. Simple work teams
   2. Relay teams
   3. Integrated work teams
   4. Problem-solving teams
  Each team type is associated with a particular enabling condition. Thus, the appropriate choice
 of which type of team to employ is related to the enabling conditions present. Table I illustrates
 the relationship between team type and the four enabling conditions. in defining these four types
 of teams and their associated enabling conditions, illustrative applications are drawn from four
 organizations: McDonald's; Wilson Sporting Goods Golf Ball Division, Humbolt, TN; Gates
 Rubber Company, Siloam Springs, AR; and Logan Regional Hospital, Logan, UT.
   McDonald's is a world leader in the fast-food industry. The other three are award-winning
 organizations that use teams to drive production, quality improvement, and customer
 satisfactions
   Simple work teams. Teams responding to the first enabling condition – when there is more
 work to do than one person can complete in the required time – may be called simple work
 teams. The focal role of simple work teams is to complete a large task within a limited period of
 time. Each employee performs basically the same task.
     Wilson Sporting Goods' surlyn cover injection teams, with 12 to 15 members each, are
 examples of simple work teams. Here, injection mold operators place golf ball cores in a mold
 with the appropriate dimple pattern. The surlyn cover material is injected around each core. As
 thousands of golf balls are produced each day, this requires a team of operators, all doing
 essentially the same task, to complete the daily volume requirements.
   Other generic examples of simple work teams include assembly teams, on which each person
 does total assembly of a unit, such as at Wilson; painting teams; and short-distance delivery
 teams, where one person is responsible for one or more complete deliveries.
   Relay teams. Teams responding to the second enabling condition-when a sequence of tasks
 must be performed on an object (good or service) in a specified order, one following the other-are
 called relay teams. Here the object is passed from one team member to the next in sequence,
 although all team members may be working on other objects in various stages of completion.
   The assembly of sandwiches at a McDonald's restaurant is an example of a relay team.
 Although the matching of tasks to specific workstations varies slightly from one McDonald's to
 another, the basic assembly process requires that each sandwich go through the following
 series: bun preparation, dressing (sauce, lettuce, onions, etc.), meat placement, wrapping, and
 queuing.
   Other examples of relay teams include traditional in-line manufacturing; long-distance mail
 delivery teams, where intermediate exchanges are required; and newspaper writing-editing-
 production teams.
   Integrated work teams. Teams responding to the third enabling condition-when different roles
 must be coordinated-may be called integrated work teams. These teams combine a variety of
 related tasks to produce a product (good or service). In integrated work teams, several tasks are
 performed at the same time.
   Logan Regional Hospital's surgery teams are an example of integrated work teams. Surgery is
 a service requiring several different kinds of tasks that must be carefully coordinated, focusing on
 some specific aspect of the patient's body.
   The lead surgeon has primary responsibility for the team and performs the surgical procedures.
 A consulting or assisting surgeon often is present to provide additional expertise and a second
 pair of hands to perform surgical procedures required to support the lead surgeon.
   A lead, or circulating, nurse supervises the setup of the operating room and patient preparation,
 at the lead surgeon's instructions. A surgical technician helps set up the sterile components of
 the operating room and prepare the patient in the operating room. The surgical technician also
 hands the surgeon the instruments, and both the circulating nurse and the surgical technician
 count instruments, sponges, and needles, and provide ad hoc surgical support as needed.
   An anesthesiologist, or nurse anesthesiologist, is responsible for administering anesthesia and
 working with the lead surgeon to ensure the proper level of brain activity and to monitor the
 patient's vital signs during the surgical process.
                                                                                                  23
  All of these tasks are required for a typical surgery, and all are integrated and focused on the
successful completion of the surgical procedures on an individual patient.
  Other examples of integrated work teams include book production teams, road production
teams, and advertising production teams. The main purpose of these teams is to produce an
identifiable product as efficiently as possible, using a diversity of skills and careful integration of
those skills.
  Problem-solving teams. Teams responding to the fourth enabling condition-when the task is
unstructured and/or the solution to a problem requires more knowledge or expertise than one
person has-may be called problem-solving teams.
  Gates Rubber's quick changeover kaizen team is an example of a problem-solving team.
Kaizen teams map processes, find waste, use cause-and-effect analysis to determine causes of
waste, design and implement countermeasures, and check to be sure improvement has been
made.
  Kaizen teams are typically formed for a few days and disbanded when the problem is solved.
Gates Rubber also uses problem-solving teams to achieve cycle-time reductions, increase
throughput in production cells, and reach proper staffing levels for manufacturing processes.
  Other generic examples of problem-solving teams include quality improvement teams, crime
prevention task forces, and design teams. The work of these teams is primarily cerebral. The
main purpose of these teams is to combine and focus brain power in addressing workplace
problems. Solutions are generally reached by consensus.

What to do when multiple conditions are present
  When more than one of the enabling conditions occur simultaneously, there is likely a need for
more than one of the four basic team types and their corresponding activities. When this occurs,
rather than devising some new form of team, successful teams become multiconditional. First,
tasks are segregated into different categories corresponding to the existing conditions, and then
the subtasks are performed according to the basic team activities required.
  One example of a multiconditional team is a typical site evaluation team for a quality award,
such as the Shingo Prize or Malcolm Baldrige National Quality Award. When conducting a site
visit, the team of examiners often encounters all four of the enabling conditions simultaneously,
as well as conditions calling for individual tasks.
  Time constraints often require team members to examine different parts of a company's
operations separately, all looking for approximately the same sorts of things (simple work team).
Team members also coordinate different roles during site visits: data collection, analysis and
evaluation, and report preparation (relay team, integrated work team). Finally, members must
combine their knowledge and expertise to reach a consensus opinion on the team evaluation
(problem-solving team).

Team size
  Important to the organization of any team is determining its size. Each of the four kinds of
teams and their associated activities suggest a different strategy for determining the number of
members required. While a variety of factors may affect team size, only a few factors in each
case are most likely to drive team size. The primary factor for all types of teams is the size and
scope of a required project. Beyond this basic consideration, however, certain factors appear to
come into play when determining the appropriate size for each type of team.
  Simple work teams. The principal factors driving the size of simple work teams are:
   The amount of work to be done
   The amount of time available to do the work
   The amount of work one person can do in the available time
  With this information, it is a simple matter to divide the total estimated work to be done by the
amount of work one person can do in the available time period, giving the number of people
required to do the work in the required time.
  For example, suppose 50,000 square feet of surface must be cleaned in five hours, and one
person can, on average, clean 5,000 square feet in the five-hour period. Ten people, then, would
be required to complete the job in the allotted time.
  Relay teams. The main factors influencing relay team size are:
   The differentiation of tasks to be performed in sequen
                                                                                                    24
     The balancing of task assignments to ensure a smooth flow of work without bottlenecks or
     unnecessary idle resources
   The cycle time required
  A single work process may be divided into, say, three, five, or eight separate tasks, depending
on ho the tasks are defined. For example, in some McDonald's restaurants the task of dressing a
sandwich bun may include placing the meat on the bun, while at other restaurants, dressing may
include eve thing other than the meat, and placement of the meat a separate task.
  To balance the work flow, it is necessary to assign the tasks to individual workstations so that
units of work pass through the sequence smoothly Tasks may be combined or redifferentiated to
accomplish this balanced flo For example, one McDonald's restaurant divides the six step
sandwich assembly process into four workstations: bun preparation (step 1), dressing the bun
(step 2), coo and meat placement (steps 3 and 4), and wrapping and queuing (steps 5 and 6). A
second restaurant, one with less customer demand, uses only two workstations. Bun
preparation, dressing the sandwiches, and meat placement are combined, and cooking is taken
off the assembly line entirely. Cooking is an off-line support, just-in-time process
  Integrated work teams. The principal factor driving the size of integrated work teams is the
differentiation of the required tasks. To determine team size, the integrated production process
must first be planned, standardized, and balanced to ensure an integration of tasks without
creating bottlenecks or slack points. Once the integration and balancing of the tasks have been
accomplished, team size is determined by the number of integrated human tasks required to run
the production process.
  For example, Gates Rubber, as well as other companies that use cellular manufacturing
techniques, uses this approach to determine the number of team members for each production
cell. First, daily production numbers are determined. These are usually tied to customer
requirements.
  Next, takt time is calculated. Takt time is calculated by dividing the productive time available in
a given period by the number of units required by the customer during that period. Takt time is
sometimes referred to as the "heartbeat" of the customer. Working to a takt time is one step in
getting production to flow more smoothly
  Third, cycle time (the time to complete each operation in the cell) is calculated. Cycle time is
the actual run time of the operation. Each worker in the cell is then assigned operations that as
much as possible equal takt time, thereby minimizing the number of operators in each cell.
  Problem-solving teams. The principal factor driving the size of problem-solving teams is the
number of dimensions of the problem significantly affecting the solution. Generally, the more
dimensions, the larger the team. Of course, in some circumstances, one person may cover more
than one dimension, which would reduce the number of team members required. In other cases,
one dimension may be so complex that more than one person may be required to cover it.
  As an example of determining the size of a problem-solving team, the design of a new golf ball
by Wilson might include consideration of quality, cost, customer requirements, production
capability, and customer service. Consequently, this product design team would likely include a
quality expert, an accountant, a research and development specialist, supplier representatives, at
least one production specialist, and a marketing specialist. This team might include as many as
10 people.

Other factors affecting team size
  Beyond issues related to team type, additional factors must be considered in determining the
appropriate size of a given team. These include the periodic need for reserve team members,
consideration of technological capabilities and sociological needs, and the need to vary team size
during a project.
  Need for reserve team members. The more critical the need to meet specific project criteria,
the greater the need to assure the performance of each team member. This need sometimes
requires alternate or substitute team members held in reserve. The number of reserve members
will depend on the importance of the task and the probability that substitute members will be
needed to fill certain positions. A surgical operating team, for example, is likely to have reserve
support readily available for each key team function (i.e., lead surgeon, assisting surgeon, lead
nurse, surgical nurse, and anesthesiologist).

                                                                                                  25
   Technological capabilities and sociological needs. One question that arises in determining the
 size of teams is whether teams can become too large. The answer seems to hinge on two
 factors: technology and sociology. First, technology seems to determine the limits of effective
 communication, integration of roles, and effective handoffs, for example, on integrated work
 teams.
   A typical surgical team, because of the restricted confines of the operating room, restricted view
 of the patient, and close work space, is limited to spontaneous, in-person voice communication
 between team members to coordinate the various tasks. Electronic media (audio and video) can
 be used to allow the participation of a few off-site team members whose knowledge may be
 required, but such participation is awkward at best.
   Technology should facilitate team efforts, not hamper them. When a team reaches a size
 where the available technology cannot support the team effort, or the technology required for the
 team to function begins to interfere, the team is too large. In either case, technology should not
 reduce the team's effectiveness and efficiency.
   Second, the sociology of teams includes a psychological and emotional identification with the
 team. As the team becomes too large, such identification can be difficult to establish and
 sustain. In general, it seems that as teams grow to the point where team members are less
 familiar with each other, both by person and by role, they are less likely to hold a strong
 psychological and emotional identity with the team as a whole.
   Of the specific companies sur-
veyed for this article, the upper
limit was about 15 team
members, as seen on Wilson's                 ‘When more than one of the enabling conditions
simple work teams. Integrated                occur simultaneously, there is likely a need for
teams ranged between five and                more than one of the four basic team types and
eight members, and problem-                  their corresponding activities.’
solving teams ranged up to 10
members. Relay teams observed
at McDonald's ranged up to eight
members, with two people at
each of four workstations.
   Technically speaking, however, relay teams conceivably could involve an endless sequence of
 handoffs. The primary limitations on the size of relay teams seem to be the size of the project
 and team members' sociological needs. For example, the production, assembly, and delivery of
 automobiles requires hundreds of individual tasks to be performed in sequence at different
 locations, resulting in hundreds of handoffs.
   In a large sense, perhaps everyone involved might refer to the team effort required, but
 individuals are likely to feel more of a team relationship with others working on the same shift or
 in the immediate area. In this case, the team would range from two or three members to perhaps
 two dozen.
   Changing team size. Some teams may vary in size during a project. Generally, there is a core
 group of team members present for the entire project, while other team members may join the
 team temporarily to complete specific tasks.
   For example, audit teams frequently employ specialists who join the team only long enough to
 perform a specific procedure. But while they are present, these specialists are very much a part
 of the team: Their work is focused on the team project; they communicate directly with other
 team members in the performance of their work, which must be coordinated with other team
 tasks; they become part of the team social network; and they and other team members
 understand their role in completing the overall project.

                                           Team duration
  Teams can be permanent or temporary. If the conditions leading to the establishment of the
team are stable over long periods of time, it is appropriate to assign team members on a
permanent basis. When conditions, or the nature of the work, change often or are of limited
duration, it is generally best to fon,n teams on a temporary basis. Under such circumstances,
teams can be established on an ad hoc basis and dissolved when the work of the team is
completed.
                                                                                                  26
  Managing teams
  Whether teams are self-managed or have a designated team leader or supervisor, effective
teams require effective management. Mismanagement can cause-and has caused, in too many
situations – dysfunctional teams. Like the issues of team type and size, team management
should be tailored to the type of activity required.
  In analyzing effective team management, the authors have identified certain management tasks
that must be performed in all teams regardless of team type. These are designated as
foundation tasks. These tasks form the foundation of team management activity and represent
the tasks required for effective management of simple work teams. Beyond these, the authors
have identified unique additive team management tasks that must be applied when other
enabling conditions are present and the management task becomes more complex.
  For each type of team activity, a unique strategy is called for, forming a hierarchy of team
management tasks. This hierarchy is illustrated in Table 2.
  Managing simple work teams. Simple work teams are the simplest team form; they usually
perform less complicated work requiring less coordination and, often, less direct supervision.
Effective management of simple work teams involves the six foundation tasks identified in Table
2:
  1. Identification of work to be done. The work to be accomplished by the team must be
   clearly identified. Associated with this task is the need to ensure that a team is really called for-
      that at least one of the four enabling conditions calling for the use of teams is present.
  2. Team selection. The appropriate team members must be selected, including possible
      reserve members.
  3. Allocation of work. This involves ensuring that the work is allocated in such a manner that all
      required work can be completed in the allowed time, and with as little overlap as possible.
  4. Coaching and facilitation. These are required to ensure that all team members understand
      and perform their assigned tasks, that they have the tools and resources required to do the
      job effectively, and that problems are resolved.
  5. Coordination with suppliers and customers. This must occur on an ongoing basis, with both
      internal and external suppliers and customers, to ensure effective quality is achieved in the
      team‟s work.
  6. Cheerleading. This is essential to the recognition and celebration of quality work and team
      accomplishments.
  Managing relay teams. Relay teams are a relatively simple form, but somewhat more complex
than simple work teams. The reason for their greater complexity is the use of handoffs, or
transfers of work units between workstations. Careful coordination of the effectiveness and
efficiency of transfers from one task to another is the primary distinguishing feature of relay
teams.
  Beyond the six foundation tasks, effective management of relay teams requires the
management of these handoffs. A good handoff is one in which the object is properly secured to
avoid dropping or breakage, is transferred in good form and ready for the next task, and is
transferred quickly with as little expense and movement as possible.
  To manage the handoff of sandwiches between workstations at McDonald's, sandwiches are
placed six at a time on a single tray, which is then moved down a stainless steel counter to each
subsequent workstation. The workstations are balanced to avoid bottlenecks and smooth the
flow from station to station.
  All employees are carefully trained and coached to operate each machine and handle the work
flow, and to perform their individual tasks and the handoffs to preserve the appearance, taste,
and nutritional quality of the food. Each manager also is trained to carefully facilitate the work
process by making proper workstation assignments and providing well-maintained and properly
designed equipment, well-designed work processes, immaculate facilities, and a friendly, pro-
ductive work climate.
  Managing integrated work teams. Integrated work teams are distinguished from relay teams
by the complexity and direction of handoffs. Handoffs in integrated work teams tend to be
multidimensional and more complex. Thus, the additional task associated with integrated work
teams is coordinating and scripting complex integrated routines.


                                                                                                     27
  Surgical teams, for example, typically consist of several specialists. Each team member is
responsible for filling certain roles at various phases of the surgical procedure. Most surgical
procedures have an established protocol wherein team members play their varying roles. These
are scripted in advance, and are refined over time as team members gain experience working
together.
  Beyond formal scripting, team members actively observe the overall process, stepping in and
assisting as necessary, in response to formal and informal cues provided by the team leader or
other team members. Thus, the management task involves formal scripting of team protocols
and routines, training team members to understand their role in the entire integrated process,
clarification of cues, and mechanisms for informal adaptation and team learning.
  Managing problem-solving teams. The defining need of problem-solving teams is to provide
structure that helps the group process take advantage of every team member's potential
contribution, combining them to achieve a single solution. Usually, the people recruited to these
teams already possess the requisite individual knowledge or expertise.
  The management problem is to generate a single solution from the individual parts. Successful
management of these teams usually includes additional coaching in the team problem-solving
process and leading and facilitating that process.
  Team problem-solving processes usually include several features: team orientation to the
problem, individual consideration of the problem, individual input, synergizing, and consensus
building. Each part of the process is crucial. Team orientation focuses all efforts on the required
solution.
  Individual consideration and input ensures everyone's contribution. Synergizing allows team
members to brainstorm together, considering the problem collectively Consensus building
develops a single solution. Techniques using all of these features include brainstorming, focused
group, and Delphi techniques. The best kaizen teams also include these features, although there
is no well-established, standardized kaizen team process.
  At Gates Rubber, kaizen teams are organized to effect significant change in a five-day period:
  Day 1: Team members are trained and familiarized with the area to be improved.
  Day 2: The current situation is analyzed. Time analysis, machine capability, cycle time, and takt
time are examples of some measurements taken early on the second day Later during the
second day, data are analyzed and cause-and-effect analysis begins.
  Day 3: Countermeasures are designed and implemented.
  Day 4: The effect of the changes is checked, and additional changes are made to increase the
gains in time, productivity, or quality. Near the end of the fourth day, new work standards are
written based on the improvements, and reports documenting the kaizen team's work are
prepared. Follow-up items are then listed, with individual responsibilities and deadlines, to
ensure that the gains made during the week are not lost due to poor communication or lax
implementation.
  Day 5: The morning is spent reporting to supervisors and managers.
  In managing the team problem-solving process at Gates Rubber, the team leader or facilitator
plays a vital role in training team members in the kaizen methodology, ensuring that the
structured process is followed, and managing the process to ensure that key milestones are met.

  Outstanding teams, outstanding organizations
  The guidelines included in this article (summarized in Table 3) represent a synthesis of
hundreds of informal observations in many different organizations – public and private, small and
large. Specific examples come from four organizations recognized for their excellence, and that
strongly emphasize the use of teams. Violations of the guidelines, except in exceptional
situations, seem to occur consistently among mediocre or dysfunctional teams in struggling
organizations. While these guidelines are general and there may be exceptions, they are used
consistently among outstanding teams in outstanding organizations.

 REFERENCE
 1. Wilson Sporting Goods Golf Ball Division and the Gates Rubber Siloam Springs Plant were
1993 recipients of the Shingo Prize for Excellence in Manufacturing. Logan Regional Hospital,
affiliated with Intermountain Health Care, is a recipient of the 1991 Healthcare Forum/Witt Award


                                                                                                28
and the 1996 National Quality Healthcare Award presented by the National Committee for Quality
Healthcare.


RICHARD L. RATLIFF is the Arthur Andersen Alumni Professor at the School of Accountancy,
Utah State University, Logan. He has a doctorate in accounting from the University of North
Carolina at Chapel Hill. Ratliff is a member of ASQ.

STEPHEN M. BECKSTEAD is associate director, Shingo Prize for Excellence in A4anufacturing,
at Utah State University, Logan. He has a doctorate in management strategy from Purdue
University in West Lafayette, IN.

STEVEN H. HANKS is senior research associate, Shingo Prize for Excellence in Manufacturing,
at Utah State University, Logan. He has a doctorate in business administration from the
University of Utah in Salt Lake City.




                                                                                            29
                                                                                SAV
                 SDC
                                    Swiss-AIT-Vietnam Management Development Programme
c/o HCMC University of Technology, 268 Ly Thuong Kiet, Dist.10, Ho Chi Minh City, Vietnam Tel: (84-8) 865 08 80 Fax: (84-8) 865 08 81 E-mail: SAV@netnam2.org.vn / swissait@hotmail.com




         Course: Project Organization and Implementation
         Instructor: Dr. Tran Phuong Trinh

         Teaching notes of
         Analytic Hierarchy Process by Expert Choice 8.0
         For the topic of:

         Prepared by Phan Trieu Anh




                                                                                                                                                                             30
                           AHP Basics Review
 Purpose: A technique aids in making multiple criteria decisions

 Routine:
   Goal
   Criteria
   (Attributes)
   Alternatives
   Scale 1-9 to define superiority
   A tree building with root (goal), branches and nodes (criteria or
    attributes), and leaves (alternatives)
   AHP essential: deciding weights for all the branches of the
    tree, then the desired weights of alternatives.
   So, pairwise comparison: weights of the branches
   Note: Inconsistency ratio of less than 0.1 to have a fully
    confident result.
   Global priority: list of ordered weights of alternatives

 Expert Choice helps in:
   Visual aid in building The Tree
   Calculation of the weights
   Sensitivity Analysis
   Graphical reports




                                                                    31
Using Expert Choice (EC 8.0)


EC 8.0: DOS program (1992)

   Starting the software: double click the icon EC
   Enter the optional directory to store models (each model is created to solve a problem): any existing or
    create a new folder. Enter the name of an existing folder or the name of a new one, answer Yes to
    confirm the creation of the new folder.
   Make/Retrieve model: create a new model to solve a problem or open an existing model from file to
    continue working on it. Answer Yes to confirm new model.
   Definition: Specify the goal of the problem
    Ex: Choosing the best project work group on competitive basis


    Expert Choice menu is activated by pressing Alt key.


   Go Edit, then Insert to create a new node (any criterion, attribute, or alternative) on the tree.
    Under the goal, there are criteria, and in the bottom are alternatives
   Type in the name of the node and then the definition of the node
   Alternatives can be copied under different nodes by going to Edit–Replicate–To Peers
    Continue to draw the tree
   Pairwise comparison: compare all pairs of criteria, attributes or alternatives: Go Compare-Other-
    Pairwise-Numerical
   Get the result from Expert Choice: Go Synthesis-Distributive mode
   Print out the result: Go File-Reporting


Example: Ranking the project work from different groups from the standpoint of the Project Management
teacher and on competitive basis as the rule of the Institution. Five characteristics chosen for comparison
are: project work quality, submitting punctuality, in-class presentation, consultation, teamwork. There are 3
groups in Project Management class. The hierarchy should be drawn as Figure 1 and the pairwise
comparison is given in Table 1 and Table 2.




                                                                                                                32
                                            Choosing the best group




     Quality                Punctuality        Presentation         Consultation     Teamwork




                              Group A                   Group B           Group C



Figure 1: The tree hierarchy for choosing the best group
Table 1: Comparison of characteristics with respect to choosing the best group.
                        Project       Submitting           Presentation     Consultation   Teamwork
                        quality       punctuality
Project quality         1             5                    3                7              3
Submitting              1/5           1                    2/3              1              2
punctuality
Presentation            1/3           1.5                  1                3              1
Consultation            1/7           1                    1/3              1              ½
Teamwork                1/3           ½                    1                2              1
The priority vertor for that matrix (0.496, 0.153, 0.146, 0.078, 0.127)
Inconsistency Ratio: 0.066
Table 2: Comparison of groups in respect to the 5 characteristics
                        Project quality
                  Group A         Group B           Group C
Group A           1               5                 3
Group B           1/5             1                 2/3
Group C           1/3             1.5               1
Inconsistency ratio:0




                  Submitting punctuality
                  Group A         Group B           Group C
Group A           1               1                 1
Group B           1               1                 1
Group C           1               1                 1
Inconsistency ratio: 0




                                                                                                      33
                          Presentation
                Group A          Group B        Group C
Group A         1                7              3
Group B         1/7              1              1/5
Group C         1/3              5              1
Inconsistency ratio: 0.062
                          Consultation
                Group A          Group B        Group C
Group A         1                1              3
Group B         1                1              3
Group C         1/3              1/3            1
Inconsistency ratio: 0
                           Teamwork
                Group A          Group B        Group C
Group A         1                2              1
Group B         ½                1              ½
Group C         1                2              1
Inconsistency ratio: 0
Table 3: The local ranking of groups by corresponding characteristics

                      Project            Submitting       Presentation   Consultation   Teamwork
                      quality            punctuation
Group A               .653               .333             .649           .429           .400
Group B               .131               .333             .072           .429           .200
Group C               .216               .333             .279           .143           .400
Inconsistency         0                  0                0.062          0              0

To obtain the overall ranking of the school, we multiply table 3 with the row vector of the weights of the
characteristics.
        Group A: .554
        Group B: .261
        Group C: .186
Overall inconsistency index: 0.05
Group A has the best score to be chosen as the best group in Project Management.




                                                                                                             34
Your turns,
1. The RTA judge with the following criteria, all the groups have the same characteristics comparison tables
as above, which group is the best?
                   Project    Submitting        Presentation        Consultation      Teamwork
                   quality    punctuality
Project quality    1          5                 7                   5                 3
Submitting         1/5        1                 3                   1/5               1/6
punctuality
Presentation       1/7        1/3               1                   1/4               1/5
Consultation       1/5        5                 4                   1                 1/5
Teamwork           1/3        6                 5                   5                 1

2. Build The Tree for solving the following problem – provide reasonable attributes, put the figures in and
show the results – deciding the most suitable landscape to visit during term break.




                                                                                                              35

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:105
posted:11/9/2010
language:English
pages:35