Fit/Gap Analysis Phase

Fit/Gap Analysis Phase

In this phase, the package is installed in a development or test area, and the stakeholders get together in one room to compare the features and functions of the package with the needs identified in the system analysis phase of the Selection stage. Any required functionality that is not included in the package is identified, in addition to any changes to the package that are required. If necessary, the system analysis may need to be revisited, to incorporate the functions of the package.

The primary participants in this phase are the core team and all additional stakeholders identified as extended team members and scheduled in the Fit/Gap Analysis Planning phase.

Deliverables

Package Installation The package is installed in a development/test area for functional appraisal, using University data.
Use Cases and Scripts Use cases are specific examples of business processes. Scripts are step-by-step instructions for appraising functionality. At this time, there are neither templates nor samples for these items.
Updated Business Process Models These models show the triggering event, the primary and secondary outputs, and the inputs of the desired system. These models must be updated from the original Business Process models to reflect the customized package, and any new processes must be modeled using Visio templates available on the M drive. Note: If you do not have Visio on your machine, you will not be able to use the template. In this case, you can use the PC in the hallway where Visio is installed.
Updated Business Process Document This document is the text companion to the Business Process models. Update the original document with the new processes, and change the previously-defined processes as required.
Updated Activity Flow Diagrams This diagram documents the flow of activities for a business process or sub-process. Update existing activity flow diagrams as needed to reflect the customized package. If there is an attached Word document describing the activity flow, be sure to update that too.
Updated Extended Entity Object Model The extended object model includes aggregates and inheritance, as needed. If the package is very different from the projected system defined in System Analysis, you will have to create a new model; otherwise, you can update the existing model to reflect the customized package. This model is updated or created in Visio.
Object Life Cycle Models If new objects have been added, or an existing object has a different life cycle in the package than the projected system, new models may be required. These models are created in Visio.
Customization Report This is a brief explanation of the adaptations and adjustments required to make the package work for Princeton. At this time, there is no template and no sample for the Customization Report.
Updated Project Plan with Phase Section for Logical Design The project plan produced in the System Analysis phase is updated with information on deliverables, resourcing, and schedules gleaned from the Fit/Gap Analysis. In addition, a phase section is produced for the Logical Design phase and attached to the project plan.
Methodology Compliance Form This form is initialized by the project team, and completed by a methodology representative who has reviewed the project documentation and found it acceptable. It is completed in Word. At this time, no sample is available.
Recommendation Form This form is completed by the project team, and contains the recommendation to the approving authority on whether or not the project should continue. The form is completed in Word. At this time, no sample is available.

Steps

The project team reviews the documentation from the previous phases, and pulls in extended team members with business and technical expertise.

The team meets to review the data, and map the legacy data into the package database. Pay particular attention to multiple mapping of single data items, since these will require decisions about where to locate the data. If you do place the data in multiple locations, plan how you will key the updates to be sure to update all locations.

The team meets to generate a list of what people are going to try to do with the system (examples rather than models), and creates use cases to be used in scripts for appraising the functionality of the package.

Scripts are written based on the use cases. Keep in mind that deviations from the script can be useful, provided that scripted functionality is not skipped.

The team meets to map the business processes discovered in business and system analysis against the package functions, using the scripts, and noting which processes are not available in the package, or work differently in the package. Be sure to check security requirements.

The team meets to determine where the differences are between the expected system and the delivered package and discusses the following:

Which differences can you live with, and which must be fixed?
What can you do about the differences you can't live with?
What can you get the vendor to change?

Based on the preceding steps, the team updates the business process models, activity flow diagrams, entity object model, and object life cycle models to reflect the customized system.

Based on the preceding discussions, the team writes the customization report, detailing what changes will be required to make the package work at Princeton. This includes any interfaces to existing systems, and additions and changes to the packaged system. The report also indicates for each item whether the work is to be done by Princeton staff or the vendor.

Based on the customization report, the team updates the Project Plan, and completes a phase section for the Logical Design phase.

The project team forwards the deliverables to the methodology representative for review. The methodology representative reviews the documents for compliance, and completes the Compliance Form. If the deliverables conform to methodology requirements, they are returned with the completed compliance form to the team, which then proceeds with the next step.

If the deliverables do not conform to the methodology requirements, the deliverables and the compliance form are returned to the team with an explanation of what is wrong. The team then corrects the deliverables as required and returns them to the methodology representative for a follow-up review. When the reviewer approves the deliverables, the team continues with the next step.

The project team writes a recommendation indicating whether they think the project should continue or not, using the Recommendation Form. The recommendation form is attached to the updated project plan and any other project documentation, and forwarded to the project sponsor for review. If there are significant changes to the scope, schedule, or budget, the project sponsor forwards the documentation and recommendation form to the approving authority for review.

The project sponsor or approving authority decides whether or not to move forward with the project.