Arc Phases

1. Project initiation and management

Create project initiation document

The Project Initiation Document (PID) confirms the project objectives and terms of reference, and defines a structure for overall management of the project.

The purpose of the PID is to provide a concise statement that confirms the project's overall business case, timescales, resource requirements and major risk areas, and to provide a strategy for implementing the change. The PID defines:

  • Overview of the business framework.
  • Project scope, objectives and business benefit expectation.
  • Project strategic approach and policy constraints.
  • Project outline plan and resource requirements.
  • Project risks and countermeasures.
  • Summary business case.
Define project management controls

Project team roles and reporting hierarchy are confirmed, with named staff members from the organisation and external consultants allocated to particular roles. Procedures are defined for:

  • Identifying and managing ad-hoc issues and new risks.
  • Configuration management and change control of project output deliverables.
  • Formal management reporting.
Define high level and detailed plans

Planning is undertaken at two levels. The first level is the outline project plan, which is included in the PID, identifying project phases and inter-dependencies with a rough timescale for their completion. The second level of planning breaks each project phase into stages and detailed tasks. Both levels of planning focus upon the deliverable outputs required from phases/stages within the context of the agreed project strategy and policy constraints. From this basis estimates of resource requirements and timescales for undertaking projects and project stages are made.


2. Business strategy framework

Define corporate vision and goals

A Vision Statement, agreed by the organisation's executive group, is confirmed. Such a statement already exists within most organisations, but sometimes needs clarification. It will provide a reference for project outputs and guidance in establishing the project approach. It should identify the fundamental culture of the organisation, its visionary goals and the strategic approach to attain them.

Define existing business process model

An existing business process model is defined. The model should show how business processes interlink and what current business process problems exist. It should provide a rough-cut view of the operational costs associated with each business process. The relationship of business processes to the organisational structure (people and sites) should be defined and any unique site to customer/supplier/product relationships identified. Development of the business process model is normally done in a workshop environment, from the basis of a pre-defined high-level Draxmont Owl generic model:


business process model
Define process CSFs and performance indicators

Identifying the Critical Success Factors (CSFs) for each business process will provide the focus to review existing practices and redesign the future business process approach to be taken. CSFs should relate to one of two generic issues:

  • The efficiency with which the business process uses the resources assigned to it to achieve its desired outputs. Such CSFs will have Key Performance Indicators (KPIs) that represent process costs per unit of output.
  • The effectiveness, in the eyes of its external or internal (business process) customers, with which the business process meets its customer's needs. Such CSFs will have KPI's associated with product or service quality attributes.

3. Information systems and technology strategy

Define information systems and technology strategy

Information systems and technology strategies tend to be driven by an intuitive senior management decision to adopt an integrated enterprise application package in support of the organisation's core business processes. Nowadays, the principal enterprise package system vendors have also established partnerships with other third-party specialist application vendors, enabling specialist applications to integrate with the core enterprise systems. The information system and technology strategy boils down to:

  • Choosing an enterprise application package vendor who is going to stay in business and continuously develop it's products.
  • Deciding upon the extent to which third-party specialist vendor products will be required to bolt onto core enterprise applications.
  • Deciding upon the technical infrastructure architecture upon which data and application systems will be stored and delivered to users. This will include decisions on communication standards, database standards, operating system standards, and application development standards. All will have implicit skill requirements.
  • Deciding upon whether the organisation will manage the day-to-day delivery of data and applications to users itself, or whether it will subcontract this to a specialist service provider.

4. System and service selection

Defining requirements

The "information systems and technology strategy" should provide the framework for procuring hardware, systems software and application software. The strategy will constrain and provide focus for the procurement decisions. A requirements specification for application software is usually provided to potential suppliers for tendering purposes, but care should be taken to focus it to the really key issues that the application needs to address.

These days the functionality available from the major enterprise-wide package system suppliers, with their alliance partners, is sufficient to meet the needs of most organisations. Over-prescribing detailed functionality requirements during the selection process is unnecessary and will constrain the thinking required to improve the effectiveness and efficiency of business processes. The core enterprise package selected will, in itself, provide fresh ideas for improving existing business processes.

Application system selection

The decision as to which core enterprise-wide system to go for should be based upon:

  • The information systems and technology strategy.
  • The key functionality issues.
  • Implementation costs, licence fees and ongoing maintenance costs.
  • The supplier's business stability.

5. Process redesign

Form process improvement teams

Process Redesign Teams (PRTs) should be formed to review and recommend changes to the operation of one or more business processes defined within the existing Business Process Model. PRTs should include people with hands-on experience of the business process concerned and also people from other processes that interface with it. The PRTs should include people with a detailed knowledge of the functionality of the application system (or systems) that has been selected to address the business process. Some people may be involved with more than one PRT.

Conduct process improvement workshops

The overall objective of process improvement workshops should be to change the way that things are done within the business process, so that it more effectively and efficiently addresses the Critical Success Factors of the process. A key aspect in doing so should be to recognise the capabilities and functionality that can be provided by the new application system addressing it. The PRT should evaluate the process Activity Chain. Key events taking place in the Activity Chain should be identified with attribute measures such as volumes and frequency of work being handled; data security issues; and the existing organisational roles which are involved with particular activities. Opportunities for changing the way that things are done, to improve the business process, should be identified. Recommendations should be provided for:

  • Rules and Policies to be adopted within the business process.
  • Changing the process activity chain.
  • Changing roles and responsibilities.
  • Using (and not using) the new application's functionality to support the new activity chain.
  • Change implementation issues that will need to be addressed.

6. Prototype system development

Design and build a prototype system

Prototyping is concerned with configuring the new application system and using real life data to prove the working logic of the new business process design. Ideally, development of the prototype system should be conducted in two cycles.

A two-stage prototype approach will support achievement of fast and demonstrable business benefits and maintain the momentum of the project. An initial prototype design should make no attempt to alter or enhance the packaged application's vanilla functionality. Solutions for addressing business process requirements should be sought from the package system's existing functionality, utilising the inherent configurability and screen design utilities provided. The first prototype stage should meet 90% of the requirements of the new business process design. In itself, it should be capable of implementation into a live business environment, providing significant business benefits. The first prototype should be demonstrated to users. Change requirements should be critically examined and approved by a senior management team before inclusion into any second prototype stage.

Prototype steps

A number of prototype steps will be required:

  • Specifying application configuration and change requirements.
  • Programming change enhancements.
  • Application configuration.
  • Prototype database population.
  • Definition of business process transaction scripts.
  • Configuration of user access and controls.
  • Definition of test transaction data and test specification.
  • Testing by the prototype team.
  • Prototype demonstration to users.
  • Agreement of user change requirements.
  • Finalisation of application report designs.
  • Final prototype build and configuration.
  • Formal user sign-off of the prototype system.

7. Process change preparation

Define the full system's infrastructure requirements

Working with the system supplier a schematic vision of the hardware, software, database and communications infrastructure should be defined. A strategy for evolving the full systems infrastructure should be established. This should be based upon business priorities, the dependency sequence for installing the various infrastructure elements and the risks (and their countermeasures) involved in the strategy. From this a detailed project plan should be developed for installing each element of the hardware, software, database and communications infrastructure.

Establish the system management organisation

A system management organisation should be established to manage the systems infrastructure and to provide system services to Users. The size of this organisation will vary from a single individual for small installations to a full IT department of technical specialists for large installations. Conceivably aspects of system management services could be outsourced to a third party organisation. However, a "system administrator" role is likely to be retained in-house to provide a basic system configuration service and to manage user access to the applications.

Define live system implementation procedures

Detailed plans and procedures should be defined for building databases for live business use and for rolling out the use of application modules across the organisation. Key considerations will involve:

  • Synchronisation with the plans for building the technical systems infrastructure across the organisation.
  • How the initial databases will be populated and how "switch over" to maintaining these new databases and stopping the use of old databases (and their history files) will be achieved.
  • The system management and user resources required to effect "switch-over"
  • Managing initial user access to the live environment.
  • Starting the provision of on-going system management services in the live environment.
  • The implementation risks and how they might be averted.
  • Post implementation review procedures.
User training

Suppliers (both application software and technical hardware) will most likely have standard training courses available which can be used as the basis for all user and system management training. These courses should be examined, and if necessary adapted and enhanced, to construct optimal training modules for the organisation's staff. Each role defined within the new business processes should be related to the training module(s) that it requires. A training schedule should be developed and individual user training programmes defined, based upon user roles and the training modules. The training schedule and individual user training programmes should be discussed and agreed with senior user managers. Ideally, formal user training should be scheduled to complete approximately one to two weeks before users are required to use the live system.


8. Prototype system implementation

Install and test the full systems infrastructure

Application systems and databases should be loaded into a "test" system environment created on the live system technical infrastructure. Business scenarios should be defined for testing all aspects of the full system. These scenarios should be based on those defined for testing the prototype system and any subsequent scenarios used for testing enhancements and interfaces. Testing should follow a similar pattern to that conducted during prototyping.

Implement the live system

Implementation will most likely be achieved in a phased manner. Implementation phases should be established to cover a homogeneous area of business processes. The period between implementing each phase should be a minimum of one to two weeks. This will allow the core project team members to address any teething problems and provide users with adequate support. It is imperative that the core project team members are available, and seen to be available, to users during each implementation phase. They should provide support cover to users at all times when users are actively using the system. This may mean providing 24-hour shift cover (particularly in shop floor situations).

In the first few weeks of use, users will need project team members close by them, to provide on the job re-training and support. There are also likely to be minor changes required to the new business process design and other minor changes to user interface screens, reports and possibly user access rights. Project team members will have to be involved in a hands-on manner during implementation to recognise and assess these change requirements.