This is exactly where I start the initial investigation, Doug. Except that I think of it in terms of "client investment" rather than risk. That is:
Lowest Risk = Existing Client Involvement, including Automation. This client says things like, "We have this system that was built in dBase III+. It works well, but we need to have something web-based." Medium Risk = Existing Client Involvement without Automation. This client says things like, "We've done this for years on paper, but everyone says we could do it better with computers." Highest Risk = No Client Involvement. This client says things like, "I heard about this idea at a trade show..." I don't like talking about risk much with the client. It's good to acknowledge risk, but not dwell on it. - Jeff On Tuesday, March 26, 2002, at 10:44 AM, Douglas Smith wrote: > > 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 ==^================================================================
