Lifecycle of a typical structured project
End to end process
This following is a summary of the
end-to-end process:
 |
Determine process goals |
|
Determine end-to-end scenarios |
|
Determine sub-processes aligned to key
areas of responsibility |
|
Sign-off process owner documents for
each sub-process |
|
Sign-off process design documents for
each sub-process |
|
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.
|
What are the goals
that the process is to solve? |
|
Who is relevant to
participate in it? |
|
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:
-
Start with an end to end process model
roughly identified in the workshop, refine and agree with all
stakeholders
-
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
-
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:
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:
|
To give guidance to
how the process is to be executed (from a functional perspective) |
|
To gives audit the
opportunity to asses sub-processes’ ability to satisfy control and risk |
|
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:
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:
|
Each discrete end
state identified in the process ownership document should have its own
scenario in the process design document. |
|
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:
|
Simplify the
interactions/activity |
|
Reduce the stages of
interactions/activity |
|
Shorten the
interactions/activity |
|
Increase parallel
work |
|
Formalise a control
framework |
|
Formalise
alternative scenarios |
|
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:
|
Use the scenarios
and steps identified in process design as the starting point. |
|
Visual glossary
should form the basis of choice of screen shots |
|
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.
© 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
