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.

Creating the Whiskey Context Decision Tree - Part Two

My last post described the general challenges of building a context decision tree, and the specific challenges surrounding my search for expertise regarding whiskey selection. In the end, I decided I would have to rely on my own ideas, developed during the many hours of research I conducted while building the other inputs to the Whiskey Recommender. My immediate need was to create a context decision tree so the Recommender Apperator could generate a Whiskey Recommender app. Once that example is published, I hope to find some real, live whiskey experts that can help me build other, alternative Whiskey Recommenders.

I created my decision tree using our free KnowtShare web application. KnowtShare was designed to make it easy to build tree-shaped models. We, at Apprentice Systems, know from our many years of building intelligent systems that trees - hierarchical, non-cyclical models - are essential for capturing several modes of reasoning. Classification, composition and multi-pronged evaluation are all best described using trees. The branching behavior of a decision tree is also easy to document with this sort of model.

While some trees are best built bottom-up, a decision tree is usually built top-down. In other words, you decide the first question you are going to ask, list the possible choices, then determine what choices will be presented based on that first choice, and so on. The tree will document all the possible paths through the context collection process, but users will only travel one of those paths each time they use the application. At the end of each path, a 'leaf' on the tree, will be a recommended option - in this case, a type of whiskey.

I decided, pretty easily in fact, what the first question in my decision tree would be: "Are you going to mix your whiskey or drink it straight up?" I think this is a good first question because most whiskey connoisseurs agree that if you are going to mix your whiskey with Coke, it really doesn't much matter what you drink! Just don't waste a good Scotch! Of course, there are those who will mix an expensive whiskey with Coke, and I need to allow for that possibility as well.

Here is the 'mix it' side of my whiskey decision tree:

The next set of choices I present are using a flavorless mixer (water or club soda) versus a flavored mixer. You can still be a whiskey purist, of sorts, if you only use water or club soda. If your whiskey is to become part of a cocktail, however, it will be difficult to taste the whiskey itself - which is perhaps one of the goals of drinking a cocktail.

I'm pretty comfortable with these first few questions; I think I am on safe ground. Now the going gets much more difficult. I knew the 'flavored mixer' path was taking me towards the cheaper whiskeys, such as Canadian and American blended whiskeys, so I created the next set of choices: do you care more about price or status? If the user selects 'status', I decided to recommend either a Kentucky Straight Bourbon (like Wild Turkey) or a Tennessee Whiskey (like Jack Daniels). Picking 'price' leads to a variety of inexpensive American and Canadian options.

The real puzzler is the next set of options for the non-flavored mixer path. Remember, choices have to be presented in a language that represents the user's perspective (this was covered in the last post). Waxing poetic about the process differences between Scotch, Irish Whiskey and Bourbon won't work here! The target audience of the Whiskey Recommender is someone who is new to the world of whiskey, not an expert. Newbies couldn't care less about the finer points of distilling whiskey, especially since their palates probably can't distinguish the taste differences that result. So I decided to keep things simple, and make the next set of choices "do you prefer American products, or not?"

Finally, at the next level, I reached a point in the tree where I relied on taste profiles to make a distinction. American products were split into 'spicy', which leads to American Rye, and 'sweet', which leads to the bourbons. The non-American choice was split into 'light and smooth' (Irish Blended and Canadian Single Malt) and 'smokey and robust' (Scotch Blended and Single Grain).

This is the point where I need to reiterate an important message from the last post: this is all subjective! Even if I were a whiskey expert, which I'm not, this would still just reflect my opinion. A recommendation, by definition, exists in the world of subjectivity. Otherwise, this would be an 'Answerer', not a Recommender.

The power of the Recommender pattern is that I can create "Deb's Whiskey Recommender" just by building this tree in KnowtShare and combining it with the Whiskey Data Table in the apperator. Then my friend Richard, a real whiskey expert, can generate "Richard's Whiskey Recommender" by creating his own decision tree. He can even reuse my Whiskey Data Table. Better yet, in the future we can crowd source a much more complete data table and make that a community asset we all tap into when we build our own unique Whiskey Recommenders. That's the vision.

Back to my Recommender. Let's take a look at the other major branch of my decision tree, the 'straight up' branch:

I reused the 'do you prefer American products' choice again, and early on in the question sequence, because I needed to account for American Single Malts and I can't do it through a taste profile. American Single Malts are all over the board, taste-wise, because American distillers are using a wide variety of processes to create their single malts. Some are following the Scottish methods, and beating high-end Scotches in blind taste tests. Some are creating their own unique processes that are leading to unique taste profiles. All that binds them together is their country of origin, and that American origin is important to some people, including me. I like our underdog status in the Single Malt arena, and I like to support these distillers when I can.

As for the rest of the 'straight up' branch, it is a taste-driven breakdown between Irish Whiskey and Scotch, and within Scotch, a breakdown into the various regions. While some regions have distinct flavor profiles (like Islay) and some are more diverse (like the Highlands), taste is still the easiest way to direct a Scotch drinker to a particular region.

A real Whiskey Recommender, as opposed to this demo application I am building, could recommend specific Scotch brands, like Laphroaig. To keep things manageable, I have decided to stop my recommendations at a type of whiskey, like Islay Single Malt Scotch. If you've read the other posts about building the Whiskey Recommender, you will know that this is one of many simplifying assumptions I have made during this process.

Now that I've built my Whiskey Context Decision Tree and saved my KnowtShare file, I have all of the knowtifacts necessary to generate my app. The next step will be to enter them into the Recommender Apperator and generate my own custom web app.

Creating the Whiskey Data Table

As I mentioned in the last post, the whiskey poster I am using as my initial knowledge source has almost 450 different whiskey brands listed. These brands represent the many options a whiskey drinker has from which to choose. In a Recommender with a smaller number of options, like the Beach Town Recommender, these possible choices can be added as notes to the KnowtShare file and dropped directly into the classification tree, becoming the 'leaves' of that tree. However, 450 notes would be difficult to work with in a visual environment. Data tables are better at that.

So I switched from KnowtShare to Excel and began creating my data table.

I began by creating columns that aligned with the classes and sub-classes I had established in my classification tree.

Each row in the table is an option that can be recommended. The first column should always hold the option name; in this particular example it is a particular brand of whiskey. 

I should point out that 'brand' is not the lowest possible level I could go in whiskey database. A particular brand can have many variants. For example, Macallan, a very fine scotch, comes in Macallan 12, 18 and 21, the number in the name referring to the number of years the whiskey has been aged. There is a basic Macallan, which is aged exclusively in sherry seasoned casks, and a Macallan Fine Oak, which is aged in a combination of sherry and bourbon seasoned oak for a lighter flavor.

In fact, the variants of whiskey seem to be endless, so to make the Recommender manageable I decided to stop at the brand level. This has its own challenges, because my next step will be to add some attributes to the table, attributes like 'taste' and 'price'. Any attributes I add will need to be generalizations, in a sense, because they will be referring to a group of whiskeys that vary in age, process and bottle size. If the data in this table could be crowd-sourced in some way it would be possible to account for this complexity, but as a demonstration app (which is what I am building) I will need to make some simplifying assumptions.

My next task is to expand the table by adding attributes to the whiskey brands.

Creating a Whiskey Recommender: The Classification Tree

The whiskey poster I found in an issue of Fast Company (see my last post) showed a complex network of specific whiskey brands and types, but on closer inspection it's clear that it is a single classification tree bound together by class/subclass relationships. There are four major classes of whiskey in this chart: American, Canadian, Irish and Scotch. These classes then break down into sub-classes in a variety of ways, based on the ingredients and process used.

I needed to capture the knowledge from the Whiskey poster in an actionable form, so I used KnowtShare to create a classification tree. This is the American Whiskey branch:

The window in the lower right hand corner is a navigation pane that shows the complete tree.

The KnowtShare app lets me create notes and group them quickly and easily into a hierarchical structure.

The American Whiskey sub-classes are a mix of grain used (wheat, rye, corn) and process (single malt and blended). Bourbon is a unique designation based on both grain requirements (at least 51% corn) and process (charred barrels).

Some of these sub-classes are further broken down based on region and company. The whiskey poster goes on to name specific brands in each of these categories, but with 450 brands listed I opted to stop the KnowtShare tree at this level and handle the brands in another knowtifact: the options data table.

Here are the Canadian and Irish branches of the tree:

The Irish whiskey branch has two new sub-classes: single grain and single pot.

And finally, here is the Scotch whiskey branch:

Scotch is unique because it calls out six different regions for single malt. Each is considered to have its own special taste based on process, but all are made from malted barley.

In KnowtShare, when working with a very large tree such as this, you can use the page itself as the top node of the tree (here it equals "whiskey"). This allows you to arrange the next group of classes in any way that works best visually. The text view will show everything as one comprehensive outline and the .knt file that is saved will combine the four groups into a single hierarchical file.

The next task will be to create the options data table.

Creating a Recommender

I am going to do a series of posts that document the process of creating an app using a knowledge pattern. I am going to use a particular pattern we call a 'Recommender'. The Recommender pattern is shown in both The Shape of Knowledge eBook and in Part 2 of the video series that provides an overview of the eBook's content.

You can view the videos at these links:
Part 1 https://www.youtube.com/watch?v=ui8kjxGmjE0
Part 2 https://www.youtube.com/watch?v=Hma_ho2fHck

The Recommender pattern is made up of one optional knowtifact and two required knowtifacts.

The optional knowledge artifact is a classification tree of the options under consideration. The two required knowtifacts are a context decision tree and a data table that lays out all of the options and their attributes.

In the book I talk about two simple Recommenders: an app that asks a potential knowledge author questions about what they want to achieve and then recommends the best knowledge artifact for the job (the KA Recommender) and a Beach Town Recommender that asks a future traveler a series of questions and then recommends the best beach towns for vacation.

For this example I am going to create a Whiskey Recommender (or "Whisky" Recommender, if you prefer that spelling of the word; I learned in my research that whiskey aficionados feel passionately about this question).

I picked whiskey NOT because I am an expert - I'm not. I picked it because I ran across this great visual in an issue of Fast Company:

This poster, which is very cool looking, appears to be a hopelessly complex constellation of whiskey names and types, but I knew immediately that it was something much more fundamental -- it is a classification tree for whiskeys.

In The Shape of Knowledge, the classification tree is one of my prime examples of the Triangle shape. This whiskey visual doesn't look very much like a triangle, or 'rooted tree', but it is. My first task in building the Whiskey Recommender is to transform this content into a usable form, and I will do that by organizing the basic tree structure shown in the diagram, using KnowtShare.