I think that's a very helpful way to look at the process, Doug. Having
objective definitions (as you provided) would be very helpful in
convincing the client that these designations are neither pejorative nor
gratuitous. 

Steve has talked about "scenarios" that detail what task a client is
trying to accomplish. Perhaps applying a risk factor (probably with a
different name for PR purposes) to these scenarios might be the ticket.

Hal

-----Original Message-----
From: Douglas Smith [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, March 26, 2002 10:45 AM
To: [EMAIL PROTECTED]
Cc: michael; Beth
Subject: Levels of Modeling Risks and FLiP



I was thinking about modeling business processes in a prototype, and I 
realized that there are several "levels of modeling risk" as I am
calling 
them.  They reflect client familiarity with their own processes, and how

much effort needs to go into prototyping in order to get clear and 
sufficient feedback from the client.  It strikes me that processes that 
have higher risk should be budgeted much more time during prototyping.

I was wondering if anybody here would be interested in a conversation
about 
how they fit into prototyping and FLiP.  I would be interested in any 
philosophical and real-life observations.

1) Lowest Risk.  The business process is already modeled in an existing 
computer system that is being converted (to fusebox, for example).  The 
client is already familiar with computer screens and steps they need to 
take to get from A to B.  They can easily give meaningful and accurate 
advise to the programmer on exactly how they they think the new system 
should operate.  That does not mean that the old system did things the
most 
efficient way.  You may very well want to convince the client to do
things 
slightly differently.  However, it does mean that the client has a clear

understanding of the process as it is implemented by the software, and 
won't need much education and guidance.

2) Medium Risk.  The business process is already modeled in non-software

office processes and paper work, but is not modeled in any computerized 
system or software, or is partially computerized, in spreadsheets, for 
example.  The customer knows what data they want to get out of the
system, 
and they often know what they want their reports to look like, but they
are 
more at the mercy of the programmer when it comes to getting that data
into 
the system in a user-friendly way.

3) Highest Risk.  The business process not directly modeled in the
client's 
office environment.   The customer knows of some similar system that
does 
what they want, or knows about some of the potential types of data that 
could be extracted from the system, but cannot give clear and immediate 
feedback on what they really want.  The client is absolutely at the
mercy 
of the programmer and the prototyping process to produce something that
is 
meaningful.  In my opinion, you should educate the client that these
types 
of system will *almost always* require follow up releases of the
software 
down the road, as since they can't know all the limitations or 
possibilities of the system until they actually start using it.  In
other 
words, even with all the amazing things that prototyping can do, it may 
very well not solve all their problems.  Also, maybe role-playing with a

paper or manual solution, simulating the data flow and output,  would be
a 
way to do "real world prototyping" before any software-based prototyping
is 
done.

Of course, actual software system are often contain a mixture of
elements 
with different levels of modeling.  My main point is that the higher the

risk, the more you need to make sure the client is intensively involved
in 
the prototyping process.  Also, you will need to to budget or estimate
more 
time/money up front for the higher risk items.







================================================
Douglas M. Smith - Application Architect
TeraTech - Tools for Programmers(tm) - www.TeraTech.com
[EMAIL PROTECTED], ICQ: 41044319
================================================

==^================================================================
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9
Or send an email to: [EMAIL PROTECTED]

T O P I C A -- Register now to manage your mail!
http://www.topica.com/partner/tag02/register
==^================================================================



Reply via email to