[Chapter-delegates] Membership System

[James M Galvin]

I am replying to Wladek's message primarily because it conveniently 
summarizes many false statements that many people on this mailing 
list insist on repeating, over and over again.

See my comments inline below.

This message is a bit long but I decided to just get it all said, 
once again, in one message.


--On Wednesday, February 08, 2006 12:03 AM +0100 "W. Majewski" 
<wladek at isoc.org.pl> wrote:

> Dear David,
>
> > As has been mentioned, prior to purchasing the membership
> > system ISOC  conducted extensive surveys and outreach among
> > members and chapter delegates.
>
>  > The resulting ‘draft’ RFP took that feedback into
>  > consideration and the consequent final RFP was again reviewed
> by  > chapters and we received and considered their input in
> proceeding  > thereafter.
>
> Sorry but above statement are not accurate. It happend before you
> joined  ISOC so I understand that you were given a brief without
> details.
>
> No surveys were conducted.

False.

If you check the Board Meeting Summary from November of 2003 you 
will see a link in Section VIII to a presentation I gave detailing 
the results of the survey that was conducted.

Among other things, in the presentation you will find Slide 19 has 
the following list of requirements for the membership system:


* Full membership management support
* Integrated membership and financial modules
* Web enabled and Integrated with ISOC Web site
* Support for Chapters
* Event management including Surveys and Elections
* Support for Mailing Lists and Publications distributions
Committee management
* Support for dues/fees processing
* Multilanguage/Multinational support and functionality
* Cost effective Open Standards and Open Architecture technology 
(minimize dependence on vendor for future enhancements)
* Scalable and Strategic – Allows ISOC to position itself for 
today’s and future needs.


Note the requirement for support for Chapters.  If you review the 
RFP (no longer online but many of you should have a copy and for 
those who do not I would be delighted to provide you with one) you 
will see that it is there, in part because we heard you when you 
told us what you wanted.

It is worth noting that EXACTLY ONE system included the support you 
see now in the system for Chapters.  The Q system from GO that has 
now been deployed.  No other system that was reviewed allowed for 
views into the database on a per Chapter basis.  For privacy 
reasons, we had to choose between the GO system and no support for 
Chapters.

Note the requirement for dues and fees processing.  This is because 
we heard you when you said you wanted this.  The reason it is not 
in the current deployed version is an operational choice we made. 
Specifically, it quickly became apparent that accepting multiple 
currencies and moving money between countries would bury us in 
banking fees.  It was possible that after paying off all the fees 
there would be very little if any money left over.  So, this was 
left for a second phase of deployment when we could focus some 
attention specifically on this issue.

Note the requirement for multilanguage/multinational support.  This 
is because this requirement is important to ISOC as well as the 
Chapters.  This requirement was not met, at least not in this first 
phase of deployment.  The reason is because not a single one of the 
18 RFP responses we reviewed met the requirement.  That statement 
bears repeating.  Of the 18 responses we review, from 5 different 
countries with 2 of them being open source solutions, NOT A SINGLE 
ONE INCLUDED INTERNATIONAL SUPPORT in the way in which we would all 
like to have.

However, the Q system from GO, the one that was ultimately 
purchased, indicated that their system could support multiple 
languages.  It was designed for that to be true, although truth be 
told this had not been completely tested.  The Q system, which was 
a major new release of GO's software, was driven by an API and 
templates that are intended to be adaptable to other languages.  It 
was always our intention to add support for other languages in 
future phases of the deployment.



> Chapters delegates were not consulted.

False again.

Chapters reviewed the RFP before it was issued.

> No  specification of requirements was published. Call for bids
> provided  potential bidders two weeks to file detailed offer.
> Bidders were  required to build an unspecified system over six
> months. Homebrew  systems were excluded.

False again.  Note that the RFP was the specifications for the 
system and Chapters not only saw them, they review them and 
provided significant input before the RFP was released to the 
public.

Also, potential bidders were given the time they need to respond. 
I do not recall the specifics of the time frames involved but I 
suspect it was two weeks because that is pretty typical in my 
experience.  In addition, I remember giving more than one vendor an 
extension to respond to the RFP; all they had to do was ask.

Frankly, there is no reason why any vendor should have needed more 
than 2 weeks to respond to the RFP.  We were looking for off the 
shelf products and it should have been a simple matter of comparing 
our needs with what they already have and then submitting the 
details.



>
> No info about bidders and offered prices was published. Contract
> was  awarded to bidder with no experience on international
> market.  Implementation of basic functionality lasted over two
> years.

You are correct, we did not publish a list of bidders and prices. 
However, more than one response included a requirement to keep that 
information confidential.  As a non-profit ISOC was extended 
certain discounts and many did not want that information to be made 
public.  This is an entirely reasonable and ordinary business 
practice in my experience, especially since we did not state in 
advance that all responses would be made public.  Nonetheless, I 
imagine we could have published a list of bidders.

As far as no experience in the international market is concerned, 
let me repeat what I said above and have said many times before, 
NOT A SINGLE ONE OF THE RESPONSES WE REVIEWED HAD ANY REAL 
INTERNATIONAL EXPERIENCE.  It was important to us to be able to 
offer multiple languages, eventually if not immediately.  Only GO 
offered this opportunity because part of their business plan 
included expanding into international markets.  So, we fully expect 
to be supported in our quest for multiple languages as time passes.

As far as the deployment lasting two years, you are correct that is 
a very long time.  However, it turns out that the Chapter support 
GO sold us was in fact not present in the product at the time.  It 
was a classic case of "sales" failing to consult "engineering" as 
they sold us a bill of goods.  To their credit they delivered on 
their promise, which we can all be thankful for.  The alternative 
was no support for Chapters.

There were several other technical issues that arose as deployment 
began, which is to be expected when such a large and complex system 
is deployed.  I could bore you for hours with the very large 
spreadsheets that Nelson maintained so we could track things and 
make sure all issues were resolved.  Some of these issues turned up 
during testing by the Chapters.  We are, of course, thankful for 
those Chapters that took the time to use the system and provide 
such valuable feedback to us.


> Up to now no chapter declared on this list that existing system
> satisfies chapter's needs and helps it to perform membership
> management  tasks. The most favorable opinion says "it does not
> harm to much".

Even we have never said the system was perfect, or had everything 
we wanted.  We know there are going to be improvements as we move 
through the phases of deployment.  Nonetheless, the system is still 
so much better than anything we had before.


> > When we looked at web-based systems at the time (late 2003),
> > not one of  them offered all of what we were seeking and not
> > one of them was  international in scope (even though we
> > received bids from a number of  different countries) – only
> > GO appeared interested and capable of  becoming international.
>
> What do you call "international"? Why they refused to allow for
> member's  names with no-ASCII characters and scripts?

This is an overstatement of the technical problem.  This system 
does allow for alternate characters in Latin character sets.  It 
does not allow for Cyrillic or Kanji character sets, at this time.

But it is worth repeating that NOT A SINGLE ONE OF THE ALMOST 20 
RESPONSES WE REVIEWED HAD SUCH SUPPORT.  However, the GO system 
offered the opportunity to be expanded to include such support in 
the future, which is one of the reasons we decided to go with it.


> ISOC donated to them three years of free advertising plus
> $60.000 in  cash and they still were not willing to dedicate at
> least one full-time  skilled programmer to implement
> ISOC-specific requirements?

We made a strategic decision to focus on phase one deployment.  You 
can certainly criticize us for that but it was a choice and I stand 
by it.  Obviously, phase two will require some dedicated technical 
support, with multiple skills sets.


> In 2003 ISOC Polska suggested implementation and sustained
> development  of our basic free-software based system. 30 months
> later it still has  more functionality and flexibility than GO
> system despite beeing frozen  over this period.

Back in 2003 a strategic decision was made to purchase an 
off-the-shelf product.  There was no desire (and at the time no 
money available) to support development of an ISOC system.

You are free to criticize that decision but at the time it was the 
only sensible option for ISOC.


> > We were aware that the system lacked functionality in some
> > critical areas
>
> And...?

And the plan was phased deployment with each additional phase 
adding more functionality.


> > ... it should be recalled that we asked chapters
> > to float the RFP by their members and by possible vendors and
> > we also  posted the RFP on our website.
>
> When did it happen and how long it lasted? Two weeks?

Actually, the RFP preparation process was several months long, 
although frankly I do not recall the details.  It was at least 
something like July to October in 2003.

The two week timer was part of the solicitation process, i.e., we 
released the RFP and allotted two weeks for vendors to respond.


> > chapters efforts to disseminate to potential vendors. Despite
> > this no  web based system fully measured up to the requirements
> > in the RFP. Their  shortcomings were largely centered on:
>
> > The system not being international enough:
> > a. No international character sets
> > b. No currencies other than dollars
> > c. Only available in English
>
> What do you call "web based" system? Web frontend is a feature
> with no  importance. What matters is a database structure and
> procedures.

And the Q system from GO has this.


> > It bears repeating - the system does work and it is delivering
> > value to  chapters and members. Fifteen chapters have been
> > using it.
>
> It bears repeating - the system never worked. Which chapters have
> been  using it with good results?

Wladek, the fact that the system has never met even your basic 
needs is regrettable, but it is not fair to say the system has 
never worked.  In fact it does work, and quite well.

The usability may be cumbersome in some places and the use of 
English only is a limitation, but these are fixable issues and do 
not qualify as asserting the system does not work.

Keep in mind that Chapters never had any membership system support 
from ISOC prior to this system.  So, anything we have now is an 
improvement.  Granted, the quality of that improvement may be 
limited or varied for different Chapters, but this will improve as 
we move forward with our phased deployment.


> > 2. The system is not international:
> > a. Cannot use international character sets
> > b. Cannot accept currencies other than dollars
> > c. Is only available in English
>
> Oh, so how it differs from other options which were rejected due
> to  shortcomings listed earlier?
>
> List of basic shortcomings is much longer that you mention:
> - no database interface for local repositories and front-ends
> - no record of individual activity and membership history
> - no support for local events and meetings
> - no support for chapter's membership fees collected locally
> - no support for local special interest groups and their projects
> - no support for local newsletters
> - no single-sign-on functionality for local or global content and
> services - no support for local org members
> - no triggers to remind members about renowal of their membership
> ... and much more.

In order of your list above:

False.
False.
False.
False.
False.
Not sure.
Limited.
False.

Many of these features are not directly accessible to Chapters 
through their Chapter interface.  There are reasons for this and 
some of that may be addressed later.

It is true that the support that is present for Chapters is quite 
limited.  But we were thankful to get what we got, since NO OTHER 
SYSTEM INCLUDED ANY SUPPORT FOR CHAPTERS.


> Last but not least: http://members.isoc.org/PortalTools/Index.cfm
> does  not satisfy W3C standards with its tables-based design.

There are many issues with ISOC web site, but I expect all of them 
will get addressed this year.  An internal project is just 
beginning to completely revise the web site, so this will get fixed.


> > We have developed considerable experience with the GO system
>
> They were tried and found wanting.

I agree that there is work to be done.  We always knew that.  It is 
time now to put together a committee of folks who can help to 
prioritize the work to be done.



Jim Galvin
VP Chapters and Individual Membership, retired


>
> Rgds
>
> Wladek