Project Delivery Process D211

D211 - Plan & Prepare Prototyping Approach

DEFINITION

The purpose of this process is to plan and prepare for using the package software as a prototyping tool to design the way in which the package’s facilities will be used to meet the organisation’s business needs.

SUMMARY

This process involves the development of a prototyping approach, prototyping scenarios for each area, test cases, scheduling prototyping sessions, and developing the prototyping procedure.

PATH PLANNING GUIDANCE

This process is optional.  It is used where prototyping is conducted on a wide scale such that formalised control and planning is beneficial.

DEPENDENCIES

Prerequisites (Finish-Finish):

• Prepare / review / agree Topics / IP descriptions and sign offs (D100).

Dependent procedures (Finish-Finish):

• Configure initial model (D364)
• Build core testing data for prototyping (D383)

Dependent procedures (Finish-Start):

• Design / prototype - Implementation Papers (D400)

RECEIVABLES

• Definition of Requirements (DoR)
• Delivery Approach Definition (DAD)
• Definition of Topics (DoT)
• Business process specifications

DELIVERABLES

• Prototyping approach IP
• Prototyping cases
• Prototyping schedule
• Prototyping procedures

TOOLS

• MS Project or othe PM software
• Aris Toolset or other BPM tools, if available
• Test script definition templates

DETAILED DEFINITION OF TASKS

Develop prototyping approach

The purpose of this activity is to define the overall scope, objectives, and approach (technical and procedural) to be taken in using the base package software as a prototyping tool for the design of the business solution.  The objective is to support the iterative design prototyping that is used in Process D400 (individually for each topic) to:

• refine requirements,
• consider options,
• agree an approach, and
• determine the detail of that approach.

It should be determined which functions and features of the software to focus on in order to target future prototyping appropriately.  Also, procedures should be set in place that define the method for determining which suggested changes can be implemented.  Further steps will rely on the procedures established in the prototyping approach, so there should be sufficient detail to guide the set-up of the package modules, prototyping procedures, and session schedules.

These may include:

• detailed objectives and criteria for acceptance (ie, major design issues in question - performance assessment, screen format/navigation, tool evaluation, process functionality),
• scope (business units, functions and processes, types of customers, etc),
• participants,
• extent of simulation,
• process approach (how sessions are scheduled and controlled), and
• technical approach (tools for building and running prototypes).

The prototyping approach would normally be defined and agreed in the form of an implementation paper (see Process D400 for a generic description of the format and usage of Implementation Papers).

Develop prototyping scenarios (each area)

Using the defined prototyping approach, procedural scenarios that will be used in the prototyping of the software with respect to one business area or site should be developed and described.  Each scenario is designed to show how the package handles a specific business situation and may involve one or more procedures and various package functions and features.  Where appropriate, alternate scenarios should be developed to explore differences in current procedures and those implicit to the package software.  Level of detail should be sufficient to guide scenarios for business process to be evaluated and presented in a text and / or matrix format.  Clearly define specific functional processes within each business area which are to be prototyped.  Each scenario should include:

• policy and procedure issues addressed,
• description of business situation, including procedures and controls, triggering and triggered events, etc.,
• conditions to be tested, and
• set-up requirements (databases, equipment, etc).

Develop test cases

The purpose of this task is to develop the specific test cases to be used for each of the prototyping scenarios developed in previous steps.  It is optional whether these should be prepared in detail in advance or whether they should be left to the individual prototyping work teams to define as they go through the design process (see Process D400).

The detail should be specific scenarios to prototype all significant business processes within the overall business requirements.  This may be presented as structured text and graphics.  In order to provide this, a series of test cases may be established, providing specific storylines that cover the business processes identified.

Test cases might include:

• reference ID
• scenario and conditions tested
• initial data values
• special set-up procedures
• reference data requirements
• sequence of cases/steps to run
• expected final data values.

Schedule prototyping sessions

The purpose of this task is to identify desired participants for each business area and site identified in the prototyping  approach and to make whatever arrangements are necessary to ensure that appropriate facilities and system resources will be available per site location.  This will involve scheduling one or more prototyping sessions for each business area or site.  Scheduled dates, times, and locations of all prototyping sessions should be confirmed well enough in advance to ensure appropriate participation.  The session should go into sufficient detail to provide support for scheduling and monitoring of task work.  Each session should include:

• grouping (business area or site)
• facility resources (computer equipment, desks, terminals, etc.)
• software support and settings necessary
• necessary supporting documents or business forms to support all prototyping activities (data entry, recorded results, etc.)
• date, time, location
• participants
• advanced preparation.