CIVICRM - 2

CiviCRM: OneStep

One Step at a Time

CiviCRM can be used for the majority of your non-profit's information and communication needs. You'll probably want to use it for as many of these needs as possible but you should resist the temptation to switch everything to CiviCRM from day one. Some CiviCRM implementations are simple, and some are more involved, but whatever your level of complexity you may benefit from an incremental approach.

Why is it sensible to break things up?

Non-profit staff usually wear many hats and are busy with day-to-day work. They may view the CRM as unimportant or incidental to what they do. Implementing a CRM often requires significant changes in working practices for staff. A useful approach is to break implementations up into discrete stages. This allows staff to get used to the changes gradually and makes the adjustment easier to manage.

Introducing functionality a bit at a time also gives breathing room to the implementer, making it easier to change or undo things should that become necessary. Any mistakes you make won't be "global" and you'll be able to incorporate learning into the next stage.

It's pretty much impossible for those involved in a CRM implementation to fully articulate all their requirements at the start of the project. Even a good project plan is likely to miss a number of things. Despite your best intentions, as the project progresses you'll make some mistakes and have to revise some decisions.

Make sure that you plan time for staff to have hands-on experience of the system and enable them to provide feedback (both positive and negative) that you can incorporate as the project progresses. The importance of this cannot be overstated. If staff are having problems or concerns and feel that these are unheard, they will resent the new system and your project will have more difficulty succeeding.

If you are planning to use CiviCRM for any large or mission-critical events, make sure that you have allowed adequate time for staff training and testing.

Training is more manageable

CiviCRM's range of functionality can be overwhelming at first (especially to the less technically minded). Remember that staff who were not involved in the project's early stages will need to have concepts explained clearly to them.

Trying to cover everything in one training session probably won't be effective. Your staff will need time to get on board and digest the new ideas. Instead, try smaller training sessions, introducing concepts and specific functionality, followed by periods of testing, piloting and feedback.

Resistance to change is reduced

Introducing a new CRM is likely to cause changes in work flow and processes at the organization. These changes may be 'political' or they may be technical. Either way, a lot of change at the same time is usually difficult and stressful.

To alleviate this, give staff time to accept and support each change. Show them how the new system will make their work easier. If possible at the beginning of deployment, focus on simple tasks first and then follow up with difficult tasks.

Test systems

Setting up a test database is a great way to introduce a new system. Using real world data in a test system gives staff a chance to experiment with CiviCRM without fear of any consequences. It also lets staff test functionality and learn what works and what doesn't.

Pilots

Organisations with existing processes and systems may like to try a pilot. This would work well, for example, for organisations that organise a lot of events. CiviCRM could be used to manage one of these events and the learning fed back into the development process.

Taking manageable steps

There are a few tried and tested ways to break up deployments. It's unlikely that all of these will make sense for your organisation, but applying the general principle might be helpful.

Introduce your CMS independently of the CRM. The difference between the two isn't immediately obvious if they are presented together. Understanding the difference between the two helps staff understand the architecture of both, and the implications of them being linked together.

Start by allowing only staff to access and edit data (that is, don't give your constituents access to the data via the CMS). Although the ability of constituents to update data is a key advantage of using CiviCRM with a CMS, it is a significant conceptual leap which may introduce the extra task of monitoring changes made by constituents. Consider introducing constituent access to data via the CMS after staff are more familiar with the new system.

Hopefully these steps will help you and your organisation have a successful and rewarding experience with implementing your project.

There has been error in communication with booki server. Not sure right now where is the problem.

You should refresh this page.