How the Dutch Socialist Party climbed the mountain

Includes

• a short history of the Dutch Socialist Parrty
• making the transition to CiviCRM
• facing the challenges step by step

Introducing the Dutch Socialist Party
The Socialist Party in the Netherlands is a political organization that, of course, has set its goal on winning over as many people as possible to their cause.  The SP does that with the help of thousands of volunteers and members of Parliament on different levels throughout the country.

The Dutch Socialist Party was founded on the 22nd October 1972 and has made a constant rise since then which resulted in 1994 in a major breakthrough on a National level. That year two of its members were elected into Parliament. After that the growth has continued and nowadays the SP is the third biggest party in the Netherlands, in terms of both its members and seats in Parliament. At this time the SP has about 42.000 members divided over 163 local branches.

The administration which this entails has been centralized since the early nineties and is done from the party office in Amersfoort, a small town in the vicinity of Utrecht. The first steps in the field of automation were done with the help of a program that was built by one of the members of the party. When they could no longer do the job, the SP made the switch to Manyware, a program that is hosted by Ifunds which is a Netherlands based company.

After years of working with Manyware the SP ran up against its limits. New developments continued to be vague promises which caused a growing lack of confidence in the supplier. In the end the SP decided to look for a new program.

Meanwhile new ideas about software changed the preference of the organization towards open-source software instead of proprietary software. Nowadays a big part of the organization runs on open-source software, from the operating system to, by now, the membership administration.

Making the transition to CiviCRM
The search for a replacement program started in 2013 and was based on a list of demands put together by the people who had to work with the new program. After they looked at several programs they developed a preference for CiviCRM. Then it was just a matter of choosing an organization to help them make the transition. After a few demonstrations from different companies they eventually choose to work with Civicoop, a Dutch based cooperation, who is also a partner of CiviCRM.

The most important reason, from the perspective of the SP, was that Civicoop convinced them that it would be better to make the transition one step at a time instead of giving the commission to a company that could provide them with a finished product after a few months of development. In hindsight they didn't regret ever making this decision, because now the program feels like it is really theirs.

In February 2014 the team that was in put in place to make the transition came together at the start of this process and decided to have weekly meetings. After the first introduction, they described all of the processes that needed handling by CiviCRM and they ended up with about 100 different scenarios, each of which described into the last detail, step by step, what was required.

Facing the challenges step by step
The next step was to see how far the team could get by using the existing modules provided by CiviCRM and to decide what had to be custom built to meet the requirements. It appeared that they could go a long way, but one of the major problems they ran into right from the start was how to capture the party structure inside CiviCRM.

The team solved this problem by linking the postal code database to public data collected from the Dutch Central Bureau of Statistics, which helped determine to which municipality a certain city belongs. Then all the developers still had to do was to come up with a module that would enable the SP to manually connect every municipality to a local branch. Luckily that only had to be done once and after that was out of the way the team had solved a major bottleneck. From this point confidence in the flexibility of CiviCRM grew by the minute.

Another challenge they faced was the migration of all the old data to the new system. In the course of the years the database had grown to more than 148.000 unique contacts. The information concerning these contacts was being recorded in an ever widening range of different fields, which made it extra complex to say the least. How to transfer all of this into the correct fields in CiviCRM and to determine which data they would and would not take over to the new program gave the team a lot of headaches. But after a lot of work was done on writing a good script they finally managed to get the job done. The only downside to this was that all this work ensured that they had to postpone the original deadline by a few months.

This blog could go on and on about all the problems the team tackled during the year. But from the fact that the SP went live in February 2015, one can read that they withstood all these challenges. Hopefully the editors of this blog will post more information about the different modules built especially for the SP so that we can let you in on a few more riddles the team had to solve and how they cracked them. And maybe you can draw some inspiration from that.

At the moment the team is busy with the next phase, which is making CiviCRM accessible for all the local branches. When everything goes according to plan, and why shouldn't it, they will begin by training the first couple of branches of the SP on how to use the stripped version of CiviCRM in the beginning of 2016. That means there is still a lot of work to do but with CiviCRM, what else is new! There are always new avenues to explore, new modules to test or wishes to fulfill.