Project Requirements Process R010

R010 - Foundation

DEFINITION

An initial investigation is undertaken to establish the current “starting point” for the work.  It would record the current business processes, the structure of current data and the current organisation.

SUMMARY

Where the functionality of new systems being implemented is based on existing business functionality (whether computerised on not), the structured documentation of those processes (and the data which supports them) is a useful starting point for the definition of requirements.  In addition, the basic facts about the existing situation will be needed. This exercise focuses the minds of users on agreeing the status quo  - essential if it is to be the basis of the new system.

This process involves documenting or modelling:

• the organisation structure,
• the business processes, events, steps, used functionality as well as the performance of the processes, and
• data structures.

This modelling may be done by using techniques taken from structured systems analysis and design methodologies (eg ARIS), from Softtware AG, or from a package specific approach. In order to later estimate the effect of proposed solutions, it might be relevant to collect information about the performance of current business processes in terms of used resources or cost as well as achieved performance as elapsed time, processed work etc.

Emphasis should be placed on making outputs intelligible to the lay user.  These techniques are intended to be used by both analysts and users, and (particularly in the case of data flow diagrams) should be “walked through” and agreed with relevant users at each stage.  Other relevant information about current systems can be obtained through a fact-finding exercise.

PATH PLANNING GUIDANCE

This process is optional. It should be used where current practices are relevant to the proposed systems.

DEPENDENCIES

Prerequisites (Finish-Start):

• Project launch

Prerequisites (Finish-Finish):

• Review/Confirm ToR, Scope, Objectives (L010)
• Detail Segment Plan (L120)
• Staffing/Team Structure/ Organisation (L130)
• Set-up/Review User Involvement (L170)
• Set-up/Review management organisation (L180)

Dependent procedures (Finish-Finish):

• System Vision (R070)
• Final report (R150)

RECEIVABLES

• Project Constitution or other definition of project scope
• Project Organigramme

DELIVERABLES

• Analysis of Current System - part of Definition of Requirements (DoR); this may include:
• an organisation chart with functional responsibilities / roles
• business process documentation (eg process diagrams including starting and finishing event of the process, steps, used functions and data, performing organisation unit,  or as data flow diagrams with supporting descriptions)
• cost and performance measures of business processes.
• documentation of business data and its structure (eg a data model)
• detailed facts about the existing systems and business processes as appropriate.

TOOLS

• Functional Questionnaires (per application)
• Guidelines: modelling techniques
• “Orgmap”
• Computer aided software engineering (CASE) tools
• Fact finding tools:
• Applications Inventory Worksheet
• Communications Inventory Worksheet
• Hardware Inventory Worksheet
• Hardware Statistics Worksheet
• IT Spending by Resource
• IT Headcount Profile
• Staff Management Skills Profile
• Staff Operations Skills Profile
• Staff Technical Skills Profile
• Staff User Skills Profile
• Staff Experience Profile
• Application Profile Worksheet
• Application Cost Worksheet
• Interface Inventory Worksheet
• Interface Questionnaire.
• ARIS Toolset etc.

DETAILED DESCRIPTION OF TASKS

Document Current Organisation

An organisation chart should be obtained or produced covering all functions of the organisation relevant to the scope of the project.  It should include all project sponsors and major users. The chart should identify names, position / job-title, lines of reporting (solid and dotted) and (if this is not clear) functional area.  If possible it should include unofficial roles and influence as well as official relationships.  The “Orgmap” technique used within the change management processes may be used for this purpose.

It should be accompanied by brief descriptions of functional responsibilities.  It may be useful to refer to individuals’ project roles as documented in the Project Organigramme, to clarify how the various functional areas are being represented in the project team.

Document Current Business Processes

Business processes can be documented as text, but it is usually more appropriate to use modelling techniques.

Using ARIS it is possible to document:

• the company organisation,
• the company data model using ERM diagrams,
• function trees of used functionality,
• events, that trigger action within the company,
• the steps performed in the triggered business processes, and assigned organisational responsibility, functions and data to perform the step in the business process.

A widely-used technique for documenting processes (whether manual, computer or a mixture of both) is data flow modelling.  It is used by a number of structured systems analysis methodologies, and its main output is a series of diagrams which document data flows.  It provides a clarity, comprehensiveness and lack of ambiguity difficult to achieve in purely textual documentation.

The steps involved in data flow modelling current processes are:

• to establish (normally through interviews with relevant project user representatives) the documents used in the system and their sources and recipients,
• to document these flows (as “context” and “document flow” diagrams), and with the help of users to identify the system boundary (ie which flows are within outside or across the functional boundary of the system),
• to produce a high level data flow diagram showing the data stores accessed or updated by the processes within the system boundary , and to walk through this with senior user representatives to validate it,
• to “decompose” or explode processes on this high level data flow diagram in order to document the more detailed processes that make up each high-level process - these then need to be reviewed with the users to validate them,
• to produce supporting documentation (description of external sources / recipients, and inputs / outputs that cross the system boundary),
• after a logical data model (see below) has been produced, to “logicalise” the data flow diagrams (removing specific references to the physical work environment).

To assess the effect for the organisation of implementing a new system, it might be relevant to measure cost, used resource and performance of current business processes. Sometimes the major justification criteria for implementing a new system does not come from the areas originally expected, e.g. a new sales system might not be justified on a pure cost basis, but rather by the company being able to respond to customer requests more rapidly.  Some indicators include the following:

• Relevant cost and resource information might include employed capital, number of people working in the different steps of the process, amount of equipment used in the process.
• Relevant performance indicators could include:
• different time indicators like elapsed time from triggering a processes until the finishing event or work time in relation to elapsed time,
• service indicators, like number of requests served within a given time frame,
• quality information, like number of defects.

Measures and indicators should be chosen carefully to make it possible to compare the "before" and "after" situation.

Further information about data flow modelling and other modelling techniques can be found in Guidelines: Modelling Techniques.

Document Data Structure

A logical data model may be produced (if a corporate data model doesn’t exist already) to document the type of information held by the firm to support its business processes. Logical data modelling (like data flow modelling) is a well established technique used by ARIS and other structured systems analysis methodologies.  Data modelling produces logical data structures, which identify groups of related data such as clients, invoice lines etc (referred to as entities) and the relationships between them.

Once the logical data structure has been produced, it should be validated against the processes and data stores in the data flow diagrams.

Further information about data modelling and other modelling techniques can be found in Guidelines: Modelling Techniques.

Fact Finding

Other useful information, to supplement the above, can be obtained from interviews and questionnaires .  This may include:

• volumes (eg number of master file entries, transactions)
• a hardware, systems software and communications inventory
• an applications and interfaces inventory
• geographical locations / distribution (of staff / equipment)
• IT headcount / skills profile
• IT spending breakdown.

The toolkit includes a number of fact-finding tools.  These should be used as and where appropriate given the scope of the project.  The Functional Questionnaires are also available covering most application areas.  These may be used to identify areas of questioning.  Although they are used primarily to gather information regarding new requirements (see process R100), they can also be used to define aspects of the existing business systems.

The tools include:

• Applications Inventory Worksheet
• Communications Inventory Worksheet
• Hardware Inventory Worksheet
• Hardware Statistics Worksheet
• I/T Spending by Resource
• I/T Headcount Profile
• Staff Management Skills Profile
• Staff Operations Skills Profile
• Staff Technical Skills Profile
• Staff User Skills Profile
• Staff Experience Profile
• Application Profile Worksheet
• Application Cost Worksheet
• Interface Inventory Worksheet
• Interface Questionnaire.