Membership Management System Toolkit - EN

ORGANISATIONAL DEVELOPMENT
MEMBERSHIP
MANAGEMENT
SYSTEM TOOLKIT
© World Scout Bureau Inc.
Organisational Development
May 2020
World Scout Bureau,

Global Support Centre
Kuala Lumpur
Suite 3, Level 17,

Menara Sentral Vista, No 150
Jalan Sultan Abdul Samad
Brickfields, 50470
Kuala Lumpur, MALAYSIA
Tel.: + 60 3 2276 9000

Fax: + 60 3 2276 9089
[email protected]
scout.org
Reproduction is authorized to
National Scout Organizations and
Associations which are members of
the World Organization of the Scout
Movement. Credit for the source
must be given.
MEMBERSHIP
MANAGEMENT
SYSTEM TOOLKIT
Table of
Contents
List of terms and concepts 6
Introduction 8
The Framework 9
Choosing the right time 10
Change Management 10
Building the team 12
Gathering requirements 20
Compare the requirements 21
Make a build vs. buy decision 21
Request a proposal 21
Evaluate the proposals and select the vendor 21
Implement the project 21
4 MEMBERSHIP MANAGEMENT SYSTEM TOOLKIT

Next Steps 22
Appendixes 23
Appendix A. NSO Self-Assessment (survey) 24
Appendix B. How to use the Scope of Requirements 28
Appendix C. Product Vision Board

(Target group, Needs, Product, Business goals) 36
Appendix D. RFP Template 40
Appendix E. Writing user stories 42
MEMBERSHIP MANAGEMENT SYSTEM TOOLKIT 5

List of terms and concepts
Term Description
Software as a Service
Software as a service is a software licensing and delivery model in which software is

SaaS licensed on a subscription basis and is centrally hosted. It is sometimes referred to as
“on-demand software”, and was formerly referred to as “software plus services” by
Microsoft.
Membership Management System
MMS Membership software (also known as an association management system) is a computer

software which provides associations, clubs and other membership organisations with
the functionality they require to provide their services to their members.
Application
app App is short for “application”, which is the same thing as a software programme. While
an app may refer to a programme for any hardware platform, it is most often used to
describe programmes for mobile devices, such as smartphones and tablets.
General Data Protection Regulation

GDPR European Union and the European Economic Area. It also addresses the export of
personal data outside the EU and EEA areas.
Payment Card Industry Data Security Standard
The Payment Card Industry Data Security Standard is an information security standard
PCI-DSS for organisations that handle branded credit cards from the major card schemes. The
PCI Standard is mandated by the card brands and administered by the payment Card
Industry Security Standards Council.
Hypertext Transfer Protocol Secure
Hypertext Transfer Protocol Secure is an extension of the Hypertext Transfer Protocol.

HTTPS It is used for secure communication over a computer network, and is widely used on
the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer
Security, or, formerly, its predecessor, Secure Sockets Layer.
NSO National Scout Organization
NSA National Scout Association
USER A person who uses or operates a system.

Admin/System Administrator - a person who manages the system
An admin/system administrator is a person who is responsible for the upkeep,

Admin configuration and reliable operation of computer systems; especially multi-user
computers, such as servers. The admin seeks to ensure that the uptime, performance,
resources and security of the computers they manage to meet the needs of the users,
without exceeding as set budget.
Role A collection of permissions defined for the entire system.
Application program interface
API In computer programming, an application programming interface is a set of sub-routine,

definitions, communication protocols, and tools for building software. In general terms,
it is a set of clearly defined methods of communication among various components.
Single Sign-On
SSO SSO is an authentication process that allows a user to access multiple applications with
one set of login credentials. SSO is a common procedure in enterprises, where a client
accesses multiple resources connected to a local area network.
MailChimp Is a marketing automation platform and an email marketing service.
Service Level Agreement
SLA A service-level agreement is a commitment between a service provider and a client.

Particular aspects of the service – quality, availability, responsibilities – are agreed
between the service provider and the service user.
Secure Sockets Layer

SSL SSL is the standard security technology for establishing an encrypted link between a
web server and a browser.
Internet Explorer (web browsers developed by Microsoft and included in the Microsoft
IE
Windows line of operating systems).
User Acceptance Testing
UAT In software development, user acceptance testing - also called beta testing, application
testing, and end user testing - is a phase of software development in which the software
is tested in the “real world” by the intended audience.
Agile Approach to software development under which requirements and solutions evolve
software through the collaborative effort of self-organising and cross-functional teams and their
development customer(s)/end user(s).

Introduction
The “Membership Management System (“MMS”) Toolkit” is designed to

be used by National Scout Organizations (hereinafter NSOs) to help them
navigate, what can otherwise seem like a complex process, of engaging
with a third-party supplier to secure a membership management system.
As part of the WSC’s Triennial Plan 2017-2020, it was highlighted

that strong and sustainable NSOs is a goal and the Good Governance
workstream supports NSOs to ensure continuous improvement. Under
this workstream a Unit was established in order to focus on developing a
Toolkit to support the delivery of a Membership Management System.
The Toolkit will guide National Scout Organizations to make a decision

associated to implementing a Membership Management System. The
Toolkit will give the NSO the ability to consider an “off-the-shelf” product
or a bespoke solution.
A Membership Management System will enable:
• To measure and demonstrate the impact of Scouting to the broader

community as well as for continuous improvement.
• Supporting and strengthening the capacity of the National Scout

Organization with regard to Good Governance principles.
• Capturing correct data in association to membership numbers for

the NSO, including collections of fees and maintenance of a historical
and updated official record of its members.
• Generate data and statistical information, which will make good

decisions for the future of the organisation.

The Framework
Specifically, the Toolkit is for NSOs who wish to use an “off-the-shelf”
existing product to assist with:
• Scoping out the standard requirements for an NSO in terms of

membership management.
• Identifying existing 3rd party software / web tools on membership

management, being mindful to include those already in use in
membership-based organisations.
• Comparing 3rd party tools against a standard scope of requirements,

developing a feature matrix enabling the NSO to easily understand
the functionality of existing tools against the “standard
requirements”.
Alternatively, an NSO may wish to develop a “bespoke” solution. The

Toolkit is also designed to provide guidance to NSOs in:
• Analysing their specific needs
• Translating needs into a proper request for proposal
• Running a proper tender and selection with software companies on

the market
• Contracting a selected supplier
• Overseeing project management during design, development and

deployment phase
• Providing guidance on maintenance after deployment (including SLAs

etc)
Framework:
1. Choose the right time to begin the process of introducing the MMS
in your NSO.
2. Change Management is imperative for the success of the

delivery of implementing the MMS.
3. Build a team of knowledgeable people to support the introduction of

the MMS in your NSO.
4. Analyse the current situation with regards to membership

management and registration processes; identify the needs and key
stakeholders.
5. Gather requirements for the MMS.
6. Compare the requirements with the solutions available on the

market.
7. Make a build-or-buy decision.
8. Request a proposal from list of vendors.
9. Evaluate the proposals and select the vendor for the system.
10. Implement the system.
11. Maintain the system.

Choosing the right time Change Management
Choosing the right time to begin It is crucial that every NSO ensures the managing of change. It is a major
this journey is an important factor part of the work required to make the project successful. The Membership
to be considered. The Management System aligned with the procedures in place will facilitate
your NSO in achieving its goals. There are decisions needed to be made
development of a new MMS for an which will impact on the way your members interact with your membership
NSO can occur for a few different processes, therefore good change management is needed. You need to
reasons: invest the time into bringing your NSO on the journey with you – a tool
which may help you in this process is provided below.
We will use a popular change model for explaining and managing the
1. The NSO does not have
process of change. This follows a five-step approach:
an MMS and would like to
implement one; or
1. Gain commitment:
2. The existing MMS no a. demonstrate commitment in leadership
longer meets the criteria
for efficient membership b. examine communication systems
management and reporting.
c. use facts rather than hype and spin
d. explain the benefits
e. explain why the changes are taking place
2. Decide where you want to be:

a. what is your vision
b. what about three years’ time
c. assign priorities
d. set objectives
e. consult as widely as possible

3. Define where you are now:
a. collect data and facts
b. talk to people – consult as widely as possible
4. Plan how to get there:

a. develop options
b. choose methods
c. plan
d. allocate tasks
e. select a project manager
f. deal with resistance
5. Implement:
a. monitor
b. adapt
Changes your NSO would

like to implement:
When managing change,

remember:
• change is a process, not an event
• get everyone involved
• publish early success
• expect it to take longer than you anticipate
• don’t expect to be able to control all factors

Building the team
Choosing the right team of people to implement the MMS is a critical
step towards ensuring the success of the project. Successful projects
take careful planning, a talented team and collaboration of a project’s
team members, both internal and external (NSO and potential vendor
representatives).
Based on the best practices we recommend that the people involved in

your team should:
• Be a small group of five to seven dedicated volunteers and

professionals. This can be flexible and may vary depending on the
size of the NSO. For some NSOs, a larger group may be needed
although the group, ideally, should not exceed 15 members.
• Have the knowledge of membership management process within the

NSO.
• Have a strong understanding of the organisational needs of your

NSO.
• Be able to compile input from different stakeholders and negotiate

priorities.
• Have a commitment to not only developing the requirements but

also following it through to the implementation and the monitoring
of the successes (and challenges) your NSO achieves throughout the
implementation.
Following the current trends, we strongly recommend using an agile

approach to the team structure and operations. In agile approaches, the
three common team roles are used:
Product Owner - responsible for guiding the direction of the product i.e.
the MMS, focusing on its “business” value for the NSO. The product owner
provides feedback and steers the direction of the next piece of functionality
to be developed. He/she works with the external stakeholders, end users,
and teams to define the project direction.

Cross-functional Team Members - team members with skills necessary
to deliver the working system. If the MMS system is delivered by a
supplier, the technical team members reside with the supplier, however,
there are usually other team members required from the NSO to assure
system acceptance and smooth transition to the production use.
Team Facilitator - this role can be called a project manager, scrum

master, project team lead etc. The team facilitator provides facilitation,
coaching and impediment removal. If the MMS system is delivered by a
supplier, the team facilitator role for the software development resides with
the supplier, however, team facilitation is usually needed from the NSO.
Suppliers / Vendors - Suppliers and vendors are third party companies

or specific people that work for third parties. They may be subcontractors
who are working under your direction, or they may be supplying material,
equipment, hardware, software or supplies to your project. Depending
on their role, they may need to be identified and included in your team.
For instance, if you are partnering with a supplier to develop your
requirements, you probably want them in your team. On the other hand, if
the vendor is supplying a common piece of hardware, you probably would
not consider them a part of the team.
Users / Testers - These are the members and people who will actually
use the deliverables of the project. These people may also be involved
heavily in the project in activities such as defining the requirements.
In other cases, they may not get involved until the testing process.
Sometimes you want to specifically identify the user organisation or the
specific users of the solution and assign a formal set of responsibilities to
them, like developing use cases or user scenarios based on the needs of
your requirements.
Finally, there are several elements in the work dynamics that are
crucial to building a productive team:
Communication: Effective communication is the most important part of

teamwork and involves constantly updating each person. Never assume
that everyone has the same information. Being a good communicator also
means being a good listener. By listening to your team, you show them
respect, which is an essential trust-building method. Collaborating and
being open to new ideas are also essential ingredients for a harmonious
team environment.
Delegation: Teams that work well together understand the strengths and
weaknesses of each team member. One of the benefits of strong teamwork
is that team leaders and members are adept at identifying all aspects of a
project and allocating tasks to the most appropriate team members.
Efficiency: A strong and cohesive team develops systems that allow them
to collaborate efficiently to complete tasks in a timely manner. Through
working together, team members will be aware of their own capabilities
and the capabilities of the group in general and can organise the workload
accordingly.
Ideas: When a team works well together, colleagues feel more

comfortable offering suggestions and ideas. A respectful and trusting team
environment will not only enable colleagues to think more creatively but
will lead to more productive and collaborative brainstorming sessions.
Support: All projects provide challenges but having a strong team

environment in place can act as a support mechanism. Building bonds of
trust and reliance on each other can be extremely important when facing a
particularly difficult challenge or if the group is forced to deal with the loss
of a team member while continuing to maintain productivity.

Analysing the current situation
Getting a comprehensive National Board - the National
understanding of the current state Board plays a supportive role in
of your NSO and the context in the project and provides strategic
which you operate, is crucial in decisions with regard to the project
terms of developing an efficient implementation and project funding.
MMS for your organisation,
stakeholders and your members. Leaders - leaders at all levels, as a
There are several steps involved in future end-user for the MMS, have
this analysis, including assessing to be informed about the project
internal capacities, requirements progress, provide feedback and be
and identifying stakeholders. trained for the use of the MMS.
The analysis shall cover the Individual Members - individual

following areas such as the members, as potential end-user for
current membership management the MMS, have to be informed about
processes, the needs of the NSO the project progress and provide
and internal capacities (human, feedback based on their experience
financial, organisational) available. from working with the system.
Part of this analysis process is to This short video provides some tools
identify the stakeholders - people and techniques on how to complete
or groups that will be impacted stakeholder analysis
by the MMS implementation
project, analyse their expectations
and impact on the project. The
usual stakeholders for the MMS
implementation projects are, but
not limited to, the following:

Creating a product vision board
A product vision board is one method to quickly and clearly set out what
you are hoping to achieve with your MMS on one page. It can be used
internally within your NSO and/or shared with software suppliers to show
what you are hoping to achieve.
By creating product vision boards with the key stakeholders in your NSO, it
can help you to articulate your vision, target user group, needs, what the
product is and your goals for the membership management system.
An example product vision board and template can be found in Appendix D.
NSO/NSA Self-assessment
This self-assessment tool can be used to help your NSO to identify if you
are ready to implement an MMS and which development route is right for
your needs.
Appendix A provides a self-assessment for NSOs to help you establish

which of the MMS project options may be best for you.
The self-assessment will take you through the following questions -
NSO/NSA Self-assessment
This self-assessment tool can be used to help your NSO to identify if you
are ready to implement an MMS and which development route is right for
your needs.
Appendix A provides a self-assessment for NSOs to help you establish

which of the MMS project options may be best for you.
The self-assessment will take you through the following questions -
• Do you already have an MMS in place?
• What is your budget?
• What knowledge, skills and expertise do you have available in or to

your NSO?
• Do you have or are you able to form a project team?
• Do you have existing structures or frameworks for managing processes

and collecting data for the following?
1. Youth programme 6. Scout places/venues
2. Awards 7. Programme planning
3. Training 8. Fundraising
4. Event management 9. Communications/Marketing
5. Finance management 10. Inventory/Asset Management
Size of your NSO?
Time available?
Can your processes change and adapt?

Options for your MMS
There are three main options available Software as a Service (SaaS),
customisation and configuration of an off-the-shelf software or a custom-
built option.
Software as a Service
SaaS (Software as a Service), is software that runs on the Internet (in the
‘cloud’). Often you will create an account and then subscribe to a service
that is provided through a website.
There are many positives to using a SaaS development in your NSO,

including:
• Leverage costs over a larger user base;
• You run your MMS and let the cloud company ensure the software is
online;
• Cost-effective;
• Backed by on-going maintenance/development;
• Shorter launch cycle;
• Greater level of resources available; and
• Ability to follow best practice.

However, this also comes with some challenges:
• You leave your data with the company operating the system (there
may be data exporting features available);
• No guarantee about how long the system will be available;
• System features can change and may cause dysfunction in your

processes;
• You may need more than one application to address all your
requirements;
• Cloud App may leave you completing more work offline to

compensate for the shortcomings of the programme;
• Costs of re-development can be more than building your own.
In short, SaaS is a great way to leverage technology for a fraction of the

cost. However, you are using a generic platform and can often compromise
your own procedures to work within the parameters of the software.
Often using SaaS can be a great solution for generic functions in your NSO
but may not always suit supporting core competencies.
Customisation and Configuration
In between SaaS and custom software, some software companies offer

their own systems however they allow for the system to be customised
and/or configured so it meets your NSO’s specific needs. There are
normally two ways this is offered, the company themselves to complete
the work requested and they charge you for this in addition to the licence
costs or they provide developer access so you can customise/configure it
yourself.
There are a few positives to this option; however, it should be approached

cautiously and knowingly.
• Leverage costs over a larger user base;
• You run your MMS and let the cloud company ensure the software is
online;
• Could be cost-effective;
• Potentially backed by on-going maintenance/development (depending

on the supplier and the options you take with them);
• Shorter launch cycle;
• You may be able to link it up with other systems you may have;
• You may have more control over the system;
• You may not have to compromise your procedures to fit the software;
• Greater level of resources available; and
• Allows you to build brand through your system.

However, this also comes with some challenges:
• You leave your data with the company operating the system (there
may be data exporting features available);
• No guarantee about how long the system will be available;
• System features can change and may cause dysfunction in your

processes, or could stop working with your customised features;
• If you decided to complete the development in-house this could cost

more than you anticipate and leave you with a system which is out
of support or an unusable system if it goes wrong;
• You may need more than one application to address all your
requirements;
• Cloud App may leave you completing more work offline to

compensate for the shortcomings of the programme;
• Costs of re-development can be more than building your own.
Custom Software
On the other side of the coin to SaaS, Custom Software (specifically those
available online) is just that - software designed and developed to your
specific requirements. As opposed to Cloud Apps, Custom Software is not
an easy task to implement/evaluate, so it is important to ensure that it is
approached cautiously. If done well, the benefits can be fantastic.

Here are some key positives of the Custom Software approach:
• You get exactly the features you need;
• You own the data;
• You have more control over the system;
• Don’t have to compromise your procedures to fit the software;
• Can replicate best practice that you have;
However, this comes with some challenges:
• The development cycle takes longer;
• Costs can be higher;
• Ongoing maintenance required to ensure that the system continues

to function;
• Management of hosting/data becomes your responsibility; and
• Greater dependence on your developer to get the right solution.
If your NSO is looking to “systematise” unique core processes, then

you cannot go past Custom Solutions. Capturing and replicating core
competencies in a system can lead to amazing results. There are a lot of
risks in going down this path - it requires a development programme that
is well researched and employs people with the competency to deliver.
In the end, SaaS solutions, customisation/configuration and custom

software present viable solutions. It is important that when considering
alternatives, you evaluate alternatives on all sides of the development
spectrum and choose the option that best suits the requirements of the
system. Do not be led by a supplier trying to sell you a product that is
ultimately not right for your NSO’s situation.

Gathering requirements
Often unsuccessful projects
• Establish project goal and
finished with the statement “the
objectives early
requirements were not clear”.
Gathering requirements is a way • Document every requirements
to solve this problem, but it is also elicitation activity
very challenging and needs some
real structure and thought for it to • Be transparent with
be successful. requirements documentation
Gathering requirements refers to • Talk to the right stakeholders

the practice of defining the software and users
requirements. At its core it is really
trying to understand the process • Don’t make assumptions
of what it is you want to have built about requirements
and why you are building it. There
• Confirm, confirm, confirm
is a process to determine, document
and manage stakeholder needs and • Practice active listening
requirements to define the product
and project scope. • Focus on business
requirements, not tools
There are several techniques that
can be used to gather requirements • Prioritize product features
from the stakeholders:
brainstorming, interviews, focus • Remember that you didn’t get
groups, user stories, questionnaires everything
and surveys or benchmarking with
other NSOs. There are some easy To streamline this process in
steps to follow: the NSO, there is a requirement
blueprint that should be enhanced
and adjusted by the NSO to
document their requirements for the
MMS. The requirement template can
be found alongside this guide.
More information about how to work

with the template can be found in
Appendix B.

Compare the requirements
As there are existing solutions available on the market, the next step
would be to analyse if the existing solutions are able to match the NSO
requirements. The requirement template is available as a part of this
toolkit and provides mapping between the standard requirement and the
existing solutions. The NSOs can amend this comparison for their specific
requirements and/or other vendors.
Make a build vs. buy decision

Based on the comparison outcome, the NSO can make a decision if they
would like to develop their own MMS or buy an existing “off-the-shelf”
product, potentially with the ability to make customisations.
Request a proposal
Based on the build vs. buy decision, the NSO shall send the project
documentation including the MMS software requirements to the potential
vendors, and ask them for a technical and price proposal for implementing
the MMS. It is a good practice that the technical proposal is separated from
the price proposal.
Evaluate the proposals and select the vendor

The vendor proposal should be evaluated by the evaluation body to
select one or more successful bidders. The evaluation body reviews each
submitted proposal according to the selection criteria and selects the
vendor that can best satisfy the NSO requirements in terms of functionality
and pricing. Before the contract can be awarded to the selected vendor,
keep in mind that National Board approval might be required.
Implement the project

After the contract with the vendor is signed off, the project can move
to the implementation stage. We recommend that NSOs use the agile
approach to delivering the project if the collaboration with the vendor allows
for that. Following the agile approach, the project is delivered in short,
usually 2-week iterations called sprints and other agile practices such as
retrospective, backlog preparation, backlog refinement, daily stand-ups and
demonstration/reviews allow for constant adaptations to the ever-changing
organisational environment.

Next steps
It is now up to you – do you decide It is imperative that you speak with

to implement a very basic MMS other NSOs who have also gone
or are you ready to embark on a down the path of implementing a
bespoke MMS for the NSO? membership system. Understand
why they went with what they did,
Keep in mind that the Toolkit consider the various packages/
includes a Standard Scope of vendors that they spoke with and
Requirements that enables you to take the time to find out what
set the level of MMS that you could worked for them, what were the
set up for your NSO and decide the challenges and more importantly
best product for your NSO/NSA. what they would do differently.
There are three functional options
within the Scope of Requirement: Put your people first - talk to the
members of your NSO who will be
• Basic using the system. Really delve into
what the user of the MMS really
• Advanced
wants it for and no matter which
• Professional path you decide to follow this will
only drive project success.
The right version for you
depends on the objectives, needs The final recommendation is to
and requirements of the NSO contact the WOSM Support Centre
implementing an MMS. to guide you on the appropriate
course of action depending on the
The first step is to follow this MMS you wish to proceed with.
guideline no matter what level
you think you require. Start
building your team and gathering
requirements regardless of the
product level you think you will
implement. You then will go to
market for the product you are
looking for, whether this is for an
“off the shelf” package via desktop
research or a bespoke product
through a Request for Proposal
(RFP) model.

Appendixes
A. NSO Self-Assessment (survey)
B. How to use the Scope of Requirements
C. Product Vision Board (Target group,

Needs, Product, Business goals)
D. RFP Template
E. Writing user stories

Appendix A: NSO Self-Assessment
This self-assessment tool will help What is your budget for MMS in the
to indicate if your NSO should context of your country?
consider the Basic, Advanced or
Professional level requirements. □ Don’t Know - 0 points
□ No budget - 0 points
The questions should help you to □ Low budget - 2 points

reflect and consider if your NSO is
ready to consider an MMS project. □ Medium budget- 3 points
□ Significant budget- 5 points
Tick the box next to the answer

which applies to your NSO’s current What knowledge, skills and
situation. expertise in leading/managing
Has your national board agreed to digital/membership systems work/
your MMS project? projects do you have available in or
to your NSO?
□ Yes - 5 points
□ Don’t Know - 0 points
□ No - 2 points
□ None - 0 points
□ Limited amount - 2 points
□ Limited amount but our budget

Do you already have an MMS in allows for getting in the right
place? team - 4 points
□ Yes - 5 points □ We have a team who lead digital/

membership systems work/
□ No - 2 points projects - 5 points

Do you have or are you able to form a project team?
□ Yes - 5 points
□ No - 0 points
Size of your NSO?
□ <5000 members - 2 points
□ 5000 - 30,000 members - 3 points
□ 30,000 - 100,000 members - 4 points
□ >100,000 members - 5 points
Time available to deliver the project?
□ < 6 months - 2 points
□ 6 months - 18 months - 4 points
□ >18 months - 5 points
Can your processes change and adapt?
□ Yes - 5 points
□ No - 2 points
Do you have existing structures or frameworks for managing

processes and collecting data for the following?
□ Youth programme
□ Yes - 5 points
□ No, but we want to develop one as part of this project - 2 points
□ No, we don’t want to include this in the MMS project - 1 point
□ Awards
□ Yes - 5 points
□ Training
□ Yes - 5 points

□ Event management
□ Yes - 5 points
□ Finance management
□ Yes - 5 points
□ Scout places/venues
□ Yes - 5 points
□ Programme planning
□ Yes - 5 points
□ Fundraising
□ Yes - 5 points
□ Communications/Marketing
□ Yes - 5 points
□ Inventory/Asset Management
□ Yes - 5 points
Total points

Points 0 - 25 25 - 45 45 - 65 65 - 85
Further
Outcome consideration Basic Advanced Professional
required
Based on the
answers you have
ticked it may be
worth considering
if your NSO/NSA
is ready to start
looking at an MMS Based on your
Based on your Based on your
project. answers it
answers it may be answers it may be
Further may be worth
There may be worth considering worth considering
information considering the
some further the basic level the advanced level
professional level
resources, skills, requirements. requirements.
requirements.
knowledge or
decisions that
need to be made
before you
consider taking the
project forward.

Appendix B: How to use this Scope of Requirements
The Scope of Requirements is a There are three functional options

document with recommendations within the Scope of Requirement:
for general and functional
requirements for an MMS. The • Basic
Scope of Requirements has been
• Advanced
designed with both the complexity
required for and to deliver an • Professional
MMS based on the NSO’s ability
to implement a system that is
sustainable. Sustainability refers
to technology, affordability and
creating long term value.
The Scope of Requirements is a

working excel document which
should be customised for the
NSO’s specific requirements. The
purpose of this document is to
support the software selection
process by gathering the functional
requirements and matching them
against the vendor’s offerings.

Which is determined by recommended rating framework:
MSC Rating Function Options
M (Must Have): The system Basic

without this cannot work
S (Should Have): It would be Advanced (including all Basic

important to consider requirements)
C (Could Have): System could Professional (including all Basic &

have this part Advanced requirements)
Determining which option is best for the NSO will be determined by:
• The objectives of the NSO for implementing an MMS
• The challenges the NSO is trying to solve by implementing an MMS
• The high-level goals you want to achieve with an MMS
Section 1: Overview
The Overview section is for the NSO to highlight the reasons as to why and
what the MMS is to deliver once implemented. This section provides to
both internal stakeholders and external vendors the reasoning behind why
an MMS is required and will help vendors focus their technical responses to
delivering on the goals of the NSO.

Section 2: Milestones
Project Milestones are the timelines required for delivering on the project.
Timelines are critical to the success of the project being delivered on time
and to budget.
Project Milestones are the visible indicators of the progress of the project
and typically mark critical decision points and phases of the project.

Section 3a: General Requirements SaaS
General Requirements SaaS are requirements in the case that you

have selected to develop a system for your organization. The General
Requirements covers the general and non-functional requirement for all
new solutions. The recommendation is that all software solutions must
have, but not limited to, security, web and mobile responsible, adherence
to regulatory requirements and data security.
Each requirement has been given a rating as to level of need for a system
indicated by:
M (Must Have): The system without this cannot work
S (Should Have): It would be important to consider
C (Could Have): System could have this part

Section 3b: General Requirements Custom
General Requirements Custom are requirements in the case that you have
selected to
customize an existing system in the market. The General Requirements

covers the General and non-functional requirement for all new solutions.
The recommendation is that all software solutions must have, but not
limited to, security, web and mobile responsible, adherence to regulatory
requirements and data security.
Each requirement has been given a rating as to level of need for a system
indicated by:

Section 4: Functional Requirements
The Functional Requirements are the key pieces of work which could be
feature, customer request or a business requirement. The Functional
Requirements have been written in a manner to support how individuals
would want to use a specific area of the MMS otherwise known as a user
stories. For example:
As an administrator, I can assign role types to an organisational unit.
This will then allow the vendor or project team to determine the technical
function in the MMS that meets that user need statement.
This list is by no means exhaustive and could be added to or even removed

from depending on the goals of the NSO.
Again, the recommendations in the Functional Requirements follows the

same rating framework of:

Section 5: Comparison
Comparison is a matrix in which you can compare what is offered by each

of the system vendors, which will allow you to analyse what each one
offers and based on that information, choose the best option for your
organisation.
It is designed to account for each requirement that the system vendor

meets according to the requirements previously presented.
If the systems vendor offers to fulfil one of the requirements in his

proposal, we must mark it, but if the vendor does not offer to fulfil a
requirement in his proposal we must leave it blank that line.
Once this process is finished with each of the system vendors, the system
vendor that obtains the highest score translates as the supplier that will
most comply with our requirements and therefore our best option to
contract.
This matrix is for internal use by the NSO and should not be shared with
system vendors.
If you send the Excel file with the requirements, be sure to have deleted
this sheet.
Promoting the good governance of this process, we recommend that the

results of this matrix be socialised with the members of the national board.
The matrix formalises the technical decision of the contracting of the MMS
within the official documents.

Section: Roles Matrix
The Roles Matrix allows the NSO/NSA to map out the user’s role/
permissions as either Read (R) or Read and Write (R/W).
Column A list the attributes the user can access (e.g. create a new
account, view reports etc). Columns E-AC maps out the roles (e.g. unit
leader, headquarters etc).
The Permissions are broken into 3 options:
• R - Read only access. Users with this permission is only able to read
/ view content.
• R/W - Read & Write. Users with this permission is able to read /
write / update / delete content.
• N/A - No Access. User’s with this permission does not possess the
permission to view, read, write or delete content.

Appendix C: Product Vision Board template
Vision
What is your purpose for your MMS?
What positive change should it bring?
Target Group Needs
Who will use the MSS? What problem is your MSS trying
to solve for the users?
What benefit does it provide to the users

Product NSO Goals
What type of MMS do you want? How will the MMS benefit the NSO?
Is it feasible to develop? What are the NSO goals?
Adapted with permission from Product Vision Board by Roman Pitchler

Author: Roman Pichler
Source: www.romanpichler.com
Licence: Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0)

Appendix C (cont.): Product Vision Board example
Vision
What is your purpose for your MMS?
What positive change should it bring?

A membership management system that enables us to keep track of our members
so we can better support them with their programme.
A system that allows us to keep our members personal data so we can contact
them about events and opportunities.
A system that helps us to complete our national census.
Target Group Needs
Who will use the MSS? What problem is your MSS trying
Unit leaders
to solve for the users?
Head office users What benefit does it provide to the users

To move away from paper records for members so we
can keep a better track of members centrally.
The members will receive better communications

about events and opportunities.

Product NSO Goals
What type of MMS do you want? How will the MMS benefit the NSO?
Is it feasible to develop? What are the NSO goals?

Simple easy to use system that is accessible So we accurately know the membership size of the
on mobile phones. units and reduce the admin of our national census.

Appendix D: Request for Proposal (RFP) Template
A request for proposal (RFP) is a document that an organisation uses to

elicit a response -- a formal bid -- from potential vendors for a desired
digital solution. The RFP specifies what you are looking for and describes
each evaluation criterion on which a vendor’s proposal will be assessed.
Although each RFP is unique, they should all contain enough information
so that bidders can fully understand what is required and expected.
In the RFP it is helpful to include information about your organisation,
relevant information for the project, the project scope, bidder qualification
requirements, timeline and guidelines for the proposal.
1. Summary and Background
This section of the Request for Proposal (RFP) should provide a

high-level description of what the request for proposal is for and the
purpose of the requirement. It may provide background information
about your organisation as well. Most of the requirement details will
be included in subsequent sections of the document.
2. Proposal Guidelines
This section of the Request for Proposal should provide a description

of what each responding organisation’s proposal should contain. It
should also include a timeline within which all proposals must be
submitted. Any requirements that must be included in each proposal
should be described in detail in this section of the RFP.

3. Project Purpose and Description
This part of the Request for Proposal Template provides the purpose
and description of the project or work to be performed in as much
detail as possible. In order for companies to submit accurate
proposals, they need the details of exactly what work needs to be
performed and the purpose of the work. The purpose of the work
is important because sometimes bidders may be able to provide
different but more effective solutions.
4. Project Scope
While the project description provides bidders with general

information about the project, this part of the Request for Proposal
template includes details of what exactly is required for the project
as well as what is not included as part of the project. In addition to
the description of the project, this section of the RFP template details
any additional work required to achieve the desired result (i.e.
research, coding, etc.).
5. Request for Proposal and Project Timeline
The Request for Proposal should provide known information about

the timeline for the RFP process as well as the project itself. Much of
the project timeline will be determined in the project initiation and
planning phases once the winning bidder is chosen. However, any
known deadlines or time frames should be listed in this section.
6. Budget
This section of the Request for Proposal should explain what bidders
include in their proposals regarding budget items. Often, an RFP
will ask bidders to list pricing a certain way or describe what exactly
should be included in the pricing for the proposal. This may describe
specific items to include or exclude depending on the project or task.
This request for proposal template provides an example below.
7. Bidder Qualifications
This part of the Request for Proposal should describe the criteria that
will comprise the successful bidder’s organisation. You may ask for
examples of work from bidders, contact information for follow on
questioning, company history, executive background, information
on company size, organisational charts, or any other number of
information to aid in the decision-making process.
8. Proposal Evaluation Criteria
Here the Request for Proposal should describe exactly how proposals
will be evaluated. It should include a list of criteria that will be
reviewed and describe what is suitable for each of the criteria. The
more detail that can be included, the more thorough and complete
the proposals should be.

Appendix E: Capturing and Writing User Stories
User stories describe a user and the reason why they need to use the
service you’re building.
User stories can be used to:
• track everything they need to do
• think about their work from a user’s perspective
• discuss their work with colleagues
• prioritise their work
How to write a user story

What to include:
Your user stories should include enough information for your product
owner to decide how important the story is. They should always include:
• the person using the service (the actor)
• what the user needs the service for (the narrative)
• why the user needs it (the goal)

The normal format for user stories
User stories are usually written in the format:
As a… [who is the user?]
I need/want/expect to… [what does the user want to do?]
So that… [why does the user want to do this?]
Example user story:
As a unit leader, I need to collect the personal details of my youth

members so that I know who to contact in an emergency.
You don’t have to use this format but you should always briefly explain the
actor, the narrative and the goal.
Focus on the goal

The most important part of a user story is the goal. This helps you:
• make sure you’re solving the right problem
• decide when the story is complete and a user need is met
If you’re struggling to write the goal, then you should reconsider why you
think you need that feature.
Acceptance criteria
You can also include a few acceptance criteria for each story. Acceptance
criteria are a list of outcomes that you use as a checklist to confirm that
your service has done its job and is meeting user needs.
They’re often written as a list that begins with ‘it’s done when…’.
Example:
The acceptance criteria for the registration for a log in to the MMS feature:
• ‘it’s done when the user knows how to register online’
• ‘it’s done when the user knows how to reset their password’
• ‘it’s done when the user knows they have been registered’
Use the acceptance criteria to link to any evidence (for example

spreadsheets or diagrams) that support the story.

© World Scout Bureau Inc.
Organisational Development
May 2020
World Scout Bureau,

Global Support Centre
Kuala Lumpur
Suite 3, Level 17,

Menara Sentral Vista, No 150
Jalan Sultan Abdul Samad
Brickfields, 50470
Kuala Lumpur, MALAYSIA
Tel.: + 60 3 2276 9000

Fax: + 60 3 2276 9089
[email protected]
scout.org

Membership Management System Toolkit - EN

Uploaded by

Copyright:

Available Formats

Membership Management System Toolkit - EN

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Membership Management System Toolkit - EN

Uploaded by

Copyright:

Available Formats

ORGANISATIONAL DEVELOPMENT

World Scout Bureau,

Suite 3, Level 17,

Tel.: + 60 3 2276 9000

Building the team 12

Compare the requirements 21

Make a build vs. buy decision 21

Evaluate the proposals and select the vendor 21

Implement the project 21

4 MEMBERSHIP MANAGEMENT SYSTEM TOOLKIT

Appendix B. How to use the Scope of Requirements 28

Appendix C. Product Vision Board

Appendix D. RFP Template 40

Appendix E. Writing user stories 42

MEMBERSHIP MANAGEMENT SYSTEM TOOLKIT 5

Software as a service is a software licensing and delivery model in which software is

Membership Management System

MMS Membership software (also known as an association management system) is a computer

General Data Protection Regulation

Payment Card Industry Data Security Standard

Hypertext Transfer Protocol Secure

Hypertext Transfer Protocol Secure is an extension of the Hypertext Transfer Protocol.

NSO National Scout Organization

NSA National Scout Association

USER A person who uses or operates a system.

6 MEMBERSHIP MANAGEMENT SYSTEM TOOLKIT

An admin/system administrator is a person who is responsible for the upkeep,

Role A collection of permissions defined for the entire system.

Application program interface

API In computer programming, an application programming interface is a set of sub-routine,

MailChimp Is a marketing automation platform and an email marketing service.

Service Level Agreement

SLA A service-level agreement is a commitment between a service provider and a client.

Secure Sockets Layer

User Acceptance Testing

MEMBERSHIP MANAGEMENT SYSTEM TOOLKIT 7

The “Membership Management System (“MMS”) Toolkit” is designed to

As part of the WSC’s Triennial Plan 2017-2020, it was highlighted

The Toolkit will guide National Scout Organizations to make a decision

A Membership Management System will enable:

• To measure and demonstrate the impact of Scouting to the broader

• Supporting and strengthening the capacity of the National Scout

• Capturing correct data in association to membership numbers for

• Generate data and statistical information, which will make good

8 MEMBERSHIP MANAGEMENT SYSTEM TOOLKIT

• Scoping out the standard requirements for an NSO in terms of

• Identifying existing 3rd party software / web tools on membership

• Comparing 3rd party tools against a standard scope of requirements,

Alternatively, an NSO may wish to develop a “bespoke” solution. The

• Analysing their specific needs

• Translating needs into a proper request for proposal

• Running a proper tender and selection with software companies on

• Contracting a selected supplier

• Overseeing project management during design, development and

• Providing guidance on maintenance after deployment (including SLAs

2. Change Management is imperative for the success of the

3. Build a team of knowledgeable people to support the introduction of

4. Analyse the current situation with regards to membership

5. Gather requirements for the MMS.