· They cost too much

· They take too long

· They generally do not give the desired results

· It is a planned undertaking

· It will result in tangible products that are related towards accomplishing a common goal

· It is an effort which is unique, infrequent, or unfamiliar to the existing organization

· It is recognized by everyone concerned including higher management as constituting a project

· Improved user relationship

· Broadened staff experience

· Better control of activities and resources at all levels of management

· Better planning of the work to be done

· A direct facing of the problems of intra-departmental communication and coordination

· Increased productivity through group synergy

· Easier and more efficient stall motivation and training.

· Planning

· Balance between authority and responsibility

· Teamwork

1. Planning. The most important prerequisite to high quality project performance is careful and exact planning. This is true regardless of the size and complexity of any project. When all the steps, relationships between individual tasks, and matchings of resources and requirements have been in advance, chances are excellent that the project will achieve its assigned objectives. A good plan identifies potential trouble areas and allows the project manager to take steps to minimize the dangers prior to actual project start-up. During the project, the manager can compare actual performance with this prior estimates as a way of measuring and controlling progress. Clearly. No project should be started it is has not been preceded by proper planning. Current thinking on project management is tending toward the subdivision of large projects and the construction of a number of short range projects which are under control of a number of project leaders. This of course means there must be a strong project manager to coordinate all these functional projects but it also implies the subdivision of the daily control function and the step-by step development of a massive project effort.

2. Authority and Responsibility. In the project management approach, authority and responsibility are always together as two sides of the same coin. One is useless, if not impossible, without the other. Authority will be neglected or misused if not tied to defined responsibility. On the other hand, responsibility without authority can only lead to frustration for both the project manager and higher management. The balance assignment of authority and responsibility applies from the project manager to the most junior person assigned. This assignment should be clear and unambiguous.

3. Teamwork. The third basic concept in the project management approach - teamwork - must be carefully cultivated by the project manager. Teamwork relies heavily upon the existence of harmony in the project team. When the project manager selects team members, he should consider the ability to work well with others one of the most important attributes.

1. Interdepartmental Projects. The responsibility for a single project cannot be split between functional departments. If this becomes necessary, for any reason, then there should be more than one project. A project team may be composed of personnel from several departments, but the responsibility for a particular project can be assigned to only one person.

2. Shifting Personnel Among Projects. In an organization using project teams the tendency to shift personnel from project to project due to changing priorities must be resisted. Although there are cases where shifting of personnel is necessary, there are frequently other alternatives. A shift of personnel from project to project disrupts the activity of the individual, who must reorient himself, and disrupts the ongoing project from which he is removed.

3. Need for Long Range Planning. A problem related to the one described above occurs when a person is assigned to work on a long term project and thus becomes unavailable for work on other projects. Documented long range planning is the basic solution to such problems. When an organization know how it will use its personnel for some time in the future, it can make better evaluation of the impact of staffing a particular project team.

4. Duplication of Effort. In many cases the work done by one project can be used in whole or part by another project with consequent savings of time and manpower. Good project documentation and an open line of communication between projects and departments is needed in order to recognize that such situations are occurring.

5. Individuals Career Development. In many cases it is desirable to have certain individuals on a project team throughout the life of a project in order to ensure continuity and avoid the problems created by replacement of specialists who have a thorough knowledge of the project. On the other hand, too long a commitment to a specific project may either make an individual too narrowly specialized or create personal frustrations if he wishes to expand his scope of experience. The needs of both projects and individuals must be taken into consideration as a basic part of planning both for departments and specific projects.

6. Monitoring of Project by Upper Management. There is a tendency to only monitor those projects that appear to be in trouble. Both monetary and emotional costs can be reduced when management carefully monitors all projects and is ready to give assistance to a project manager before the project is in serious trouble. In monitoring projects, management must encourage the project manager to be complete and accurate concerning the status of the project so that problems can be treated while they are still minor. Frequent small milestones with defined products are a better control than a few major widely spaced milestones which can allow a crisis to develop.

7. Part Time Team Members. One of the reasons for the project management approach is to ensure a concentrated and controlled effort on a particular project. This effort can be severely hampered by indiscriminately using part time team members as part of the effort. Obviously, there are times when there is no choice but to utilize part time team members as a result of staff shortage, an urgent need for a certain type of experience. Or in the case of several small projects where full utilization of personnel becomes a problem. Part time team members must have very clearly defined responsibilities and their tasks must not require frequent interfacing with other team members.

1. Make Commitments to User. The project manager is obligated to make specific commitments to the user concerning the project. The user needs these commitments in order to make his own plans. These commitments will be based on milestones in the project plan. If the user requests specific commitments on items which are uncertain, the project manager must qualify his response so that the user will know the degree of uncertainty and can act accordingly.

2. Keep User Informed. The project manager must keep the user continuously informed. This is particularly important in regard to aspects of the project which may have an impact on the userís organization. Normally the user will have made plans and commitments based on inputs from the project manager and these may have to be revised.

3. Make Sure User Understands Information. The project manager is responsible for assuring that all communication between him and the user is understood. Important verbal communications should be oriented to language that is understandable to the user. Difficulties cannot always be avoided such as when there is a change of user liaison personnel; therefore, a mutual sign-off procedure should be employed to avoid misunderstanding.

1. Provide Balanced Assignment of Tasks. One aspect of task assignments is career development considerations. Another aspect is the assignment of tasks which are challenging to the team members but not beyond their capabilities. If the task is too easy then the team member will lose his drive, whereas a too difficult task will be extremely frustrating to him and his inability to accomplish the task will impact the project.

2. Isolate Team Members From Outside Influences. The project manager must act as a buffer between the members of the project team and higher management and the user. Higher management or the user must make their criticisms or complaints to him rather that directly to the team member. When the project manager must pass on the criticism or complaints he is responsible for giving the team member assistance in correcting the condition and providing additional aid if needed.

3. Provide Guidance in Solution of Problems. The project manager is responsible for the early recognition that a team member is having problems and assisting him in finding a workable solution.

4. Provide Honest and Objective Treatment. The project manager must be honest with the team members. He should praise them for outstanding accomplishments and frankly criticize them when that is required, He is responsible for giving fair and objective appraisals of team members in the performance reviews.

5. Provide Support for Team Members. If both the project manager and the team members are in agreement on a specific point, the team member must know that he has the backing of the project manager in presenting it to the user. Without this trust, the project teamís effort will become mechanical and will not display any creative ability.

6. Set the Proper Example. The project manager must remember that he is implicitly setting an example to the team members of what it means to be a project manager.

1. Provide Meaningful Status Reports. The project manager is directly responsible for informing management of the project in clear and understandable terms. A status report is almost worthless if higher management cannot understand what the project manager has written. An important aspect of such status reporting is relating the items in the report to the plans and products laid out in the directives controlling the project.

2. Openly Communicate Problems. The project manager is directly responsible for telling management the truth. It is human inclination to hide problems and difficulties in the hope that they will somehow vanish. Usually, the result is that the problems develop into a major crisis before management is aware that there are any problems. Higher management cannot afford unpleasant surprises, and such surprises will be largely avoided if the project manager is honest in his reporting.

3. Provide Sufficient Alternatives. The project manager must present management with adequate information on which to base decisions. The easy route is for the project manager to prepare his inputs for management in such a fashion that he has already biased the decision making. He should present significant alternatives whenever possible and indicate the consequences and cost of each alternative.

4. Make Decisions at the Project Level. The project manager is responsible for making the decisions within the area of responsibility assigned to him by higher management. He has been entrusted with this responsibility so that higher management will not have to be concerned about the day to day details and decisions of the project.

5. React to and Supplement Higher Level Decisions. The project manager has a basic responsibility of reacting to the decisions of higher management while these decisions are being made. There is, of course, no problem when the project manager agrees with the decisions. However, when the project manager disagrees with a decision, he should in a clear, detailed, and unemotional manner present the reasons which make him believe that the decision is incorrect. Higher management and the project management should determine the precise points of disagreement (often it is a misunderstanding rather that a disagreement) and then seek to find a solution to the disagreement.

6. Implement Higher Level Decisions. Once a final decision is made by higher management, it is the responsibility of the project manager to implement the decision to the best of his ability. In some cases higher management will make decisions which are not optimal from a narrow point of view of a particular project but which align that project with other organizational goals. It is inappropriate for a project manager to seek to fight or undermine a decision once it has finally been made by higher management.

7. Notify Upper Management of the Availability of Personnel. The project manager is responsible for early notification to management of the dates by which project team members will become available for work outside of the project. This will assist management in its long range planning for both personnel and projects. This could include requests for the unplanned removal of personnel from the projects. In this case, the reasons for recommending removal should be provided in a clear and objective manner. The project manager should also state the consequences of removing or not removing the individual.

· Improper project staffing

· Late Project completion

· Unrealized objectives

· Non-optimal systems

· Unexpected crises

· Unhappy project team members

· Unhappy users

· unhappy management

· Higher costs

· Various negative external influences

· An iterative process

· Estimating independently from scheduling

· Based on the plannerís experience

· Tempered by judgment

· Influenced by history

· Based on standards

· Organized

· Flexible

· Project definition

· Initial project planning

· Project team organization

· Detailed project planning

· Study each activity included in the application section and attempt to relate known factors concerning the project.

· After studying all activities, reference the activity network for the applicable stage of development located in the introduction of SDM. Attempt to develop a mental picture of the project by weighing each of the activities in relation to each other and by analyzing the sequence of the activities.

· Utilizing SDM as a guide, compile a checklist of questions to be answered. Whenever possible make the questions specific; however, in the beginning many of the questions must be of a general nature.

· Use SDM as a guide to what information should already be available. Review the previously prepared documentation to check that all information required by this stage(s) is presented.

· User requirements

· Project objectives

· Project boundaries

· Acceptance criteria

· Project status reporting

· Project definition statement

1. User Requirements. Once the background material of the project has been reviewed and the particular activity requirements have been analyzed using the SDM, it is time to consult with the user to further specify what constitutes the project.

The goal of the project manager in this task is to obtain complete and accurate information. Four keywords which are relevant here are preparation, motivation, consideration, and documentation.

For preparation the project manager should have a checklist of questions to be answered. There will be questions that will be too general in nature to be answered. In these cases, he can solicit help from the user in further qualifying the questions.

To motivate the user, he should fully understand what the information provided by him will be used for. The project manager must emphasize the fact that the user is participating in the development of the system and that without this input the project will not be successful. If the user has doubts about the usefulness of certain information, the project manager will be able to point out that part of the SDM which justifies his line of questioning. A clear sign that the user has become actively engaged in the project is when the user initiated contacts with the project manager and ceases to be a passive recipient of questions.

The project manager must have consideration for the userís time and attitude. Meetings should always be scheduled in advance with an agenda and the amount of time allotted for the meeting should be adhered to. The project manager should always be aware of how the user is reacting to him personally. The free flow of information can easily be blocked because of personality conflicts.

The relevant information obtained at a user meeting must be documented and reviewed by the user before distribution and as soon after such meetings as possible.

2. Projective Objectives. With the aid of user representatives a clear and mutually agreed statement of project objectives should be made. If this is a later stage of system development than the Definition Study, the total system objectives should be available in the technical report resulting from the Definition ?study. A particular project, unless it covers all stages of system development, can only accomplish its predetermined part in satisfying these objectives. The introduction to each stage of development in the SDM states the general objectives to be provided for in that stage.

The SDM provided in general terns the activities and their resulting products within each stage of system development. An attempt should be made at this time to determine, in relation to project objectives, which of these activities and products are necessary for the particular application.

The project manager must review the expected project products with the user; this should include his definition of each product and how each assists in satisfying project objectives. The result of this review should be an agreement between the project manager and the user on the deliverable products which will enable the project manager to qualify those activities presented in the SDM as they relate to the particular project.

Projects are normally constrained by time, money, and/or manpower. Depending on the relative priority of these factors, one of the following will have more or less importance and must be reflected in planning:

An attempt should be made to identify one of these with the aid of management and the user as a primary limitation on the project. This does not mean that you set impossible limits on a project - a good plan must be a feasible plan. It must be recognized that there is always a minimum amount of time, money, and manpower required for a project and attempts to plan for less that the minimum is, at best, misleading.

3. Project Boundaries. The boundaries of a project are the other side of the coin from project objectives. Specifically, these constitute what the project will not do, areas the project will not investigate, or interface points to other projects. Possible boundary areas to be investigated are:

4. Project Acceptance Criteria. It is important to identify very early in the project planning phase the acceptance criteria that will determine whether or not the project is complete. This can have an important impact on planning. It is often the case that the acceptance criteria for a project are only identified when the project team delivers the final product to the user and finds that it is totally unacceptable.

5. Project Status Reporting. The value of identifying project status report requirements during early project planning should not be underestimated. The project manager must plan his own time as well as that of the project team, and project reporting has many times unanticipatedly become a major activity. The following procedure should be followed:

6. Project Definition Statement. The results of the initial project start-up activities should be summarized into a project definition statement which will be the basis on which further planning will be made. The following items should be treated in the project definition statement:

· Setting up the project file

· Estimating specific activities to be performed

· Fixing the major project planning constraints

· Creating the initial project schedule

· Establishing the initial project plan

1. Project File. It is clear that at this point in the project there may be only a little information which must be filed, but information from this time forward will be generated or collected at an ever increasing pace.

Initially the project file is set up as a ìdummyî file. To do this, all sections that will comprise the file are made up as folders in a file drawer and inserted even though contents are not yet available. At this point the project file represents the framework for the project. The organization, retention, and classification of then work done under the project will be quite simplified. The process of documenting the project becomes a matter of ìfilling in the outlineî of the project and what is left to be done by looking at the empty sections in the file as compared to the completed ones.

The project file is a record of all information concerning the project. It must always be up to date and reflect all that is currently known about the project. A major benefit of this file, outside the obvious value of documenting the project, is that it will serve as a historical detailed reference to future projects. The project file could consist of three divisions:

2. Estimating Major Activities. Estimating an automation project is a necessary and difficult task. The project manager should be aware of the following considerations:

The SDM is an aid for estimating in two respects; first as a checklist and second as a means of determining what must be accomplished for those activities in which the project manager lacks experience

One of the most frequently made mistakes in estimating is not looking deep enough into a major activity. A good example of this is the activity of preparing program module test data within the programming stage of system development. In many cases this activity is simply lumped in with the coding activity(s) with little consideration given to the additional time which will be required.

Not all of the major activities of the project will be performed by the project team. The project manager is also concerned with the planning and scheduling of other activities such as:

Other activities Which are necessary to include in the plan and schedule are those related to project management and administration. The omission of these activities is one of the reasons that estimates of EDP projects are often too low. It is important that these activities are clearly and visibly included in the project plan and the associated milestones.

The manager should use the SDM to identify the components of the major activities and in addition, should try to find other aids for facilitating his estimating. If such records are available, he might begin by consulting the organizationís records of previous projects to determine whether similar activities have been performed before.

3. Project Planning Constraints. Based on the major constraints of the project, the project manager should fix the primary limitations for the project plan. This is in terms of a project budget, project deadline, and project staff load. With one of these fixed, the situation can be analyzed with respect to the others using the total of the estimates of the major activities. From this analysis one of three possibilities will probable occur:

In the first case, the project manager can continue with the planning. The second case, as the point implies, is marginal. Depending on the specific situation with regard to necessity, project size, results of failure to meet the primary target, etc., the project manager may decide to continue with the planning effort or return to the project definition stage. In the third case, the project must return to the project definition stage retaining the new information or be scrapped altogether.

4. Initial Project Schedule. This is the first of three levels of scheduling which the project manager must perform. The nest two levels which will be discussed are project organization, Section 8.3.3, and detailed project planning, Section 8.3.4.

Before going further, the basic concepts of all three levels should be understood. At the initial project schedule level the project manager is making plans based on activities. These activities in many instances relate directly to the activities found in the SDM; however, a major activity may include several SDM activities, or on the other hand may only be a part of the SDM activity. A major activity will also be identified as a milestone. A definition of deliverables and completion criteria should accompany all activity definitions. The next level of scheduling, the task plan, is concerned with tasks within and among activities. Each task normally results in one or more deliverable products; however, two or more tasks (two or more persons) may jointly produce a single deliverable product. The third level, in the detailed project plan, concerns forming subtasks within tasks. The subtasks result in intermediate products (not necessarily deliverable).

The project manager must now convert the activity estimates, which he previously made based upon ideal conditions, into a schedule which also reflects numbers of personnel, the project managerís judgment of unknowns, and other time consuming activities.

There are number of different methods for presenting a schedule, including narratives, bar charts, and network analyses. The project manager should choose the most suitable to his specific project.

The activity network located in the introduction to each section of the SDM provided a sequence for activities which is generally applicable to many projects. However, the project manager will have to tailor this sequence to fit his particular project.

In many instances, the SDM indicates some of the previously mentioned unknown factors which must be compensated for in the activity schedule. For example, in the activity for estimating personnel and environment requirements, the SDM indicates possible time delays which would not be considered under ideal conditions such as:

There are many adjustment factors that should be included in this level of scheduling. The project managerís past experience is one of the best sources of these factors since in addition to citing the factors, he can recall the impact which they had on other projects. The activity estimates prepared previously are now the base to which allowances for the factors are added.

Some of the more important scheduling adjustment factors to be considered are:

5. Initial Project Plan. At this point, the initial project plan is complete. It should be submitted to management and the user for approval. With this approval, work can proceed on the establishment of the project organization. If the plan is unacceptable, re-planning or the termination of the project is necessary.

The plan as a whole consists of:

This plan, when approved, is entered in the project file. It of course will be subject to modification based on the detailed project plan which is described in Section 8.3.4.

· Determine personnel requirements

· Identify resources

· Define project tasks and their contingencies

· Identify project milestones

· Assign personnel to tasks

· Set up steering committee

· Prepare project work order

1. Project Personnel Requirements. At this point the project manager has determined and documented the number of personnel needed to accomplish each activity as the result of preparing the initial project schedule. He should also by this time have formed a general idea of the skill and experience requirements of the project team members. As staffing schedule must be prepared which will show what types of personnel, how many, and what time they will be needed.

If the Chief Programmer Team approach is adopted (see the Baker and Mills references), there will be organizational consequences. This approach requires finding the persons having the special qualifications required of the chief programmer, backup programmer, and programming librarian.

Rarely will a project manager have complete freedom in selecting those individuals he would like on his team. If his requirements are not satisfied, it mat be necessary to modify the initial project schedule.

2. Other Resources. As early as possible the project manager should identify the resources other that team members which will be available to him during the project. The project manager should seek to discover potential resources by having the project team members and other personnel participate in the resource identification.

3. Task Plan Development and Contingencies. The project manager must next apply each individual to the major activities previously estimated and lay out specific tasks which result in products.

Certain planning relationships exist:

These products of a project represent the only tangible output of that project. These products are the concrete results of the activities which make up the initiate project schedule; therefore, tasks are formed around products.

4. Project Milestone Identification. The production of a product no later that a certain date is in itself a milestone. Thus, there are at least as many milestones with a project as there are deliverable products and there may be more milestones created by products which are only for internal use of the project itself. However, not all milestones have the same significance. Possible important milestones can be identified by:

5. Assign Personnel to Tasks. The personnel who have been selected for the project must be assigned specific tasks to accomplish. If in identifying tasks for specific individuals the task schedule becomes adversely affected, the project manager has selected the wrong personnel, mis-schedules the task, or assigned them incorrectly and corrective actions must be taken.

6. Steering Committee. Parallel to the task planning the steering committee should be set up. Depending on the size, complexity, and importance of the project, the steering committee may consist of only the data processing manager and a user representative or may be larger including other user representatives and special corporate representatives.

Meetings should be schedules throughout the life of the project. The first goal of the steering committee should be to review all planning documents and approve the project work order.

7. Project work Order. At this point the project manager should be able to prepare a project work order to be approved by the user and the data processing manager. While this may appear to be unneeded additional paperwork to some, in a larger organization this single document can save a considerable amount of time and energy. The reason for this is that the approved project work order represents an official statement of understanding agreeable to all parties concerned and provides the project manager with the authority to proceed with the project plans as set forth in the work order.

Throughout the iterative approval process, the project manager must maintain control of the situation. He must not forget that the final approval project work order is his responsibility to implement. When the project manager agrees to modification from either the user or higher management he is ìputting himself on the lineî for the responsibility of adhering to that modification.

1. Detailed Project Plan. A detailed plan normally consists of the following elements:

2. Detailed Plan Functions. There are typical problems associated with project management that can be at least partially solved by establishing a good detailed project plan. Some of these are as follows:

3. Detailed Plan Negotiation. During the initial project effort, the project manager stated his estimate of work hours and timing schedules for each task. Now the estimate of that individual who will execute the task is needed, The probability of the two estimates coinciding is remote; however, the difference between the two estimates can be minimized if the project manager can communicate the same base knowledge from which he formed the original task estimate to the team member.

4. Detailed Plan Commitment. The final result of the detailed project planning process must be a task definition and set of subtask work estimates for which both the project manager and team member can accept mutual responsibility. This commitment must be based upon a complete disclosure and analysis of all available information and shall remain valid until such time as this information base is substantially altered by new information.

The project manager is committed to provide the resources defined by the team member as being essential to the timely completion of the task. Should he subsequently fail to provide these resources, he will have a difficult time holding the team member to his committed estimates. Further, the project manager is committing himself to walking a supervisory tightrope; i.e., continuously applying enough pressure to ensure timely fulfillment of subtasks but not so much that he interferes with team performance. The project manager must keep in mind that his supervisory techniques must be flexible since each team member requires and responds to different variations of leadership.

There can be no question about to what a team member is committing himself at the conclusion of the task negotiation process. He must feel that he has agreed to accomplish a specific, defined task within so many hours of his time. To do so in his responsibility and his success or failure will be the basis upon which his performance will be judged.

5. Detailed Project Plan Approval. The detailed plan should be submitted to higher management, the steering committee, and the user. This serves the purpose of letting those entities know exactly what is planned and allows the opportunity for objections to the plan at the beginning of the project rather that in retrospect. If this plan is acceptable to all, there will be less likelihood of future confusion over the direction and intent of the project. By submitting the plan for approval, the project manager is committing himself to its completion.

Once the detailed plan is approved, it is installed in the project file and work can begin of the project. The plan should never be considered rigidly fixed, dead, and buried, but rather a living guidance for the day-to-day running of the project and where absolutely necessary, subject to change.

Should the plan not meet with the approval bt the concerned authorities, then re-planning back to the appropriate planning stage is in order or else the project should be scrapped. In no case should work begin under a plan that is unacceptable to any of the concerned parties.

· Data Processing Manager

· Project Manager

· Internal Auditor

· Director of the user department(s) involved [or a representative who is authorized to make decisions for the user department(s)].

· A representative of the accounting department when necessary

· To make timely decisions on such questions as the effect of automation on the user organization, changes to specifications, budget problems, user and project priorities, technical problems affecting system specifications, etc.

· To ensure that project progress is constant by reviewing project milestones for timeliness, quality, and accuracy.

· To ensure that standards are closely adhered to

· To review suggested schedule changes from the project manager and identify their impact on the whole organization.

· To provide technical application knowledge to the project when necessary

· To resolve any differences between the project team and the user which go beyond the normal project manager user relationship.

· To see that the project stays within the original objectives set for the user.

· Review the scope of data processing within the company.

· Set long term goals for the data processing department

· Set and review budgets

· Select and authorize projects internal to the data processing department, such as equipment purchases

· Select and authorize system development projects and establish priorities.

· Periodically review the departmentís progress.

1. Availability: The project manager should be available for consultation as much as possible. If this is not the case. Someone should be designated to act as his deputy.

2. Inclusiveness: The project manager should be quick to include team members in project matters when it is to their and the projectís benefit.

3. Fairness: Praise and criticism should be dealt with fairly.

4. Decisiveness: The time given to decision making should be clearly relevant to the importance of the decision.

5. Humility: Mistakes should be admitted, corrected, and forgotten.

6. Objectivity: A decision should always be based on the concrete gain to the project.

7. Patience: The team members should be allowed to work at their own pace as long as the project is not in any danger.

8. Unprejudiced Attitude: Team members should be judged on the current job done, not work done in the past.

9. Conciseness: A project manager should be quick and to the point.

10. Detachment: Care should always be taken to detach the private life from business life.

11. Motivation: Care should be taken in assignment of jobs in order to keep team members motivated.

12. Assignment of Responsibility: The project managerís appraisal of the efficiency of a team memberís work performance will largely determine the degree to which additional responsibilities will be allocated. In such cases the project manager should be very aware of four possible pitfalls:

13. Resolution of Team differences: After learning details of both sides the project manager should decide which way is the best and support it completely. In most cases a compromise is unsatisfactory because neither party will feel obligated to work any harder to make a compromise solution work.

1. Technical Authority. The project manager should be and normally is the individual on the team with the most experience and knowledge concerning the whole project problem, although other team members may have more knowledge in specialized areas. The project manager, as the principle technical authority, should determine or at least approve of the technical approaches used in the project.

2. Technical Review. The project manager should review the work that is being done and the products that are being produced. No team member should be working without the project manager understanding and approving what he is doing. At the same time, no product should be released to the user without the review and approval of the project manager. One way to do this and also to ensure that the project team is kept up to date on all technical areas of the project is to have biweekly or monthly design review meetings.

3. Technical Revision. Unfortunately the case will occasionally arise when a product must be redone. In this case the project manager has three options:

The first option should not be used unless absolutely necessary. The second option is the preferable one because it has the least negative effect on the team members, but may take more of the project managerís time as it may end up being redone more than once. The third option should be avoided unless the original author requests the task be given to someone else.

4. User Interface. Although the project leader has developed a technically sound system, it is often very difficult for the user to understand the documentation he sees concerning the project. The reasons for this are:

It is for these reasons that the user should be kept involved and informed on various technical decisions which affect the application. This is especially true when a previously agreed upon solution is found to be technically not feasible. There are a number of ways to avoid possible confusion by the user. These are:

1. Measuring Progress. Measuring progress is made easier by a detailed plan. The tasks have a planned start date and a planned amount of time to be expended. The team member will provide weekly figures of the time spent on each subtask and an estimate of how much time is needed to complete each subtask. The task progress is measured from the actual start date but comparisons will be made to the planned start date to determine relative progress.

The total of the subtasks is analyzed to get a measure of the task progress and, in turn, the project progress. In addition, progress should be measured on the basis of completed, acceptable deliverables.

2. Time Accounting. For the purpose of evaluating true performance and progress the organization or project manager must set clear standards as to what is reported for the time worked. In all project organizations there can be a number of factors which affect project progress. They are:

Although many of these factors should have been included in the planning function, invariably there may not have been sufficient time allotted. It is important then that the project manager requires strict and accurate time reporting so all factors which are affecting progress can be analyzed.

3. Maintaining Direction. During the life of the project it is often very easy for individuals to vary from the predetermined direction of the project. The project manager must be aware of this and be able to assure that every member of the project is pursuing the specific goal of the project.

In conjunction with maintaining the direction of the project, the project manager must constantly coordinate the various efforts of the team. To do this he must always be aware of how the various pieces of the project fit together and must know how the activities of one individual will affect another.

4. Maintaining Schedules. It is very important that all schedules be met. The schedule of each task becomes important, as the overall project schedule is a composite of these. Sometimes no matter what steps are taken the projects get off schedule. If this happens, a new project plan must be produced, reflecting the areal situation. The project plan should be changed by the project manager, but only with the approval of all interested parties, such as the steering committee.

5. Progress Recording. One factor which is often overlooked is the accurate recording of events which have affected the project. As an example, management may force the project manager to make some ìsimpleî changes to the system which turn out to be much more difficult that originally conceived. The effect on the project plan may be disastrous. The recording of these events becomes the project summary and history and by having noted them when they occurred, there will be no problem in recalling them at a later time.

Another factor often overlooked is the problem of accounting for rework. Rework often indicated that the task was not properly completed and failure to account for it overstates progress.

1. Quality Achievement. Quality products are not produced by accident. They are the result of careful planning and analysis or, in the absence of these, the results of much extra work.

In producing a quality product it is critical to have a thorough understanding of the problem to be solved. Ample time spent understanding a problem pays large dividends when it comes time to actually solve the problem

Good documentation is one of the keys to quality products. Too often documentation is product only to meet a userís requirements, and even then it is produced after the product has been completed. The purpose of documentation is not only to tell what was done, but to tell what is to be done. The reasons for making major design decisions are also documented as these reasons are often forgotten.. After the implementation is completed, the documentation should provide a usable guide to anyone attempting to maintain, modify, or add to the product. It should also provide a useful summary of the techniques used in solving the problem so that others faced with similar problems can draw on the experience gained in solving the problem.

2. Quality Maintenance. So far, quality has been discussed as if it were always concerned with products being developed from an initial requirement. Once the product is developed, though, it must be maintained, and that presents a different type of quality control problem. The objectives of maintenance are to correct any errors and make any necessary modifications without introducing new errors.

Maintenance is much easier when the original products have been designed and documented properly. Proper analysis and documentation are equally important during maintenance. The effects of any change should be thoroughly studied before the change is adopted, and the documentation should be revised to reflect changes made. This aspect of maintenance is too often neglected with the result that the documentation soon becomes meaningless.

3. Quality Assurance. Quality assurance procedures are not self-enforcing, they must be applied by individuals. Upper management is responsible for maintaining a staff capable of producing the required work, supporting that staff, and stimulating lower levels of management to produce quality products. The lower levels of management (project managers) are responsible for enforcing the standards and procedures which produce quality. It is the daily efforts of the project manager that will be reflected in the quality of the final product.

There should be a quality assurance program which would include design walk-throughs, code inspections, project audits, etc.

4. The Cost of Quality. While it is difficult to calculate the cost in instituting quality assurance procedures, it is not so difficult to estimate the cost of not instituting such procedures. What is the cost of a defective or unacceptable final product? What is the cost in morale when a job is made mindlessly difficult? Above all, what is thew cost of redoing a job when the user is not satisfied with the product? Improving quality, therefore, can be a means of lowering the total cost of development.

· Personnel administration

· Training requirements

· Communications

· Coordination with the user

1. Personnel Administration. In the day-to-day execution of a project plan it becomes increasingly evident that a major ingredient to a successfully functioning team is the way the project manager handles his people. There are a number of factors both in a group level and on an individual level which when exercised by the project manager can contribute to the success of the project.

2. Training Requirements. One of the major administrative functions of the project manager is to train the individuals on the project team.

Training can be conducted formally (courses, lectures, schools, etc.) or informally (home study, on the job). Informal training occurs continuously and allows a worker to grow in skill while actually performing a job which makes it an integral part of the project effort. This training function must be recognized by the project manager and a conscious effort made to fulfill this requirement on a daily basis. The type of material suitable for informal training includes standard, procedures, technical matters, and practical disciplines.

A dual purpose method is the training of one member by another more experienced team member. The more experienced team member gains experience in training and directly managing the work of the less experienced person. This enables the experienced person to develop his own leadership capabilities. The trainee can gain by being directed by a person who is in close daily contact with him.

3. Communications. Successful communications is one of the most difficult areas of human activity and one of the most important. Failure to communicate information has often been one of the causes of project failures or costly overruns in time and manpower. These are two distinguishable types of communication failures that need to be emphasized:

Some of the sources of the failure in understanding are:

All too often vital information is not communicated at all or is not available when it is needed in a usable form. Some reasons that such vital information is not communicated are:

The following are methods used to improve communications"

4. Coordination with the User. It is important to the project manager to retain an open line of communication with the user. One method of doing this (the steering committee) was discussed in section 8.4.1. However, at some points in the project, progress tasks may be assigned tom user personnel. Since the project manager still has ultimate responsibility for the project, he must coordinate these efforts also. An example of this is during system acceptance test. It is important that the project manager and an appropriate line manager retain close formal contact on the progress of both efforts. Generally this can be accomplished by short weekly status meetings highlighting accomplishments and potential bottlenecks.

The importance of good relations with the user during the course of a project cannot be overemphasized. User relations are not just a problem for the project manager but rather must be born in mind with all the other project managerís responsibilities. He must ensure that his personnel thoroughly understand the environment in which they are working to preclude their creating problems which the project manager must then solve.

It is essential that the project manager establish a good working relationship with the userís representatives. It is usually a matter of demonstrating that the project manager intends to concentrate on assisting the user in achieving his organizational goals. The project manager must be able to show the user how the project will improve the work of the userís organization. He may have to directly confront the threat felt by a user who is being introduced to automation. What the project manager is trying to achieve is an environment in which he and his counterpart can frankly discuss technical problems without either party being on the defensive. Involvement in internal political problems within the user organization should be avoided.

Project personnel must always demonstrate a positive attitude. This is applicable to the work to be done by them as well as that being done by the user. To appear negative about any aspect of the userís situation will be interpreted by him to be criticism. It implies that he has created the situation through his own mistakes. The project manager will rarely have even a partial understanding of how a user arrived in his situation; therefore, it is much safer to concentrate on ways to improve it along the lines desired by the user and to do it in a positive way.

The project manager must control all demands made on the time of user personnel to assure himself and the user that these demands are justified. All significant demands should go from the project manager to the user manager.

Any information given in confidence must not be disseminated. The user will be more open and frank with the project manager when he knows that the project manager will not repeat the confidential remarks to other persons.

1. Final documentation. The importance of adequate and proper final project documentation has been previously discussed. The key to timely and good final documentation is an early start ñ at the beginning of the project. Prior to commencing final assembly and reproduction:

2. Final Presentation. Upon delivery of the final product, and informal presentation should be made to the userís staff which will provide them with a basic, overall understanding of the product. An introductory explanation of the documentation package, and each type of document, should be provided. Any questions or comments from user staff should be cleared up and corrective action immediately executed.

3. Operation Turnover. The results of a project may be the completion of a system. The turnover to operations personnel (where applicable) is reasonably straightforward and should require little effort. It requires that a few members of the project team sit down and review the operating requirements/instructions with the operations staff to ensure their ability to interpret it. Having done this, a production test (i.e., an actual production run under very close supervision/control) should be walked through with customer personnel to check all aspects of the actual operation and procedural instructions. The familiarization of the operations staff with the system should have been started long before this final test.

4. Maintenance Support. If a system is ready for maintenance, the project manager and the user should set up a procedure for post turnover support. Although the system has been carefully turned over to the user, during the initial startup period, he will still have problems with it. Agreement should be reached as to the level of support which can be expected by the user when either procedural or technical problems arise. The function of supporting the user is probably best placed with the person(s) who is performing the program maintenance for the system.

1. Project Work Order Analysis. One of the initial steps in the project was to create the project work order. Some of the basic questions which are of significance are:

2. Project Plan Analysis. The Initial Project Plan dictated the management and technical approach to the project. Following this came the Detailed Plan negotiation with the team members. Below are some additional questions which should be answered in regard to the overall project plan.

3. User Relations Review. Good user relations are sometimes as important as good technical products.

4. Product Quality. All of the products developed by the project should be reviewed for their technical quality. These products include analysis and design documentation, user manuals, programs, etc.

5. Standard Techniques and Procedures. The project used a number of standards, and these should be reviewed so that any necessary conditions, additions, or deletions can be made to these tools which assist project performance. Items to be reviewed should include:

6. Post Mortem Reports. Within a specific period after the delivery of the final product, the project manager should submit a report to his management. This report should answer all the questions above as objectively as possible. The purpose of the report is not to fault anybody, but rather in intended as a constructive basis on which performance can be improved. The project manager may wish to comment on the adequacy of the support (technical, managerial, psychological, etc.) that he felt he received. In this report, the project manager is called upon to certify that he has completed all project termination requirements as outlined in this section.

· Contains copies of all reports and correspondence.

· Contains copies of all progress reports.

· Is in chronological order.

· Includes a copy of, or cross reference to, the original project work order and any amendments thereto.

· Contains a complete copy of all project planning and control documents.

· Contains copies of all working papers and supporting documentation.

· Contains a copy of the final product.

· Contains a copy of the post mortem report.

Pred = Predecessor Event - Two alphabetic followed by three numeric

Succ = Successor Event - Two alphabetic followed by three numeric

Dur = Duration - In man days

Resp = Responsible Person/Organization(s)

Description: Short but meaningful

Schedule: Schedule Day Completed

Actual: Actual Day Completed

Inter: = Interfact to another net

Milestone: Completion represents a milestone

NOTE: Pred/Scc event numbers are made of Subnet ID plus three digit number. The end of the Subnet is always 999