Many non-profits live and die by the grant money that they are able to bring in. CiviCRM can currently track incoming grant applications through CiviGrant, but there is no way to track outgoing grants applications.
This functionality has been requested by users of CiviGrant in the past, but the project never moved forward. The organization that I work with is very interested in tracking our grant application workflow, which in turn makes me very interested in implementing this functionality.
After some discussion in the forums, it was suggested that I write up a blog post with a few ideas on how to go ahead with the project. Essentially, I see three options:
Before moving ahead, I would like to gather as much input as possible from the community. While I will obviously be biased toward fulfilling my own organization's needs, my goal is to contribute a useful improvement to the CiviCRM community. If you have any suggestions or concerns, please leave a comment, especially if you already use CiviGrant, CiviCase, or both.
Incoming and outgoing grants can be distinguished by the relationship between the grantor and the grantee.
The most obvious way to extend CiviGrant would be to simply modify the civicrm_grant table to hold information about incoming grants as well as outgoing. Some new fields would be required, but some existing fields could be reused. Further, some of those existing fields would change semantics based on whether a grant was incoming or outgoing.
For example, a new field called direction would signify whether the grant is incoming or outgoing, while the amount_requested field could be reused. For incoming grants it would list the amount requested from your organization, and for outgoing grants it would list the amount requested by your organization.
One problem with this approach is you end up with fields in the table that are only applicable to a given record, or whose semantics change, depending on the direction of a grant. You could keep separate tables for incoming and outgoing grants, but then you end up with redundant fields since incoming and outgoing grants share some common characteristics. I think the database folks have a technical term for this, but I just think it's ugly.
Another problem with this approach is that it is very rigid. It does not provide much room for future extensibility, or for customization to fit a particular organization's workflow. For example, my organization would like to keep track of each time an inquiry is made regarding a particular grant application. This naturally leads one to think of activities.
This option is motivated by two key insights:
The goal then, is to only store the common characteristics of grants in the civicrm_grant table and track the interactions with those grants in some other way. This will require adding some fields civicrm_grant, modifying some fields, and removing some fields.
Furthermore, the information that was previously stored in removed fields must be recorded in some other way. Since that information essentially descibes an interaction with a contact, it naturally lends itself to recording as an activity.
After these modifications, each of the fields in the civicrm_grant table will be applicable to a grant regardless of its direction. Moreover, they have consistent semantics regardless of direction or status.
The deprecated fields from the previous section will be replaced by new activity types. Notice that each of the activity types are applicable to incoming grants, outgoing grants, or both.
I can foresee two major impacts on current users of CiviGrant.
First, there will be some changes to the UI. My goal would be to keep the UI as streamlined as possible, and preserve the ability to enter a new grant -- as well as any associated activity -- using a single screen. This is an area where I would really appreciate community input. What works with the current UI? What does not work?
Second, there should be an option to migrate data from deprecated database fields to the new activity types. The migration should be a seamless, one-click bulk operation. Moreover, it should performed on-demand by the user. While I would love to simply delete the deprecated fields and migrate the information automatically, I realize that this would not sit well with many of you! However, the deprecated fields should eventually be removed and the migration forced in some future release.
The nice thing about this option is that it leaves a lot of room for flexibility, depending on a particular organization's workflow. For example, multiple inquiries can be recorded, or none at all. Custom activity types can be created easily.
It also lends itself to future extensibility. For example, grants for a particular campaign or pool of funding could be grouped easily using tags. A ranking system could be established that prioritizes grants based on the strength of an application or the likelihood of receiving funding.
The activity-based extension to CiviGrant described above has obvious similarities to CiviCase. Therefore, it might make sense to pursue a CiviCase-based workflow instead of "reinventing the wheel".
Like Option 2, such an approach would involve creating new activity types. It would also require creating some custom fields to go with those activity types (e.g., to record the amount requested, amount granted, etc). The difference is that the custom data would be associated with an activity, while in Option 2 the information would be associated a grant. Some custom reporting would also be required to perform any accounting functions associated with grant applications.
My main concern with this approach is that CiviCase has a very complex workflow, which might make it overkill for the grant use-case.
In order to avoid having two components (CiviCase and CiviGrant) that duplicate each other's functionality, the CiviGrant module should be deprecated if this option is implemented.
At this point, I am leaning toward Option 2. As you can probably tell just by reading this blog post, it is the option that I have put the most thought into.
It's not that I want to duplicate the functionality of CiviCase into CiviGrant, but that I want to use a consistent paradigm with existing CiviCRM building blocks to extend CiviGrant's functionality. I think two-way grant tracking is a general enough function for most non-profits that it deserves it's own component.
However, I think pursuing Option 3 would be interesting if for nothing else than the learning experience. Through doing so, I would be in a better position to weight the pros and cons of each option. My staff has alread agreed to becoming guinea pigs, so I will most likely begin to pursue both options in parallel and see which works better for us.
I will report back here as my implementation progresses. If you have any questions or concerns, or would like to help with implementation or testing, please leave them in the comments below. Hopefully this will generate some healthy discussion.