Which steps are involved?

There are a few steps usually involved in the process of creating a custom DBMS solution. A RAD (Rapid Application Development) platform such as FileMaker Pro allows you to install some basic solution, a template, or a readymade ("business in the box") solution and start immediately, then develop the system as you work on the daily basis. This is really a great feature for some business environments as it uses minimal planning in favor of rapid prototyping. Unlike when using the System Development Life Cycle (SDLC) or "Waterfall methodologies" which is the opposite method, with RAD you could practically see your system as it is developed, adjust things as they occur and change them quickly when you want to. However, there are a few phases in the process that shouldn't be skipped in order to get to the better organized system:

Phase 1:Initial Consultation - this phase is the way to get to know all the subjects that would be involved in the project and lay the grounds for the future relationship. A lot of work of a database developer is done remotely and the communication is held over the phone or using emails, so it is not bad to meet the people involved in the process at least in this initial phase. It also provides a chance to take a quick look at the current system and go over some general ideas on what could be improved and what would be good to keep as it is. It is very good to relax people in regards to the new system and convince them that they are getting something better, which, for the users, usually means less complicated and more powerful.
Phase 2:Requirements Planning - users, managers and IT staff discuss on business needs, project scope, constraints, and system requirements. The team has to agree on the key issues and obtain management authorization before moving to the next phase.
Phase 3:User Design - during this faze users interact with the developer in order to translate user needs into working models. User design is a continuous interactive process where the DBMS developer frequently communicates with users, online or at workplace, to lay a foundation of the system. The developer can watch users perform specific tasks and comb through the finer points of the project, here what they have to say, and make a better plan allowing the developer to better understand, modify, and eventually improve a working model of the system to meet the user's needs. At the end of this faze the clear plan should be developed with attention to the detail and deeper aspects of system functionality, business processes and business logic (actions).
Phase 4:Construction - maybe this phase should be called final construction, as with RAD you would be constructing the system all the time from the phase 1. This phase is supposed to focus on program and application development, mostly like it would be done in the System Development Life Cycle (SDLC) method. Here the developer should take some time to prepare the database tables, fields and relations, setup the security levels, download and prepare necessary software, plug-ins, drivers, write the scripts, design and organize the layouts, and so on, there are plenty very important things to do before importing the actual company data and documents and handing the system to the users. However, with RAD, users usually continue to participate and can still suggest changes or improvements as actual screens or reports are developed. Actually, in the real world they usually just continue with using the system from the faze 3 and then it develops as they work. This is not the best practice as far as i am concerned and i always strongly advise against it, but at the end of the day, it will be whatever the management decides.
Phase 5:Cutover/Deployment - this includes data conversion (import), testing, changeover to the new system (if not done during the phase 4, which is not recommended, but happens a lot) and user training. By this phase, the users might be well into the system, using it and informing each other of the features, so this last phase is pretty much compiled with the previous one. Compared with traditional methods (SDLC), the entire process is compressed and the new system is build, delivered, and placed in operation much sooner. It is not rare that the system is tested in the actual live working environment, so the developer has to be careful and mindful about this strait from the phase 1 and build appropriate security features to control this process further without putting system in danger.

It is important to mention here that, although RAD methodology provides a good framework for faster project development, successful implementation often depends on project type, schedule, software release cycle and corporate culture. The RAD systems are often advertised as an "easy ride" towards getting a sophisticated database management system, which seams wrong, not only in my opinion. This methodology definitely facilitates the process and it is easier to understand and deploy, but to get to the really functional system you will still need a serious approach, with a lot of planning and a lot of hard work. Some of the largest software vendors, such as Microsoft and IBM do not extensively use RAD in the development of their flagship products and mostly still rely primarily on the more traditional "waterfall methodologies" with some degree of "spiraling", more related to RAD.