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.

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.

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.