23/2/2008   arrow contact us printer print
  Project Design

Valid XHTML 1.0!

Designing your project

Because of the modular nature of SPRINT and the differences between different projects and organisations, the first piece of BPR work you undertake may well be on the project itself!

Throughout the project we should always reflect on our methods and revisit our objectives. Apply BPR thinking to the BPR process itself - are we adding value or are we creating waste?

Ideally the 'design' of the BPR project will be undertaken by the steering group when they first meet - and should certainly be on the agenda. However, depending on the size and scope of the project it might be the project team that undertakes it.

The formal design framework for the project is likely to follow your organisation's usual project management process, including the setting of targets, milestones and timetables, as well as allocating resources.

The informal design of the project is more concerned with discussing the appropriate tasks and techniques for the project, and should be as 'open ended' as possible, to encourage everyone involved in the project to contribute.

Consider the following:

  1. What do we already know?
  2. What resource is available?
  3. Which tasks are appropriate?
  4. How 'deep' do we need to go?
  5. Who else might need to be involved?
  6. What are our outputs?


In most projects there is usually a pay off between 'getting it done' and 'getting it right.'

Experience tells us that cutting corners at the analysis stage can have a negative impact further down the line. On larger projects, in particular, the BPR team may find understanding current business processes a daunting - and possibly endless - task. Getting access to the right people, the right processes and at the right time, and then mapping them fully can cause delays.

Because it is a modular system, SPRINT allows for this. There are a number of ways to accelerate SPRINT without cutting corners or compromising the integrity of the work.

"Parallel tasking" - in many cases it will be possible to 'parallel task', with different members of the BPR team taking on different tasks at the same time.

"Meet often and quickly" - formal meetings take time and create overheads (e.g. agendas, checking diaries). Where possible meet often and quickly. Rather than arrange a meeting for a week or two weeks ahead, use parallel tasking to meet up in a number of days - and make the meeting quick and to the point, involving only those who need to be involved, allowing the team to regularly share ideas and information.

"Share your outputs" - too many system design methods are rigid in their deliverables. With the internet and other related technologies there is no need for an avalanche of paper - and SPRINT doesn't force you to complete reams of inappropriate documentation. Set up a simple central data store, either on a shared server, a weblog or using groupware software, so that everyone has access to the information as soon as its been collected.

"BPR your BPR!" - Don't get up hung up on technique. If something's not working, reflect on why, and whether it is necessary after all. If its "too difficult" to get some particular information - that in itself might be a conclusion or offer a recommendation. The BPR team can become the first beneficiary of the BPR work.

"Horses for courses" - not every project will require the same documentation; and not everyone who has an interest in the project will need to see everything you've done. Rather than spending your resources on a comprehensive document going into great detail on all you've done, concentrate on producing an 'executive summary' and use your raw data as evidence or as back up.

back to top


Next >
< Back