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.
Tuesday, November 18, 2014
Tuesday, November 4, 2014
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.
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.
Subscribe to:
Posts (Atom)