Creating the Content Table for the Grant Proposal Generator

My first challenge was to identify the comprehensive set of information items that would cover all the questions asked by foundations in their grant application forms. I started with the most comprehensive single form I could find: the one used by the Catalogue of Philanthropy, a Washington D.C. organization, to vet charities in the D.C. region for inclusion in their publication.

I decided based on my initial assessment that a table was the right shape for this information, and that I would use Excel to create my table.

I used the questions as the row labels, and created columns for the various types of proposals a charity would typically generate.

When a charity makes a grant request they must declare how the money will be used. Is it for general operating support? Or is is for a specific program or project? If it is for a specific program, which one? Once the intended use is declared, all of the following questions must be answered with that end use in mind. Some of the answers, like contact information, will be the same for both general support and specific programs, but many will be very different. To accommodate this variation, I setup separate columns to represent the various versions of the proposals. A charity will fill out a project-specific column for each project that requires funding.

I also setup separate columns for long and short form answers. This is necessary because many online application forms limit the number of words for each response. The approach I envisioned here is that the long form would be written first - it's easier to be wordy - and then a short, pithy version crafted next.

I started with the Catalogue for Philanthropy questions, which are in white. The next application form I reviewed was the Washington Regional Association of Grantmakers "Common Application", and the incremental questions from that were color-coded in yellow. I proceeded in this way, selecting application forms from large foundations, adding any new questions I found and color-coding them to show the source. As I had hoped, after only a handful of forms, the number of new questions dwindled to one or two per foundation. This consistency is important, because it confirms that an automated approach is truly possible! After reviewing five sources, the total number of information items was 130, with about 50 related to financial numbers.

At the same time I was creating the Content Table I was also working on the Sequencing Table, the other knowtifact required for the Grant Composer to work. I'll describe the Sequencing Table in my next post.

Knowtifacts Required for a Composer Application

As I said in my last post, a Composer is basically a document configurator. Two required inputs for any configurator are a parts catalog and instructions for how to select and assemble the parts to meet the current need. To build a Grant Composer, I needed to design those two knowtifacts  -- first, generic versions capable of generating any type of document and second, specific versions suitable for generating grant proposals.

My high level goal for The Shape of Knowledge -- the book, this blog and the Apprentice Systems website -- is to create an environment where people with knowledge can generate useful applications that embody that knowledge without writing computer code. To achieve this, people must be able to document their knowledge in easy-to-use tools like Microsoft Excel. A spreadsheet is perfect for capturing 'square' knowledge like tables. We created our own tool, KnowtShare, for documenting hierarchical triangle-shaped knowledge like decision trees. Between KnowtShare and Excel (Excel can also capture lines/lists and cubes/3D tables) we've been able to document many forms of important knowledge. The knowledge necessary to create a Composer is two tables, so only Excel will be required.

Then our job at Apprentice Systems is to create the Application Generators - - "apperators" - that can consume this documented knowledge and generate simple but useful applications. This method only works because underpinning the whole process is a highly reusable, generally applicable knowledge pattern that provides discipline and acts as a link between the documented knowledge and the app generator. Yes, two tables are all that's required, but the two tables must meet a consistent set of requirements for the Composer Apperator to work. My task is to design the two tables and identify those requirements.

The first table is the Content Table, and it will act as the 'parts catalog' for my configurator. It will be the comprehensive set of questions and answers that the Composer will draw from to generate a grant proposal. There will be multiple columns in this table, representing the various versions of the content.

The second table is the Sequencing Table, and it will act as the instructions for how to select and assemble items from the Content Table. There will also be multiple columns in this table, providing different sequencing instructions for different potential target audiences.

"To meet the current need" -- establishing the context for a particular document -- will determine which columns to use from each of the two tables. When running the Composer the user will select the version of the content and the target audience for that particular document, and the Composer will generate an HTML document that meets those specifications.

This is the general game plan. The next posts will show how this actually works for grant proposal generation.

The Composer: a Document Configurator

I said in my last post that one of the challenges a nonprofit faces is that every foundation has their own unique grant application. That's not exactly true.

There's at least one group, the Washington Regional Association of Grantmakers (WRAG), that has attempted to create a common application for their members. It is not unlike universities, who have a 'common app' that many colleges use for vetting students. But if you've applied to colleges you know that 1) many schools don't accept the common app and 2) those who do often have a supplement that asks the additional questions each university still wants answered.

This is because different institutions have different wants and needs. I don't blame them for wanting answers to all their questions; they have the right to know what they want to know before admitting a student to their school. Foundations definitely have the right to know what they want to know before giving another organization their money! In the case of WRAG, out of 100+ members only 18 accept the common grant application.

If you look more closely at the grant application process, you will see that while each application is unique, the questions asked are not. After all, there are only so many items of information you can request from a nonprofit organization. Maybe you can ask a prospective student a wild and innovative essay question to surface his or her true character, but most of the answers a foundation is seeking could be pulled from the nonprofit's business plan, if only they had one.

I felt instinctively that if I could develop a comprehensive set of questions, what would distinguish any particular application would be the subset of information being requested and the order in which the questions were asked. In other words, what I was trying to solve was a classic configuration problem.

Apprentice Systems has solved many configuration problems for our clients. Configuration is a design process where solutions are created by selecting from a set of predefined parts and assembling the parts to meet the needs of a particular situation. We've built systems to automate product configuration (part assembly), process configuration (task assembly) and decision configuration (criteria assembly). What was needed here was a special case of product configuration: document generation. We know how to solve that problem by writing custom code. Could I simplify it into a knowledge pattern that would put automated grant writing within reach of nonprofits everywhere?

After six weeks of research, I feel we are well on our way to making this goal a reality. The knowledge pattern that makes it possible I've dubbed "The Composer". The knowtifacts necessary to generate a Composer are two squares: a Content Table and a Sequencing Table. My next posts will describe my design and creation of these knowtifacts, and the challenges and opportunities for the philanthropic community that have surfaced along the way.