Techniques for discovering the work context diagram?

[Nathan]

Hello.

Can you suggest any techniques for meaningfully discovering the work
context when the business doesn't really know it's current business
processes?

I recently attempted to construct a work context diagram for a
business team that manages a portfolio of 300-odd construction
projects and a budget of 14 million kiwi peso's.( I think that equates
to 10 euro).

As I had no familiarity with the teams specific business processes or
any similar functions, I asked if they for any documented business
processes. Which they didn't.

So I asked them to describe how they do their business right now.
Three months of full-time effort later, I truly regret ever putting my
hand up for this.

Cheers,

Nathan.

[Suzanne Robertson]

Hi Nathan,

I'm sure that this is a subject that lots of Volere business analysts are
interested in and have had various experiences with. In this message I will
give you my input and I hope that other users will weigh in with their own
experiences.

- When constructing a work context diagram one needs to know the goal of the
project in order to decide what to include and what to exclude. This is
where the Stakeholder, Goals, Scope strategy is useful. Without a goal it is
very easy to go off track and either miss things or spend a lot of time on
things that are not relevant.

- I assume the the name of the work is something like "The Work of Managing
a Portfolio of 300 Construction Projects. Start with that as one big bubble
and then consider what does the work need to know in order to do this work?
The answer to that should help you uncover a number of flows of input.

- Then for each flow of input consider where does this input come from? This
should help you identify each relevant adjacent system.

- Given that you have already spent considerable time analysing the How Now
view of the work you should be able to use all of that effort to come up
with the context.

- The next thing is to test your context by attempting to partition it using
business events. This will help you to break the work up into logical
functions and determine where you need to do more investigation and where
you already have enough detail.

- If you are still having trouble after employing this strategy then try
another one. Build a business data model to identify all the business data
and relationships that you think are Created, Referenced, Updated, Deleted
by the work. Put the data model (notionally) inside the work context bubble.
For each class of data ask, which dataflows need to come into and/or leave
the work in order to Create, Reference, Update, Delete this class. Add those
dataflows to the context and add the adjacent systems that they come from/go
to. From that point you should be able to do your business event
partitioning.

- Back to the first point that I made, you do need to have a well defined
goal in order to know what to include/exclude from the work context.

Finally, do not be discouraged that you have put so much effort into looking
at the current business. The amount of time you spend depends on how well
organised a business is and how much you know about it and the people who
work in it. However do try and work on coming up with the work context in
parallel with doing the investigation into current business processes. In
other words for each thing you discover about the current work ask yourself
- what does this teach me about the work context? What can I add to my
growing work context model? Do I know enough about this part of the current
work or do I need to investigate it further in order to decide how it
relates to the work context?

Have a look at the Volere articles page at
http://www.volere.co.uk/articles.htm
There are now 5 articles specifically about aspects of Volere several of
these contain hints that might be useful to you.

I hope this helps. Keep talking.

Bests
Suzanne

==============================================================
Suzanne Robertson
Principal of The Atlantic Systems Guild
suz...@systemsguild.net
www.systemsguild.com <http://www.systemsguild.com>
www.volere.co.uk <http://www.volere.co.uk>

Our new book "Adrenaline Junkies and Template Zombies - Understanding
Patterns of Project Behaviour" is the Jolt Award winner, Best General
Computing Book of 2008-2009.

http://www.dorsethouse.com/books/ajtz.html


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

[James Robertson]

Nathan,

Firstly, what you are attempting to do is hard. The sheer size of the
project means that it is complex, and has lots of data entering and
leaving. But you already know that.

One suggestion is to draw a rich picture. Try:

http://systems.open.ac.uk/materials/t552/pages/rich/richAppendix.html

The intention of the rich picture is to capture the elements of the
business, such that you can begin to scope it. Elements in this case
would be some of the things and people that the construction company
use - work crews, machines, quantity surveyors, site foremen, etc.
You show these things as icons, and connect them with the more
important connections.

A rich picture is similar to a mind map, and if you feel more
comfortable with mind maps, they use one instead of a rich picture.

This is just away to get started. You still have to convert the rich
picture to the context model. Perhaps if you did this by drawing the
rich picrture of *part* of the business and add that to your context
model, then go back and draw the RP for another part, add that, and so
on. This would sooner or later get you the compete context diagram.

I hope this helps.

James

____________________________________
James Robertson
the Atlantic Systems Guild
ja...@systemsguild.net
http://www.systemsguild.com
http://www.volere.co.uk
Twitter http://twitter.com/InReqs