Online Marketplace Implementation Roadmap –

practical guidance for councils considering deploying an

eCommerce system to facilitate the market for adult social

care.

A product of the Mobilising Community Capital Programme

- Shaping Community Care Markets in the West Midlands

Produced by Impact Change Solutions Ltd

Paul Johnston

September 2011

2

Introduction and context

The traditional economic concept of a market is 1“any structure that allows buyers and sellers to

exchange any type of goods, services and information. The exchange of goods or services for money

is a transaction.... There are two roles in markets, buyers and sellers. The market facilitates trade

and enables the distribution and allocation of resources in a society. A market emerges more or less

spontaneously or is constructed deliberately by human interaction in order to enable the exchange

of rights (cf. ownership) of services and goods”.

The West Midlands Market Shaping programme ‘Mobilising Community Capital’ is concerned with

the market for social care services for adults and has been set up to support the region’s efforts to

transform adult social care by creating an environment where care markets can “shape themselves

to meet needs and achieve positive outcomes”.

2The vision is for a richer, more efficient community care market, shaped around customer needs,

with a mixed economy of providers delivering real choice, better care and improved outcomes.

Through the personalisation of social care, significantly more ‘buyers’ of services are entering the

market in their own right, rather than as passive recipients of services bought by the state on their

behalf. This has the potential to significantly impact the nature of service provision as ‘sellers’

respond with increasingly personalised and tailored services to meet individual needs.

This assumes that buyers are well informed about the availability, services, quality, etc. of sellers and

are enabled to transact for the services that best meet their needs and resources. The sector-led

partnership agreement ‘Think Local, Act Personal’, like its predecessor ‘Putting People First’,

recognises the importance of information and advice services:

3“Targeted joint prevention strategies and effective provision of information and advice will be

critical to support the changes to service delivery models. Providers - large and small - will need to

offer an increasingly flexible and wider range of good value services developed with the people who

use them, with the independent sector greatly extending its reach.”

The Law Commission goes further, recommending that 4“… statute should place duties on local

authorities to provide information, advice and assistance services in their area and to stimulate and

shape the market for services.” Councils have made significant progress in developing their

information and advice services (for example, see 5West Midlands Information & Advice Services

Case Studies) and many are now considering further enabling people who use services by adding a

‘transactional module’ to their information systems – allowing people to research, find, compare

and purchase care services from within a single, integrated system.

This guide has been produced to help those councils to take forward their desire for such an

integrated eMarketplace by offering a rapid implementation roadmap that can be used as the basis

for local project planning.

1 Wikipedia

2 West Midlands Market Shaping programme ‘Mobilising Community Capacity’, September 2010

3 Think Local, Act Personal, January 2011

4 Law Commission no. 326, Adult Social Care, recommendation 6, May 2011

5 Harriet Mathie for Impact Change Solutions, Dec 2010)

3

Implementation Roadmap

The implementation of an Online Marketplace is likely to be a complex and costly activity (either in

terms of capital outlay or staff effort, or both) and should be approached as a major change project.

A typical project will have the following characteristics:

- A defined lifecycle, with a definite start and end date

- A defined, agreed and measurable set of outputs (the products, or deliverables, of the project)

- A set of activities to deliver the agreed outputs – note that these will not be confined to just IT

- A defined organisation, roles, responsibilities and resources

- Clear checkpoints, to involve the sponsor and stakeholders on key decisions surrounding the

project.

This roadmap does not seek to replace or undermine existing project methodologies (and assumes

that such methodologies are both in place and actively used) but rather is intended to identify some

of the key issues to consider throughout the project’s lifecycle, so that actions can be appropriately

planned without unnecessary delay to the project.

Whilst the project lifecycle adopted by individual councils may differ slightly from the one presented

in figure1 below, it describes the typical activities that are common to most projects and helps frame

the guidance that follows.

Figure 1: Specimen Project Lifecycle

The Implementation Roadmap provides practical guidance for each of the activities described at

each stage of the project lifecycle described above. It can be adopted for new projects and for

projects that are already underway, by determining the relevant ‘entry point’ and checking that the

previous steps have been adequately addressed.

4

Pre Project: Business Idea

Projects are typically undertaken in response to a specific set of circumstances (e.g. policy direction,

operational improvement challenge, customer demand etc) in order to explore, develop and

implement appropriate solutions that address the requirements of those sponsoring the change. At

the pre-project stage there may be a number of ‘ideas’ that might be put forward, most of which

won’t be approved as projects.

It is important to have mechanisms in place to discuss and prioritise these ideas – usually involving

‘external’ stakeholders such as service providers and people who use services – and the principles of

Productive Engagement developed elsewhere in the Mobilising Community Capital programme

should be applied before any projects are approved or given funds and resources. Remember also to

consider the possibility of working across Local Authority boundaries – most service providers and

many people who use care services will not think of the care market purely in terms of authority

boundaries!

If we consider an idea for an online marketplace, this could start with a discussion along the lines of

“how might we make it easier for people who use services to find out about the range of

community-based and statutory care services that are available to them; and how might we help

them to purchase those services directly from the relevant provider”.

In facilitating this discussion, it is important to emerge with:

A clear and shared understanding of the problem to be addressed (e.g. lack of accessible

information about care services, over-reliance on statutory agencies to identify relevant

services, inability to directly purchase services from preferred provider, etc.);

An indication that a project to further explore, develop and implement an appropriate solution is

broadly supported (i.e. is it a good idea?);

An expectation that the effect of the project would be desirable and fits with business and

community priorities (e.g. facilitating choice and control, enabling independent living, etc.);

An idea of the likely social, economic and environmental benefits arising from the project’s

success (e.g. increased wellbeing, increased efficiency, greater economic prosperity, etc.)

These outputs will be important in building support (in the form of funding and resources) for the

project.

Pre Project: Initiation

This is about securing the funding and resources need to develop a clear understanding of the

expected costs and benefits of the project and demonstrating that investment in the project is

worthwhile. Councils will have individual approval mechanisms and have delegated funding powers

to senior officers who hold departmental budgets and it is these people that Initiation is seeking to

influence. Key considerations at this stage include:

Gaining senior-level sponsorship - a Project Brief, reflecting the outputs of the ‘Business Idea’

phase, provides a helpful basis for discussion and for gaining senior level commitment and

sponsorship. Once agreed, this represents the sponsor’s expectations of the project and should

only change with the express approval of the sponsor. Sponsor support is likely to be required to

authorise the remaining Initiation activities.

5

Generating Solution Options – it is important not to narrow the options at this stage but to

explore these with a view to having further discussions about specific requirements later in the

project. For example, options to consider at this stage might include ‘in-house development’,

‘off-the-shelf purchase’, ‘strategic partnering’ etc. This could be undertaken through productive

engagement with key stakeholders and an initial view of the ‘preferred option’ may be

developed at this point (although not the specific solution, which should be identified later in

the project lifecycle).

Estimating Resource and Funding requirements - forming an initial view of the likely costs and

resources needed to deliver the project. Importantly at this stage, a firm commitment is not

being sought for whole-project costs – the purpose is merely to offer an indicative view so that

the sponsor can assess affordability in the widest context.

Identifying the Benefits – building upon the initial view of the social, economic and

environmental benefits available. Productive engagement with internal (business area, IT,

Finance) and external (Strategic Partners, Providers, Carers, People who Use Services)

stakeholders to identify the benefits available to each, in order to present a broad and inclusive

view of benefits. This could form part of a ‘planning day’ with Solution Options considered in the

morning and Benefits discussed in the afternoon.

Gaining Project Approval – at this stage it should be possible to construct an outline business

case (OBC) setting out in broad terms the reasons for investing in the project. The OBC will

reflect the problem being addressed, the sponsor’s requirements, the options considered, the

preferred solution option (in broad terms), the resource and funding estimate for the project

and the expected benefits. This information should provide the evidence basis to support, defer

or reject the project.

Not all ideas for a project will be approved – for example, a Solutions workshop for an Online

Marketplace was held in Solihull6, supported by the Mobilising Community Capital programme,

in March 2011. Whilst Initiation was halted as a better understanding of funding and resource

requirements began to emerge, the outputs from the workshop remain available to Solihull

Council and their partners should they decide to prioritise this development in the future.

Securing ‘Stage 1’ Funding – It is important that good cost control is maintained throughout an

approved project and the notion of ‘stage funding’ is recommended. This ensures that only the

money needed to develop the project up to the next agreed checkpoint is released, so that

should business conditions change or new priorities emerge, the project can be suspended or

cancelled before the total budget is committed or spent.

Initiating the Project – this is about assembling the project team and establishing Project

Governance (e.g. by forming a Project Board to steer the work), ensuring that everyone involved

has a clear understanding of the project and their role in it. A Project Initiation Workshop might

be appropriate to formally ‘launch’ the project and to introduce team members to each other.

Involve external stakeholders in project governance arrangements (e.g. specific roles on both

Project Team and Project Board).

6 Online Marketplace / PA Register Solution Options - Solihull, March 2011

6

Stage 1: Definition & Planning

Newly initiated projects necessarily have a limited understanding of what will be delivered, how and

by when. The groundwork laid in the pre project phases has been focussed on demonstrating the

case for investment – it is in the Definition and Planning phase where we describe what the project

will deliver based on a defined set of business requirements and confirms how the project will be

delivered, when and by whom.

This level of clarity also provides the basis for confirming in detail the forecast costs of the project,

which will be reflected in the Full Business Case (FBC). Some considerations for Definition & Planning

include:

Defining stakeholder requirements - a Statement of Requirements sets out the requirements of

affected internal and external stakeholders. Each stakeholder will have a particular set of

requirements of the project, all of which should be afforded equal consideration. For example in

an Online Marketplace solution, people who use services will want to be able to find, research

and purchase services that are relevant to their needs; service providers will want to market

their services and compete with other providers on an equal footing; while Local Authority IT

Managers will be concerned with system security, integration and cost of operation. The Local

Authority may wish to impose design constraints, for example around the vetting or approval of

suppliers for inclusion in the Online Marketplace service directory, or there may be specific

requirements in terms of operational ownership, branding, access etc.

Establishing the right identity for the service is important as it will convey a strong message

about ownership. For example, in the case of Solihull the Solihull Care Directory has its own

brand (ie independent of the LA or the PCT) and is operationally managed by Enable Solihull.

Thus it is positioned as a ‘community’ (rather than ‘public sector’) resource. By contrast,

Staffordshire County Council has developed its ‘Purple Pages’ as a community information

directory within its own branded website. Both approaches are equally viable and it is a matter

for requirements gathering to consider the relative merits and to identify the preferred

approach.

Requirements should be captured, discussed and prioritised then recorded in the Statement of

Requirements. This is then used to help inform the project plan and is critical to ensuring that

the solution design (produced in the next phase) is fit for purpose. A Project Definition

Workshop should be held to facilitate requirements gathering and also to identify any risks,

issues, dependencies and assumptions.

Planning the project - Having identified the business requirements and any dependencies, the

Project Manager can begin to plan the project. This should involve relevant team members and

stakeholders, particularly where they will be responsible for specified actions. Project plans

should show:

o What your project is producing and when these products will be started and completed

o Who is producing it and how

o How much effort (in units of time) is required to produce it

o When events will happen during the life of the project (including checkpoint meetings

and senior stakeholder reviews)

7

o Related plans (e.g. communications plan, training plan, stakeholder management plan,

benefits realisation plan etc.) should be developed as these represent critical

components of the overall project. Training and communications may be required for

external stakeholders – for example, if community organisations are to be involved in

facilitating access to the system on behalf of people who use services – and guidance

will need to be provided over the procedures for community enterprises wishing to

register and maintain their information within the Online Marketplace Service

Catalogue.

o In the case of an Online Marketplace, benefits are likely to be driven from uptake of the

system which in turn will depend on the ‘recruitment’ of service providers, in sufficient

numbers to make real choice available to people who use services, and on the

awareness amongst both providers and people who use services of the availability,

features and benefits (to them!) of the system. Recruitment planning and Marketing

planning should therefore feature at this point in the process, with responsibility

assigned to operational teams.

o Engage operations staff in developing the ‘Transition plan’ setting out the requirements

for handover to day to day operations and closure of the programme. This should

specify clear acceptance criteria to be satisfied before project support is disbanded.

Formalising the Business Case – the Full Business Case should provide a much more granular

view of the project’s costs and benefits, incorporating detailed financial, resource and benefits

plans. The FBC covers the entire scope of the change - for example the business case for buying a

new computer system should also take into account the impact on training, communications, job

roles, procedures, accommodation, customer interactions etc. As the FBC provides the key

evidence for decision-making it should be reviewed and updated throughout the project.

Planning the next phase - plan in greater detail the activities, milestones, funding and resource

requirements for the “Design” phase. Remember that it isn’t just the technology solution that

will need to be designed – there may be impacts in terms of business processes, organisation

structures, job roles, facilities, infrastructure etc. and these should all be planned for. Approval

of the phase plan provides authorisation for expenditure on the planned design activities.

Stage 2: Design

Detailed design work is informed by the Statement of Requirements produced in the Definition &

Planning phase. There is a range of design options that might be considered for an Online

Marketplace and each will impact to a greater or lesser extent on other elements of the business

design. Broadly solutions fall into one of five categories as follows:

Information Service - All online marketplaces are underpinned by a robust information service which

provides high quality content about the services being sought in order to enable informed choice.

Examples include the websites operated by Local Authorities, Direct Payment Support Organisations

and some Community Networks such as CDSM’s ‘People & Places’ service (www.cdsm.co.uk) and the

network site for Personal Assistants run by www.panet.com.

Signposting Service - Signposting services typically provide information about specific vacancies /

service providers and offer basic marketing and search facilities. For example, Staffordshire’s

www.carematch.org.uk allows registered service users and providers to advertise their vacancies

and provides vacancy lists to prospective employees. Worcestershire County Council has recently

8

launched a PA Register module within its ‘Carewise’ information service

(http://search3.openobjects.com/kb5/worcestershire/directory/home.page) which signposts to

registered Personal Assistants – providing a PA Profile that can help service users choose a shortlist

of candidates. Lancashire-based User Led Organisation UKPARegister (www.ukpar.org) also signposts

the services of registered PAs and these are arranged geographically to facilitate choice.

Matching Service - Some Online Marketplace / PA Register solutions go beyond simple signposting

by applying intelligent filters which serve to match the requirements of service users to the

attributes specified by providers (e.g. PA within 5 miles of B90; CRB checked; qualified to NVQ level

2, etc). Examples include iCaring (www.icaring.co.uk) and PA Pool (www.papool.co.uk), both of

which offer time-limited subscription services which allow PAs to advertise and service users to

search. In the case of iCaring, PA subscribers are rigorously checked before being allowed access to

the site, whilst PA Pool offers attractive low-cost short-term memberships (3 – 6 days duration) to

recognise that most people don’t need a year-round service.

Some DPSO’s also offer a matching service which is ‘mediated’ by advisers rather than being directly

accessible to people who use services. For example The Shaw Trust runs a back-office matching

service, maintaining a database of registered PAs and using this to search for potential candidates on

behalf of their service users. Advisors then provide the candidate list to their clients so that they can

select a shortlist of people to interview. The service works on a subscription basis and sits outside of

Shaw’s LA-contracted service.

Transactional Service - A more sophisticated offering, transactional services essentially add ‘book

and pay’ functionality to allow service users to research and select from a browseable catalogue of

services and providers and to complete and pay for their requests for support in a single visit.

Examples include www.shop4support.com, Slivers of Time (www.slivers.com) and

www.southwarkcircle.com – each of which has its own unique features built around a platform that

enables ‘trading’ to take place.

Another more local example of this type of transactional service is the Assistive Technology (AT)

portal (www.asktara.com) developed on behalf of the West Midlands councils by The Community

Gateway, a community interest company set up to improve access to AT products. Whilst currently

targeting community equipment services, this service is available across the whole of the Region

(with sign-up from all of the LAs in the West Midlands) and could potentially be expanded to include

a wider range of care services.

Interactive eMarketplace - So far each of the options considered assumes a passive role for

providers; service users carry out (or are helped with) research, find a range of providers, make a

choice and buy the service. The final option assumes a more interactive relationship between the

suppliers and service users.

Coventry City Council has been working with supply chain management company Matrix-SCM to

develop a better understanding of the supplier market and how it responds to opportunities arising

from people’s care needs. Matrix has developed a system whereby service users create a profile

describing their needs; the profile is shared amongst registered providers who choose whether or

not to ‘offer’ themselves as a potential provider, and on what terms. Service users then choose from

the offers received according to their preferred criteria. The system monitors and reports on

requirements entered and offers made and is driving significant efficiencies whilst encouraging

9

providers to develop highly personalised offers. The system also offers the potential to integrate

with other back office systems and has been developed on a ‘shared risk / shared reward’ basis, with

Matrix taking their fee in the form of an agreed proportion of the financial savings achieved.

Whichever solution is considered most appropriate, the associated design considerations are:

Business Process Design – new and revised business processes are designed around the

specified requirements. The processes affected by the introduction of an Online Marketplace

will include ‘Provide information about community-based services’ and ‘Buy community-based

services’, with the ‘customer’ of the process in both cases being people who use care services (or

their representatives). Process Development workshops should be run in order to map out the

existing (‘as is’) process and the desired (‘to be’) process and this will determine the target level

of service. A methodology for Process Design can be found in the Appendix below.

Organisation Design - Role changes may be required to support the new or updated Business

Process Design. For example, there may be ‘new’ responsibilities to ‘manage the information

flow’ between LA, Providers and people who use services, or additional posts to accommodate

increased demands on existing teams. These role changes need to be carefully managed and

communicated. HR involvement must be sought where role changes are identified and the

following ‘cost and control’ issues must be given consideration:

o Do we need to recruit new people?

o Have existing budgets been amended to reflect the required changes?

o Headcount may increase or decrease. If there are to be staff reductions, factor in the

appropriate staff and trades union consultation.

o Existing Job Descriptions may need to change – again, factor in staff and trades union

consultation.

System Design – key systems may need to be redesigned to enable the operation of the

required Business Process. For example, it may be a requirement that periodic reports are

generated to show the number or value of personal transactions conducted via the Online

Marketplace, or there may be a requirement for integration with other (e.g.financial) systems.

The system design is done after the completion of the Business Process Design. Consider the

following:

o Capture all development requirements in a Systems Development Log – this should

reflect the Statement of Requirements, Benefits Plan and the ‘to be’ Business Process

Design.

o Develop technical specifications for all development needs.

o Prioritise systems development – there may be systems dependencies that constrain

development or require that it is undertaken in a particular order. Some components

may be being built in house, while others may be being bought from an external

supplier. Be aware of ‘lead times’ to ensure that development follows the project’s

critical path. If necessary, factor in training for systems development.

o Define the technical environment requirements - The current systems environment may

not be suitable to cope with what is to be implemented for this project (e.g. existing

‘technology servers’ may be running at or near capacity). Assess the technical upgrade

requirements and define the required environment. Update project cost forecasts if

these haven’t previously included systems upgrades or if revised estimates are needed.

10

Physical Design - new office facilities and facilities changes may be required to support the

desired business process and new organisational structure. If new staff are to be recruited they

will need desk space; and it may be the case that space is to be created in civic buildings for

public access terminals or brokerage teams.

Technology Design - upgrades to Telephony, Network and Computer Hardware may be required

to support the re-designed business processes as specified in the ‘technical environment

requirements’ prepared during System Design. For example, it may be part of the design that the

council should deploy more ‘public access computers’ into community buildings in order to

facilitate access to the Online Marketplace.

Update the FBC - Each of the design components will have an effect of the project budget and

the FBC should be updated with revised forecasts and actual expenditure. The amended FBC

should be used as a basis for confirming ongoing investment in the project.

Plan the next phase - plan in greater detail the activities, milestones, funding and resource

requirements for the “Development” phase. Approval of the phase plan provides authorisation

for expenditure on the planned development activities.

Stage 3: Development

The emphasis for the Development phase shifts to the production (or “build”) of the new processes,

structures, systems, facilities and hardware as described in the Design phase. Development also

incorporates the testing of the new capabilities produced. Consider the following:

A typical system development could involve a number of phases:

o Prototype - useful for ‘proof of concept’ and also for unearthing issues where significant

risks have been identified. May not be necessary for smaller projects.

o Business Scenario Walkthrough – brainstorming a range of scenarios to ‘stress-test’

redesigned processes

o Pilot – it may be sensible to run a limited-scale version of the solution in order to identify

key issues and risks to full roll-out. Learning from a pilot phase will inform the final build.

o User Acceptance Testing – prior to full implementation, involving a range of ‘users’ to

perform a robust test of the solution to ensure that it meets their defined requirements.

Make sure that there is a good range and mix of people involved in testing.

o Final Build – this will involve making any approved changes arising from walkthrough

and user acceptance testing and preparing the technical environment for

implementation.

The emphasis is on good communications, business area involvement in organisational change

and robust testing involving a range of end-users.

Remember to place orders with external suppliers in good time to meet delivery deadlines and

in line with corporate procurement policies. Even if the design solution will involve ‘internal

development’, there may be a need to purchase additional technology capacity as identified in

the ‘Design’ phase.

Liaise with HR as necessary over any organisational / structure changes.

Liaise with Facilities Management over any required physical changes.

Update the FBC – Update the FBC with actual development costs. The amended FBC should be

used as a basis for confirming ongoing investment in the project.

11

Plan the next phase - plan in greater detail the activities, milestones, funding and resource

requirements for the “Implementation” phase. Approval of the phase plan provides

authorisation for expenditure on the planned implementation activities.

Stage 4: Implementation

The Implementation phase should be fairly short. The main task is turning on and starting to use the

new systems and processes. A period of post-live support should be provided prior to moving on to

the final ‘Closure’ phase.

Note that promotion of the new capabilities, recruitment of providers to the Service Catalogue and

uptake in use of the system are not ‘project’ responsibilities but rest with operational teams charged

with benefits realisation. The role of the project is to create the new capability – it is an operational

role to maximise its benefit. The task of delivering benefits sits outside of implementation but should

commence at this point in the roadmap and should continue through project closure and beyond.

Commence implementation – Complete the scheduled pre-implementation activities (e.g. pilot,

communications, training etc) as required to facilitate a decision to proceed to implementation.

Secure agreement to proceed – Ensure that the agreed criteria for implementation have been

met; gain operational support to proceed via an operational Go / No Go checkpoint. NB if

operational teams recommend a delay at this point, document the issues and initiate the

activities required to address them as fully as possible before proceeding with the final Go / No

Go checkpoint.

Final Go / No Go checkpoint – Report the outcome of the operational Go / No Go checkpoint

and any action taken to the Steering Committee; seek approval to implement.

Implement to Live – Implement the full solution; put post-live support arrangements into action

and monitor / manage all post-live issues raised. Escalate issues to the Project Sponsor and

Project Board as necessary.

Update the FBC - make any changes to the business case as necessary to reflect results of

Implementation and the estimated closure costs; gain sponsor approval.

Stage 5: Closure

This phase is concerned with ensuring that everything has been properly completed before shutting

the project down. Project documentation needs to be completed and archived, and any useful

lessons regarding the way the project went should be captured. Finally, there needs to be clarity

around handover of any residual actions to operational owners – including the ongoing delivery of

project benefits.

Provide post-live support – continue to offer post-live support for the period specified in the

Operational Acceptance Criteria.

Review project performance –facilitate a full post-project review, involving project participants

and other affected stakeholders. Document the outputs from the post project review and gain

sign-off from review participants.

Assign follow-on actions – identify operational owners of any outstanding issues and follow-on

actions required; gain acceptance of all follow-on actions from identified action owners.

Update the FBC - make final changes to the business case as necessary to reflect results of the

post project review.

12

Prepare project closure report - once the sponsor is happy with the post project review and

revised Business Case, the project manager should prepare for formal closure approval.

Complete the “Project Closure” report and obtain sponsor approval.

Project closed – Acceptance of the Project Closure Report marks the formal closure of the

project.

Manage benefits delivery – Benefits delivery is an operational line responsibility. Benefits

identified during project Definition & Planning, and updated to reflect the various revisions of

the project business case, should be tracked on an ongoing basis, with periodic formal benefits

reviews leading to regular updating of the benefits plan. Operational performance reporting

should reflect benefits achieved. Benefits delivery should continue until the point at which all

potential benefits have been derived.

Summary

Any project to implement an Online Marketplace will be a complex undertaking and should be fully

investigated before serious funds are allocated. Consideration should be given to the full range of

costs and benefits, involving a wide range of stakeholders – including neighbouring local authorities.

Once approved, the project should be resourced and managed accordingly.

It is likely (though not essential – for example, the project could be taken forward by a ULO or

Community Interest Company) that the Local Authority will want to lead the management and

governance of the project and this should be done according to existing Project Management

methods. The guidance included within this Roadmap should be considered and incorporated within

project plans.

A successful Online Marketplace will have a number of beneficial effects for a wide range of

stakeholders. It is essential that focus continues to be given to the delivery of these benefits beyond

the life of the project.

13

Appendix: Business Process Design Outline Methodology

The outline methodology7 proposed for each Business Process Design exercise is as follows:

Identify business drivers, e.g:

Need to enable specific Performance outcomes

Need to enable the implementation of IT system

Need to enable clarity and communication regarding business activities

Identify processes impacted

Identify the business triggers (e.g. ‘customer request’) and results

Identify the high level process blocks

Identify timescales, roles and responsibilities

Hold workshop to develop first draft process design

Begin to detail the process steps

Ensure process steps remain ‘logical’ (i.e. avoid references to physical systems,

organisational resources or other enablers)

Identify enablers (such as business rules, SLAs etc) needed to support each process step. At

this stage there is only a need to identify that an enabler is required e.g. there is no need to

define business rules unless they impact on the logic of the process.

Clarify who the stakeholders are

Identify risks and issues

Allocate actions and timescales for resolution.

Identify/nominate a process owner

Identify review and sign off process

Review and refine

Distribute draft process to workshop attendees and other stakeholders

Develop supporting information

For each process step, develop the detailed functional requirements

Articulate business rules where required

Identify (and articulate if possible)

o SLAs

o Organisational roles

o Other enablers

o Channel specific issues

o Supporting systems/manual support

o Specific audit requirements (it should not be necessary to identify all audit

requirements as this would be part of normal systems development but if specific or

unusual audit data is required then it should be identified)

7 See our report ‘More with Less’ for a more detailed guide to Process Design.

14

o Specific management information (it should not be necessary to identify all

management information requirements as this would be part of normal systems

development but if specific or unusual data is required then it should be identified)

o Security issues

o Volumetrics – forecast and actual (if held)

o Any specific assumptions, issues or requirements.

Review and sign off

Distribute or present for review/agreement by stakeholders

Obtain sign off by process owner.

Develop business and IT enablers

Develop all enablers which have been identified by the process

Undertake business scenario testing

Develop realistic business scenarios

Identify, where possible, scenarios which are likely to stress the process

Identify and document non-compliance.

When system enablers have been built and baselined the process should be mapped onto

the system to:

o Identify any gaps between the functional/non-functional requirements and the built

system

o Ensure that all process steps can be performed

Areas of non-compliance should be documented and agreement of Process Owner should be

obtained.

For workshop purposes processes should not be constrained by existing functional or organisational

boundaries as this is likely to inhibit the concept of Business Process Design. For presentation

purposes however it is suggested that process designs make use of “swim lanes” which enable the

process to be mapped onto organisational elements. For example:

Fulfill Service Request

Dat

a S

tore

s/

Ena

bler

s

Non

-

Cus

tom

er

Fac

ing

Aut

oC

usto

mer

Fac

ing

Cus

tom

er

Make

Contact

1

Receive

Contact

2

Greet

3

Identify

Reason for

Contact

4

Is It In

Scope?

5

Do

Something

Else

6

Identify

Customer

Provide

Identity

12

Capture

Customer

Details

Provide

Details

Yes

7

Identity

Witheld?

8

OK to Withold

Identity?

14

Close

Contact

13

All Appropriate

Details

Captured

Script Scope Rules

Customer

Data

Customer

Data

Customer

Data

Rules

End

No

9

Is Customer

prepared to be

Identified?

No

No

Yes

Rules

Yes

10

Customer

Known?

11

Confirm

Customer

Details

Yes

No

No

Yes

No

Yes

23