Analysis Questions Current membership data What it must do Current situation Design Requirements I. Necessary requirements II. Desired requirements III. Would-be-nice requirements IV. Brainstormed requirements not listed at higher levels Development Implementation Evaluation

Membership database discussion page

 

This page is for continuous ADDIE of the membership database. Please feel free to add or change anything you see fit.

 

2009-05-17--The board agreed today that everybody will add to the Membership Database Design Requirements section by Saturday 2009-05-23. David will post a complete requirements document to all board members by 2009-06-04, and at the board meeting somebody will propose it for a vote. After the board of directors thus "signs-off" on the requirements, David will go to work developing and implementing a database that meets all of the necessary, some of the desired requirements, and probably none of the Would-be-nice requirements (2009-05-17, David)

 

Note: not everybody speaks "database". But everybody does have talents that we need. In other words, you can contribute your own aspects to the design. One thing that is important is objectives. Most of the requirements I have thought of so far are not very measurable. If you can think of ways to make them measureable, I am sure it would greatly increase our chance of a successful design.

 

Another area we could use a lot of help in is project management. There are all kinds of things I have seen but do not know how to do, like phases, planning of time and other expenses, being realistic. I know we have a new board member with an MBA in project management, and I am sure several other people with project management expertise, and that success coaching expertise some of you have could probably be very useful, too.  PB Works, the host of this wiki, has some ideas posted on the main site about how to use wikis for things like project management and organizational operations (they even thought of some ways to have meetings and voting on a wiki. See their Help and Solutions pages: http://pbworks.com/solutionfinder.wiki). So, please chip in and develop this project with DeeAnn and me in the ways you know about the most.(2009-05-17, David).

 

Analysis

 

Currently the membership databases are in 3 different files (at least). Procedures are not written down, they are ambiguous, and they are complicated. DeeAnn asked David in May 2009 to help ADDIE a unique membership database with designed functions that could greatly simplify operations (2009-05-17 David)

 

 

 

The current procedure is too ambiguous and complicated:

1.     Process new/renewed memberships received through Chapter (at meetings, mail-in, phone, etc.

 

 

o    Local & National Memberships received by Treasurer

 

 

§  Forward member information to Membership Chair

 

 

§  Membership Chair logs information into Excel Spreadsheet

 

 

§  Membership Chair sends welcome/thank you email letters

 

 

§  Membership Chair forward member information to Membership committee member for personal contact

 

 

§  Membership Chair forwards member information to committee member responsible for updating CHAMPS

 

 

§  Membership Chair forwards member information to Marketing/Communication Chair, CVent administrator to add to email distribution list

 

 

o    Chapter Activity Reports from National

 

 

§  These are forwarded to the Membership Chair once a week by Jeannette Lindsey

 

 

§  Membership Chair logs information into Excel Spreadsheet

 

 

§  Membership Chair sends welcome/thankyou email letters

 

 

§  If membership is for local chapter, Chair forwards information to Treasurer and Marketing/Communication Chair, CVent administrator to add to email distribution list

 

 

§  National sends a monthly statement listing all the members processed and a check for the dollars received. You need to get a copy of this statement so you can just recheck the names to be sure you have all of them. Joan use to find names on the statement that she had not received from National. National changes staff frequently so things fall through the cracks.

 

 

2.     Answer questions from current/potential members.

 

 

3.     Have a committee member helping at the monthly meeting registration table to not only help with registration but answer questions re membership. Put copies of membership information and application on registration table. Research/answer any problems with memberships.

 

 

Questions

 

These are questions we need answers to. If they are not answered here on the wiki whiteboard, then I will use these same questions when I  reach out to interview actors (2009-05-20, David):

 

 

Current membership data

 

Where is all the current membership data? Which files have unique data vs. the ones with merely redundant data?  (Please upload all the files, if possible, and provide links, here):

 

ASTD  national

 

This database is managed by ASTD national, itself. We have some dependencies (inputs and outputs) with this organization, but not with the database, itself.

 

C-Vent?

 

Constant Contact?

 

Various Excel files?

 

(Where are they?  Can we post them here?)

 

Other sources?

 

Do we need to research missing information by asking the members, themselves, in an email blast?  (Let's reserve this for a last-chance scenario, and design it as simply as possible if needed).

 

What it must do

 

What are all the things that the database must do (rather than listing every detail here, please revise the Design Requirements, below):

 

Current situation

 

What are the major problems of the current situation regarding the membership database?

 

Problems

• There is not one clear unambiguous list of current members.
• We do not have clear procedures for renewing memberships, or updating to and from the national database.
• Members do not have a clear way to know what email address is being used for them.
• Members do not have a clear way to know when an email was sent, and from what address, so they can check for it or troubleshoot the email.
• We are a small group with a small budget, yet we have a tendency to think big. Our solution must provide simplicity for little cost.    

 

Design

List requirements, get the board to sign off on the final requirements, and then start developing a working database (2009-05-17, David).

 

This is starting to seem more of a problem with procedures than it is a problem of database design. The database itself looks like it is going to be a basic one, but that does not automatically mean that it will actually solve our problems. Lets consider really delving into our procedures for keeping track of memberships, the member pathway from interest to joining to getting greater benefits to leaving someday. Lets make a page for each procedure and really work on it until it works. We should have high-level procedures (the fiduciary responsibilities of the position), and low-level procedures (how to use specific technology to actually acheive the hi-level procedures), and best practices (2009-05-19, David).

 

Some of the requirements we are thinking of have to do with output to other databases, and input from other databases (like Constant Contact, Quickbooks, and the ASTD national database). It may work out. However, it looks more and more like a company that pulls in $10M/year. Lets prioritize these kinds of requirements. 1st: Output or get the data thru a text file or Excel file, which can then be used in a separate process (which can be changed independently as needed). 2nd: Output or get the data automatically to or from a text file or Excel file, with almost no user intervention once the file format is set. 3rd: Output or get the data automatically working directly with the other application (2009-05-19, David).

 

Requirements

We are starting by brainstorming requirements. Please feel free to add in, move them around, color them, highlight them, add notes, add sub-lists, anything you want (2009-05-17 David).

 

I. Necessary requirements

• Simple for members to use and understand.
• Enhances the overall experience of being a member of ASTD-VOS.
• Dependable online access to all functions.
• More than one person can access the database at the same time (with one person owning one record at a time while updating).
• Dependable hosting on a server controlled by (paid for by) ASTD-Vos, not too expensive, same server as our website if possible (coordinate it all with the webmaster).
  • The prototype can be on David's server (Hostmonster) until all arrangements are made to move it successfully.
• Avoid multiple copies of a file, especially diverging ones, avoid updating multiple files. Each datum has exactly one location. Update it there, and everything else is updated automatically.

 

A. Updates

• Administrator, enter a new membership record.
• Administrator, update the membership status.
• Member or adminstrator, revise a membership record (contact information).
• Allow members to check status.
• Allow for paying for membership directly through database and sent to bank accounts.

 

B. Reports

• Administrator: A list of all members and the desired data with each one.
• Administrator: All expired memberships, all expiring memberships, etc.
• Capability to output to a text file or an Excel worksheet.
• Member: A directory of all members according to their individual sharing preferences.
• Send receipts for payment.

 

C. Security 

• Password protection to allow full access only to the Database Director, Database Administrator, and a few other people for backup purposes, perhaps the President, Past-President, and President-Elect. 
• A good fail-safe data backup plan.

 

D. Data

• First name, last name, official mailing address, official email address, member status, start date, expiration date
• History of offices held and dates
• Foto

 

II. Desired requirements

• Password access for individual members.
• Password access for different administrators to see different amounts of information.
• Facilitates all the necessary procedures in a simple, unambiguous way.
• Facilitates transfer to new officer.
• Facilitates another board member filling in.
• Robustness: If our requirements change, it will not be too difficult for the database to fulfill them. It will last a long time if needed.
• Link to Quickbooks online for receipts and enter data directly into Quickbooks.

A. Updates

Text.

B. Reports

Text.

C. Security

Text. 

D. Data

Text.

 

 

III. Would-be-nice requirements

• Is not complicated.
• Facilitates teaching of new director or temporary volunteer.
• Adaptable to new procedures when we adopt new technologies.
• Comes with a maintenance and adaptation plan, so that when changes occur, we already have sketched procedures for handling them.
• Sends an automatic welcome email to new members.
• Sends automatic renewal notices. (Would have to link to Quickbooks for this.)
• Member can update preferences such as which notices to receive, paper or email, official email address for voting, etc. (would have to link to constant contact for this)
• Members can see reports that are open to members, including membership directory with individual preferences (unlisted, name only, contact info, foto, etc.)
• Public can see a list of members according to their individual preferences (unlisted to the public, name only, contact info, foto, etc.)
• Security settings are clear. The Membership director can access all data, but other board members (President, President-elect, Past-President?) can also access all data when necessary.
• Ability to notify administrator of actions that must be taken (such as sending renewal notices).
• Ability to link to Cvent so that participants who are signing up to attend a meeting/conference, it could check to see if they are eligible for member discounts.

A. Updates

Text.

B. Reports

Text.

C. Security

Text. 

D. Data

Text.

•  

 

IV. Brainstormed requirements not listed at higher levels

• A complete board management database site that enforces Robert's Rules of Order, keeps track of all members, dates of entry and exit, official addresses, votes, online meetings, secretary's reports, and makes official reports of association decisions.
• A simple way to enter time usage, goals, goals accomplished, etc.

 

A. Updates

Text.

B. Reports

Text.

C. Security

Text. 

D. Data

Text.

 

Development

Today, the possibility of using a pre-designed online solution (like PeopleSoft or Salesforce) is growing greater each year. Since we already use Constant Contact to maintain email lists, it might be possible to use that as our sole membership database. What is important in using 3rd-party platforms is making all the procedures written and unambiguous just as if we were designing the entire thing ourselves.

 

It is starting to seem more like a website project than a membership chair project. I am starting to think that a dynamic website is the best platform for a membership database (rather than just an Access file with a web interface or a stand-alone file that stays with one person and then gets copied and emailed around--aagh!). Lets find out what the new website director knows about dynamic web sites, and see how much willingness he has to work on it alone or in collaboration. Probably there are off-the-shelf and free products that can make the development and implentation much less expensive than doing it all ourselves (2009-05-19, David).

 

Possible platforms:

• Excel file. See the proof-of-concept prototype. One person is in charge of the file and has possession of it. It is the same person who is responsible for making all updates in a timely fashion, and making all reports that are properly requested. Everything is written down in procedures for that position, high-level responsibilities, and how to get it done. Rather than sending reports, the person could send a copy of the entire file. This platform is very difficult to use to satisfy some of our requrements: Accessible by other people in case the one person cannot do the job, easily passble to the next person in the position, avoid multiple copies of a file, especially diverging ones, avoid updating multiple files.
• Access database with web interfaces. Use an Access database with web access and special web forms to make processes easy. That way anybody can access the database from anywhere, password protected. This is a pretty straightforward solution that many people know how to maintain (because Access is so standard). David has used this platform for an organizational membership database with fotos. Everything could be updated online except for the fotos. Much more research would still have to be done (as always, it seems) in to meet all our objectives (the way they are looking so far). A proof-of-concept database could be presented pretty quickly, perhaps at the June board meeting along with a list of objectives.  Write procedures for using the database and test them (2009-05-18, David).
• Constant Contact. Some email or events management system, like Constant Contact that we already use, along with our own written procedures.
• Off-the-shelf product. Find a 3rd party total solution for organizational membership management, something that does everything we need. If it exists and it is robust and meets our needs, it could be very inexpensive to hire them ($10-$100 per month) to maintain and improve the system, compared to getting the same functionality with our own design ($1000 to $100,000). It would still be important to write our own procedures to make sure everything is working right (2009-05-18, David)
• Dynamic website. ASP.Net? For our requirement of it being simple for the members and enhancing their overall experience, perhaps the best solution is a dynamic website. This would use a database, but the overall design would me much more website focused. This is what most organizations seem to be doing. Members log in and get customized displays and services depending upon their position and status (2009-05-19, David)
• A wiki with tables. See the Proof of concept protoype. Free hosting. Extremely inexpensive design and maintenance costs. Alphabetic index. One table on one page for each letter of the alphabet. Available on all web browsers to anybody with a registered email address (to keep our member's contact information private).  The database volunteer (I am avoiding saying Membership Director) inserts a new row and types in the information for a new record. The database volunteer updates each individual field as necessary. This platform could be up and running in one day. It, exactly like all the others, would depend upon robust, tested, working procedures for running the organization. As far as I know, there is no performance aid out there yet that helps organizations manage their procedures. We are still on our own with that part. This solution has surprising strengths. The data entry labor is almost exactly the same with any platform. With this platform, we would lose all kinds of functionality, like database queries and reports and output to other files and programmability. It's advantage is that it does the core job (having a membership database in one central location) with extremely little set-up cost. Lots of other information would go along with it such as the director's directory, and procedures. An alternative to tables would be to keep the directory as a file in a document repository on the wiki and link to it on a certain page. Procedures would be written right with it. To modify the file, you would open it and read it in Excel. Modify it. Then, upload it to the wiki and test it. Lots of other information would naturally be readily available on the same wiki, such as a director's listing, and procedures, status reports, and history logs for running the organization smoothly.  Even if the membership database is in tables rather than linked files, lots of other stuff could still be uploaded to the document repository and linked on specific pages (2009-05-19, David).

 

 

• Zen is looking into wiki-type web design for ASTD-VOS upgrade. Currently researching Joomla (previous use and satisfaction, but was not administrator) Joomla has robust features that may work for all membership needs. As I recall it has administrator and member-defined password access levels, member database, newsletters, event announcements, etc., and member signup criteria can be defined. Will know more about queriable features soon. (2009-05-25)

 

 

 

Implementation

Text

 

Evaluation

Text

 

Number of page views: