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 ==^================================================================
