Lifecycle
Home Business Change Analysis & Design Agile Testing Templates About us

Introduction
Key Principles
Lifecycle
Appendix
Back

Lifecycle of a typical structured project

End to end process

This following is a summary of the end-to-end process:

bullet

Determine process goals

bullet

Determine end-to-end scenarios

bullet

Determine sub-processes aligned to key areas of responsibility

bullet

Sign-off process owner documents for each sub-process

bullet

Sign-off process design documents for each sub-process

bullet

Define user manuals for each logical user group (these may consolidate several sub-processes)

Establishing process scope

Before any time is spent on analysing and defining process, it is essential to define the terms of reference and understand the problem domain. It is vital we are confident that we are fixing the right process, and that we understand the tools at our disposal (resource and technical) to do something about it.

bullet What are the goals that the process is to solve?
bullet Who is relevant to participate in it?
bullet What infrastructure is available to them?

These questions can initially best be answered by the sponsor of the work.

They should be then verified as part of a workshop involving the parties identified. This gives all concerned an opportunity to voice their concerns, and identify whether they need or don’t need to participate. At the end of the workshop, try and encourage the parties to brainstorm what the end-to-end scenarios and key stages of the process should look like.

To give the discussion some focus, it is often a good idea to have a very high level straw-man in your own mind of what you believe the process could be. However care should be taken in presenting this at this stage – as the discussion should not be stifled with preconceptions.

Depending on the complexity of the project, aim to get the scope phase complete and documented in 1-2 weeks. This should also include time to get review and signoff by the sponsor.

Identifying end-to-end scenarios and sub-processes

At this stage you will have identified end to end scenario(s) aligned to process goals (See the following white paper for guidance as how to do this). You will find this discipline is good at identifying responsibility and collaboration.

You may find however these end-to-end scenarios are typically too big and unwieldy to base a word document against, so don't then try and put words to each scenario at this stage. The process owner document should typically have one prime owner (and each aimed primarily to that audience), and later process design documents should typically have no more then 10 steps in it. Hence at an end-to-end level these are inappropriate.

Instead break each end-to-end process into logical stages. How this is broken down is gained from experience – too fine grained: and there is a proliferation of documents that don’t relate well to another – too course grained: the documents become complex, lack cohesion and become hard to read.

Typically a balance would be looking at discrete sub-goals of related responsibility (and can involve more than one participant) that build up to the final goal.

These stages can be named and summarised on an activity model - this is your set of sub-processes that then have owner and process design docs for them.

This analysis forms part of the process owner document, and should not be treated as a deliverable in its own right (avoid analysis paralysis). Depending on the complexity of the project, aim to get this complete in no more than 1-2 weeks.

Establishing ownership

A key benefit of this methodology is in cementing ownership - one of the key stealth issues in process definition - at the earliest stage.

The objective here is to set a “contract” that the parties can agree to. The terms of this contract can be summarised in the following figure:

Ownership should be identified in collaborative manner, and decisions formalised in a discrete deliverable as follows:

  1. Start with an end to end process model roughly identified in the workshop, refine and agree with all stakeholders

  2. Then break into logic sub-process steps. Do not make these too fine or course grained. Whilst there are no hard and fast rules having a discrete owner for each is probably the right level

  3. Deliver and sign-off process owner documents covering the sub-process goal, outputs, handovers, responsibilities and Service Levels (SLAs)

These process ownership documents are a formal deliverable, and are described in more depth in the following:

bullet Process Owner Deliverable Guidance
bullet Process Owner Template

Depending on the complexity of the project, aim to get the ownership phase complete and documented in 1-2 months. This should also include time to get review and signoff by the owners identified in the document. Sign-off is essential at this stage, and the time taken to do this should not be underestimated.

From process ownership to process design

The purpose of process design is to formalise the “what” – that is to formalise the best set of interactions between the participants to meet what was agreed in the process owner document. Considerations of “how” can be taken – but only in the functional context.

There will be one document per each process owner document. The deliverable has the following purposes:

bullet To give guidance to how the process is to be executed (from a functional perspective)
bullet To gives audit the opportunity to asses sub-processes’ ability to satisfy control and risk
bullet To specification artefacts required to support the business process (e.g. reports, business rules etc)

These process design documents are a formal deliverable, and are described in more depth in the following:

bullet Process Design Deliverable Guidance
bullet Process Design Template

A scenario based approach is taken in describing the steps in the process design document. The starting point in formalising these scenarios should be the process owner document, for example:

bullet Each discrete end state identified in the process ownership document should have its own scenario in the process design document.
bullet Each exception identified in the ownership document should have its own scenario in the process design document, since in the proc owner doc need to distinguish exception if they have different end states or participants.

These deliverables should then be workshoped in a number of sessions, with representatives from each of the areas who are currently performing it. This is so that the benefits of their experience can be included in their design.

Business Process Reengineering techniques should be applied here to not only improve the process, but to add a sense of formality and control. Such ideas include:

bullet Simplify the interactions/activity
bullet Reduce the stages of interactions/activity
bullet Shorten the interactions/activity
bullet Increase parallel work
bullet Formalise a control framework
bullet Formalise alternative scenarios
bullet Rationalise and align activity to other business process activity.

Depending on the complexity of the project, aim to get the design phase complete and documented in 3-6 months. This should also include time to get review and signoff by the owners identified in the document. Sign-off is still important at this stage, and the time taken to do this should not be underestimated.

Process design to User Manuals

User manuals are primarily written to formalise handover, and are thus describe the “how”. Unlike the process design that should only consider the “how” (if at all) in functional terms, the “how” for the user manual must be taken in physical tooling terms.

Whilst these are clearly different deliverables, the former must be written to ensure the latter is just an addition rather than re-factoring. This is done by:

bullet Use the scenarios and steps identified in process design as the starting point.
bullet Visual glossary should form the basis of choice of screen shots
bullet Further guidance in putting together user manuals can be found in the User Manual Guidance Paper

However a key difference is that each user manual should be written from one process participant’s perspective only – this ensures the entire content is relevant to the person reading it. Since process design can cut across participants, then there may be some element of consolidation involved,

Depending on the complexity of the project, aim to get the user manual phase complete and documented in 3-6 months. Sign-off is less important at this stage, but still needs to occur.

Back Next

© 2002-2007 Codel Services Ltd

This paper has been prepared by Codel Services Ltd to illustrate how structured business modelling can help your organisation. Codel Services Ltd is an IT Consultancy specialising in business modelling. If you would like further information, please contact us at: Deryck Brailsford, Codel Services Ltd, Dale Hill Cottage, Kirby-Le-Soken, Essex CO13 0EN,United Kingdom. Telephone: +44 (0)1255 862354/Mobile: + 44 (0)7710 435227/e-mail: info@codel-services.com