I have worked in Customer Relations for a large retailer for the past 12 years and have tried to provide our many departments with the data and statistics they need to be more effective and efficient. This was a pretty hard task until we discovered QuickBase 2 ½ years ago. What was once done with spreadsheets and other basic reporting tools is now easily handled by QuickBase. I have successfully tied together departments, processes and work flows to make what was once a series of tedious tasks into a more efficient process that is helping us become “paperless.” During this time I have developed my own method for developing apps that I would like to share with you. This method works for us and it is my hope that you may benefit from our experience in designing and deploying your apps.
I’m assuming you have met with all the managers and departments involved with your new app. You have identified all the problems with their current process. You know what it is they need to track with your new app. You understand what elements are needed to track them. You understand the tables and relationships you need to make this app work. You also have an understanding of the work flow required to improve this process. It’s time to start building your awesome new app.
This is the fun part for most of us. If you’re anything like me you like to block out everything and everybody until you feel you have a good handle on this new creation. You may need to ask a question or two to key people on occasion, but for the most part it’s time to roll up the sleeves and “git-er-done.”
When it’s time to show off my interpretation of the “better solution” to their problem, I like to do it in steps with what I call the “show and tweak” method. I’m sure you all have your own ways of introducing your work to the people involved, but let me tell you how I try to keep everyone happy during this introduction phase.
Phase 1: Start with the same managers you met with in the beginning.
It only makes sense to start with the people you met with in the beginning to start this process. These are the same people who helped fill you in on the problems with their current method and the requirements they needed to correct those problems. It helps to have a list of those problems handy so that you can refer to it as you show how you have addressed each one of them in your “first draft” application.
For some, this may be their first exposure to QuickBase. For others, it will be a familiar product and process. This showing will spawn all kinds of questions and comments so be open to all of them. If there are different departments involved they will each want to see how this app will improve their life and make their day better. Explaining the work flow will generate questions that may not have been thought of in the earlier meetings. It’s very typical to add a drop-down choice or two or even extra fields during this showing. Once they actually see and hear the process step by step a “brainstorming” session is likely to occur. They may have other ideas as to how to improve it. Discuss all the ideas and write down all the “tweaks” you intend to make. Word of caution: do not let this session get too out of hand. QuickBase can’t do their work for them. If it could, why would we need them?
Phase 2: Bring the managers back with a few key end users.
After you’ve gone through the “punch list” of changes that you got from your last meeting, it’s good to meet again with the same group. I like to include key users in this next meeting. These users are going to test the app afterwards and bring back any ideas they may have on usability and what may be missing that managers didn’t think of.
This is your chance to show and explain the tweaks you just made and expose the end users to the new app and new processes involved. I find that the managers are anxious to help educate the users about what they expect. They help explain the statuses and what conditions should require each status. Example records are put in and work flow is explained in detail so that it’s a visual experience. Often the end users will have valid questions and concerns. As a group, any new change suggestions are talked about and a new “punch list” is developed.
After the meeting, I will go back and finish work on the new “punch list” and then invite the key end users to the app for testing. Testing can be from a few days to a couple of weeks. It kind of depends on how complicated the app is and any deadlines that were set.
Phase 3: Bring back managers and key users for review after test period.
At this point everyone that’s been involved is quite familiar with what’s happening. End users and managers have had a chance to use the app and have a good feel for what it can do for them. They may or may not have more of those “It would be nice if it could do this” type of suggestions. I’m never surprised when that happens.
This is usually a happy meeting. The app is really starting to feel like it’s getting “dialed in.” Everyone feels that they had a hand in making the app. When everyone is happy with any last changes it’s time to get all users involved.
Phase 4: Educating the rest of the end users.
Depending on how many people and departments are involved, it’s a good idea to get groups together in stages for education and inclusion into the app. I like baby steps here. If you get too many people together it seems to lose some effectiveness. Teaching is always better in smaller groups.
I find that I’m just a consultant in these educational meetings. The managers are teaching their people and I’m just there for questions and guidance (and a possible correction now and then). The managers will give me the names of all the end users when the meeting is over and I’ll add them to the app. There may even be more suggestions that come up with each fresh set of eyes. The merits of all suggestions are discussed again and any changes will be made before invitations are sent out. This process continues until all users are added and working the app.
Hopefully, by the end of this “show and tweak” process everyone should be content with the new app and feel a sense of “contribution.” Managers should have visibility to reports and data that they did not have before. They will be able to see data on their end users that can be used during “review” time. The end users should have confidence that their efforts on the front line are not only helping them to succeed as an individual, but also to help drive the future of their company as well.
David Vandercook is a database analyst and QuickBase developer for a large retailer.Posted in RAD Ideas | Tagged Collaboration, communication, managing teams, online database, team collaboration