Tuesday, January 27, 2015

The Grant Application Generator

While the process of creating a 'composer' that generates grant applications highlighted the need for charities to do better planning, I have never lost sight of my original intention. Yes, the Nonprofit Planner has value on its own, but the magic of the tool is that it collects important content in a highly reusable form. The first composer we have built to utilize this content is the Grant Generator, and there will be other composers down the road that can use the planning content as well.

In my book, and in prior posts about the Recommender, I talked about knowledge patterns. I have defined a knowledge pattern as a consistent set of knowledge artifacts that can be used over and over again to solve a certain type of problem. The knowledge pattern for a Recommender looks like this:


I've written a series of posts about applying this pattern to build a Whiskey Recommender.

The pattern for a Composer is remarkably similar to that of a Recommender. The pattern for a generic Composer looks like this:


How this general pattern translates into specifics for the Grant Composer is shown here:


Two knowledge artifacts are required for a Composer: a document content tree, which contains the raw material for the document to be composed, and a table, which contains the assembly isntructions. 

In earlier posts, I described the Foundation Sequencing Table, which holds the assembly information necessary to generate a grant application. This table will be a community asset that I will build and maintain. There will be only one version of this table because the information requirements for a particular foundation are the same for all charities that apply for grants.

The content to be assembled, however, is unique to each charity; each will have its own business plan, documented using our planning tool. This plan is an asset that will be built and maintained by the charity.

These two knowtifacts, then, are inputs to the composer application. Like all of our applications, the first step in using the tool is to collect the context for the current situation. In general, we run an application to solve a particular problem in the current moment, and the context is the way we describe our current needs. 

The Grant Application Generator needs to collect two types of context information.


The first type is information that helps the application 'prune' down the input knowledge artifacts to the relevant columns, tree branches and fields. Questions like 'which foundation', 'which program' and 'long or short answers' fall into this category.

The second type is specific information that refers to this particular grant request only, and therefore cannot come from the business plan. Information in this category includes the request amount and date. This information must be collected at run-time so it can be filled in at the appropriate locations in the generated document.

Once the context is collected and 'OK' is clicked, the Grant Generator creates a document that meets the specifications: just the information the target foundation wants to see, and in the order they want to see it. (I've grayed out this charity's info, to protect their privacy.)


In my next post I'll discuss some of the details about how this report is formatted, and how charities can use it.

Tuesday, January 6, 2015

Deep Dive: The Program Pages

The Program Pages act as the marketing and operating plan portions of the business plan.

As mentioned in a prior entry, every new plan is generated with a single Program Plan page called 'General Support'. By pressing the plus-sign tab, the planner can add an additional page for each program the charity executes. For example, if the charity is a food bank that has a backpack program for providing weekend meals to students on free and subsidized lunch programs, they should add a page for that. Any program for which the charity wants to seek funding must have its own page in the nonprofit plan. The General Support page is automatically added because every charity seeks funding for ongoing operating support.


The program page contains descriptions of all the major players in the program. There is a description of the population served, including breakouts on key demographics: income, gender, ethnicity and geography. This is essential because a foundation wants to determine if the charity serves the populations they consider important. Other key players are the community partners, volunteers and donors.

Another important section of the plan is the communications strategy. This is broken down into the stories that will act as the content of the communications, and the media that will be used to get that message out.

Perhaps the most important part of the operations plan is a description of the results the charity is committed to achieving, and how they will measure the actual results they achieve. This focus on measurement is not in the DNA of many charities, but it is an absolute requirement of many foundations, particularly those affiliated with large corporations. Business-oriented donors and foundations know that 'what gets measured, gets done', and they want to see this awareness in charities they are considering for grants. Making metrics part of the business plan ensures the charity considers them, whether it is natural for them to do so or not.

In my next post I will talk about the mechanism we use for managing the color-coding that shows the completeness of the plan, and how that is also used to guide formatting decisions in the generated grant proposals.