QuickBase Rules

It is being used by more than 500 users here, and I don't know how many different applications. I started with a Marketing Analytics group and migrated their CRM to QuickBase. Then I moved on to a research consulting organization here at the medical school and began to use it for managing projects, managing contacts in multi-site research projects, tracking hours worked, and to reconcile data queries for a clinical research project. I have consulted with other organizations that use it for tracking sponsors and billing, or as a place to coordinate conferences, maintain records of consultations or requests for information, and other purposes. It addresses the projects that fall through the cracks, those that are important enough to accomplish, with the need for multiple simultaneous users, but for projects that aren't at the level where an enterprise system would be in the budget.

Our organization has achieved this. There have been some failures, some applications that probably shouldn't have been built in the first place, but most are used and have increased efficiency for us. The failures seem to have deployment problems, primarily. When you build a QuickBase application, you typically don't have a kick-off meeting and then celebrate going live with a party. You just build it, then you immediately start testing, rolling it out, fixing problems, adapting it to change or requests, etc. So if you have to overcome some sort of user reluctance, or enemies somewhere in the organization, it can be more difficult. That is not QuickBase's fault, of course. On the plus side, if a project fails, the sunk costs are much smaller, too.

I think that to develop a program in QuickBase, you have to be interested in databases and applications, you have to understand the process you are attempting to model, and have had some experience with building a database application before. When I developed my first application, I did not get any help from IT personnel. I built a QuickBase application to replace a CRM that my organization had been using for several years. I used that application a model, but got rid of some of the complexity in that system that my organization did not need. It took me about two months to build and test the system, create documentation, migrate the data from the old system, and train (about 30) users, including the time I spent watching tutorials, reading online documentation, etc. If I had had more training in database development, javascript or jquery, it would have been a much better application. But it got the job done.

I maintain a tracking application for our organization that manages hours spent by our consultants and generates billing reports by project. I am constantly adapting this project in response to additional needs the organization has. Since everyone in our group has access to QuickBase, it has also become a knowledge base for statistical programming, a method to track the location of various datasets, and fulfilled other needs, as well. Recently, it became necessary to track the percentage effort that researchers spend on various NIH-funded projects, so I grafted that on to the hours-tracking portion of the application. This has not seen the type of adoption that I would have liked to see. I suspect that this was because we cannot connect QuickBase to the University's Grant Award tracking system (not QuickBase's fault--it is a security policy matter).