Context Diagrams for extremely large projects

[Megan]

I am currently assisting on a project to replicate a very large system
(with associated business processes) from one organisation to
another. The mandate is to replicate the system exactly so the
context diagram, events etc are all being used to capture what
currently occurs as it isn't well documented. The issue is that the
system interacts with so many adjacent systems in so many different
ways that capturing the context diagram on a single page (even if that
page is a really big one) is very difficult, messy and will not be
very readable when complete.

The areas of interaction can be grouped into about 15 high level areas
(with 3-10 work areas under each). These groupings are relatively
artifical and have only been done to try to understand the scope of
the work. Each of these work areas covers what would normally be a
medium sized project. These data flows cannot be grouped at a higher
level than this without losing almost all meaning

The question is does the BA attempt to:
(1) do a giant context for all work - incredibly large and complex but
capturing full scope on one page
(2) do a context diagram for each medium level grouping (15 of them) -
large and complex with somewhat arbitrary groupings of pieces of work
(3) do a context diagram for each work area (approx 65) - manageable,
readable context diagrams but with overlapping adjacent systems and
potentially some replicated data flows on different diagrams

Any thoughts?

[George Brooke]

Hi Megan,

My sympathies... the real world meets our processes!

There are a couple of things to mention. On is the inherent difficulty of
replicating a non-documented system. It is really fraught and you may end up
pleasing no one. I would strongly recommend that you make very clear the
success criteria (obviously in a measurable way) before you go too far.
Also, as mentioned below, your analysis may uncover errors/issues in the
current system and then the decision needs to be made whether to fix the old
system, fix the new system, or replicate the issue in the new system.

Now as to your question... and a diagram being worth a thousand words. Well,
IMHO diagrams are great for overview and "picturing" what is going on.
However, I do not find them very useful for analytical work. They are hard
to maintain, difficult to spot changes and in general lead to a lot of
arm-waving when applied in areas where they are inappropriate.... as in
detail analysis.

My recommendation, from the outside of course, would be to use high-level
Context Diagrams to get the overall picture, but to resort to tabular
representations for input/output/analysis. These, together with Decision
Tables, can give a clear analytical view of the processes. When I have done
this in the past it has practically always uncovered some unknown processing
or errors in the existing system ... and this is down to the existing system
having grown by accretion rather than by design, so you might need to be
prepared for this.

If you follow my suggestion, then you will end up with a hierarchy of
diagrams and tables. The top level will be the introductory Context Diagram
( in Business-speak). The next level should be a tabular version of that,
and from then on down, into more and more detail expressed in a tabular
form, with a numbering notation for each diagram which indicates ownership.
This is a kind of hierarchic set of documents. I suppose this could be
represented in a form of the Product Breakdown Structure diagram in PRINCE2
(although that generally does not allow reuse of elements... probably not a
problem).

Cross-linked to this (presumably) could be a set of System (or Product in
Volere-speak)Use Cases which identify the functionality from the User
Perspective. Once again, you may find that the Use Case Diagram is too large
for comfort and that a tabular form is preferred. I am assuming ( big
assumption) that the Business Use Cases will be very nearly identical to
those in current use? If not, then we will probably end up with some mapping
from old to new System Use Cases. Either way, again we end up with a
hierarchical view from diagram/table to Use Cases.

Summary, Divide and Conquer!

I hope this helps


George Brooke


Oak Lodge Consulting Ltd
20 Back Road
Linton, Cambridge
CB21 4JF

Tel: 01223-890390; Fax: 0870-7063077
Mbl: 07710-325818

www.oaklodgeconsulting.co.uk

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.

[alvaro rondón]

hi megan  and all,

i think that the very smart thing about context diagram is just the effort that means to resume the macro inputs and outputs of the system in a single sheet of paper including to force it to fit it in,

for example try to find phrases that aggregate 15 areas into 7, or 6, 5, ..., etc., dispite the artificial that they seem to sound,

maybe you will find yoursef picturing a dozen of such context diagrams but sure you will the end up with one or two that better convince yourself and rest of the team,

good luck friend, thank you,

alvaro,

--
cordialmente,
alvaro rondón
0412 3611867
http://teleprogramador.blogspot.com/

[James Robertson]

Megan,

can I have a little more information? What is the context model to be
used for? And what is your objective in doing this project?

I find your explanation that you are to "replicate a very large system

(with associated business processes) from one organisation to another"

a little strange. Why not just port the code and be done with it?

If you can supply a little more on what you are doing it will help me
to come up with an answer.

BTW. I liked George's answer, but disagree with the bit about diagrams
and analysis. But we are talking about scope, so that is irrelevant.

Best regards,

James
PS I might be seeing you in Nov/Dec. Ryan S is enquiring.

___________________
James Robertson
the Atlantic Systems Guild
ja...@systemsguild.net
http://www.systemsguild.com
http://www.volere.co.uk
Twitter: VolereResources
Facebook: facebook.com/JamesStruanRobertson

Our new book: 'Adrenaline Junkies and Template Zombies' has won a Jolt
Award
Amazon: http://bit.ly/TKIoR
Dorset House: http://bit.ly/teqZR

[Megan]

Thanks for the replies,

I agree that we will definitely need to break it down hierachically
somehow. At this point the lead BA intends to do a context diagram
for each work area (my number (3) above) and then relook at the best
approach from there. This is really just to be able to plan the
approach, work out how the work can be partitioned to allow multiple
resources to work on it and to get a realistic estimate for the work.
I will pass on all suggestions on ways to break it down further.

Alvaro - I am a little reluctant to create artificial grouped flows as
I would think it would make it harder for the business to understand
and increase the liklihood of missing information. Also in terms of
an estimate it will make it look simpler than it actually is
potentially causing an underestimation of the complexity of the work.

I completely agree that trying to replicate a non-documented system is
a really tough job. We have already had a lengthy discussion on
whether we should approach this from the business requirements or by
detailed documenting of the techincal aspects of the current system.
Clearly both methods have draw backs, however the approach has been
taken to attack it top down (ie from the business requirements) with
strong technical verification and analysis for each area. Needless to
say that even with fantastic planning this is going to be messy!

Thanks for the help and any more thoughts will be gratefully received!

Cheers,
Megan

[gbcambridge]

Hi Megan,

further to the response from James, above. He has a point. If you just
port the code you (should ) end up with the same system as before on
the new platform.
However, when we have done this we have found that we also have the
same problems as the previous system (if the port was accurate), and
some new ones .... often that performance is down compared to the old
(usually extensively tweaked) system. Of course you can tweak again
but then you can end up with two rather different systems.
If you have the opportunity, my recommendation would be to use the old
system as a "feasibility study" for a new system, which should focus
on promoting the successes of the old system and avoiding the issues
that have been discovered. En route to doing this you will end up with
a system which you understand and "own". You can then port this back
to the original system and replace it.
Taking on the development of "the same" system when the basis is not
well defined can lead to a system which is hard to maintain and often
has to be updated in parallel with the old. You can learn a lot doing
this kind of work (when I did it, it was porting a compiler from one
system to another, then modifying it to generate code for the
different system and then compiling it though itself. It was
necessary ... don't ask!), but sometimes avoidance is better than the
cure.
Just a thought ... and James, I still prefer tables for analysis and
diagrams for concept..... but that's just me.

George

[Suzanne Robertson]

Megan,

The giant context diagram is a very effective way to expose the top level
complexity, both in terms of the number of interfaces and the adjacent
systems.

The theme for partitioning the next level down depends on what you are
trying to look at. For example you can partition the giant context diagram
to show current computer systems (and business systems if they are included
within the context) and the interfaces between them
OR
You can partition to show the functional groupings within the context
(independent of how they are implemented)
OR
You can partition to show how the new computer and business systems will be
organised in the future.

The important point here is the word OR. You cannot build one model to
illustrate all these partitionings simultaneously. It is rather like trying
to partition an orange so that it can be eaten by a football team,and turned
into orange juice and made into chocolate covered orange strips. Try to do
that with one orange simultaneously and all you get is a squishy gooey mess.

Often, especially with a large problem, you need to start with one
partitioning (usually the one that reflects how things are done now) in
order to be able to make a more functional partitioning

In my experience the context is best defined using a diagram that exposes
the inputs and outputs and their sources and destinations.

It is easiest to keep track of the next level down if you build a business
event list/table and then separately model each business event response
(business use case). However each BUC (or PUC if you are working with a
product boundary) needs to be traceable, back to the context diagram, via
the input and output flows of data. And as you get a more precise
understanding of the inputs and outputs then they should be defined in the
dictionary of terms, down to elemental level, using exactly the same names
at every level.

If you have a very large context then you often need a middle level. To find
out what this might be you usually need to produce the first event
list/table then group the events that are the most functionally related
(common appetite for stored data is a good guideline here). Then you can run
sub projects for each of the event related groups. If your sub projects are
more subjectively grouped then the interfaces between the sub projects will
be more numerous/complex and you will need to devote more overhead to
project meta-management (managing the dependencies between the projects so
that they connect consistently with each other and with the high level giant
context.

Bests
Suzanne

==============================================================
The 2009 Business Analysis Conference will be held in London 28-30
September. There will be an exciting mixture of talks and workshops
featuring sociological and technological aspects of Business Analysis.

James Robertson, Suzanne Robertson and Neil Maiden will present a workshop
on ³How Business Analysts can be Innovative when Gathering Requirements².

For details of all the talks have a look at

http://www.irmuk.co.uk/ba2009/




Suzanne Robertson The Atlantic Systems Guild Ltd.
11 St. Mary's Terrace London
W2 1SU UK
mail: suz...@systemsguild.com
phone: +44(0)20 7262 3395
http://www.systemsguild.com


==============================================================

[Mark Wallace (Los Angeles)]

I'm going to play Devil's Advocate here.

It is entirely unclear to me that any viable cost justification exists
for any business analysis (architecture, requirements) work on this
project, whatsoever. Also, your description of the situation fails to
mention some critical success factors that could easily negate any
advice that anyone might give based on our guesses as to what is
really happening. Let's start from the beginning.

Organization A (OrgA) is currently operating a large system (LS).
Organization B (OrgB) wants to implement this exact same system (LS).
My default process for this is:

1. Clone the hardware and software required to run LS from OrgA to
OrgB.
2. Populate the cloned database(s) of LS with OrgB's reference and
(as desired) historical data.
3. Train the OrgB users to use LS.
4. Train OrgB's IT department to support the LS technology stack (if
they are unfamiliar with it).
5. Switch OrgB users over to LS in production.

I can imagine being able to pull this off without any context or
dataflow diagrams, or, indeed, any other form of business process
models.

Here's what you haven't told us:

1. What is OrgB running NOW (if anything) that will be replaced by
LS?
2. In the OrgA environment (if I interpret you correctly), LS is
currently interfaced to many "adjacent systems" (AS1, AS2, AS3 ...
ASn). Do these AS1 ... n systems also exist, with identical
functionality and interfaces, in OrgB's environment? If not, is the
plan ALSO to replicate those systems into OrgB, or is it to modify
OrgB's "adjacent systems" so that they end up mimicking the
functionality and interfaces of OrgA's adjacent systems? In either
case, the scope has just widened significantly.
3. Is LS a bespoke system of OrgA, or is it commercial software that
they licensed from a vendor? If the latter, to what extent has it
been modified for OrgA's use?
4. Are knowledgeable personnel from OrgA (or, if relevant, the
software vendor) available to train the OrgB users and IT department?

My guess, based on what little I can infer of your circumstances, is
that the most difficult work will be in my steps #2 and #3, above.
Step #2 seems to require some data architecture (but no process
architecture) work to plan the conversion from OrgB's existing database
(s) to the new ones that LS requires. I am inclined to run step #3
one screen or report (perhaps grouped by OrgB job description) at a
time, training the OrgB users to use LS. I would simply keep a list
of all the screens and reports in LS, and, when the users had been
trained in all of them, declare victory. My experience is that
business process models don't help much, if at all, in this sort of
effort.

Since your team has been ordered to replicate LS into OrgB EXACTLY, I
would keep all business process improvement issues off the table until
LS is up and running in OrgB. The only exception would be if there
are "disaster areas" where it is common knowledge that LS is currently
behaving in OrgA in a way that constitutes a major threat to bottom
line profitability. Those should be called to the attention of OrgB
management, with the question, "Are you sure you want to continue
doing it just this way?" In other words, if you discover that LS is
putting OrgA out of business, there is a professional duty to
challenge the order to replicate exactly. Otherwise, it's not the
prerogative of the project team to launch a kaizen effort at this
time. Worse, the delays involved might well end up killing the entire
project (and that wouldn't be the first time). And, if the only value
of business process models is in support of kaizen, then they
shouldn't be done at all. In that case, the entire discussion in this
forum of how best to do them is moot.

I understand that business process improvement can yield improved
profits. However, that isn't for your project team to decide.
Management may be perfectly satisfied with an inferior system (LS "as-
is") rather than open Pandora's Box by tinkering with it for the next
decade or two. And, I use "Pandora's Box" literally. Especially in a
large and poorly documented system (e.g., LS), any kind of tinkering
may invoke the Law of Unintended Consequences in a way that OrgB will
come to regret profoundly. As Bill Gates is reported to have said,
"Shipping is a feature." If, in the future, management of OrgB
decides that it does want functional changes to LS, they will have to
weigh the cost of assembling the documentation (including business
process documentation) required to do so safely, against the expected
benefits of the changes.

So, if I were brought in to run this project, my first announcement
would be that I was dismissing all of the business analysts and hiring
some experts in data architecture and some in end-user training. I
would let the latter group tell me what documentation they required to
complete their mission. In other words, I would allow documentation
only on a demand basis (i.e., someone has identified a specific task
that can't be completed without it). If the trainers don't need
business process models, so be it. Now, if there's something you
haven't told us that would make this course of action a bad idea, I'm
all ears.

Mark

[Megan]

Why we are not just porting the code:
Organisation A currently does all the functionality required. These
functions now need to be done by Organisation B instead, who already
do some of the functions (for another customer) though with no
guarantee that they will produce exactly the same results as
Organsation A wants. Tied up in this is also the need to replicate
business processes and establish service agreements - so it is wider
than just the code. Also once Organisation A has documented what is
required, Organisation B may then decide to not do some bits of it
hence the repercussions of this need to be known.
In terms of the reasons for the move ... Organisation B recently
purchased Organisation A
I hope this makes sense!

Suzanne - do you then think that the giant context will be of value?
We do already have a middle level fucntionality grouping (from some
previous work) but as always there is no guarantee that nothing has
been missed...

James - the context model is to be used to ensure we capture the full
scope of the work and hence don't miss any functionality (business or
IT) when documenting. Our objective in this process is broadly as
laid out above but in a nutshell is: to move all functionality and
associated business processes (from A to B) without reducing service
levels or otherwise impacting the customer. Note that the services
and customer impact is focussed on the ongoing system not impacts from
the actual move (that is a whole other kettle of fish). and yes
we do hope to see you at the end of the year :-)

George - unfortunately we are operating under the directive to just
'replicate' as quickly as possible and not look at improvements

Thanks for all the great input!

[James Robertson]

Megan,

"Organisation A currently does all the functionality required. These
functions now need to be done by Organisation B instead, who already
do some of the functions (for another customer) though with no
guarantee that they will produce exactly the same results as

Organsation A wants ... Organisation B recently purchased Organisation
A.."

Taking into account what Mark said, I wonder if this is in fact
something that a business analysts should be involved with.

If OrgB purchased OrgA, then why cannot OrgB simply command OrgA to
keep on doing what it is doing, but do it for OrgB's customers *as
well*. Increase the staff if needed.

This is certainly one of the most intriguing situations set for this
group.

Cheers,

James

[gbcambridge]

Hi Megan,

I can see that this project has got you quite used to complexity, you
are now answering three comments at a time.

Now, without a lot of detail I doubt if I can usefully comment
further.. apart from one thought that occurred to me in reading your
last answer. I guess I am becoming concerned about the assumptions on
which the "clone this system" request has been made. It might be
worthwhile attempting to uncover just what they are. I suspect that
the idea is that this (system cloning) is the cheapest way forward. I
am beginning to doubt if this is true. It might be a case of throwing
in a technical solution when in fact, as James outlines, the real
challenge is for the analysts and business people to get a working
system in place. There is the possibility that rather than face the
problems (which are likely to be large and political) they have thrown
the task into the technical arena for solution.
Having done that, and even if you succeed with the technical work, it
does not mean that the political / organisational problems will go
away. The organisation may impede, refuse to accept, etc., etc., what
you deliver ... for many reasons. generally not technical. There is
the real risk of failing even though you have (in a local sense)
succeeded.
I don't want to open the PRINCE2 can of worms here, but because this
is such a common problem, PRINCE2 addresses this very well with the
appoint of a Project Management Board, and clear responsibility for
the success of the PROJECT, not just the technical part (see SU, IP
and DP in particular in PRINCE2, also the Organisation chapter).
So, if you can, verify the basic assumptions, and get them clearly set
out and understood. Check that political / organizational issues are
being dealt with in a time frame that gives your project a chance.
That is, identified, owned, and a plan in place which coordinates with
your plans, to deal with them. To get buy-in and force any hidden
problems to the surface, go for iterative releases of your product,
not a Big Bang release, and make sure that senior people in both
organisations are involved and accountable. The alternative,
involving late discovery of the above issues and the lack of authority
to sort out organisational challenges, is just chilling and could
leave you very exposed.

As James finished his email, Cheers.


George

> ja...@systemsguild.nethttp://www.systemsguild.comhttp://www.volere.co.uk

> Twitter: VolereResources
> Facebook: facebook.com/JamesStruanRobertson
>
> Our new book: 'Adrenaline Junkies and Template Zombies' has won a Jolt  
> Award
> Amazon:http://bit.ly/TKIoR

> Dorset House:http://bit.ly/teqZR- Hide quoted text -
>
> - Show quoted text -

[Megan]

Sounds like my attempt to add more information made it even more
confusing! I shall try again:

To start with: OrgA's current system is working well and the only
driver for change is that OrgB wants to take on OrgA's core systems
with an anticipated long term plan of one IT department (OrgB's) and
OrgA's customers effectively absorbed into OrgB but still with the
OrgA brandname. Basically OrgA is to be absorbed into OrgA
(regardless of whether OrgA's systems are more effective than
OrgB's). Yes this is me being cynical but that appears to be the plan
- as I said I am merely consulting on the analysis for this project
not directly involved.

To my understanding; until the current (OrgA) system is known, no
decisions on solution will be finalised. This will presumably enable
OrgA to argue against the transfer if it is not a viable solution.

Mark's questions/assumptions:

1. What is OrgB running NOW (if anything) that will be replaced by

LS? - OrgB has no intention of replacing their current system. They
do a reasonable proportion of the functionality already (though as I
said this is likely to differ somewhat from OrgA) and want to
incorporate all OrgA's functionality as well.

2. In the OrgA environment (if I interpret you correctly), LS is
currently interfaced to many "adjacent systems" (AS1, AS2, AS3 ...

ASn). - OrgB's new LS will have to interface to OrgA's AS1...ASn.
Most of these involve external contracts and customer interfaces like
ATMs so the AS1...ASn cannot be moved to OrgB at this point in time.

3. Is LS a bespoke system of OrgA, or is it commercial software that

they licensed from a vendor? - I believe it was created by OrgA

4. Are knowledgeable personnel from OrgA (or, if relevant, the
software vendor) available to train the OrgB users and IT department?

- yes I expect so

Other points:
The impact on OrgA of moving LS but still having it interface to
OrgA's adjacent systems is not known.
This is high impact, secure, customer related system and hence the
move must be handled carefully. Current services must be replicated
to same level or greater (the general impression is that OrgB does not
do this to OrgA's current standard)
There is a large IT Services component to this to support not just the
system itself but any issues with the adjacent system devices
(particularly the customer facing devices)

So given these restrictions do you still believe Business Analysts
should not be involved? I'm inclined to think so however I guess I am
somewhat biased :-)

[Suzanne Robertson]

Megan,

Given my understanding of your situation, here are the analytical tasks that
I think are necessary. I have linked this back to your original question
about context.

1. Analyse what OrgA's current business is doing.
- Start by drawing a context diagram to identify the business interfaces. Be
careful not to miss dependencies between OrgA and the rest of the business
and any external organisations.

- Address managing the volume/complexity by doing a functional partitioning
driven by business events. Group functionally dependent events if you need a
middle level due to volume. You can use an event table as a way of
identifying and managing event grouping. A business data model would also be
a big help in identifying funtionally related groups. You could illustrate
the event groups and dependencies in a level 1 diagram. If you do this be
sure to have the same net inputs and outputs as you have on the overall
context diagram, failure to do this will result in lots of single minded sub
projects.

- For each functional group identify who (stakeholder analysis) needs to be
involved in providing business and technical knowledge about that part of
the functionality.

2. When you have a good enough understanding of OrgA, then follow Mark's
advice and compare OrgA and Org B to determine what changes you will make.
Use your business events as a vehicle for doing this mapping. For each
business event response (BUC) covered by Org A, compare with Org B and
identify commonality. Determine which parts of Org B will be changed given
your decision about that BUC.

3. Produce a context diagram showing the overall business context of the
part of the OrgB business that you will be changing, regardless of whether
it is a human or computer system. This will provide the basis for managing
the project and planning the design and implementation.

The business analyst needs to be involved to:
- identify the business problem/opportunity
- involve the right stakeholders at the right time
- make sure everyone stays on the same track


Good luck
Suzanne

[Megan]

Thanks Suzanne - that sounds like a good way forward.

Thanks All for your replies - you've been a great help not just for
this project but for next time something of this nature/scale comes
up!

I'll endeavour to remember to post the actual process we used (and how
successful it was) when we're done, just for your interest.

If you have any brainwaves in the mean time I'll keep checking back,

Thanks,
Megan

[Gb2009]

Hi Megan,

I agree with George Brooke. The context diagram is a good
communication tool to help you and the stakeholder understand the
system/work boundaries.(scope)

George

[Mark Wallace (Los Angeles)]

The two biggest risks that I can see are:

1. A hint of contradiction in the orders coming down from OrgB
management. On the one hand, the "mandate is to replicate the system
exactly" from OrgA into OrgB. On the other hand, "once OrgA has
documented what is required, OrgB may then decide to not do some bits
of it." The project seems to be running more like an implementation
than a replication, by which I mean that the OrgA systems and
procedures are to be studied carefully, and then converted to run in a
manner that suits OrgB's preferences. However, the Sword of Damocles
hanging overhead is that, if the time and cost to perform those
studies exceed OrgB's patience or budget, OrgB management may well
trot out the dictum that this was supposed to be an exact replication
(even though they had tolerated the studies for a while), and sack the
entire project staff ("What were you people thinking?") on the spot.

2. On a more strategic level, it seems that OrgA has been doing
rather a better job with LS than OrgB has been doing with its own
comparable system. OrgA's "reward" for this is to see its employees
(the very ones who are responsible for the superiority of LS) made
redundant, and its operations transferred (in some way or other) to
OrgB. I call this the "neutron bomb" strategy of acquisition. (You
know, the bomb that kills all living creatures in the target area, but
leaves the structures intact.) Someone should tell OrgB that the real
asset isn't LS, but the employees who created and operated it in a
superior fashion.

One is reminded of Sir Anthony Gloster's comment:

"They copied all they could follow, but they couldn't copy my mind,
And I left 'em sweating and stealing a year and a half behind."

OrgB isn't stealing anything (they bought it), but they have failed
utterly to realize that the real assets here are the minds of the OrgA
staff.

And this message of consolation to OrgA: Sorry, but where OrgB is
concerned, no good deed goes unpunished.

Mark

[Rob]

Megan:

A couple of comments on you overall project.

It is very hard to "replicate" a "very large" system. You may
understand the features (use cases), but it is likely you don't
understand how those features are used (scenarios). Users are often
very innovative about using features for "non-intended" purposes. If
you simple "replicate" the features, you may not properly support the
scenarios. So, you need to really understand the scenarios as well as
features. It is likely that their is a large body of innovative
users.

On the other hand, "very large" legacy systems often have features
that no one uses any more. Don't waste effort replicating them.

It is likely that the interfacing systems have changed a lot since you
legacy system was first deployed. You may want (need) to re-engineer
those interfaces, not simple replicate them.

Finally, "very large" legacy systems are often feature rich. It is
almost impossible to "replicate" them in the first release of a new
system; so your transition plan is often key to your successful
implementation.

This is very hard stuff.

Rob

[Nathan]

Hello everyone, and Megan in particular.

I posted a similar topic a while back and received some useful
guidance from both of the Robertsons about discovering the processes.
A couple of observations / considerations:

1. You or your team will have to know the specific business processes
in place at the moment, to be supported by the future product.
Sophisticated processes do not easily lend themselves to articulation,
and in the case of supporting existing business processes will need to
be discovered in detail.

2. Given you are under orders to do it fast, do the existing business
processes and to not improve things, why not write down the current
procedures and use that to guide your analysis/development work?

3. Combine top-down analysis with bottom up detail - top-down tells
you where you look ie the breadth and scope of business processes; and
bottom-up tells you which business procedure document to transcribe
into the event, business use case and product use cases. Perhaps you
can copy and paste existing procedures, thereby avoiding features no
longer used, and capturing features used in novel ways.

Cheers and good luck,

Nathan.