WHO SHOULD PARTICIPATE?

Although Project Management and Systems Engineering are primarily responsible for performing the System Evaluation, they are assisted by many of the same functions participating in the System Approach. This includes representatives from Software Engineering, Data Engineering, Data Communications, Data Base Administration, and DP Operations. These other functions advise Project Management on matters related to estimates and other project related expenses. They also review project delivery schedules to evaluate viability.

This type of group participation enhances communications and cooperation between development functions and helps to establish realistic project estimates and schedules.

USE OF THE ROUGH DESIGN

The rough design prepared in the previous activity becomes the basis for evaluating the system solution and project during this activity. As such, it becomes the "roadmap" for determining project plans, estimates and schedules. Even if the system solution requires the implementation of a commercial software package, the rough design is used to establish a "make versus buy" comparative analysis.

PROJECT PLANNING

The Project Plan is used to establish:

1. The phases and activities required to complete the project, along with its path.

2. The human resources required to perform the work, whether known or unknown.

Before a project estimate and schedule can be calculated, the path of the project must first be defined. Under ISEM, the project path is ultimately based on the system structure (as defined by the rough design). Following Phase 1, the remaining phases relate to the Standard System Structure as defined by "PRIDE":

PHASE	NAME	RELATED SYSTEM STRUCTURE RESOURCE
2	System Design	System
3	Sub-System Design	Sub-System
4-I	Admin. Proc. Design	Sub-System (all Adm-Procs incl.)
4-II	Software Engineering	Computer Procedure
5	Software Manufacturing	Program
6	Software Testing	Computer Procedure
7	Sub-System Test	Sub-System
8	System Operation	System

NOTE: A Phase 9 review is performed to conclude the project.

This means there is an explicit one-to-one relationship between the phase and the system resource; for example:

• For each system there will be a Phase 2 and 8.

• For each sub-system there will be a Phase 3, 4-I, and 7.

• For each computer procedure there will be a Phase 4-II and 6.

• For each program there will be a Phase 5.

This means that the remaining phases of the project can be deduced from the system structure. It also means that the project can branch into parallel phases. As an aside, this approach reflects the "explosion/implosion" design and development process inherent in the methodology.

Although the above phase/system-resource relationship is the normal way of conducting an ISEM project, there may be exceptions to the rule. For example:

• If multiple Phase 2's have been identified, it may be more practical to split them into separate projects.

• Although Phase 4-I is normally used to write all of the administrative procedures in a sub-system, there may be occasions where a complex procedure may require the execution of a separate Phase 4-I.

• Phase 5 is normally used to write and test a single program. However, if the program is extremely large and complex, it may be more practical to divide it into sub-Phase 5's where the modules of the program can be written and tested.

• Depending on the scope of the project and/or organizational considerations, the project may wish to include DBEM phases for Data Base Engineering. Normally this is treated as a separate project.

PHASES FOR DOCUMENTING A PACKAGE

Even if a commercial software package has been selected as part of the system solution, it must be documented in the IRM and merged with the other corporate information resources for control purposes. In all likelihood, the same phases will be required to document the package, except they will probably be expedited, particularly if the package is well documented to begin with. For example:

PHASE 2 - SYSTEM DESIGN - This will be used to document the sub-systems implemented by the package. Inputs, Outputs and Files will all have to be recorded as ID's, OD's, and FD's. The file formats of output data files should be documented so that interfaces can be established.

PHASE 3 - SUB-SYSTEM DESIGN - This will focus on documenting the procedures, both administrative and computer. Input transactions provide insight into the physical attributes of data elements (length, precision, scale, class, etc.). These characteristics can either be recorded on the Data Definition (DD) or established as overrides on an RD to represent the input transaction.

PHASE 4-I - ADMINISTRATIVE PROCEDURE DESIGN - Playscript instructions should still be written to walk the user through processing. However, there should be references made to vendor supplied manuals and documentation.

PHASE 4-II - SOFTWARE ENGINEERING - There is probably not a significant amount of work required here unless the vendor's software source code requires considerable modification. In most cases, all that is required is a Computer Run Book that references vendor supplied documentation. Since DP Operations will reference the Computer Run Book, the following items should be provided: definition of the program job stream, operator instructions, and backup/recovery considerations.

NOTE: If the software requires considerable tailoring or if the customer will have to maintain the program source code, a full Phase 4-II may be required to properly document program logic.

PHASE 5 - SOFTWARE MANUFACTURING - Unless the vendor's program source code requires alterations, this phase will probably not be required.

PHASE 6 - SOFTWARE TESTING - Again, this phase will probably not be required unless the vendor's source code has been modified by the customer. However, this phase is very useful for testing vendor releases.

PHASE 7 - SUB-SYSTEM TEST - This phase should be performed to assure that the sub-system performs according to specification.

PHASE 8 - SYSTEM OPERATION - This phase will be required to educate users in the system and to put it into production.

PHASE 9 - ISEM EVALUATION - This, of course, will be required to evaluate project performance.

This means that packages will have more of an impact on project estimates and schedules than it will on the Project Plan.

SELECTING HUMAN RESOURCES

Following the rough design and the project plan, consideration must be given to the types of human resources required to implement the project. Based on the type of application being developed, Project Management considers the types of Systems Engineers and Software Engineers required to work on the project, including the skills and proficiencies needed to perform the work. Based on this analysis, Project Management has four options:

1. Use in-house personnel.

2. Recruit additional personnel.

3. Use outside personnel (contractors).

4. Combinations of the above.

In all instances, the use of human resources is based on their qualifications, their availability, and their cost. Project Management, therefore, must balance these variables when selecting personnel. There may be trade-offs to consider; for example:

• One person may be more expensive than others but can deliver the work faster.

• A senior analyst could perform the work in fewer hours than a junior analyst, but is committed to other project assignments. Consequently, the analyst cannot devote sufficient time to the project. Whereas the junior analyst may have fewer conflicts and is more available for project work.

PROJECT ESTIMATING & SCHEDULING

After the path of the project has been determined, an Order-of-Magnitude (OOM) estimate and schedule can be calculated. This is an estimate and schedule of the amount of effort required to perform the remaining phases in the project. The estimate, thereby, is an expression of labor charges.

The use of human resources has a significant impact on the OOM estimate. If the project participants for the remainder of the project are known, then their specific skills and proficiencies are taken into consideration when preparing the estimate. In fact, they should participate in the development of the estimate. However, if the project personnel are unknown, Project Management considers the type of human resources required and uses an average proficiency rating when preparing the estimate. One outcome from this is Project Management may identify what additional resources need to be recruited, either internally or externally (e.g., hiring new people, and using consultants). It may also highlight the need for additional training to develop the required skills and proficiencies.

Based on the Direct hour estimate, project costs may be calculated. A cost for each phase is prepared with a total project cost summed by phases.

In addition to labor costs, Project Management must consider supplemental project expenditures. This is where consideration is given to the acquisition of equipment, software, training, or any other pertinent expense. This is an area where other project functions such as DP Operations, Data Base Administration, and Data Communications can provide input.

The Direct hour estimate is also used to calculate the project schedule. Again, if the project personnel are known, their commitments and effectiveness rates are taken into consideration when preparing the schedule. If the resources are unknown, a standard effectiveness rate should be used.

A "Project Estimate/Schedule Recap" is prepared which contains both the Order-of-Magnitude Estimate and Schedule.

MODULARITY

ISEM provides the unique ability to design, develop and deliver sub-systems either singularly, in groups, or all together within a system. Because of this, each sub-system can be priced and scheduled separately for consideration by User Management. For example:

SUB-SYSTEM	COST	DELIVERY DATE
TS-01 Query Sales Figures	$ 5,500	March 1st
TS-02 Weekly Sales Commissions	$ 5,000	March 1st
TS-03 Monthly Sales Reports	$ 7,250	July 10th
TS-04 File Maintenance	$12,350	February 11th

The user should be made aware of these project options so that there is no confusion in delivering the product.

IMPLEMENTATION STRATEGY

Phase 8 normally marks the start-up of an entire system. However, if a large system, it may be more practical to execute a Phase 8 for a group of sub-systems. In other words, deliver the system in stages. This will effect the project path and should be explicitly described in the Project Plan.

As part of the implementation considerations, Project Management and Systems Engineering should carefully consider the need to implement certain sub-systems before others. For example, file maintenance sub-systems and file conversion sub-systems (which will move data from old file formats to new formats) should be considered before display/reporting sub-systems. Also, sub-systems implementing operational requirements should be considered before those implementing control and policy requirements.

The point is, ISEM provides a good framework for executing a systems development project. However, Project Management must consider the practical implications for controlling the project and, as such, must make the final decision on project execution.

COST/BENEFIT ANALYSIS

The purpose of a Cost/Benefit Analysis is to perform an economic impact analysis on the system and the project. Prior to performing this, Project Management has prepared an Order-of-Magnitude estimate to complete the project, along with any additional planned expenditures (such as for additional hardware/software acquisitions).

"PRIDE" provides a worksheet to assist in the preparation of the Cost/Benefit Analysis. However, in-house standards should be observed when performing the analysis.

During the analysis Project Management must consider how the proposed system solution will affect the company:

• Will it increase or reduce staffing?

• Will it increase or reduce equipment resources?

• What will be the annual savings and expenses of the system as it applies to the various user departments?

• What will be the one-time savings and expenses of the project as it applies to the various user departments?

• What will be the intangible benefits of the system?

• What is the investment evaluation? For example, what will be the Break Even Point of the project? What will be the Return On Investment (ROI)?

COST AND EVALUATION SUMMARY

The Cost/Benefit Analysis becomes the basis for preparing a Cost and Evaluation Summary. This is a textual justification for the project which summarizes the economic conditions for performing the project and implementing the proposed system solution. The main objective of the Cost and Evaluation Summary is to demonstrate that the system approach is a cost-effective solution for satisfying the business information requirements. It must also highlight why the approach was selected over other alternatives.

PREPARING FOR REVIEW

Project Management and Systems Engineering assures that all of the Phase 1 activities and materials have been properly completed. A Phase Review Checklist is available for this purpose. A formal Phase 1, "System Study & Evaluation Report" is then prepared. The manual is reviewed and checked by Quality Assurance prior to distribution to management for review.

The Phase 1 Manual contains the following items:

• Phase Cover Page - including a Table of Contents, along with a distribution/approval list.
• Project Scope - as prepared in Activity A and confirmed in Activity E.
• Current System Analysis - as prepared in Activity B and confirmed in Activity E.
• Information Flow Diagram - as prepared during Activity D and confirmed in Activity E.
• Project Information Flow - as prepared during Activity D and confirmed in Activity E.
• Information Requirements - as prepared during Activity D and confirmed in Activity E.
• System Concept Diagram - as prepared during Activity F.
• System Logic Narrative - as prepared during Activity F.
• Project Plan - as prepared in this activity.
• Project Estimate/Schedule Recap - as prepared in this activity.
• Cost and Evaluation Summary - as prepared in this activity.
• Glossary of Terms - as prepared during Activity D and confirmed in Activity E.
• Supporting Matrices:
  • Requirements/System Matrix by Project - as prepared during Activity F.
  • Entity/System Matrix by Project - as prepared during Activity F.
  • Information Requirements/Outputs Matrix - as prepared during Activity F.
• Phase Review Checklist - specifying acceptance criteria for the deliverables mentioned above.