Thoughts on development

There are a lot of organizations that can achieve their goals with CiviCRM out of the box. Some organizations though will want to, or need to, customize CiviCRM to their needs. If you do want to customize CiviCRM there are two aspects to think about:

• Can we customize CiviCRM ourselves or do we need to get external help? And if so, where do we get it?
• What development methodology would suit us best?

Where to get help?

As CiviCRM is open source, anyone with the right skills can customize CiviCRM. Luckily, the community helps: CiviCRM has partners that are part of the community and have proven their CiviCRM capabilities. You can find the CiviCRM partners on the CiviCRM website at https://civicrm.org/experts. If you do not want to be limited to CiviCRM partners, make sure that whoever helps you is an active community member that posts blogs, answers forum posts, takes part in CiviCRM events, and so on.

Development methodologies

If you are customizing CiviCRM, you need to think about what development methodology you want to use. If you want to involve a CiviCRM partner, they will possibly have an opinion on the development methodology as well. If you are not customizing CiviCRM, you are certainly developing your CRM processes, so a development methodology will probably have value for you anyway.

Whatever approach your organization decides to take for developing and implementing its CRM strategy, it's usually good to have agreed upon your process and methodology. Your processes define the steps to be taken as you implement the project. Your methodology defines the rules for the process, that is, the methods to be used throughout the course of the project. The spirit of this problem-solving approach can be seen in the Traditional Waterfall Development model and in the contrasting Iterative and Incremental Development model.

Note

Projects naturally change and evolve over time. You may find that you embrace one of these methodologies for initial implementation and then migrate to a different method or mixed-method for maintenance and future development work. By no means should you feel restricted by the definitions provided, but rather adjust the principles to meet your changing needs throughout the course of the project. That being said, it's important that your team understands the project rules at a given point in time so that the project management principles are respected.

The conventional waterfall development methodology

The traditional waterfall method of software development is sometimes thought of as big design upfront. It employs a sequential approach to development, moving from needs analysis and requirements, to architectural and user experience, detailed design, implementation, integration, testing, deployment, and maintenance. The output of each step or phase flows downward, like water, to the next step in the process, as illustrated by the arrows in the following figure:

The Waterfall model tends to be more formal, more planned, includes more documentation, and often has a stronger division of labor. This methodology benefits from having clear, linear, and progressive development steps in which each phase builds upon the previous one. However, it can suffer from inflexibility if used too rigidly. For example, if during the verification and quality assurance phase, you realize a significant functionality gap resulting from incorrect (or changing) specification requirements, then it may be difficult to interject those new needs into the process. The release early, release often iterative principle, mentioned earlier, can help overcome that inflexibility. If the overall process is kept tight and the development window short, you can justify delaying the new functionality or corrective specifications for the next release. If you do not embrace the release early, release often principle—either because it is not supported by the project team, or because the scope of the project does not permit it—you should still anticipate the need for flexibility and build it into your methodology. The overriding principle is to define the rules of the game early, so your project team knows what options are available at each stage of development.

Iterative development methodology

Iterative development models depart from this structure by breaking the work up into chunks that can be developed and delivered separately. The waterfall process is used in each phase or segment of the project, but the overall project structure is not necessarily held to the same rigid process. As one moves further away from the waterfall approach, there is a greater emphasis on evaluating incrementally delivered pieces of the solution, and incorporating feedback on what has already been developed into the planning of future work, as illustrated in the loop in the following figure:

This methodology seeks to take what is good in the traditional waterfall approach—structure, clearly defined linear steps, a strong development/quality assurance/rollout process—and improve it through shorter development cycles that are centered on smaller segments of the overall project. Perhaps the biggest challenge in this model is the project management role, as it may result in many moving pieces that must be tightly coordinated in order to release the final working product.

Agile development methodology

Agile development methodologies are an effective derivative of the iterative development model that move one step further away from the waterfall model. They are characterized by requirements and solutions evolving together, requiring work teams to be drawn from all the relevant parts of the organization. They organize themselves to work in rapid one-to-four-week iteration cycles. Agile centers on time-based release cycles, and in this way, differs from the other methodologies discussed, which are oriented more toward functionality-based releases.

Implementation with an Agile methodology highlights short daily Scrum status meetings, a product backlog containing features or user stories for each iteration, and a sprint backlog containing revisable and re-prioritizable work items for the team during the current iteration.

A deliberate effort is usually made in order to ensure that the sprint backlog is long enough to ensure that the lowest-priority items will not be dealt with before the end of the iteration. Although they can be put onto the list of work items that may or may not be selected for the next iteration, the idea is that the client or the product owner should, at some point, decide that it not worth investing more resources in the nice to have, but not really necessary items. But having those low-priority backlog items is equally as important for maximizing developer efficiency. If developers are able to work through the higher priority issues faster than originally expected, the backlog items gives them a chance to chip away at the nice to have features, while keeping within the time-based release cycle. They also allow for developers to be aware of easy features that can be added while you are working on related stuff.

As one might expect, this methodology relies heavily on effective prioritization. Since software releases and development cycles adhere to rigid timeframes, only high priority issues or features are actively addressed at a given point in time; the remaining incomplete issues falling lower on the list are subject to reassignment for the next cycle.

While an Agile development model may seem attractive (and rightly so), there are a few things to realize before embracing it:

• The process of reviewing, prioritizing, and managing the issue list does take time and effort. Each cycle will require the team to evaluate the status of issues and reprioritize for the next release.
• Central to the success of this model is a rigid allegiance to time-based releases and a ruthless determination to prevent feature creep. Yes, you will have releases that are delayed a week, or see must-have features or bug fixes that enter the issue queue late in the process, but the exceptions must not become the rule or you lose your agility.

Food Pantry Association of Greater Metropolis

Throughout the rest of this book we will use a case study to help introduce concepts and explain how to configure, customize, and use CiviCRM. While the organization and names are entirely fictitious and not intended to refer to actual organizations or people, the organization's needs and how it operates are intended to reflect common patterns in the non-profit and advocacy sector.

You are in charge of all administrative functions including computer systems and finances for the Food Pantry Association of Greater Metropolis (FPAGM). FPAGM is the central organization in the food pantry system in the city of Metropolis, and its surrounding areas. The pantries range from small faith-based groups to a few larger not-for-profits in the center of the only large city in the area. The pantries disseminate food to needy families and individuals to be taken home for consumption later, and are kept particularly busy during the winter months in this city of approximately 2.1 million people.

FPAGM envisions a community where no one suffers from hunger. As a trade organization serving the needs of the pantries and advocating on their behalf before city and state government, they have become a voice for the needy throughout the region. Their primary mission is to provide cost-effective shared services to food pantries in the region. Operationally, FPAGM does the following:

• Provides wholesale food pickup from business donors and the regional food bank, storage at a depot, and regular delivery of needed supplies to pantries
• Shares best practices amongst food pantries and food pantry donors
• Begins assisting pantries in dealing with problematic individuals who abuse the system or staff
• Represents the concerns of the pantries to local and state advocacy efforts, often by undertaking research and developing policy recommendations

The FPAGM Board of Directors consists of four officers and five members-at-large. Your boss, the executive director, oversees the work of five full-time staff. In addition, the organization receives regular volunteer support to assist with daily operations.

Most staff resources are taken up with providing food distribution services for the pantries. Affiliate members and other food providers contact the FPAGM when they have surplus food available for pickup. The association owns three vans for transporting food from the providers to a warehouse attached to the FPAGM offices, and then distributing it to the pantries on a weekly basis.

The FPAGM staff also handles distribution to the pantries. The pantries place requests for food and the costs (measured by weight) are tracked against their accounts.

This system allows the pantries in the region to focus on providing food and services to clients, needy members of the community, without needing to identify food supply sources. The association also benefits from economies of scale, particularly with warehouse space, staff, and vehicles required to distribute food to the pantries. By serving the collective needs of the area food pantries, and realizing operational efficiencies, they are able to help the pantries maximize their limited financial resources by focusing on getting food to clients.

The association hosts two training events and an annual conference that draws attendees from the entire state who are involved in food pantry support. Additionally, they have member services staff who provide daily, 9-5 phone support for pantries seeking information or operations assistance.

Right-sizing the process

It's important to ensure that the process and methodology you adopt for your CRM initiative is appropriate to your organization's culture and size, the complexity of its existing systems, and the scale of your CRM effort. This goal of right-sizing the process to fit your needs is essential, both for you as the project manager/decision maker, and for any consultants you engage in the process. Besides having familiarity with your methodology of choice, the project team (organization leaders, staff, and consultants) should understand and appreciate how you have right-sized the project. For example, if you represent a small organization with 2 to 5 staff members, a volunteer board and committee structure, and 3,000 contact records, building too much structure and process into your project will impede efficient progress rather than helping it. You need enough structure to make sure that the project is well defined, well-managed, effectively tested, and implemented on time and within budget; but not so much structure that you spend all your time managing the methods instead of implementing a CRM.

If your organization is able to adapt, you will be able to benefit from a more Agile methodology. If you do need the more formal waterfall process, be sure that it does require you to know what you are going to need in advance in order to be successful.

Tiny organizations, or initiatives, may not need to iterate because the scope of work is too small—as issues are identified, they can address, test, and implement a fix very quickly. A project intending to replace a single existing CRM system with CiviCRM may find it better to proceed in a single product rollout to reduce the effort involved in running old and new systems in parallel. By contrast, replacing a number of separate siloed systems with CiviCRM can be grouped into one or more iterations for each system being replaced.

Sometimes, it can be useful to pilot CiviCRM in an important, urgent, or easy area. You might want to reach the low-hanging fruit by automating event registration for the first time. Another strategy would be to tackle the toughest area first, so that you don't get halfway down a path of converting to a new CRM before you realize there are some aspects of your needs that will require more customization than originally envisioned.

So what happens if you are knee-deep in your project implementation and realize you wrong-sized your process? Hit the pause button! Re-evaluate what is working and not working and fix things now. It's often tempting to stick with the program, at least until you complete the initial rollout phase, but if you are truly wrong-sized, delaying a process fix will only harm the project and increase the risk of failure. It's better to identify the problems and either scale back the project structure or implement new methodologies, depending on which side of wrong you have fallen.