The first step in preparing for a Conference Room Pilot is the identification and documentation of system requirements.
There are three primary sources for input into this activity:
An RFP (Request for Proposal), if one was prepared in the software selection process
A current set of User Procedures
A complete set of reports from the current system
These may be supplemented by the experience of the project team and user community.
The RFP is used as a tool for evaluating a proposed system, and thus should be the most complete compilation of system requirements available.
Current User Procedures are useful for identifying system requirements, but should not be considered a complete list of required functions. Typical written procedures cover entry of common business transactions (invoices, Journal Entries, Sales Orders), generation of reports, and period-close (month-end) procedures.
User Procedures are only a partial view of the current system, and do not describe features that are being added in the new system solution. In addition, User Procedures are written to answer the question of "how" rather than the question of "what"?
Building a catalog of current reports is another good way to identify requirements for the new system. Before a current report is included in the requirements list, it must be determined that it represents a requirement that is still necessary under the new system. Reports can become obsolete due to new on-line inquiry capabilities, changes in data base structures, or changes in business practices and product lines.
For each report listed, a solution should be identified for
that specific report requirement under the new system. The solution may be an identical report, a
similar report which includes all critical information, an on-line inquiry, or
a note indicating that a custom report will have to be developed.
CRP Processing Environment
The processing environment must be established on the hardware platform (computer or network) as part of the preparation for the Conference Room Pilot. The processing environment begins with the application software which was installed during the Project Definition phase.
If the software was not previously loaded on the system, it should be loaded now. Software which has been developed in house should be "frozen" (no further updates or modifications) at this time, until after the CRP. Package software should also be stabilized, and unmodified software should be used to the greatest extent possible.
The CRP system should be tested to insure that workstation connections are functioning, signons and passwords are set up properly, response time is reasonable, and that the software to be piloted is operational.
Conference Room Pilot Data
A separate CRP data library should be established, apart from any production or training environments. Before specific CRP test data is entered, the data files should be empty, except for reference information (Chart of Accounts, Inventory locations, codes files and tables, etc.).
Specific test data needs to be built for the Conference Room Pilot. The volume of data entered should be the minimum amount required to meet all desired test conditions. In general, data items such as Customers, Vendors, Warehouses, Manufacturing Work Centers, Employees, Departments and Assets might be established in the Establish System Prototype activity. The volume needed for each item depends entirely on the number of variations which need to be tested, but would normally be in the range of 3 to 20.
For example, for the Accounts Payable section of a CRP, five vendors would need to be established if the variations to be tested included:
Entering vouchers for a vendor whose invoices are always processed immediately.
Entering vouchers for a vendor whose invoices are always paid after 30 days.
Processing a vendor who is paid through Electronic Funds Transfer, rather than printing a check.
Processing payments for an international supplier.
Recording liabilities for a certain class of vendors for whom our liabilities are recorded in a separate general ledger account.
For testing a General Accounting application, accounts must be defined in all categories (Assets, Liabilities, Equity, Revenues, and Expenses). A full chart of accounts should be in place before the CRP begins. Accounts which are repeated in many locations, profit centers, product lines or branches, need not be copied to every location. However, if consolidated reporting is a feature to be tested, the chart must be in place for several companies, locations, branches, etc.
Transaction files should be empty when the CRP begins. For this reason, these files should be identified and reset or cleared, if any testing has previously been done in the CRP environment.
Physical Environment
Aside from the CRP processing environment is the physical environment. The physical environment includes the CRP facility, equipment, and supplies. Specifically, a productive CRP would be expected to be conducted in a physical environment which includes:
Enough space for participants, manuals, notes, etc.
A terminal with overhead projection connections.
A whiteboard with colored markers and an eraser.
At least one flip chart with various color markers.
An additional terminal for research and setup adjustments during the CRP sessions.
Meeting space nearby for off-line discussion.
Simultaneously with the establishment of the prototype environment, the scope of the Conference Room Pilot is determined, along with deciding which exercises or tests will be performed. Defining the scope of the Conference Room Pilot involves answering the question "Exactly what will be tested in the CRP?", or "Which functions will be piloted?".
On the following pages is a sample of a CRP Function List. This example would be for a CRP including the following applications:
General Accounting
Accounts Payable
Accounts Receivable
Although the specific functions in the list will change completely from one project to another, the format and level-of-detail would be valid for practically any Conference Room Pilot.
Sample Project
CRP Function List
May 1, 19XX
Function/
Step # Function to be Tested
1. General Accounting
1.1 Budgeting
1.1.1 Define Budget Patterns
1.1.2 Period by Period Budgeting
1.1.3 Annual Budget with Spreading
1.1.4 Budget Allocations
1.1.5 Inquiry on Budgets
1.1.6 Accounts to Budget:
1.1.6 Sales
1.1.6 Expenses
1.1.6 Discounts
1.1.6 Allowances
1.1.6 Returns
1.1.6 Cost of Sales
1.2 Transactions
1.2.1 Journal Entries
1.2.1 Model JE
1.2.1 Regular One-time
1.2.1 Expense Allocations
1.2.1 Reversing Entries
1.2.1 Percentage Entries
1.2.1 Units Ledger Entries
1.2.2 Review and Post Entries
1.2.3 Void one Entry and Repost
1.3 Inquiries
1.3.1 On-line Account Balances
1.3.1 Cumulative vs Period
1.3.1 Last Year
1.3.1 Budget
1.3.1 Units Balances
1.3.1 Rolled-up Balances
1.3.2 Transaction Details
1.3.3 Account Structure
1.4 Financial Reporting
1.4.1 Analysis Reports
1.4.1 Expense Analysis
1.4.1 Responsibility Reports
1.4.2 Month End Reports
1.4.2 Balance Sheet
1.4.2 P/L by Company, Business Unit
1.4.2 Cash Flow Analysis
1.5 Q&A session to discuss Accounting Issues
2. Accounts Payable
2.1 A/P Setup Parameters
2.1.1 Review Payment Terms and Hold Codes
2.1.2 Review other setup parameters
2.1.3 Enter Vendors
2.1.4 Review Vendor Master On-line
2.2 Vouchers
2.2.1 Enter Vouchers
2.2.1 Standard Vouchers
2.2.1 Recurring Vouchers
2.2.2 Review and Approve Vouchers
2.2.3 Edit a Voucher
2.2.4 Void a Voucher
2.2.5 Post Vouchers to G/L
2.2.6 Print and review Posting Reports
2.2.6 Review Posted Transactions
2.2.7 Voucher Inquiry
2.2.8 Vendor Ledger Inquiry
2.3 Process Payments
2.3.1 Print Cash Requirements Report
2.3.2 On-line Pay Item Maintenance
2.3.2 Split a payment
2.3.2 Change Discounts, Due Dates
2.3.3 Produce Computer Checks
2.3.3 Run Pre-Check Programs
2.3.3 Print Computer Checks
2.3.4 Process Manual Checks
2.3.4 With new voucher
2.3.4 For existing voucher
2.3.5 Perform Check Reconciliation Functions
2.3.6 Print Related Reports and Review
2.4 Q&A session to discuss A/P issues
3. Accounts Receivable
3.1 Review A/R Setup
3.1.1 Payment Terms and Aging Buckets
3.1.2 Hold Codes
3.2.4 Enter customers/
3.2.5 Customer Relationships/Subsidiaries
3.2.6 Review Customer Master On-line
3.2 Enter Invoices
3.2.1 Regular Trade
3.2.2 Miscellaneous
3.2.3 Recurring
3.2.4 Enter Credit Memos
3.2.5 Review and Post Invoices to G/L
3.3 Process Receipts
3.3.1 With Discount
3.3.2 Without Discount
3.3.3 Full Payment
3.3.4 Partial Payment
3.3.5 NSF Checks
3.3.6 Short Payments
3.3.6 With chargebacks
3.3.6 With Write-offs
3.3.7 Spread Unapplied Cash
3.3.8 Review and Post to GL
3.4 AR Reports
3.4.1 Aging Reports
3.4.2 Customer Ledger
3.4.3 Customer Statements
3.4.4 Dunning Letters
3.5 Q&A session to discuss open AR issues
The CRP Function List defines at a detailed level the scope of the pilot effort. It provides the basis for the detailed daily pilot schedule, and for completing the Exercise Documents. The Function List and the completed Exercise Documents comprise the Conference Room Pilot Script.
At the end of the Conference Room Pilot section of this guide is a blank Exercise Document, which should be duplicated and completed during the Define CRP Scope and Exercises activity. Each transaction, process, or business function included in the Function List may correspond to a completed Exercise Document. Alternatively, several functions may be combined into one exercise.
Detailed CRP Schedule
Once the script has been developed as above, the necessary details may be added to the CRP schedule. A weekly CRP schedule should have been developed in the Project Definition phase. This schedule is used as a basis for the detailed CRP schedule, which now includes a daily list of functional areas to be piloted.
An example of a Detailed CRP Schedule follows on the next page. The example combines our CRP schedule from the Project Definition phase and our Function List from earlier in this Phase. This detailed schedule example is only for the financial software (General Ledger, Accounts Payable, and Accounts Receivable) portion of the CRP.
Sample Detailed CRP Schedule
Financial Software Portion of CRP
|
DATE
|
APPLICATION/ FUNCTION
|
LOCATION
|
PARTICIPANTS
|
|
April 30 |
General Accounting / Budgeting |
Main Conference Room |
Steve, Cindy, Mary, Ted |
|
G/L Transactions |
|||
|
May 1 |
G/L Inquiries |
Main Conference Room |
Steve, Cindy, Mary, Ted, Frank |
|
Financial Reporting |
|||
|
May 2 |
Accounts Payable Setup |
Main Conference Room |
Steve, Cindy, Mary, Frank |
|
A/P Vouchers |
|||
|
A/P Payments |
|||
|
May 3 |
Accounts Receivable Setup |
Main Conference Room |
Steve, Cindy, Mary, Frank |
|
A/R Invoices |
|||
|
May 4 |
A/R Receipts |
Main Conference Room |
Steve, Cindy, Mary, Frank |
|
A/R Reports |
|||
The Conference Room Pilot should be conducted according to the schedule developed in the previous activity, Define CRP Scope and Exercises. Keeping the pilot on schedule is critical. Rescheduling the sessions "on the fly" will cause disruptions to the personal schedules of the participants, and decrease the level of confidence that the project team has in project management.
The CRP sessions should be conducted in an positive mental atmosphere, encouraging openness, frank discussion, and the generation of ideas. Participants should not be personally criticized, nor intimidated by the presence of management personnel. Together, the team evaluates the fit of application software to the required functions.
Roles in the CRP
It is important that each participant understands the roles of everyone present at the CRP sessions. The following roles are appropriate for nearly any type of CRP:
Project Sponsor: The Executive Sponsor, who is ultimately responsible for the success of the project, should attend portions of the CRP, to demonstrate support and interest. One technique is to have the Executive Sponsor begin the first day with some opening remarks, stressing the importance of the project and the CRP. A discrete exit soon thereafter will prevent any participants from feeling intimidated by the presence of senior management during the sessions which follow.
Process Owner: Sometimes called an application expert or business analyst, this role may be filled by a different team member for each session. This is the person at the front of the room, executing system functions and discussing the reasoning and processing behind the proposed solution. This team member fields questions and moderates discussion concerning the application and functions being evaluated.
Correspondent: This team member is responsible for documenting important decisions or ideas which are discussed during the CRP sessions, and for logging Issue Reports. Issue Reports are discussed in the next activity, Log Issue Reports. The role of Correspondent should alternate between team members from day to day during the CRP.
Project Manager: The Project Manager should be present throughout the CRP. His role is to insure that the pilot keeps moving and stays on schedule, and that important issues are either being resolved or documented.
Coach and Advisor: An expert on the software being piloted can add a great deal of value to the CRP, provided this individual remains in an advisory posture, and does not dominate the proceedings. When package software is involved, such a resource would typically come from the software vendor.
Optimum Participation
Other interested team members or system users will attend CRP sessions as well. Care must be taken when any individual is brought into the CRP who has not been trained on the software being piloted.
The optimum number of participants in any session will vary, but as a rule of thumb, more than 10 or 12 participants can indicate that some time is probably being wasted. Sessions with more than a dozen participating people can be very difficult to manage.
On the other end of the scale, CRP sessions with as few as three participants can be very productive. However, such a small session may risk omitting a team member who will be impacted by the functions being evaluated, or who would have provided some valuable input.
Before, during, and after the CRP, Issue Reports should be written for any unresolved system issue. The nature of an issue may be technical, procedural, management, or a lack of training. An issue may indicate a software problem, or simply pose a question about how a given system requirement will be handled.
At the back of the Conference Room Pilot section of this guide is a Project Issue Report form. This form should be photocopied early in the project, and completed as questions are raised and issues are identified. A stack of blank Project Issue Reports should be kept within reach in the project work area, and in the CRP facility.
As Issue Reports are written, they should be kept in a binder which is accessible to all team members. This prevents an issue from being written which has already been logged and placed in the binder. It also gives the project manager an overall count of issues identified, and can be used to track issues as they are resolved and closed out.
At the conclusion of the CRP, any issues which have not yet been recorded should be written up. The issues should be numbered for tracking purposes and possible cross-reference from other documentation. Additionally, all logged issues should be assigned to a team member for resolution and given a priority.
The Impact Analysis section of the Project Issue Report is where notes are made concerning the estimated time and money likely to be required to resolve the issue. For many issues this type of information is not available or relevant.
Assigning issues to team members and determining priorities should be done at a meeting immediately following the CRP, with all team members present. Many issues may be actually resolved at this meeting as well.
Once the CRP is completed, a set of user procedures for the new system can be drafted. The procedures will not be finalized until just before going live, which may be several months after the Conference Room Pilot. However, it is critical to assemble a first draft of the procedures just after the CRP, for the following reasons:
Assignment of responsibility for user procedures in each functional area (General Accounting, Payables, etc.) is clearly established, long before a finished product is due.
Writing draft versions of user procedures gives the developer a very clear idea of just how large the task is, and allows time for any necessary schedule adjustments or arrangements for additional resources.
Project team resources will be extremely busy as the project's live date approaches later on. Starting the user procedures from scratch after all modifications and system testing are completed would increase the risk that procedures will be given insufficient effort or none at all. Starting procedure development after the CRP reduces the required effort in the later stages of the project.
Sources for user procedure material include:
User guides or training materials provided by a software vendor, in the case of package software.
On-line "Help" features, typically found in package software.
Design documentation, in the case of custom-developed software.
Current user procedures, as part of a checklist for completeness.
Job descriptions for positions in the departments which will use the new system.
Knowledgeable users or project team members.
The format of the new user procedures should be agreed to by the various departments which will use the new system.
Following the Conference Room Pilot, an assessment can be made of how much effort will be required for the remaining phases and activities in the project. Because of the extensive analysis work which was done as a part of the CRP, this assessment is likely to be more accurate than the one made when the original project work plan was developed.
For this reason, a thorough review of the project work plan is in order at the completion of the CRP. Areas where the work plan and estimates are most likely to change include:
Development and Programming: During the CRP, additional modifications may have been identified, Also, the requirements for interfaces to other systems may be better understood.
System Integration: In the System Test and Adjust Custom Programming activities, the level of effort will correspond to the complexity of the system and to any custom programming done. Typically, the project team has a much better feel for the level of work required in these areas after the CRP has been completed.
A Scope Impact Assessment form may be found at the end of the Conference Room Pilot section of this guide. This form is used to document significant changes in the scope of the project, which will requiire additional time, budget, or other project resources. Increases in scope are often identified during the CRP, as the capabilities of the proposed solution are examined at a detailed level.
Once the project work plan has been revised, it should be reviewed with the executive sponsor so that any changes to the project budget and schedule are clearly communicated.
At the completion of all other activities in the Conference Room Pilot Phase, the appropriate Quality Management Checklists need to be reviewed or completed.
Quality Management Checkpoints, end of Conference Room Pilot Phase:
Review & Complete Conference Room Pilot Checklist
Review & Complete Project Administration Checklist