Using CiviCRM for project management and budgeting
Submitted by ChrisChinchilla on December 11, 2013 - 14:46
At Green Renters we have tried to incorporate as much of what we do into CiviCRM as possible, we figured that there was no point having a central repository of how everyone engages with our organisation if the information wasn't complete, so we sought to consolidate as much of what we do into CiviCRM as possible. This is a post explaining how we incorporated and integrated project management and accounting into our CiviCRM.
We are a small and simple organisation, so have simple requirements for accounting, project management etc… So the data objects present in CiviCRM for undertaking these tasks work for us. If you have more complex requirements, then they probably wont work for you.
There's a reasonable amount of Drupal integration here, these could be replaced with CiviCRM functionality such as reports, profiles etc if you wanted to.
We are currently using Drupal 6, which isn't officially supported by CiviCRM any more and this especially applies to a lot of the Drupal integration we use. We had to do a lot of hot fixes to get some views integrations to work that get broken every time we upgrade CiviCRM.
Bearing in mind the above, screenshots will be in Drupal 6, so you may see different options on your site (probably better options!) but I always feel that seeing a practical example is far better than a made up demo.
We opted to use campaigns in CiviCampaign as a 'project', the non-correct terminology doesn't bother us, in some respects, projects within nonprofits are often campaigns of sorts anyway. By using campaigns you also are able to relate other CiviCRM data objects to them, like contributions and activities.
This was far simpler to accomplish than we expected and is mainly achieved by just posting negative contributions and associating them to a campaign, there are also more complex ways this could be setup, such as adding custom fields for sub classifying payments and also using soft credits to represent payments that a staff member was reimbursed for. We use 'pending' payments to represent payment requests or submitted (depending if it's coming in or out of the organisation) and update these to completed when they have been paid.
Our main bread and butter income is running workshops and we're using different participant types and statuses to represent bookers, presenters, admins and attendees of each workshop, 'registering' each relevant contact to the event when it's created. This allows us to see who relates to each event, even if they're not actually a physical attendee. We have created a series of price sets to help assist with our standard hourly rates for services and use a free text box that allows us to insert the quantity (of materials or hours) that we are charging for. We have also customised receipts so that when sent to participants of a certain type (i.e. 'booker'), the terminology of the receipt is changed to reflect a quote or invoice.
A lot of our income comes from grant funded projects and it's important for us to quickly know how much money is left in a project's pot. To accomplish this we created a Drupal view combined with the views calc module that allows us to filter per project and get a summary of what's been spent. By utilising views, this offers a myriad of customisation options.
For very basic project management we use activities assigned to a campaign and these are displayed in a Drupal view and can filtered by assignee, project, priority etc.
We have a lot more smoothing out we can and should to to our set up but we hope it gives at least a rough idea of some of the potential for using CiviCRM for a multitude of tasks that it may not be specifically designed for, if you are willing to accept a few compromises and semantic inconsistencies and embrace the ease of keeping everything in the same place.