A Short Intro Video for the NPO Network

In my last post, I talked about creating a video overview of the problems charities face, and how we have a proven solution that will make philanthropy work better. I created this 26 minute video to begin the process of looking for funding, since we've taken the effort as far as we can on our own, in our spare time.

When I told my brother, Professor Vern Walker, that I had created a 26 minute video to do this he immediately told me that was way too long - it needed to be no more than two minutes!

My position was, if someone didn't care enough to invest 26 minutes of their time to learn about the situation, they certainly wouldn't care enough to donate to the cause. I still feel that way, but I understand Vern's point: really busy people need a quick way to find out if my topic aligns with their interests. That's all I can hope to achieve in two minutes - to help them decide to invest 26 minutes in the longer video. To actually convey information about the problem and our solution requires much more time than two, five or even ten minutes. I wish Life weren't so complex, but if this was a simple problem, someone would have already solved it.

So, with much consternation, I embarked on creating a two minute video that would drum up interest in the NPO Network and my video overview of "How to Make Philanthropy Work Better". Full disclosure: it runs 2 1/2 minutes...

The Decision to Look for Funding for the NPO Network

After working on the NPO Planner and Grant Generator for about eight months, my vision for what it can become has grown from a standalone application to help my local food bank, Food for Others, to an online community that helps charities and foundations alike. I've picked the name 'NPO Network' as my working title for this effort.

I see the NPO Network as a place where charities can find planning and automation tools, as well as search tools that help them find like-minded foundations.

I see foundations coming to the community to get the information they need for selecting charities and giving grants. The community's automated grant application generator will give them the control they want without the expense of designing and maintaining their own grant application website. I think foundations will appreciate that all the money they give will go towards a charity's mission, and not to pay for foundation search firms and grant writers.

And I see an online community that connects a network of coaches with charities and foundations that need their help. My experience tells me that there are a lot of people just like me who are ready and able to put their experience to work helping others.

This vision is much bigger than the project we began work on many months ago, and we've taken things as far as we can take them in our spare time. To move forward, I will need to find some funding.

My goal is to provide our services to charities for free; I don't know if this is really possible, but it is my intent. To achieve this we need to find partners who share our vision and are willing to invest in our efforts.

My first step is to create a video that gives an overview of both the problem charities face, and our solution to it. This 26 minute video is my first attempt at doing this:

Revisiting How the Nonprofit Planner Fits Into My Theme

As I get deep in an actual web application, like the Nonprofit Planner and Grant Generator, it is easy to lose track of what my overall goal is with this blog and my book "The Shape of Knowledge".

My main message is, and has been, that there are basic knowledge patterns that capture important types of reasoning. The pattern I am elaborating on here is a Composer, which captures content once and then configures and reconfigures it into various documents to meet a particular need.

The value of identifying these patterns is that a talented developer, like my partner Steve, can write a powerful program that consumes predefined knowledge artifacts created by domain experts and then generates a web app automatically based on that knowledge. I call this type of program an application generator, or an 'apperator', for short.

At the same time, the identification of knowledge patterns empowers us, the knowledge authors who create the knowledge artifacts, because we can use these 'apperator' programs to build our own custom solutions without writing code.

In this particular case, I built a template using KnowtShare (our online collaboration tool), and made it available to charities for developing and documenting their business plans. The shape of that template, and therefore all plans created using it, is a hierarchical tree model. I call this shape a 'triangle' because it grows from a single root to the many 'leaves' of the tree. This tree/triangle is the knowledge artifact that stores the raw material for the Grant Composer. Each charity will create and maintain its own business plan.

There is a second artifact required, and it is built and maintained by me, as a community resource. That is a table -- a 'square' -- containing the information requirements for particular foundations.

The 'apperator' Steve has written is a Composer that knows how to consume these two types of artifacts: a hierarchical KnowtShare file filled with written information items and a .csv file that contains a matrix of communication targets (foundations) and their preferred order for those information items. Context questions are used to identify which branches of the tree and which rows of the table to use when creating a solution at run-time.

I, as the knowledge author, decided to use business plan information to populate a grant application for foundations, so the actual app that is created is a Grant Application Generator. But the same pattern could be used to collect an individual's CV and generate a customized resume for a particular company -- that would be a Resume Generator. Or a student's transcript and essay questions to generate a customized college application -- that would be a College Application Generator. This makes sense: these examples are very similar to the Grant Generator.

What about something further afield? There's a whole industry evolving around using legal boilerplate and context questions to generate legal documents. The Composer pattern could be used to achieve the same results, and with far less programming.

My last post was dedicated to describing how the very same business planning information used in grant applications can be used to generate other reports and marketing materials. All of these are examples of the Composer Pattern and can be created by the same aperator with only minor tweaks.

The Composer is just one pattern. I have written about the Recommender pattern and the Scoring pattern as well, and I will be describing others going forward.

The challenge, and the opportunity, come from thinking about problem solving at a higher level of abstraction than we normally do.

Most applications are built to solve a particular problem. The IT team interviews their customers to determine the functional specifications for an application they want built. Then the IT people go off and build it, checking back in periodically with the customers to make sure they're still on track.

Typically there is a deadline looming, and everyone is focused on the problem at hand. No one is interested in investing time (and money) in designing a meta solution that will make the next problem easier to solve. In fact, if programming is paid for on an hourly basis, there is a disincentive to look for the patterns that will make application development more efficient. But as knowledge authors, and as problem solvers in general, there are many benefits to identifying and harnessing new patterns.

Knowledge patterns only become visible when you are exposed to many different but similar problems, and when you look for them. It also helps to have a vocabulary and a mental framework that make it easier to discuss the patterns you sense are emerging. My goal is to contribute to the creation of those foundational tools, and to create real world examples that will stimulate discussion.

Other Nonprofit Composer Opportunities

The first Composer we are building for the NPO (Nonprofit) Network, which is what I am now calling the website I want to build, is a Grant Application Generator. My last posts have been dedicated to chronicling the process I went through to design this Grant Composer. But the Strategic Planning information that we collect with the NPO Planner has value far beyond grant applications.

The NPO Business Plan has strategic information, such as the organization's purpose, mission statement and strategy. It has high level financial data. It also has program information, such as program descriptions, volunteer information and even stories that can be used to 'sell' the program to potential donors and partners. These types of information can serve as high quality raw material for many different communication pieces.

The role of a Composer is to configure information, stored in what can be thought of as an 'information catalog', into a form that meets a particular set of needs. The Grant Application Generator configures business plan information into a grant application that meets the submission requirements of a particular foundation. The same raw material could be configured to create reports for Board members, handouts for volunteers, brochures for potential donors, even public websites.

The current business plan model contains only text and numbers, but it will be expanded to include images. This extension is important, because visuals are essential in certain media, such as brochures and websites.

Professional templates will be developed for different communication vehicles, with much more extensive formatting than the Grant Generator, which is designed to replicate a completed questionnaire. Often the content of the Grant Generator is cut-and-pasted into an online form, so the main goal of its formatting is simplicity and clarity, not beauty. The formatting of Composers for printed documents, especially marketing documents, will strive for professionalism and attractiveness.

Once templates are created, we will create context dialogues that ask for important parameters, such as which program should be featured in the communication piece. The Composer will know, based on the template, whether the long or short form of the answer is most appropriate.

Ultimately, the Composer will manage the selection and placement of text and images into the appropriate template, based on the information collected in the context dialogue.

The creation of additional Composers will extend the value of the Business Plan content, and save even more time for chronically time-poor nonprofits. It will make available a growing portfolio of communication documents that nonprofits can use to get the word out about the services they provide. The availability of these documents will help in the recruitment of volunteers and donors, and improve the understanding of stakeholders like the Board of Directors and community partners.

Composers provide document automation, and like all automation tools, they free-up people to focus on the tasks that only people can do. In this case, that task is the crafting of the message. The mechanics of document assembly will be left to the computer.

One More Input to the Nonprofit Planning System

I said in the prior post that two knowledge artifacts are required to run the Grant Generator: the Business Plan Tree, which provides the content, and the Foundation Sequencing Table, which provides the assembly instructions. There is one other input, a community asset that I build and maintain along with the Sequencing Table, which I call the Nonprofit Element Attribute table.

In the process of building the Nonprofit Planner and Grant Generator, there were certain design and formatting decisions that were left to me as the knowledge author. One was the rules for when to use the green 'completeness' highlighting in the business plan, and the other was how to format the output in the grant application.

First, I'll explain the completeness rules. Remember, in KnowtPlan, when an item is completed it is outlined in green in the note view and highlighted in green in the outline view.

The rule for when to apply the highlighting to the 'leaves' of the tree is simple: when both the short and long answer are filled in, add the green outline. So the completeness rule for 'Organization's Mission Statement' is 'self'; it is highlighted as soon as its 'self' is complete.

The rules for how to roll the highlighting up to higher levels in the tree are somewhat more complicated. That is because some of the higher level notes require their own answers and some are just headers added for organization purposes.

An example of a note that is just a header is 'SWOT Analysis'. It has no content; if you clicked on it, you would not get a popup window asking for a long and short answer. So its completeness rule is 'children'; it is highlighted as soon as all of its children are highlighted. In the screenshot above, SWOT is not highlighted because two of its attached notes have not been filled in yet.

On the other hand, 'Organization's Purpose' is a note that acts as a header but also requires its own content. The charity is expected to fill in the organization's purpose, which should be short and compelling - different from a mission statement, which can be rather wordy. So the completeness rule for 'Organization's Purpose' is 'both': it is considered complete when all of its children are completed AND its own content is filled in.

So one piece of information I have to provide is the completeness rule for every item in the plan. I do this by adding an attribute called 'completeness' and setting its value to 'self', 'children' or 'both'. A second attribute I need to provide for each item is how it should be formatted in the grant application that is generated. This is similar to assigning a paragraph style in Microsoft Word.

Even though we ask for a 'long' and 'short' answer for each question, it is clear from working with the actual content that some answers tend to be much longer than others. For example, contact info tends to be very short. Descriptions of the Board members, on the other hand, tend to be much longer.

So we created two different paragraph styles: 'inline' puts the question header on the same line as the response pulled from the business plan; 'paragraph' puts the header on a separate line. There are also headers, the ones that have no content of their own, that never show up in the generated grant application. Their style is set to 'none'. This became a second attribute.

I'm sure there will be other attributes that will surface as we continue to develop the Nonprofit system. To make it easy to expand and maintain this sort of information, we capture it in a table that is easy for me to change, and doesn't require changes in computer code. The current version of the Nonprofit Element Attribute Table looks like this:

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.

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.

Deep Dive: Financials Page

The Financials Page in the nonprofit plan collects the set of numbers most often requested by foundations on their grant applications. It is a subset of the numbers found on a typical financial statement. As a 501c3 organization, a charity is required to publish their most recent financials, so this information should already be in the public domain. Foundations, however, don't want to seek this information out; they want just the numbers they want, and in the format they want it.

The financials contain numbers from the prior year, current year and next year, with the majority of the information coming from the current year.

'Prior year' asks for the budgeted and actual revenues, expenses and net income. Comparing budget to actual lets foundations evaluate a charity's planning skills, establishing how much confidence we should have in the budgeted numbers for next year.

A particularly important item is the list of funding sources, and the percentage raised from each. This shows how diverse the funding base is (or isn't), and the stability or vulnerability of that base.

The expenses are broken out to show how much is spent on fundraising, administration and programs. This is important because foundations and donors want the majority of their money to go to programs, not salaries and overhead.

Another item asks about any unusual events which may have impacted the numbers. This gives the charity an opportunity to talk about internal and external challenges that are threatening its viability.

A similar set of numbers is collected for the current year, but with two versions: the current year-to-date, and the projected full year numbers. This provides another reality check; if the YTD numbers are significantly different from the projected numbers, a red flag goes up in the minds of potential donors.

Next year numbers follow the same pattern, but reflect budgeted numbers only.

Once again, the credibility of these numbers is impacted by the accuracy of budgeted numbers from prior years. One would also expect the Next Year numbers to incorporate the impact of challenges mentioned for prior and current years, if they are ongoing issues. To not acknowledge these impacts in next year's forecast would indicate a lack of realism in the planning process.

The final pages in the nonprofit plan are the Program Pages, including a page for General Operating Support.

Deep Dive: Strategic Plan Page

The Strategic Plan page of the nonprofit plan focuses on information that describes the organization as a whole.

It has small sections for general information, such as 'year founded' and '501c3 status', contact information and key personnel information.

The heart of this page, however, focuses on strategic plan information.

The main topics in the strategic plan are purpose, populations served, goals and strategies, impact, SWOT (strengths, weaknesses, opportunities and threats) and resources.

When an item has been completed, the note is outlined in green. When a group has been completed, its header is outlined in green. This gives a quick visual overview of the structure of the plan and its current state of completeness.

When the planner clicks on a note, a dialog box opens.

In the first version of the solution, the long and short answers required two separate columns in Excel. Now they are two separate 'fields' in each note. The long answer is written first, because it is easier to be verbose. Crafting a pithy short answer from the long answer is a second step. Both answers are required because many grant proposals are documented in online systems with restricted word counts. If the targeted foundation has this type of submission system, the short answers should be selected when running the proposal generator.

The planner can also choose to work in the outline view of the KnowtPlan model (KnowtPlan is the current name for this special-purpose variant of KnowtShare). The outline view may be the preferred option for the more text-oriented user.

This view also uses green color-coding to communicate the plan's state of completeness, Both views let the planner type in answers or cut-and-paste from another document.

We are also developing an import option from Microsoft Word as a way to initially populate the plan. Ongoing revisions, however, will need to be done directly in the KnowtPlan system.

In my next post, I will give a brief overview of the other sections of the Nonprofit Plan.

Overview of the New Nonprofit Planning Model

My last post described how I came to the realization that our collaboration tool KnowtShare is a better tool for capturing content for the Grant Proposal Generator than Microsoft Excel. It's better because the required content is NOT a simple list of questions and answers, but a business plan - a plan specifically designed to meet the needs of nonprofits.

I knew it would be mechanically easy to build a hierarchical plan using KnowtShare, but I needed to decide the best approach for thinking through the model I wanted to capture.

I decided to use the bottom-up, intuitive approach to building a tree. I had the leaves of the tree -- they were the individual questions/information items gleaned from the series of foundation grant applications we had analyzed. Using the bottom-up approach, I began grouping these into small groups and creating headers for the groups. Sometimes these headers were new items; sometimes I used an existing note as the header. For example, I decided to use the Executive Director's Name as the header for the Executive Director's contact information.

Then I grouped my first level groups into higher level groups, and wrote headers for those new groups. I continued in this fashion until I reached one, comprehensive group, which was the overall plan. This basic process is called creating an Affinity Diagram, and I describe it in more detail in my book The Shape of Knowledge. Often this method is used to help a group of people develop a shared model, but I find it is a good approach for individuals as well!

The top level of the tree became my page headers: Strategic Plan, Financials and Program Plans. One of the challenges I faced while designing this nonprofit business plan was how to handle the program-specific content for multiple programs. I decided to make each Program Plan a separate page or branch of the tree, and that each should contain an identical template of questions.

I also decided to automatically generate a program page called "General Operating Support" for every plan (because every charity writes grant proposals for operating support) and then let the charity generate additional pages, one for each of their major programs. In this way, the plan is customized to match a charity's particular offerings. When it is time to generate a grant proposal, the charity will need to select one of these programs as the basis for their funding request.

In the next post we'll take a closer look at the composition of each of the major planning sections.

Lessons from the Field: My Initial Experience with the Grant Proposal Content Table

One month ago I began using Microsoft Excel to capture the answers of several small charities in the Content Table that provides the 'raw material' for the Grant Proposal Generator. This Content Table was described in my October 7th post.

As is always the case, the real-life application of tools and ideas surfaces many opportunities for refinement. That is, after all, why we do testing! In the last month I became more convinced than ever of the need for such a tool, and the value it can provide charities. But I learned a couple of important things - one about the need to be filled, and another about execution - that will impact our approach.

First, the need. From the beginning, I approached this as an opportunity to help charities generate grant proposals quickly and easily. We would do this by capturing their answers in a format that could be automatically configured to meet a foundation's requirements. What I didn't anticipate is that the charities would also need help developing those answers. In fact, by removing the impediments to proposal construction, we shone a light more brightly on the quality of the answers that were being assembled.

In other words, by focusing our efforts on capturing the one, best answer to a set of comprehensive, rigorous questions it became clear that those answers often did not exist. Or many versions of the answers existed, in many different documents. What became clear to me is that the first need the charity had was support for the business planning process. Without that, our automation efforts would churn out a high volume of low quality grant proposals.

The second thing I learned is that Excel was not the right tool for this job, primarily because a table is not the best shape for the knowledge we are collecting. The content required is a business plan, and the business plan is best described as a hierarchical model, not a table; it is a triangle, not a square. Here are some of the signs that told me a change in approach was necessary.

First, I love Excel, but it is designed to work with numbers not large blocks of text. Trying to type long descriptions into spreadsheet cells was pure misery! That's okay; I had a more fundamental reason that Excel was not the right tool for the job.

Just as a reminder, this is what the structure of the Content Table looks like:

The table has about 150 rows/questions and two columns for General Operating Support (long and short form), and two columns for each program described in the plan. So, if a charity has two programs they will have a total of six columns.

I said up front that the answers to some of the questions will be the same for GOS and all programs - contact information falls into this category. The mission statement of the organization is another example of an answer that doesn't vary. Multiple columns were required because many other important questions will have different answers for different programs: questions regarding populations served, communications strategy, and volunteer requirements, for example.

It's not until you are actually copying and pasting the same answers over and over that you stop and say 'wait! there must be a better way'. And there is.

The copying and pasting was a sign to me that I was using the wrong shape to capture the necessary knowledge. This was not a list of questions (a 'line') with multiple variations (a matrix or 'square'). It was a hierarchical business plan - a tree or 'triangle'. Some of that information I was copying and pasting many times was high level information that only needed to exist once for the whole organization, and sometimes it was information from a different branch of the tree and didn't need to be duplicated for each 'program' branch of the tree.

I knew I needed to rethink the structure of the content knowtifact. I had picked Excel because it was convenient and familiar, but our own KnowtShare application, which makes it easy to construct hierarchical models stored in JSON (a web-oriented data interchange format) was a better choice. So I went back to the drawing board to reinvent the content knowtifact for the tool we are now calling the Nonprofit Planner. My next blog posts will be about that reinvention process.

The Sequencing Table for the Grant Proposal Generator

The Content Table described in my last entry is the 'parts catalog' in the document configurator I want to build. The Sequencing Table will act as the assembly instructions.

The format of the Sequencing Table is similar to that of the content table, because they share a key field: the grant application questions.

Every row in the Content Table must have a corresponding row in the Sequencing Table for that content to be included in the grant proposal that is generated. There are a few headers added for organization purposes, like the "General Questions" text shown here, but they do not show up in the generated proposals.

A number in the column simply means that a given item is in that position in the proposal for that foundation. A blank means the information item is not required. In this way, the column of numbers shows both the subset of information required and the order it should be placed in to meet that foundation's needs.

This column of information needs to be filled out for each foundation that appears in the Grant Proposal Generator. My strategy for capturing this information is to prioritize foundations based on the needs of the charities that participate in our pilot program. I am working closely with the pilot program charities to help them find like-minded foundations that will have a higher probability of granting their requests. I will use the timelines generated from these prospecting lists to prioritize the foundations and schedule their addition to the system.

My goal is, eventually, to have foundations add themselves to the system by providing an intuitive, easy-to-use tool that helps them select the questions they want and arrange them in their preferred order. They will also be able to use the tool to modify their 'questionnaire' at any time. This will be the most efficient way to develop and maintain the Sequencing table, and will guarantee the Grant Proposal Generator is up-to-date with foundations' current requirements.

My next step is to work with my pilot charities to fill out the Content Table.

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.

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.

Finding a New Pattern: The Composer

I've written a series of blog posts about building a Recommender app by creating the required knowtifacts and dropping them into the Recommender Apperator to generate the app. My example was a Whiskey Recommender, and it was a more complex version of the Recommender pattern I introduced in my book The Shape of Knowledge. Earlier, simpler Recommenders covered in the book were the Beach Town Recommender and the Knowledge Artifact Recommender.

The Recommender knowledge pattern is one I created based on some of the work we've done at Apprentice Systems, building intelligent systems for clients. It is a simple pattern that contains both a triangle/tree (the Context Decision Tree) and a square/table (the Options Table). An optional component is a folder full of images depicting the various options in the table.

Once I defined the Recommender pattern I looked for simple examples I could use to build demo applications. In other words, the Recommender was a pattern looking for problems to solve. Now I am going to switch gears to a new pattern, one I discovered only recently, in the process of solving an important real-world problem. I believe this series of posts will make even clearer the potential of the methods I am laying out in The Shape of Knowledge. I am not espousing these ideas because they are nice to know. I am doing this because I want to make a positive difference in the world.

It was in the spirit of making a positive difference that I visited the local food bank two months ago, to see how I might volunteer. I went ready to pack boxes of food and make food deliveries, but after a brief interview with the volunteer coordinator, she decided I could make the biggest impact by helping them write grants.

Grant writing is actually the process of writing grant proposals to foundations, asking them to grant money to support nonprofits in their efforts. Charities rely on grants for both general support and project-specific support, and many nonprofits could not exist without these funds. Writing grants is a time-consuming and onerous task, and many organizations end up hiring a 'grant writer' to help them in this effort.

There is an industry of individuals and organizations that thrive on the fact that nonprofits have neither the time nor the skills to jump through the hoops of grant writing. Every foundation has their own process, which often includes filling out a custom application -- sometimes in hard copy, often online. The one-off nature of these applications means every grant proposal is usually a cut and paste exercise in Microsoft Word, using past proposals as the raw materials for new proposals. This process can be haphazard and inefficient.

It's also hard to find foundations that are likely to support the request of the charity, based on mission and geographic fit, so database companies have sprung up to meet this need -- for a stiff monthly subscription fee. My personal experience with the quality of the leads coming out of these services would indicate this is not a good investment.

I don't begrudge anyone making a living, but personally I have a problem with so much of a charity's funds being diverted into the process of writing grants. I would like to see the food bank's money going to feed hungry people! I think foundations that support the food bank would want this as well.

I also think that funds should be directed to the nonprofits with the best programs, not the best grant writers. With that principle in mind, I decided that philanthropy is a sector that could benefit from a bit of technology disruption. A high potential piece of that disruption is a pattern I identified by working with the grant writing process -- I call it the Composer.