Depending on your process—Agile, or more traditional—you will determine your needs in a less or more formal way. Whatever your process, some approaches are always appropriate.

First of all, it's useful to review the functionality, data structures, and data in your existing systems. Functionality is the easiest to discuss. It provides a sense of the sets of fields—custom data and profiles in CiviCRM's terminology—that may be needed in the new system. When analyzing existing systems, don't be limited to your primary contact database alone. For example, if you use paper sign-up sheets at events or have other paper, e-mail, or web-based data collection forms that are not part of your primary system, be sure to include them in the discovery analysis. With data structures, you'll be able to start mapping out how to migrate data from the existing to the new system. As part of this, you'll be able to identify the custom fields that may be needed, and others that are no longer needed. Enduring information such as constituent interests is worth keeping, while transient information such as their food preferences at an event is less useful.

Resist the urge to just dump everything into the new system thinking that it will be sorted out later. Clutter appears on every system over time, bogging down the system, its interface and its users. Now is the time to pare back unnecessary complications, making the system easier to use and easier to train people to use. It will also help to reduce the scope of the data migration effort, which is often a costly part of a CRM initiative.

Looking at the data will often provide a sense of the scope required in the cleanup effort. You'll need to do some cleanup just to get the data into the new system (for example, dates have to all be in the same format), and removing garbage in your system while you're at it is usually a good idea. You'll find when you are looking at the data and deciding how to clean it up, that it can be useful to have some standards in place. For example, how addresses are entered, whether honorifics like Ms. or Mrs. are used, and standardizing values in some free form fields so the data can be more easily retrieved and entered from a select widget. To reduce the scope of work, it's best to start by deciding what tables and records can be thrown away.

Interviewing users at the data entry, operational reporting, and executive levels gives a useful and diverse insight into the most important data and process needs. You'll benefit from knowing the strategy in the Executive Director's head, the important and unnecessary elements in reports, and the workarounds regarding use and data entry currently employed by front-line staff. When people experienced with CiviCRM do these interviews, there can also be good tradeoffs negotiated, such as balancing what is easy or hard to implement against its relative importance to users.

Using the existing system as a reference helps to ground solicitation of other needs. We like to ask users about the important new things the new system should do, what they would like to be included in the new system, and what is really problematic and irritating about the old system. Some "nice to have" features can be included with little effort in CiviCRM. Identifying "pain points" in using the current system provides valuable information on how the new system will be evaluated.

To get organizational buy-in for the CRM initiative and create project momentum, plan to provide short-term deliverables. This could include wire frames, screenshots, and flow diagrams that demonstrate how the functionality discussed in the discovery and specification phase will (roughly) translate to forms, pages, and workflows. Important new functionality, nice-to-have features, and eliminated pain points are all fertile quick-win areas where you can demonstrate a commitment to improving user experience.

Asking everyone for feedback on possible implementation timelines is also useful though be cautious about inadvertently making implied time-based commitments without first gaining a complete picture of the project scope. Reporting deadlines to funders, having functionality in place for certain events, and knowing crunch periods when it would be problematic to run old and new systems in parallel are all needs that should be reflected in your plans.