Project Review Document

Following is the template that we at Priority Software use for our own Project Reviews. Whatever is in black font is the actual template; the blue notes are included to help guide you in completing that template. Once everything is complete, this is the actual document we present to the customer for approval before moving forward.

0 General Description

This document is designed to assist in a preliminary review of a proposed project.It will:

  • Help define the scope of implementation for the Priority system
  • Include a list of potential business processes of implementation of Priority
  • Detail the functionality required of the system, and the nature of how Priority will respond to those requirements
  • Detail additional topics that will affect the overall cost of the project (system analysis, data migration, Key User practice sessions, go-live support, etc.).

General Description of Company Activities

A brief description of what the enterprise/organization does.

Companies Taking Part in the Implementation

How many legal entities are part of the project? This helps define the budget for implementation and the complexity of the financial processes.

Companies, Sites, Divisions and Organization Structure

It is imperative that you define how many sites and how many users (for each area) you will be involved with in working on this project.

Each additional user that you have to interact with increases the amount of hours required and decreases the ability of the team to reach decisions in a timely manner.

This information will help define the budget for practice sessions and go-live support.

Key Users

List here the names of all the Key Users who will be involved in the system analysis (there may be more Key Users involved in practice sessions).

At most, there should be 6 Key Users with whom you meet to conduct the system analysis. Theseusers should have authorization to make integrated and informed decisions on the workings of the system (e.g., the Key User for sales needs to understand how his/her decisions will impact inventory).

The number of users will directly impact the budget of the SOW.

1 Project Management

This will normally cover 10% of the budget of all the other items in the project. This budget is designed to be used for overall planning and oversight of the project, as well as managing the implementation team, steering committee meetings and meetings with the customer on important issues that arise in the course of the project.

2 System Analysis

This stage is devoted to preparation of the Scope of Work (SOW) document.

  1. Performing a review of existing processes (with the existing system/tools) in conjunction with the people actually performing the actions (how inquiries are recorded and tracked, who receives the inquiries for handling, forms that need to be completed, reports, etc.).
  2. Defining the requirements for the new system as outlined by the users and the IT team.
  3. Defining the proposed solution in Priority, including a description of the work processes as they will flow once Priority has been implemented, as well as detailing gaps in the system (Gap Analysis), if any, vs. requirements.

The product of this phase is (1) a Scope of Work (SOW) document describing the overall scope of the project; (2) delineation of any required customizations; and (3) a detailed work plan specifying tasks for the next stage of the project.

Planned Meetings, Number of Meetings and Notes on Agenda

It is of utmost importance to detail the meetings to be held in terms of content (issues to be discussed) and participants, as this provides clear guidelines that assist you in scoping the project. It also minimizes the ability of the customer to increase the project scope, and thereby avoids going over budget.

The number of meetings is defined in part by the number of sites and the number of users in each area, for example:

  • Financials: 3 meetings (including discussions on migration of financial data, consolidation of reports and inter-company accounting)
  • Sales: 2 meetings (including lead management, price quotations and orders)
  • Etc.

Total number of planned analysis meetings:[insert number]

Each meeting is budgeted at approximately 10 hours, 4 hours of which are to be dedicated to face-to-face meetings and the remainder to writing up the document and follow-up discussions until completion. More complicated material will require additional hours for each stage of the process.

3 Data Migration

Description of Planned Working Methodology

Please note that, in our description of data migration, we use Priority's migration module so that the process becomes the customer's responsibility as much as possible.The more the customer wants the implementation team to take responsibility for the migration, the more this bank of hours will grow. We recommend that you minimize the involvement of the implementation team in data migration, and instead concentrate on transferring the knowledge of how to work with the migration module as efficiently as possible.

  1. Decisions as to the data to be migrated and/or input manually into the new system will be agreed upon in the framework of the SOW.
  2. The customer will provide files in the structure prescribed in the SOW.
  3. Migration will be done by loading files into dedicated forms which are essentially a "work area," in order to manipulate data prior to final import.
  4. Following the initial loading, data will be enhanced/corrected by the customer as per the instructions in the SOP and with the assistance of an implementer (within the framework of practice sessions).
  5. Data will be input by the customer on the basis of the SOP and the practice sessions given prior to the commencement of data entry.
  6. The migration module handles the following areas: Parts, BOM, Designations, Alternate Parts, Manufacturer Part Numbers, Customers, Customer Contacts, Customer Part Numbers, Price Lists, Open Customer Orders, Vendors, Vendors Contacts, Vendor Part Numbers, Vendor Price Lists, Open Purchase Orders, Goods Receiving Vouchers, Inventory Count, General Ledger, and Journal Entries.
  7. Proposed migration budget:10 hours for practice sessions on the migration module + 20 hours for actual migration, oversight and checks on the financials of the live system.

This budget is very basic and should be adjusted if required. If the data is to be entered manually, this should be clearly specified. Our approach is to provide the customer with the tools to migrate data themselves, or instructions on how to enter it manually.

4 Required Functionality (Preliminary Gap Analysis)

In this section we define the different operational business processes that will be implemented in the course of the project. The main purpose of this section is to "seal" the project and to clearly define for the customer what is and what is not included in the functionality we are proposing.

We defineat a high level (at least the modular level) those areas that require implementation. In the areas where a gap has been identified, it is preferable to cite the area and a very brief description of how the issue will be resolved. The actual functionality of the system will be detailed in the SOW.

For example:

4.1 Sales

Lead Management

Sales Budgets

Price Quotations

Customer Orders

Contact Management

4.2 Purchasing

Purchase Planning

Purchase Orders

Vendor Management

Etc.

As stated, the basic assumption is that the implementation will proceed without customizations. However, if customizations are required, they should be mentioned here, or at least be allocated a bank of hours in this document. For example:

4.3 Interfaces

Purchase order import interface, which includes the project number to be invoiced. The number of activities will be fixed and defined in advance. The file will be input into Priorityin compliance with the approved format.

This section details the interface to be developed, which will then be included in the Project Plan.

4.4 Bank of Hours for Reports

The bank of hours will be used for the development of documents and/or reports according to specific and detailed definitions.

Rather than committing to a specific number of documents and reports, we commit to a number of hours. This ensures that the customer understands that every request they make has a price, and that hours will be deducted from the bank of hours accordingly. Once the bank of hours is exhausted, a separate order will be required for additional hours. If the customer insists on specific developments for which they demand an estimate without which the project will not move forward, this must be specified separately and hours allocated.

5 Practice Sessions

  1. Planning the course of the project and the breakdown of topics into stages for implementation and eventual operation (go-live) will be determined in the SOW stage.
  1. Practice sessions of Key Users for each work process will be held on the basis of the SOPs.
  2. It is the customer's responsibility to practice with the SOPs and to thoroughly review them until they are able to sign off on them with confidence that the SOPs meet their requirements.
  3. The budget does not include end-user training. End-user training will be conducted on the basis of the SOPs and is the responsibility of the customer.
  4. The customer's Project Leader will attend each practice session.
  5. The SOPs will continue to be reviewed and modified if necessary by the Key User during the course of practice sessions, the pilot and actual go-live. At each juncture updates must be provided to, and approved by, the implementation point person.
  6. The final version of the SOP, following go-live, will be documented by[insert your company name here], to be used by the technical support team and the customer's Project Leader.
  7. Notes regarding practice sessions:
  • Each session will include 3-4 Key Users (it is the responsibility of the customer to prepare a room for practice sessions with enough computer workstations for all participants).
  • The customer's Project Leader will attend each practice session.
  • Each practice session will take place only once.
  • The estimation of hours required for each practice session is based on our experience with similar projects.
  • The duration of each practice session will be approximately 4 hours.
  • Participants should come prepared for the practice session (having read through the requirements, the SOW and the draft of the relevant SOP).
  • The move from the SOP stage to the actual practice session is to be authorized in writing by the Key User. [This is crucial in establishing the Key User’s responsibility for the processes s/he will be accountable for in the system].
  • The sessions will take place only after there is actual data in the test system, and after the customizations for this particular area of the system (if any) have been delivered. [Theoretical practice sessions should never be provided. Practice sessions should only commence when the system is ready, developments delivered and data has been input and/or migrated].

Planning the Practice Sessions

Writing up the SOPs

This section covers the preparation of Standard Operating Procedures (SOPs). Templates for SOPs are available in the SOP Archive in the Partner section of the Priority Software website. The budgeted hours cover changes that need to be made to the existing SOP template and the composition of new ones, if required. The amount of hours needed depends on how far removed the customer's specifications are from the system "as is."

Introduction and Infrastructure

Introduction to the system, including the basic user interface, introduction to working with SOPs, and practice sessions on the system using SOPs for the following broad topics:

Financials

Purchasing

Inventory

Sales

Production

Human Resources

Systems

Etc.

Integration Meetings

Integration meetings are designed to address interfaces used by different departments, represented by different Key Users. The meetings will be scheduled only after individual practice sessionswith Key Users are complete.Sign off on processes addressed in these meetings will be done by all parties involved.

The total number of practice sessions that will be accompanied by an implementation person: approximately [insert number] sessions

6 Go-Live Assistance

Here we outline our commitment to the customer once the project reaches the go-live stage. Using the SOPs endorsed and authorized by the Key Users greatly reduces the need for assistance, as all users should be using the SOPs in their work. If a problem arises, they should be able to pinpoint exactly at what stage of the SOP it occurred. There are then two options: (1) if the user's observations are correct and justified, the SOP can be changed; or (2) if they have not understood the procedures completely, the relevant section of the document can be re-written for better clarity, or the procedure can be explained to the user.

Accompanying Operations and Financials Over the First Few Weeks

For example, the budget might be for 2 people on-site at go-live for two days, or several hours of an implementer's time over the first two weeks.

Assistance in Generating Original Documents and Handling Tax-related Matters

Same as above

Responding to Questions About the SOPs