Dear Bob ... As someone who (in past years) has been guilty of building Access databases, maybe you can answer a more general question for me: When is it appropriate to use Rapid Prototyping tools to boost productivity? When is it better to remain COTS (Commercial Off-The-Shelf)? And how do you know when it is better to fundamentally overhaul a workflow instead of just automating a part of the process that had p Dear Bob … As someone who (in past years) has been guilty of building Access databases, maybe you can answer a more general question for me: When is it appropriate to use Rapid Prototyping tools to boost productivity? When is it better to remain COTS (Commercial Off-The-Shelf)? And how do you know when it is better to fundamentally overhaul a workflow instead of just automating a part of the process that had previously been done manually? Or to put it another way, are Excel macros the work of the devil? – Satan Dear Satan … When is it appropriate to use rapid prototyping tools to boost whose productivity? The programmers? Or the end-users who will benefit (presumably) from the result? As a general rule (ManagementSpeak for “The exceptions are nearly as numerous as the situations where this guidance makes sense.”) use rapid prototyping tools when nobody knows or can know exactly what they want just yet. One of the great myths of IT is that the requirements for a system that’s going to automate a previously manual (or very badly automated) business function are knowable in advance. They aren’t. So before building an expensive system, build a cheap one that works the same way so the business can gain experience and learn from it. Even better, assign a programmer to the business area to build the system and use it, side-by-side with the end-users. Doing the work is a far better way to learn what’s needed than interviewing end-users. Use COTS when everyone’s understanding of what’s needed is well-defined and there isn’t a lot of uncertainty about it. Also use COTS when it means adding a module to a software suite that’s already part of your core architecture. Which is to say, if you’re an SAP shop and need to automate (for example) project resource scheduling, don’t even think about it – use the SAP module and use its capabilities as the starting point for business process redesign. Your last question is the toughest. The diagnostic answer is to talk one-on-one with the people who do the work now and have them describe how they go about it. Don’t even bother with process mapping – just listen. If the whole thing sounds really stupid, like nobody really knows how it works and everyone expects it to collapse any second, DON’T TOUCH IT! Just kidding. If it sounds like a Rube Goldberg apparatus, serious process redesign is a good idea. Otherwise, you’re better off looking for the process bottlenecks and fixing them. – Bob ——– Technology Industry