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.

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.