This stage is often conducted in iterations where the initial execution would take the form of a preliminary investigation to provide management and the user with broad statements as to the scope of the system as a whole, and a gross approximation of the feasibility of undertaking the effort. This is especially true for large systems where the complete definition study is too large an effort to be undertaken until management and the user have a gross estimate of resources required and some assurance that the system, as a whole, is feasible. If such a preliminary investigation is conducted, care must be taken to ensure that the complete definition study is not avoided, or that critical portions of it are slighted. As a major result, the preliminary investigation would produce an examination of the feasibility of conducting a more detailed study.

The initiation of a definition study, or the preliminary investigation to this study, may occur in several ways:

· The issuance of a request for a proposal by the user

· A management directive to conduct a definition study

· A direct statement of a requirement, problem, or need by the user

· Identification of a problem by an analyst

· A predetermined step in an overall company plan for system development

The initiation of the study occurs after a problem has been identified. It may only be the result of an idea that the application of computerized data processing to a company operation might solve a problem, affect economics, provide new management techniques, or deliver other desirable benefits. In most cases, the total problem is usually not sufficiently defined in advance of the initiation of the study. In fact, the formulation of a problem statement itself may be complex and technical. For this reason, the first activity of a study consists of defining the problem, formulating the problem statement and establishing the scope of the study. It is not unusual, while considering the initial problem, to uncover new and more severe problems of which the originators are not aware. A management decision may then be required after completion of the first activity of the definition study.

The products of a study are the Definition Study report and supporting documents. This report will provide management with concise information (i.e., system needs, cost estimates, schedules, alternative solutions, advantages, and disadvantages) necessary to make the judgment either to continue or discontinue the system development effort. This report and supporting documents will also provide the system concept and basic requirements data for starting a preliminary system design. The results of this study will outline what is known about the system characteristics in terms of cost, time, speed, quality, hardware, personnel, media, facilities, required features, etc.

The standard activities included in the definition study stage are to:

· Define the problem and establish the study scope (1.1)

· Collect data on existing methods and procedures (1.2)

· Analyze existing methods and procedures (1.3)

· Develop system objectives and set performance criteria (1.4)

· Determine resources, constraints, assumptions, and items for resolution (1.5)

· Analyze system outputs inputs, and major functions (1.6)

· Determine system capability requirements and potential approaches (1.7)

· Evaluate and select system approach (1.8)

· Determine the types and magnitude of expected implementation and conversion requirements (1.9)

· Prepare an overall plan and cost/benefits analysis of the proposed system (1.10)

· Produce the Definition Study report (1.11)

All the SDM activities and resulting products may not apply to a particular study. This is because the activities described in the SDM are described in general terms in order to fit all system efforts. To determine which activities are mandatory, the objectives of the study must be correlated with the SDM activities. This process is performed during the first activity of a definition study while defining the study scope. During this process, the activities and products cited by the SDM are converted into specific terms that are directly applicable to the study. Combining of several SDM activities, or deletion of some, may be indicated. If a preliminary investigation is being performed, all activities should be conducted in a cursory manner, producing high level and summary results. All products in this case (especially cost/benefits) must be approached with caution as they are likely to change drastically as a result of the complete Definition Study.

The standard products produced by the Definition Study are:

· Problem statement and background

· Definition Study scope

· Facts on the organization

· Collected information on existing system

· Documented meetings

· Documented analysis of existing methods and procedures

· System objectives

· System performance criteria

· System resources

· System constraints

· Assumptions

· Items for resolution

· Preliminary system output and input descriptions

· Data element descriptions

· Data group classifications

· Data group activity relationships

· Major system functions

· Functional specifications

· System capability requirements

· Alternative system configuration charts

· Alternate system Approach summaries

· System approach recommendation

· Selected system approach

· Supporting documents covering selection process

· Data conversion and system implementation requirements

· System acceptance criteria

· Overall system plans and schedules

· Cost/benefits analysis

· Definition Study Report

1.4 1.10

1.5

1.1 Define the problem and establish study scope

1.2 Collect data on existing methods and procedures

1.3 Analyze existing methods and procedures

1.4 Develop system objectives and set performance criteria

1.5 Determine resources, constraints, assumptions, and items for resolution

1.6 Specify system outputs, inputs, and functions

1.7 Determine system capability requirements and potential approaches

1.8 Evaluate and select the system approach

1.9 Determine implementation, conversion, and acceptance requirements

1.10 Prepare overall plan and cost/benefits analysis of the proposed system

1.11 Produce the Definition Study report

A Definition Study is usually initiated by a document that either does not identify the real problem or insufficiently defines it. At the start of the study effort, it is frequently unclear as to who should conduct the study, what resources are required in order to accomplish the study itself, and what probable size and cost parameters apply to possible solutions.

Initially, management will require that one or more persons should analyze the problem and prepare a document which will indicate what the study itself will involve, and how it will be conducted. For small system studies, this may be a very restricted effort, whereas large studied may involve many people over a period of time extending beyond a year. In the case of large scale studies, management will want to know what resources will be required.

Definition and formulation of the problem statement itself may require considerable time and effort because the initial problem statement may involve the following conditions:

· It may reflect a real, though vague need

· It may be prepared by persons with specialized concerns who are not able to clearly state the problem to non-specialists

· It may reflect symptoms of more basic underlying difficulties of which the statement originators are unaware

· It may be excessively restrictive and the stated problem may form only a small portion of a larger problem

· It may be so worded as to imply that there is some specific solution, rather than clarifying the problem without biasing the possible effective solutions

The importance of clearly delineating the problem cannot be overemphasized; a faulty understanding of the problem will misguide the study efforts and result in a system which is designated to solve something other that the real problem. An agreed and clearly stated understanding of the problem will enable a common interpretation to be maintained from the outset and through the development and implementation stages.

The definition of the problem and its clarification, as well as the delineation of the scope of the study, will be an iterative process. If the personnel responsible cannot present the problem and the study scope clearly, then the study should not be undertaken; a vague beginning will lead to a vague and unsatisfactory ending. It is especially important that the resources required should be understood by all and that responsibilities be specifically assigned.

The scope of the study efforts should include:

· The objectives

· The authority of the study and the liaison required with sections of the organization

· The restrictions placed upon the study by management (seldom is the study not subject to restrictions)

· The manpower and skills required

· The composition of the team at the top level

· The specific study milestones and the dates by which they are to be accomplished

· The format and content of the final report to be presented to the team

· Any specialized or unusual techniques to be used

· Any computer time or other resources that may be required

It is important that all concerned should have a well-defined understanding as to what they are trying to accomplish. For this reason, the objectives of the study should be presented as clearly as possible; advantages will be that:

· Management will understand what they wish to accomplish

· The study team will have a well-defined set of goals

· There will be a framework for evaluating the final outcome

The authority of the study team must be clearly delineated. The extent of the authority will, in part, reflect management’s evaluation of the importance of the study effort. This authority will be related to the ability of the study team to:

· Require the time and cooperation of personnel who are information sources.

· Request and receive copies of relevant documentation,

· Observe actual operation of existing methods and procedures in an operational environment.

If certain areas must be excluded from the study, these exclusions must be clearly stated from the outset. The person responsible for stating the scope of the study should make clear to management the potential impact of restrictions placed by management on the study. The restrictions may include:

· Numbers and skills of personnel

· Time in which to make the study

· Limits or permissible contracts or requirements placed by the study team on organizational elements

· Limits on solutions to be considered

· Related problems not under consideration

The type of skills and number of people required should be specified as explicitly as possible for full and part time team members. Certain types of studies may require unique knowledge of certain aspects of the company organization and practices that can be provided only by highly experienced and able personnel who are critically needed elsewhere. These personnel should be specified by name if possible. Certain specialized analytical skills may also be required, such as statistical expertise. or knowledge of the capabilities of specialized equipment.

In all cases, the team members must be capable of performing the study in a thorough and professional manner. A second-rate study team will lead to a second-rate study.

For major studies, the top personnel of the team must have significant positions within the organization. A good analyst is not sufficient for a major study. In many cases, the most obvious candidate is not suitable because other commitments will leave him only partly involved, or may bias his leadership to a predetermined set of results. The responsibility for the quality of the study must be specifically assigned.

The study should have a set of milestones and definite dates for accomplishment. If these are not set, then a last minute "crash" effort is probable, with degradation of the final product. These milestones should take the form of activity products which can be reviewed, as well as the items to be produced. Certain large studies may require a more detailed level of milestones that are provided for in this manual. For example, if several existing systems are to be analyzed prior to consideration of a combined system, there may be milestones for gathering the data on the existing system and a separate milestone for each system.

The format and content of the final report should be clear to all concerned. Where it varies from the outline provided by this manual, the variations and related reasons should be clearly defined.

If any special or unusual techniques are to be used during the study, the techniques and reasons for their use must be specified.

All significant resources that may be required during the study must be identified and their availability determined.

Determining what must be done in a large definition study is probably the most difficult of all phases of system development. The user himself is not usually able to state his requirements and their relative importance quite specifically and this is the point at which the SDM is very helpful as a project planning guide. In order to clarify how the SDM can best be used to determine what must be accomplished, a test case will be presented. The problem chosen is the automation of a Project Monitoring System (PMS); the project having been initiated by management directive (see Exhibit 1.1-A). The problem is stated as follows:

1. Conduct interviews with the originators of the problem in an attempt to evolve a clear and mutually acceptable statement (see Exhibit 1.1-B).

2. Analyze the problem, not only for clarity of statement and the immediate implications, but also as regards the history of how the situation arose.

3. Extend the problem analysis to investigate any directly related or associated problems that became apparent during problem investigation.

4. Iterate the steps until an agreed statement of the nature and history of the problem is arrived at, together with a statement of any uncovered, related problems.

5. Develop a statement of any restrictions applicable to the study (see Exhibit 1.1-C).

6. Determine composition of the study team, including the team leader and all key personnel, with the definition of the authority and responsibility of the team and its members (see Exhibit 1.1-D).

7. State and justify any special methods that may be required.

8. Develop the study milestones and schedules (see Exhibit 1.1-E). This is a good example of how the SDM can be used to assist in identifying what activities will be required.

9. Prepare the objectives of the study.

10. Agree to the format and content of the study report.

11. Present the documents comprising the full definition of the study scope to management and originators for review.

12. Repeat the above steps until either the scope and the problem re-definition are approved or the study efforts abandoned.

13. Use the relevant documents as a basis for the creation of the Project File.

MEMORANDUM

TO: Director of Automation Department

FROM: John Doe

SUBJECT: Definition Study for the Automation of Project monitoring

Referring to our meeting of 15 December, concerning the automation of project monitoring, it is our desire that your department prepare a plan of action for accomplishing a definition Study. The only guidelines which can be given at this time are in reference to time and the general objectives which we discussed at the meeting. These items were as follows:

· Out planning includes a decision on the feasibility of this system by the end of May.

· The resulting system must supply reports which are applicable to three levels of management; the project manager, the bureau chief and the department director.

· The system must be capable of reporting the following information:

- Manpower performance

- Project status (actual versus planned)

- Projected completion times

- Translation of hours and resources into cost

- Staffing summary

- Labor distribution

· This system must include on-line capability for the following purposes:

- To serve as a training mechanism for the development of in-house teleprocessing expertise

- To provide instant response concerning the status of critical projects and personnel

1. The project manager shall have direct access to the Director in the event of unresolved difficulties.

2. The study team will be allowed to interview any member of the company after two days’ notice to the supervisor affected.

3. All documents requested by the study team will be provided within one week (if existing documents).

1. The study team shall not use more than three full-time analysts in addition to the project manager.

2. A full-time typist will be assigned to the project for its duration.

3. The study shall be performed only by company personnel.

4. The study efforts shall be limited to less that 50 man-weeks.

1. The study must be complete by the beginning of May in order that a decision on the feasibility of this system can be made by the end of May.

2. The period of performance for this study will be from 8 February to 30 April.

1. Three meeting have been scheduled to discuss this project with all user project managers, bureau chiefs and the department manager. It is expected that these meetings will take about half a day each, scheduled for 10 March,11 March and 19 March.

2. Mr. Smith has been assigned by the Director as the primary contact for the project. Except for the meetings mentioned above, all communications will be directed through him; he is responsible for approval of all products.

1. The results of the Definition Study shall include detailed system objectives to indicate how the system will benefit each level of staff involved. Acceptance of the proposed system by all persons concerned is a critical factor.

1. The personnel to operate the system must come from within the Company without additional hiring.

2. Organizational changes beyond sub-department level will not be considered.

1. Mr. Jones, our staff specialist on software packages, has agreed to obtain literature on project monitoring packages. This information is expected from him by 8 March.

(To be supplied.)

A list of major tasks follows:

1. Project management and coordination. This is an on-going activity which includes the normal functions of a project manager such as preparing status reports, liaison, project direction, etc. However, for this particular project, the project manager will also be responsible for certain definition study products. This is estimated to be acceptable due to the relatively small number of people who will be required.

2. Extended problem description. While everyone working on the project will participate in this activity to some degree, it will be performed primarily by the project manager. Included are the following:

· Continuation of the problem description as stated in the work order

· Determination of assumptions and items for resolution

· Determination and evaluation of resources and constraints

· Cost analysis of the current and proposed system

3. Analyze existing methods and procedures. Although the existing project monitoring system is relatively simple and an automated system does not exist, it is anticipated that the effort required here will be relatively significant.

4. Develop system objectives. Dependent upon the previous activity, this will identify detailed objectives of the system. Wherever possible, these objectives will be stated in measurable terms. Objectives such as improving employee morale and assisting career development will be investigated for the purpose of making the system acceptable to all levels of staff. Special attention is required for the objectives associated with on-line processing as this area is new to the organization and will serve as a test case.

5. Establish system outputs and inputs. The outputs required to satisfy the system objectives will be identified in this activity together with the necessary inputs. The most significant problem here will be relating the normal project methods of planning and controlling to the input procedures required by the system. On-line inquiry processing will, of course, create special input/output considerations. A balance between ease of use of the system and system capabilities is a critical factor in this activity. This activity calls foe a level which will enable realistic estimated to be prepared for conversion and implementation requirements shown in Activity 8.

6. Estimate system functions and recommended approach. The major system functions will be estimated with alternative approaches for satisfying these functions; and finally, a recommended approach will be given. Included in the alternative approaches will be an investigation of existing off-the-shelf packages which might be used. Also included in the alternatives will be the degrees of capability that can be provided and the user implications for each. It is hoped that an agreement can be reached with the user on a recommended approach within a reasonable amount of time. Identified with the recommended approach will be the acceptance criteria for that particular approach.

7. Prepare plan for system effort and determine implementation and conversion requirements. It is expected that enough information will have been gathered at this point for the preparation of a Project Work Order for the accomplishment of Preliminary Design. The remain stages of development will be estimated in more general terms. Estimated cost and time frame for the development of the total system will be given. Also included will be an estimate of the implementation and conversion requirements based on the output from Activity 5.

8. Complete Definition Report. This will be a summary of the previous activities, highlighting the significant factors. The products produced earlier will be attached to the report for reference.

(To be supplied.)

There are numerous ways of determining objectives; one being to ask management officials what they are trying to accomplish, what decisions they are faced with, how they measure performance, and what information they must have to control operations.

Lacking any other method of determining system objectives, the usual approach is to start with the existing information structure and to modify it to meet known deficiencies and foreseeable requirements. In order to accomplish this, existing user methods and procedures must be carefully analyzed. This may cause unwanted disruption within the user organization and generate unwarranted concern among the user personnel. In order to counteract this tendency, it is important to fully inform the concerned parties of exactly what is to be accomplished by the study. The user personnel should not feel threatened by the conducting of the study and by the impending system development.

The purpose of the activity is to gather information on the existing methods and procedures. The information is concerned with:

· Objectives of the existing system

· Output the system produces

· Input provided

· Data retained within the existing system

· Processing required to produce the output from the input

· Organization performing the processing

· Policies under which the system operates

· Quality of the output produced

· Suggestions made for improvement to the system

· Existing problem areas in the system

· Evaluation of cost and relative benefits of the existing system

The level of detail to which this activity must be carried is, of course, highly dependent on the size and complexity of the proposed system, and dependent on the level of knowledge of the analysts concerning the particular system or similar systems. It may be that most of the data is already known or is easily obtainable; in which case, referencing or documenting those data is all that is required or, in the other extreme case, an exhausting and lengthy effort may be required to gather or create the appropriate data. The level of detail is also determined by whether or not there is to be one Definition Study or iterations, starting with the preliminary investigation.

The existing procedures can be mechanized, be clerical, or be a combination of both. Besides the steps which constitute the procedure, the systems analyst is also interested in quantitative data, such as:

· What are the volumes of transactions

· How long does it take to prepare a particular source document

· What data are required for the procedure

He needs frequency distribution information of all transactions, the numbers of individual types, the frequency of need for the procedure, and the frequency with which the alternative procedure is used. A description of all exceptions, as well as normal processing, must be known. Here again, volume information concerning exceptions is important, as there is obviously a world of difference between an exception occurring once in a thousand cases and one occurring once in ten cases. the scheduling of input and output is required (when source documents will be available for processing, when reports must be prepared). Work flow information (how smooth it is, and where it peaks), and any legal or other requirements that are imposed on the system from without are other considerations.

Process charts for the existing mechanized procedures probably exist. Consequently, in order to understand the mechanized aspect of the procedure, little more needs to be done that to acquire and to study these charts to ascertain the process involved. The systems analyst needs to determine from key people within the organization whether the charts are up-to-date, and, if not, how they can be updated, In addition, the data content of mechanized files is essential to the description of the mechanized process.

It is possible that a clerical procedure is as completely documented as a mechanical one. However, in many cases documentation of clerical procedures is rudimentary, if it exists at all. In these cases, the procedures and the task description of the people involved exist only in the minds of men who are involved with the procedures, either from the operating or supervisory viewpoint. In such cases the procedures must be documented; aspects pertinent to this documentation are: type of equipment, forms, and work aids used by the clerical force.

As regards any procedural step, it is useful to know:

· The quantity of work being performed; that is, how many units of work go through this step in a meaningful period of time? For example, how many invoices does the billing department handle each week.

· The time required; that is, how long does it take to perform this step on one unit? How long does it take to extend the invoice?

· The data required to execute the procedure.

1. Hold the briefing with the personnel potentially affected to explain the purpose of the study and to enlist their support.

2. Prepare and disseminate a brief sheet describing the study.

3. Collect any small or large scale studies that have been previously prepared on the system or any part of it.

4. Gather facts about the organization (s), procedures, forms, volume or workload during normal and peak periods, individual assignments and workloads and equipment availability and suitability. Sketches and flow diagrams will be prepared to illustrate the flow of information and work. All facts will be entered into the project file.

5. Observe existing operation processing and interview personnel, using questions previously designed and organized, and record the information gathered.

6. Collect all written documentation concerning existing systems, being sure to verify the accuracy of the documentation.

7. Determine any statistical sampling methods that will be used.

8. Collect samples of all data files.

9. Collect samples of all outputs, being careful to site destinations and general usage of the outputs.

10. Collect samples of all inputs, citing all sources and relating the inputs to the outputs to which they contribute. Note the relative difficulty of obtaining the particular input information.

11. Give particular emphasis to collecting data on errors, time delays, and their sources.

12. Seek information concerning both present problem areas and known future problems; e.g., whether the present number of people will be able to handle the expected growth. There may be major problems other than those initiating the study.

13. Conduct interviews and meetings to clarify the existing process and document the results pertinent to the definition study.

14. No less than once a day, record the facts gathered and enter them in the project file. It may be found that charts can facilitate recording the facts. Systematically recorded facts will make the subsequent analysis much more effective.

· Facts of the organization

· Collected information on existing systems (see Exhibits 1.2-A - 1.2-D)

· Documented meetings (see Exhibit 1.2-E)

· Information on existing systems

· Problem statement and background (1.1)

· Definition Study scope (1.1)

1. Identify the specific departments or sections to be examined.

2. Identify the functional groups within the departments or sections.

3. Define the functions of these groups.

4. Identify the initiating (trigger) transactions which address the functional groups.

5. Collect existing statistical information concerning the initiating transactions.

6. Identify all associated and generated transactions relating to the initiating transactions.

7. Fix statistics to the associated and generated transactions when direct relationships exist.

8. Identify transactions to which statistics cannot be fixed.

9. Conduct transaction sampling, if necessary, to establish unavailable statistics or to verify the accuracy of statistics which are available.

10. Complete the transaction picture for the department or section examined.

11. Locate and specify all files and other resident data within the concerned department or sections.

12. Develop correlation figures and methods for remaining departments or sections, where possible.

13. Extrapolate statistics to other departments or sections, where possible.

· Average number of "live" projects 17

· Average number of new projects per month 1.3

· Average number of finished projects per month 1.1

· Number of employees to be covered under a new Project Management system 123

· Average employee growth percent per year 10%

· Number of employee classifications 9

· Number of departments concerned 4

· Number of project information reporting levels 3

· Number of project reports per month 2

· Average delay in determining the status of a particular project or demand 2 days

· Percent of projects experiencing overruns 65%

· Average percent overrun per project 23%

· Average time to process a billing action 2 weeks

· Percent unassigned employees (average) 10%

· Percent unassigned tasks (average) 4%

(To be supplied)

(To be supplied)

The resume’ places the results of the meeting in a form that can be used by attendees and others for reference. Verbal discussions are subject to misunderstandings and to being forgotten if not recorded immediately.

A transcription of all that was said is neither feasible nor desirable; only major points should be briefly covered.

1. Schedule and actual meeting dates.

2. Attendees All who are scheduled to attend should be listed by name, organization, and telephone number, for use as a checklist to ensure that they have been notified.

Those actually attending should be noted as being present. If an alternative representative is sent, this should be noted. If others attend who were not scheduled to do so, they should be entered.

3. Distribution The distribution of the resume’ can be limited to scheduled or actual attendees, or to include others.

4. Purpose of the meeting Prior to the meeting, notification of the scheduled attendees should include a statement of all major points to be covered in the meeting. These should be numbered consecutively and be brief but descriptive.

5. Attachments Attachments may be sent to prospective attendees for background material prior to the meeting.

6. Meeting events Each of the items noted under "purpose of the meeting" should be covered. If not discussed, the reason should be listed. If conclusions are reached, these should be clearly worded and supported.

Any additional items arising during the course of the meeting should be listed and described.

Documents produced by the meeting, such as signed contracts, approved schedules, or other agreements should be listed.

7. Next meeting The date, time and location of the next meeting should be listed together with any already determined topics for the meeting.

8. Follow-up action Any follow-up actions should not only list the desired actions, but who is to take action and by what date.

If an existing system is being used, it will be necessary to evaluate the associated methods and procedures for defining the problem in terms of requirements of and constraints on the proposed system. This does not necessarily mean that the requirements and constraints will be based completely on those of the existing system; a new concept may be better. If, during this study of the existing system, inadequacies are discovered that are masking a much larger problem, a re-definition of the problem may be necessary. For instance, the problem under study may only be a symptom, not the real problem. The scope of this activity may range from the complete study of a total organization in the development of an integrated system, to one very specific aspect of a limited system. This activity is interleaved with activity 1.2; Collect Data on Existing Methods and Procedures. The amount of analysis required here is dependent (as with 1.2) on the size and complexity of the system and on the degree of knowledge about it.

1. After fact gathering has been completed, the findings are discussed with management before beginning the analysis.

2. In analyzing the collected facts, each step of each procedure used in a process must be challenged; why it is performed and why it is required. All outputs must be evaluated in terms of their design and preparation, as well as whether the information is necessary, or whether the same information is a by-product of another process.

3. Following the analysis of the facts, review and, if necessary, refine the problem’s original definition.

4. Conduct interviews to expand the view of the system and to clarify confusing issues.

5. List all existing equipment with operating characteristics and present use.

6. Critically evaluate input form, file, and report samples.

7. Determine destinations and origins in terms of:

· User activities receiving the outputs

· Media parameters

· Physical and/or geographical location of the users

· Organizational structure

8. Flowchart the system data flow from input acquisition through processing and eventual output.

9. Carefully analyze all errors as to type, source and impact, using statistical tools, if appropriate.

10. Analyze all problems both present and predicted that have been uncovered in the collection activity.

11. Write a narrative description of the present system.

12. Develop operating and data flow statistics, including volumes and frequencies.

13. Develop a detailed cost view of existing system, including manpower, equipment, and loss due to error or time lags.

14. Assemble the information collected above into one document: Existing Methods and Procedures.

* List of existing equipment

* System data flowchart

* System narrative description

* System cost view

* Existing reports analysis

* Existing forms analysis

* Manual data analysis

* Procedures analysis

* Output analysis

· Revised problem statement and background (1.1)

· Definition Study scope (1.1)

· Collect information on existing system (1.2)

Project Status Report

· Project status including scheduled hours vs. hours spent

· Employees status including scheduled hours vs. hours spent

· Actual and projected project over or underrun

Every two weeks

Project status Form - F.102. This form is not considered necessary, especially if the system is automated.

4 copies x 17 projects x 3 pages per project

1-1/2 week lag between cutoff date for source information and distribution of the reports.

Current two weeks and cumulative-to-date

Project Schedule From the Project Plan

Project Time Expenditure From the Employee Time sheet

Prepared by hand each two weeks by the Project Manager based on the Project Plan and employee Time Sheets.

3 hours x 17 pages = 51 man-hours Project Manager time every 2 weeks + correction time.

1 copy to Project File

1 copy to Dept. Manager

1 copy to Accounting

1 copy to user

· Report project status to the user and management

· Indicate staffing requirements

· Report time for billing to accounting

· Indicate trouble areas

None

An average of 25% of the projects show errors in reporting status. This wastes considerable time and effort on the part of the Project Managers and upper management.

The report serves its function in the areas of staffing requirements and billing accounting. The function related to status reporting and trouble indicating are not served because the reports are too out of date and erroneous for timely action. In addition, the information reported is not sufficient but this is all that can be reasonably provided with a manual system.

All reports are retained for the life of the project in the project file. On project termination the last report is retained as history and the others discarded.

None - other that corrections by the Project Manager

Project Manager

The report serves several functions that are absolutely required such as associated with accounting; however, it falls far short of the requirements for good project planning and control and the requirements for adequate status information for management. It is felt that the cost of producing this reports not worth the benefits derived in the current environment.

The report should be completely modified as well as the whole reporting procedure to remove the deficiencies noted. The report cannot be disposed of completely due to accounting requirements but could be reduced in scope to only an accounting instrument prepared once per month or expanded in scope to provide adequate and timely project management information. It is felt that more and better information is needed, not less.

In this activity, the user’s needs are translated into clear objectives ( requirements) to be satisfied by an operational system. The problem statement and the existing methods and procedures must be reviewed and system objectives developed. These objectives should be identified in sufficient detail for enabling a measurable level of performance to be prescribed for the system design. The objectives are generally a statement of the prime results the system is to accomplish. Attendant results, resources, and constraints are important and discussed in subsequent activities. /without needlessly constraining design, useful system objectives should have the following characteristics:

· They should communicate to management and to members of the developmental effort what the intended results of the system will be.

· They should be at a level of detail which will facilitate measurement of the system’s capability, by including quantitative/qualitative terms to serve as benchmarks.

· They should be organized into a logical and non-redundant structure.

· A preliminary set of system objectives can be developed by using estimates of the output characteristics which can be derived from descriptions of user activities. These include:

- Information requirements of the user

- Means of expressing the information

- Frequency, accuracy, quality, etc.

The purpose of this activity is also to establish the criteria by which the effectiveness of the system is to be measured. The process of identifying these criteria will continue throughout the development effort, becoming more detailed and refined with each stage. All the criteria should be stated in such a way as to demonstrate how the system will contribute to, and enhance, overall organizational objectives.

Examples of possible criteria are cost and time savings, reduction of accidents. material loss or impact on customers or employees (in terms of complaint rates or grievances). In addition, there are those specified by user requirements: quality, frequency, speed, quantity, etc.

These criteria will be stated in ranges of acceptable performance. The ranges will be narrowed as development of the system progresses.

It may be that development of an integrated data base or a real time communications system is stated as a system objective. If so, this will place a major restriction on the system design and the alternatives explored. If not, such determination will be among the alternative solutions examined later in the study.

All system design based on projected extensions in the "state of the art" should be carefully examined and evaluated. System design should not be based on technological "breakthroughs", but rather on what is possible within the limits of today’s available technology. In no case should system design be dependent on technology beyond "laboratory proven" techniques.

The feasibility of questionable technology should be tested by asking one of the following questions:

· Has the technology been "proven" anywhere in the business world?

· Has this technology been "proven" by laboratory methods?

· Has this technology been "proven" by some other testing method?

Where possible, the priorities of the different objectives should be expressed, since it is possible that system development may prove two objectives to be mutually exclusive, and the one with priority should take precedence.

This activity is normally performed parallel with activities 1.2 and 1.3.

1. State the explicit limits of the system, including a statement of what the system does not do.

2. List volume and throughput expectations for the system, being very explicit as to which are merely target figures or goals, and which are absolutely necessary for the system to be operationally feasible.

3. State qualitative expectations for the system (such as the required accuracy), again specifying the absolute and approximate objectives.

4. State the economic goals of the system (such as how much it should cost/save).

5. Define the expected organizational impact of the system.

6. State all other objectives relative to policy, tradition, industrial practices, and management directives.

7. Determine the impact on customers and employees in terms of the complaint rate, grievances, etc., that will be allowed.

8. Define the ultimate expected products of the system.

9. Rank order the objectives according to priority. Examine the list of objectives to determine if the attainment of any one objective is important only because it is a means to the attainment of another objective on the list. If so, it may be eliminated. Combine objectives that are essentially the same.

10. Using available information from industry and other sources, evaluate the feasibility of the technology to meet the objectives.

11. Include these objectives in the project file.

The process of identifying performance criteria should continue throughout the development effort, becoming more detailed and refined with each stage.

· System performance criteria (see Exhibits 1.4-B)

· Problem statement and background (1.1)

· Definition Study scope (1.1)

· Documented analysis of existing methods and procedures (1.3)

· Technology information:

- Industry

- Professional association

- Technical literature

1. Provide up-to-date status on all projects. The status should be made current at least weekly.

2. Provide the means and encouragement to promote good project planning.

3. Provide the proper reports to inform the project level of management, user, and project team concerning the project plan, and the progress made for that plan.

4. Reduce the number of occurrences and the total time involved in project overruns by 75%.

5. Provide staffing summaries for the four operational departments: a six-months period should be sufficient.

6. Be flexible enough to cover 20 departments, 1000 employees, 1000 projects, and 100 tasks within a project.

7. Provide on-line inquiry capability. Response time is not critical (around 10 seconds) since this objective exists largely to satisfy training requirements in teleprocessing.

8. Include a network planning technique, such as CPM, to ensure that the effect of an over- or underrun of one task is reflected in all other tasks which are dependent on it.

9. Provide a method for capturing and reporting on historical data.

During this activity, all resources, constraints, assumptions and items for resolution are identified and evaluated to determine their effect on the design of the new system (e.g., existing hardware constraints).

The process of recording these items should continue throughout this study. It should be understood that, when an unresolved item is listed, it should be resolved as quickly as practicable. A target date for resolution should be determined.

Resources and constraints are conceptually very similar. for instance, hardware might be considered a resource in one application, while being a constraint in another. The distinction would be whether the hardware represented expanded capability (resource) or whether it restricted the capability (constraint).

Resources represent capabilities which are available for utilization in building the system. They should include:

· Hardware, software, personnel

· Supplies (cards, tapes, disks, etc.)

· Facilities (buildings, air conditioners, desks, chairs, etc.)

· Modes of expression (chairs, tables, codes, etc.)

· Finances (estimates of costs for implementation and operation)

Constraints represent the limits on the resources in terms of resource capacities. Constraints also refer to environmental conditions which may impose limits on the system development. Sources of information for this activity include:

· Management directives and recommendations

· previous systems and their documentation

· Compatibility and expandability

· Time required for implementation

· long-range plans

· financial reports

· Maintainability and flexibility

· Job descriptions

· Company policy

· Legal and regulatory documents

· audit requirements

· etc.

During any development effort, many assumptions are made during the early phases in order to proceed in the design effort. These assumptions are based on considerations such as:

· Historical studies

· Company background

· Industry standards

· General statistics

· Empirical evidence

· etc.

An item for resolution is a particular question or problem that must be answered or agreed during the system development.

1. List all available resources and evaluate them for their impact on development.

2. List all known significant constraints.

3. Evaluate constraints to determine whether or not they should be changed, eliminated, or strictly adhered to. For example, a company policy that restricts the use of outside consultants for developmental work may be too constraining and it may be desirable to change policy.

4. List the corporate policies and legal considerations which may also impose constraints on the system design.

5. Examine resources and constraints for possible trade-offs (e.g., increase a time constraint and lower the manpower).

6. Consider internal control requirements (e.g., audit trails) for possible design constraints.

7. Identify all capabilities currently being provided by the existing system.

8. List all assumptions or items for resolution with regard to existing problems or system objectives; associate the reasons of these conditions.

9. List all industrial or generally accepted standards or statistics important to the system to be developed.

10. List all assumptions or items for resolution regarding hardware capacity or availability.

11. List all assumptions regarding time limits and schedules.

12. List all assumptions pertaining to general resource and personnel capacity, capability, and availability.

13. Establish milestones for completing the items for resolution.

14. Verify that assumptions are not in conflict; if so, combine in an "item for resolution".

15. Rank all above items on the basis of their potential impact on the system.

16. Include this list in the project file and maintain it throughout the life of the system.

· System resources (see Exhibit 1.5-A)

· System constraints (see Exhibit 1.5-A)

· Assumptions (see Exhibit 1.5-B)

· Items for resolution (see Exhibit 1.5-C)

· System objectives (1.4)

· System performance criteria (1.4)

· Documented analysis of existing methods and procedures (1.3)

1. Up to 2 hours of dedicated computer time for one core region is available for this system each week. Up to one disk drive and pack may be used with appropriate back-up packs. One tape drive may be used for selected periods during the day not to exceed one hour. The system may be tested and implemented under this configuration.

2. There are currently 3 analysts available to work on the system in addition to the Project Manager, Mr. Jackson. Two programmers will be made available when needed. One typist is available.

3. When the system is operational, Mr. Thompson will be available to control and monitor it.

4. Mr. Thompson, who is an expert in project management principles, will be available for consulting throughout development.

5. Management personnel will be available to a reasonable degree to answer questions and express their wishes.

1. All new positions created will be filled by current company employees.

2. All required expertise will be developed within the company through company supported training programs.

3. The new system will not alter the basic company organization nor alter the pay scales.

4. All concepts will be directed towards a centralized management system and an integrated data base.

5. All systems will be installed on currently owned equipment, with the exception of required terminals.

6. All affected departments must concur on the system objectives.

7. There is little valid historical information concerning projects that were completed more than a year ago.

8. The system should not create more paper work, but should encourage more time to be spent on quality planning and control

A functional specification is required at this time to define what the system must accomplish to satisfy stated objectives and comply with stated constraints. This specification must be in user terms and must be arrived at through user negotiations, which thoroughly cover all aspects of the proposed development. Coincidental with determining the system functions are the identification of the outputs from the inputs to the system.

It is generally a straightforward task to determine the outputs of the system. This can usually be done by examining the system objectives in conjunction with the output data that are provided by existing manual or automated systems. A case where this is not true is in the development of a totally new system - a condition which is not often found. The outputs should be analyzed at this time to the detail of determining which data items are required and not necessarily to the point of trying to establish definitive formats, etc.

Once the required output data items have been identified, data group analysis can occur where the individual items are associated in logical groups, i.e., the name and address data group equals name, street, house number, city, and country data items.

The identified data groups can then be analyzed to determine what is required in terms of input. This input can take the form of either actual inputs to the system or system resident data (data base). This distinction should be made at this time where possible.

The various input, output, and data base groups may now be analyzed to establish activity relationships; that is, what must be done to and with the data to form the required transformations (functions) from system inputs, via the data base, to the system outputs. More detailed specifications are developed during Preliminary Design, transforming user related functions (what must be done) into system related processes (how it is done). The functions identified at this time usually fall in the following categories:

· Input preparation

· Input validation

· Data base maintenance

· Information retrieval

· Calculations

· Data manipulation

· Output handling

· etc.

The function of a new system may strongly resemble the functions in a correspondingly old system, while this will not necessarily be true for resulting processes.

A functional specification must be very much user oriented and completely understandable by the user. One way to promote this is to document all or part of the functional specifications in the form of a User’s Manual for the proposed system. This will seem highly premature as most User’s Manual’s are produced after the system has been completed. There are strong advantages for writing such documentation in terms of what a system will do from a user viewpoint rather than what it already does. In this way, there is much more assurance that the system developed from such functional specifications will actually do what the users expect and be acceptable after implementation.

Such a preliminary User’s Manual would vary in the level of detail presented depending on the degree of precision attainable at this time. It should be completed in terms of its structure and the major contents. This can also be the beginning of defining what will constitute an acceptance procedure for the system itself as a User’s Manual is a description in users terms of what the system is and what it is supposed to do.

In the functional specification there should be as clear as possible a preliminary delineation between those functions which are to be performed by people and those which should be performed by computer equipment.

1. Prepare, with the user, a preliminary output description (Exhibit 1.6-A) for each system output requirement. The destination and use of each output should be included in the description. The actual output layouts need not be considered at this time. It is also not the time to worry about the technical aspects of how the computer will produce the outputs.

2. Identify all the data elements that will be required to arrive at the specified outputs. Many of the data elements may already be accounted for in the existing system. The originator/source of all data elements should be identified. When available, the field size and data type should be noted. it may not be possible to identify all the data elements of each output at this time. Where this is the case, a note to this effect should be included in the output description.

3. Without being overly influenced by the output requirements of the system, classify common, related data elements into data groups . A data group, as defined here, consists of a number of data elements that are considered together because of certain similarities. For instance, data elements related to location, such as town postal code, street name, and house number could be classified under the heading of a data group defined as "location" (Exhibit 1.6-B).

During the classification of the data elements, it may be found that some data elements are common to more that one data group.. At this time, duplication or redundancy should not be a major consideration in the classification of data elements. Data elements should be listed in each data group where commonality exists. While this will result in a certain amount of overlap between groups, it will also indicate the possibility of combining certain data groups. The combining of data groups is desirable in that the number of data groups should be kept to a reasonable number.

4. Identify with the user the input requirements. A preliminary description of each input should be prepared. The actual input layouts need not be considered at this time.

5. Determine data group activity relationships. This is accomplished by presenting the relationship [common data element(s)] between each data group and the inputs and outputs of the system. Statistics concerning the frequency and volume of the inputs and outputs should be included together with media and sequence requirements. Based on the inputs and outputs activity against the data groups, certain preliminary indications about the characteristics of the required data organization can be determined. For instances, the resulting analysis may indicate that certain data groups are significantly more central that others in terms of accessing requirements.

6. Analyze the data group activity relationships and determine whether interactions and transformations must occur between the inputs and data groups to meet the system output requirements.

7. Specify, with the user, input/output handling functions.

8. Specify, with the user, input validation functions, such as: format validation, field validation, logic checks, and source validation.

9. Specify, with the user, data base maintenance and updating functions. Should the data base updating be a real time process or a batch process.

10. Specify, with the user, all information retrieval functions. Can most output requirements be satisfied by a generalized reporting system? Are there any 0n-line real time information retrieval requirements?

11. Specify, with the user, all of the applications particular calculations that must be made on the data, as well as other forms of application dependent data manipulations that must occur. For instance, particular methods for calculating interest are quite pertinent for the user in a banking application or the particular techniques for managing an investment portfolio would be quite critical in an investment system for an insurance company.

12. Develop a detailed description of all system functions, relating them to each other and to system outputs and inputs. Prepare diagrams depicting functional and I/O relationships.

13. Produce the functional specifications in a form that can be readily understood by the user, such as in the form of a preliminary User’s Manual for the system. Such a document would of course be modified and expanded in detail as the system is developed up to implementation. However, it must not change functionally as it represents an obligation to the user of what the system will accomplish.

14. Carefully review all functional specifications with the user and get his written concurrence that they represent, in fact, the way in which the system must function.

· Preliminary system output and input description (see Exhibit 1.6-A)

· Data element description (see Exhibit 1.6-B)

· Data group classification (see Exhibit 1.6-B)

· Data group activity relationship

· Major system functions (see Exhibit 1.6-C)

· Functional specifications

· System objectives (1.4)

· System performance criteria (1.4)

· Documented analysis of existing methods and procedures (1.3)

· Assumptions and constraints (1.5)

(To be supplied.)

During this study the major system functions and data groups are analyzed to determine general system capability requirements. for example, the data base storage and organizational requirements should be determined. It is realized, of course, that at this time it is not usually possible to accurately specify these requirements; they will be refined later in the design effort. System hardware and software support requirements must also be specified. for example, the requirements to support real time teleprocessing.

Based on these requirements, a number of system approaches can be developed. The purpose of examining a number of different approaches is to determine a configuration approach which is the most favorable, based not only on performance but also on cost. It has been shown by experience that when the mind is forced to remain open and creative in order to find more that a single solution to a problem, some of the solutions developed are of a higher quality that others. It should also be realized that as the number of possible solutions increases, the probability of finding the most optimal solution increases as well.

In determining possible approaches, one possibility that should always be considered is to do nothing and to retain the existing system whether it be manual or automated. The possibility of a new manual system, or even going from an automated system back to a manual approach, may also be a consideration. Approaches need only be developed to a sufficient level where advantages and disadvantages of each can be shown. Latter in the design effort, after the most optimum approach has been identified, detail system configurations using equipment from several computer manufactures can be compared.

1. Determine and specify the system capability requirements in a general way (see Exhibit 1.7-A).

2. Determine and specify system approaches that will satisfy all system capability requirements. These system approaches should be presented in the form of actual hardware configurations (see Exhibit 1.7-B) without considering any specific equipment manufacturers at this time. For a large and highly complex system, a modular approach will simplify this task. This method enables trial configurations to be developed by just varying the configuration within each module and the way in which the modules are connected.

3. Write a brief narrative description of each approach (see Exhibit 1.7-C).

4. List all the advantages of each approach described.

5. List all the disadvantages of each approach described.

6. Classify and weigh the advantages and disadvantages as to their relative importance and priority. for example, certain approaches will provide more reliability or security that others.

7. Indicate all relative costs and benefits which may be expected with each alternative approach.

8. Review to ensure that all reasonable approaches have been considered, including that which exists, whether manual or automated.

· System capability requirements (see Exhibit 1.7-A)

· Alternative system configuration charts (see Exhibit 1.7-B)

· Alternative system approach summaries (see Exhibit 1.7-C)

· System objectives (1.4)

· System performance criteria (1.4)

· Major system functions (1.6)

· System Constraints (1.5)

· System resources (1.5)

· Comparable systems

The communications area has the greatest impact on the system approach. There will be terminals in four basic sites. All of these sites already have computer processing capability. Therefore, the communications could all be local for the P.M. System if the P.M. System were run asynchronously on the four computer systems. Likewise, the processing could be done centrally in one site with remote terminals in the other sites on a dial-up or leased line basis. The third possibility uses computer to computer communications with three of the sites acting only as communications handlers with the fourth site doing the processing. The selection of approach is dependent on cost and the type of communications experience desired within the organization.

A portion of the data base will be on-line so there is a requirement for mass storage. The amount of storage is felt to be rather small. In addition, some information such as historical data could be maintained on either tape or disk.

The processing requirements are relatively light with probably one batch run about 1 hour per week. In addition an inquiry program will be required on a demand basis throughout the day. This program will not have to be resident all the time but should have a high priority.

This will be low volume card or mag tape in and printer or mag tape out.

(To be supplied.)

The purpose of this activity is to objectively evaluate the system approaches developed during activity 1.7, and to select the approach to be recommended to management. In order to make this evaluation and selection, the relative cost effectiveness of each approach must be determined; the objective being to select the approach which provides the same, or better, performance at lower cost that any of the others.

An important consideration not to be overlooked in the selection process is the potential impact on the user organization. The user implications may be described in the following general classifications:

· Business (the level of resources the user must commit to each approach):

- Finances

- Management

- Time

- Etc.

· Organization (the organizational changes required by each approach):

- Number of people

- Kind of people

- Training

- etc.

· Customer (the effect of each approach on the customer):

- Service

- Errors

- Cost

- Information Flow

- Functional Structure

- etc.

The process of selecting the proper system approach is often complex and difficult to validate. Likewise, there is a tendency to become subjective, biased, and arbitrary in the whole selection process. This often leads to serious problems and unwarranted costs, such as the case where a system that really should never have been automated ends up as a complex, expensive and not very beneficial computerized system.

The selection process used should reduce the large, important, and difficult decision of approach selection to a large number of smaller decisions which are easier to analyze. The objective is to remove, as much as possible, the subjective aspects of decision making in the selection of system approach. In many cases, the relative values of the various alternatives may seem obvious and a rigorous analysis superfluous; but caution should be used to ensure that personal bias does not color the situation and lead to a less than optimum choice of approach. Complex, or totally new system will require much more analysis and more rigorous evaluation methods, while, in other cases, the system approach may be dictated as a constraint imposed by policy, existing methods and procedures, or by hardware.

1. Analyze the objectives of the system together with the resources and constraints in order to determine the set of parameters which must be used to evaluate the relative worth of the alternate approached described in activity 1.7. These will usually be based on a standard set, such as:-

· Cost

· Reliability

· Security

· Ergonomics

· Availability

· Flexibility

· Capability

· Etc.

These parameters or selection categories are quite general and, if applied to various approaches, would be extremely subjective and prone to bias. Likewise, the relative importance between these categories will vary considerably from application to application and weighting factors will be required for each system considered.

2. Allocate weighting factors to each category based on the relative importance of the categories within the particular system under consideration. Cost would usually be considered as being the standard and be assigned the relative weight 1.00 with all other categories assigned weights that are relative to cost (see Exhibit 1.8-A).

3. Subdivide the general categories into measurable elements (evaluation criteria). The level of detail will vary depending upon the size and complexity of the system being considered. An example of the breakdown for the general category "cost" is:

· Initial hardware costs

· Initial software costs

· Operating costs

· Software maintenance costs

· Hardware maintenance costs

· System test costs

· Conversion and implementation costs

· User organization costs

· Etc.

4. Select a method for comparative analysis for the various approaches, considering the weighted evaluation criteria. It is beneficial to break down major decisions into a group of small and easy to make decisions. This is assisted by the fact of having broken down the evaluation criteria into any elements. In most cases, it is important to introduce as many opinions into the selection process as possible. With this in mind, a procedure such as the Delphi Method may be used (see Exhibit 1.8-B).

5. Compare each approach in terms of each evaluation criterion and assign relative values as to how effective the approach is. This is usually expressed in terms of cost effectiveness.

If some opinion polling method such as the Delphi Method has been used, average the relative effectiveness of each approach. It may also be instructive to compute the relative effectiveness of each approach. It may also be instructive to compute the reliability of this average figure, perhaps in terms of standard deviation (see Exhibit 1.8-B).

6. Multiple the general category weights derived in step 2 by the average effectiveness rating to give the proper emphasis to each rating.

7. Determine the relative effectiveness of each approach by summing the weighted average ratings of step 6, taking into account the reliability factors (see Exhibit 1.8-C).

8. Recommend or select the approach(es) that are evaluated as being the most effective solution(s). Selection may be made by the Definition Study team, the user, higher management, etc., depending on the particular organization. More than one approach may receive equal evaluations. In this case, multiple recommendations may be made and the final selection accomplished on a more subjective basis, or the whole evaluation process could be repeated in more detail.

· System approach recommendation

· Selected system approach

· Supporting documents covering the selection process (see Exhibits 1.8-A - 1.8-C)

· Definition Study scope (1.1)

· Documented analysis of existing methods and procedures (1.3)

· System objectives (1.4)

· System resources (1.5)

· System constraints (1.5)

· Assumptions (1.5)

· Preliminary system output and input descriptions (1.6)

· Major system functions (1.6)

· Alternative system configuration charts (1.7)

· Alternative system approach summaries (1.7)

(To be supplied.)

In many systems development efforts, the problems of implementation and conversion are paramount. It is possible to anticipate these problems well in advance and to provide for their solution in parallel with the development of the system. It is necessary to ensure that the data base or any other data implementation or conversion, necessary for system implementation, can indeed, be accomplished. For example, a conversion of a manual file is correct, only to find out at conversion time (too late) that the manual file has extensive errors and, in fact, cannot be converted as planned.

In some systems development efforts, the actual process of implementation and conversion may require as much expenditure as the rest of the systems effort in total. Under these circumstances, an appropriate and corresponding amount of design and development effort must begin with the definition study.

Under any circumstances, the requirements of implementation and conversion must be fully understood and explicit at the definition stage, and appropriate techniques developed for the resolution of problems.

At this stage of development, only a high level assessment of the conversion and implementation effort is normally necessary. The results of this activity should be at the level of detail required to determine the manpower, resources, and time required by this effort. It should be noted that in certain cases where the conversion of implementation is massive or very complex, a very details and exhaustive analysis of the effort may be required to determine that the system has a reasonable assurance of success. In any event, a more detailed examination of conversion and implementation is required in the Preliminary Design and Detailed Design stages of development.

In this light, it is important to specify what will constitute the acceptance of the system early in its development in order to eliminate or reduce the possibility of developing a system which is unacceptable to the user. The acceptance should be expressed at two levels:

· User acceptance of system logic (testing)

· User acceptance of system implementation

In many cases, these are combined into one acceptance activity at the end of implementation. This could be dangerous and expensive since it is possible to go through an expensive implementation and conversion effort only to find that the system logic or performance is unacceptable.

Acceptance criteria should be clearly linked to the documentation which states system definition, system requirements and system specifications. This should be done by referencing statements which define throughput, input/output, reliability, etc. Vague non-measurable criteria should be avoided and replaced by criteria which define acceptance clearly enough so that all can agree when the system performs correctly. Instead of "response times for the input of XXX data will be satisfactory" this should be "The average response time for input XXX data will be 3 seconds under normal loading and no longer than 10 seconds under peak loading of the system as a whole."

Acceptance criteria should be expressed in terms of:

· Observation time intervals

· Acceptance test exercises

· Acceptance test data

· Required results:

- Volume

- Speed

- Accuracy

· Approving organization and personnel

1. Determine the amount of data that must be collected from non-machine-readable sources. In most cases, the major data conversion effort will be expanded in converting these data.

2. Identify major differences between existing machine-readable files and new files that may cause difficulties, such as:

· Differences in file organization

· Differences in record organization or content

· Differences in structuring data items at the field level

· Differences in data representation (fixed length words, packed decimal, etc.)

3. Sample the existing data whether on manual or automated records. Analyze these data carefully to determine if it conforms to specifications and if the level and type errors in the existing data are acceptable or readily correctable. The more massive or complex the data conversion, the more important this becomes.

4. Identify any special resources that will be required to effect data conversion, such as additional hardware, special conversion aids, and unusual numbers or special types of personnel.

5. Identify all computer programs or manual procedures that must be converted from existing systems to the proposed system.

6. Determine the responsibility and level of effort required for hardware planning, preparation and installation. This would include acceptance testing of any vendor-supplied software.

7. Determine the level of effort required in the development of the manual aspects of the system, which includes all human interface areas and manual operating procedures.

8. Determine the level of effort required for personnel training. focus special attention on large or complex existing manual operations where long standing procedures will significantly change. This is an extremely critical area that is often overlooked. Existing personnel must be able to adapt to and effectively operate with the new system.

9. Identify any additional support functions that may be required, such as:

· Auditing control

· Human factors

· Methods and standards control

· Simulation and modeling

10. Determine the approach to implementation of the system:

· Immediate cutover

· Phased cutover

· Parallel processing

· etc.

11. Based on the information collected above, estimate the resources and time required to accomplish implementation and conversion, as well as the total level of effort and cost.

12. Request user acceptance criteria, evaluate these in terms of:

· Reasonability

· Completeness

· Attainability

Interact with the user until a mutually agreed upon set of acceptance criteria are resolved. The criteria must:

· Prove the usability of the system to the user

· Facilitate the proving and turnover of the system by the developer

· Data Conversion and system implementation requirements

· System acceptance criteria (see Exhibits 1.9-A)

· System objectives (1.4)

· System approach (1.8)

· Preliminary system output and input descriptions (1.6)

· System resources (1.5)

· System constraints (1.5)

· Documented analysis of existing methods and procedures (1.3)

· Problem statement and background (1.1)

1. A live project will be used for testing.

2. Live time sheets will be used as basic transactions.

3. Extraneous transactions will be generated to test every possible path through each program.

4. Inquiry process will be artificially driven at 2 transactions/sec to test performance.

5. All test runs and test results will be reviewed by the steering group.

6. The responsibility for the quality of the test data lies with the steering group.

7. The system must be demonstrated and tested on-line prior to acceptance.

1. The system must operate without major problems for six months using 3 pilot projects.

2. The evaluation by the project managers of the three projects will be a prime acceptance factor.

3. Management evaluation of the reports produced is important.

4. Ease of use for the Project Managers and management is important. Difficult procedures must be kept to a minimum.

5. The system must not interfere with project or overly influence computer operations..

During this activity, the overall plan is derived from the system objectives and from the overall structure of the selected system configuration. This plan will identify those processes necessary to build a system which will meet the system objectives for the system approach recommended. If more than one approach is recommended, then a plan for each is necessary. Included in the plan should be the phasing of the various applications within the system, a time schedule for the applications and stages of development, expected manpower and other resource requirements, and projected cost/benefits.

The construction of a cost view of the proposed system is based on the best estimate available. When good estimates cannot be obtained, a range of estimates with an appropriate intermediate condition should be used. These profiles will be used to compute the possible net annual savings or additional costs when compared with existing system. the results of this study will be used to determine if the new system is economically feasible.

At this stage, the cost figures will be rough; however, they should be reasonably accurate. The estimates of benefits or savings is often much more difficult, especially since many benefits or savings is often much more difficult, especially since many benefits may not be quantifiable; e.g., who can place a value on saving a human life, on stopping a ballistic missile, or on improving customer services. In such cases, the qualified cost must be applied to benefits that cannot be expressed in terms of reliable quantified savings. Other cases are more simple, where a specific cost (automated billing) may be applied against a specific and quantified saving (reduced personnel or greater interest return). In any event, the user can quite often be helpful in deterring the value of potential benefits and savings.

1. Derive the basic requirements through identification of personnel, budget, scheduling. facility co-ordination, etc. for both short and long term development.

2. Form these requirements into a basis for preparation of the developmental plan.

3. Develop a plan (CPM/PERT network and/or other scheduling documents) which will outline what is expected to take place, and when, during the developmental effort. CPM/PERT is particularly useful in illustrating the interdependence of events within the developmental effort.

4. Include in the plan review points for critical items and turnover checkpoints.

5. Identify all critical milestones.

6. Determine the initial costs (system development)

7. Determine the operational cost relative to the operating cost of the existing system where possible.

8. Include cost of personnel, equipment, space, supplies, etc.

9. Extend the plan to show both short and long range costs.

· Overall system plans and schedules (see Exhibits 1.10-A and 1.10-B)

· Cost/benefits analysis (see Exhibits 1.10-C - 1.10-E)

· All Definition Study documentation

(To be supplied.)

(To be supplied.)

(To be supplied.)

(To be supplied.)

(To be supplied.)

This is the last activity in the Definition Study stage. it consists of preparing the end product of this study, the Definition Study report, which is considered as a final technical report. The results of all the previous activities are summarized in this report. the level of detail and questions to be answered in this document are directly related to the scope of the study. The documented outputs from all the supporting activities are working papers and should be references by the Definition Study report - thus providing the details of the study. this report is compiled to provide management with information necessary to:

· Approve continued development

· Recommend a more detailed successive definition study.

· Request modification and changes

· Discontinue the development effort

· Postpone or redirect the effort

It must be remembered that this report will be the "base-line" for further system development.

1. Compile all the documentation created to date.

2. Produce an outline for the contents of the final report according to company standards. The outline should allow for the distribution of the work on sections of the report to members of the definition study team.

3. Plan the production of the various components of the report with the various members of the design team.

4. Produce a draft of the report. Depending on the size and complexity of the system, the size of the report may vary between a concise, few pages, and an extensive publication.

5. Carefully edit and publish the report. Take care to ensure that the presentation is of high quality and reflects a professional approach.

6. Submit the report to management for decision on whether or not to continue the development effort.

7. Give a briefing session to management for clarification of the report.

8. Retain the Definition Study report, together with a synopsis of the management reaction to the study for posterity or further system development.

· Definition Study Report (see Exhibit 1.11-A)

· All documentation from prior activities.

The Definition Study documentation will consist of a Definition Study report and a number of supporting documents. The arrangement and content lend themselves to subdividing so that further system developmental efforts, if recommended, can be initiated in limited and specific areas or to cover the entire study area. The following is an outline for the study documents:

· Title Sheet

· Management Summary

· Introduction Provides information which leads logically to the technical analysis and evaluation.

- Purpose Included a brief discussion of the reason for the definition study. This should include a clear and concise statement of the problem being studied.

- Scope Identifies the geographic or functional area, subsystem segment, organization, and/or echelons that will be included in the study (e.g., a statement of the study boundaries). Included is the amount of effort involved, and the costs.

- Background Describe the situations and conditions which existed when the study’s requirement was identified. It includes a historical narrative of pertinent events that occurred prior to the study.

- Assumptions and Items for Resolution Contains all the specific assumptions or items for resolution pertaining to the functional areas studied. For example, assumptions could pertain to the organizational structure, echelons performing specific functions, tactical considerations, information volume or material consumption rates.

- References Identifies all regulatory and procedural documents considered, analyzed, or employed during the study. References which contributed significantly to the study will be cited.

· System Objectives and Performance Criteria Includes all the objectives and performance criteria as modified and expanded during the execution of the Definition study.

· Technical Description Contains qualitative information developed during the course of the definition study:

- The functional Description describes each functional area, system, subsystem, phase and/or segment as it exists and alternative methods proposed to improve it. Each description should include a discussion of the system concepts, organizational structure, functional operation by echelon, major functional items of equipment, interfaces between functional operations and integration required.

Describe the present functional operations, specifying such items as echelons served, equipment used, staffing, loading factors, and any limitations or disadvantages of the present system.

- Include a narrative describing each proposed alternative system approach which was considered for accomplishing the specified objectives. The difference between each proposed approach and that recommended should be clearly defined. Flow charts, tables, and tabular formats may be used to support the narrative description.

- A discussion of alternative courses of action leading to the optimization of the organization and the final system should be provided.

- If automated data processing is indicated, the equipment considered must be related to the output required of the functional operations, operating conditions, personnel requirements, state of the art of equipment, software, projected future requirements, etc. It should be specified whether or not the equipment will be unique to the requirement. The computer system should be described in the general terms of type, size. I/O devises, special features, and other peripheral equipment.

- A brief description of all system inputs and outputs should be included.

- If appropriate, the transmission requirements of the proposed alternatives should be stated in terms of a wide range of traffic volumes for each functional operation. The location at which terminals or other equipment will be necessary will be identified. A description of interconnecting stations, communications modes, allowable error rate and security requirements will be included as applicable.

· Feasibility Forms the basis for demonstrating that the proposed solutions are practical and efficient and will yield the best end product at the most favorable cost.

- Technical Feasibility Relate performance of the proposed solution to current standards and criteria. If ADP is indicated, it should include an analysis of such technical considerations as the feasibility of an on-line real time computer system, the feasibility of various input media and the feasibility of achieving the acceptable error rate stated in the users requirements.

- Overall Plan and Schedule Describe the events, with an approximate schedule, for the system development process. Make any special comments on the loading of existing equipment or acquisition of new equipment.

- Develop a summary of personnel resources and deployment, the required training program and a summary of critical factors affecting the development of the overall system.

- Cost/Benefits Define cost/benefits relationships for areas specified for the proposed methods. Using acceptable methods, determine estimated costs and related worth of the existing system compared to the proposed system or to predetermined criteria.

- Simulation A mathematical model may be constructed to test cost, time, accuracy, and range of variables in the proposed method. Simulation may be used to determine whether the stated concepts of the proposed system are feasible and whether the proposed computer configuration and communication complex are technologically feasible. if used, the results should be summarized.

· Conclusions and Recommendations Summarizes the technical facts resulting from the Definition Study and recommendations concerning the proper course of action. It includes:

- Conclusions A summary of findings including precise statements concerning:

* Objectives determined to be feasible

* Concepts that should be incorporated within the proposed system

* Proposed optimization techniques

* Alternative solutions which satisfy the system objectives

* General computer specifications, if applicable

* Summary of the technical feasibility

* Summary of the cost/benefits

- Recommendations The major recommendations are stated, including reasons as to why they should be adopted. The recommended system or method must, as opposed to the several alternatives, be based upon the technological, analytical, and cost/effectiveness data contained in this documents. The following factors should be considered when providing user management with the recommended course of action.

* Exploration of a technological breakthrough

* Performance of design is well within the bounds of being feasible in terms of; System Concept, Functional Area Requirements, Software Requirements, and Hardware Requirements.

- Supporting Documentation The specific products produced as a result of the standard activities conducted during the Definition Study are summarized in supporting documents to the basic report.