Enhanced grant tracking: CiviGrant vs. CiviCase

Published
2011-02-21 14:24
Written by

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:

  1. Extend CiviGrant by adding DB fields.
  2. Extend CiviGrant by leveraging activities.
  3. Replace CiviGrant with a CiviCase workflow.

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.

incoming
An external contact is the grantee (i.e., a constituent), and the your organization is the grantor.
outgoing
Your organization is the grantee, and an external contact is the grantor (i.e., a foundation).

Option 1: Extend CiviGrant by adding incoming grant specific fields

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.

Option 2: Extend CiviGrant through activities

This option is motivated by two key insights:

  1. Incoming and outgoing grants share some common characteristics.
  2. The differences between incoming and outgoing grants are based mainly on interactions with contacts.

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.

New fields

name
a descriptive title for individual grants
direction
binary field to denote incoming / outgoing
grant_application_due
could be rolling deadline specified by NULL value

Modified fields

grant_due_date
renamed from grant_report_due for the sake of consistency

Deprecated fields

decision_date
replace by grant decision activity
applicaton_received_date
replace by grant application received activity
money_transferred_date
replace by grant money transferred activity
grant_report_received
replace by grant report received 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.

New activity types

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.

grant inquiry
an inquiry was made regarding the status / eligibility of a grant (both)
grant application submitted
a grant application was submitted to a funder (outgoing only)
grant application received
a grant application was received from a constituent (incoming only)
grant decision
a grant decision was made (both)
grant money transferred
grant money was transferred (both)
grant report received
grant report was received (incoming only)
grant report submitted
grant report was submitted (outgoing only)

Migrating current users of CiviGrant

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.

Advantages

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.

Option 3: Replace CiviGrant with a CiviCase-based workflow

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.

Conclusion

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.

Comments

I have typically used CiviCase for outgoing grant applications for clients. i've found that it provides a good balance between structure (using timelines) and flexibility. re: timelines -- in one case I created a standard pre-populated timeline implemented when the grant application process begins, and a second one manually applied to the case if the grant is accepted -- with the subsequent actions that would follow it. it proved a nice way to track the application and acceptance, followed by the reporting requirements.

the only thing that it doesn't offer is any connections with CiviContribute -- but CiviGrant doesn't either. providing that enhancement would be useful.

 

here's a basic xml config: http://pastebin.com/WPR7Hm8h

(doesn't have the additional timelines for branching actions after a decision on the case has been made -- just a single timeline for all actions)

I actually use this as an example of a case type in the very-soon-to-be-released CiviCRM book from Packt. I think it has a lot of potential as a tracking tool for grant-applying organizations.

It would certainly be useful to have a connection to CiviContribute. Maybe we can use the connection between CiviEvent fees and CiviContribute as a model.

 

Option 2 is basically very similar to the goals of CiviCase. Doing so this way would help improve CiviCase and extend its feature sets (to allow customizable layouts) and in the long term allow CiviCase to be adapted for other use cases

 

I think it should be fairly easy to create the set of XML definition files to get you going with using civicase for grant management

 

lobo

xavier dutoit (not verified)
2011-02-22 - 00:37

Case seems to offer another benefit over grant to track the relationships around a grant, not only activities. As far as I have seen, knowing who is involved, both within the organisation and the external contacts is really important. Beside, all the work you have done for 2 of identifying the activities is going to be useful as well for the cases.

I'd suggest to go case for two reasons: it has already interesting reports (eg timeline vs. what happened) and as it's more versatile than civigrant, that's likely more features will be added to cases. Moreover, I'd rather see civigrant obsoleted and replaced by pre-configured cases than spreading the attention on two featurewise quite similar modules.

Something I found cumbersome in configuring a case it so have to create separately the relationships and activities related to the case, it'd be good to make it easier to install (using the API, that's easy to create them). Don't think that extensions can handle cases now, but that would be nice to have grant as one, that would automatically create whatever needed to have civicase up and running.

Using CiviCase for tracking grant applications might be a bit cumbersome for organisations which also use CiviCase for other activity. Grant tracking and "core CiviCase" stuff are usually completely different workflows and mixing them together in one "data bag" might cause some confusion at the moment - until CiviCase gets some functionality to address that. Not that it's a show stopper, but might be worth to remember that. :-)

I could see this being an issue, especially with our organization. While we haven't started using CiviCase extensively, I have begun to map out potential workflows for various functions. 

 

All of the potential workflows are pretty closely related to each other... except grant tracking. It just doesn't seem like it "belongs" with the other stuff.

 

seems like we should be able to extend the code to create different workflows for different "cases" and rename things as needed. Seems like some additional meta-config information

 

lobo

 

You're right, and  that feature of "isolating" better cases would be useful no only for the grants, but also for all org that want to use cases for tracking different type of "projects", same goes for timelines and other civicase features.

What we did with CiviCampaign was to split the "regular" surveys and the petitions into two different dashboards an menues to create them, even so the underlying code is mostly similar. Wasn't a big issue to implement, doubt it would be complex In civi cases.

Might be needed to add a navigation API, but that would be beneficial everywhere too.

I really think having common and powerful tools that are versatile enough to cover a lot of different needs are a better solution than zillion of not as complete modules that do one thing, and later having to re-implement the same feature that exists into another module that does mostly the same stuff, with a different label. Clearly, having a lighter UI is a common need (see colemans' solutions). Having it on case instead of restricted to grants would be a greater benefit for a wider user base.

 

To recap: one stone, three birds ;)

 

Good points.

I'm definitely beginning to be swayed toward the CiviCase side. There are certainly some drawbacks, but fixing those issues would probably go a long way towards making CiviCase more usable and powerful in general.

CiviGrant future?

There seemed to be consensus 3 years ago that CiviCase could replace and enhance CiviGrant. There have been many other enhancements but just wondering what the plan is for CiviGrant?