Katascopic Planning


This is a guide on how to actually make a katascopic plan. It is written primarily to show people interested in the Technocracy Katascopic Project just how this is done, and what kind of work they would be doing should they decide to help with the development of the plan in Stage 1 (see here). These instructions however can also be used for other applications however, such as for a different Technocracy project, or personal project, planning an event, or even trying to devise the best way to achieve personal goals in your life, such as getting a degree, or buying a car. The applications are virtually limitless. The main thing to keep in mind though, is that even if many different people are using this process for their own projects, while they may be performing them katascopically from their level and down, they are still working anascopically if there is no such plan above them to coordinate resources. Think of the boat built anascopically in the article Technocracy Comparative, and you will see what this means.

This article only outlines the basic process of how to do a Katascopic Plan so that you can use it anywhere. Some details like requirement coding etc. may still be needed for actually doing it, and are only given as examples here.


The process is outlined and described here:

  1. Goal: Determine what the overall goal of the project, operation, or group is. An example of this might be “To determine the energy resources of North America for group presentation.” In some cases a time-limit may be specified at this step, but should be avoided unless necessary, as in “Prepare energy presentation for VIP visit that is on April 25.”
  2. Requirements: This is probably the most important part of the process, as all the "items" in the Katascopic Plan will be requirements. A requirement is something that is needed in order to reach the goal, or more commonly the requirement above this one. When trying to determine requirements, the basic idea is to ask yourself: "What do we need to make this possible?" This can be anything from people, to objects, to information, etc. There is more on the different types of requirements below.
    Requirements can include things you have, or do not have, but both should be included. If you already have those requirements, then great, they can be checked off when the plan is done and you can move on. There are two reasons for including fulfilled reqirements though. One is because each time a KP is done, it serves as a starting point for anyone else wanting to do the same thing, so that they do not have to do this process again, or at least has something they can change to suit their own requirements. This avoids duplication of effort. The second reason is that even though you may already appear to have a required resource, it may turn out not to be later on. For example, if we need someone good with HTML coding, and Bill can do HTML coding, then that requirement may appear fulfilled. However, Bill may be needed elsewhere on a more important part of the plan, or a different one, and thus not be available. The same could happen for a computer. Many projects may need a computer, but if there is only one available, then it can only be used for one thing at a time. Thus its availability will depend on scheduling. So in summery, remember to document all the requirements you can, whether they appear fulfilled or not.
    Requirements can be as general or as specific as needed at the time, since the process can repeat to lower and more detailed specifics. An example of a list of requirements for the example above might be: “Energy data accurate to within 5 years; 2 computers for data processing and storage; a presentation medium for the resultant data; 4 people, two qualified in geology, one in spreadsheet/database design, and one in presentation software.”
  3. Tasks: Make a list of tasks for attaining these requirements, and assign them to available, qualified personnel. Example: “1- Make list of available sources of data. 2- Obtain data. 3- Correlate with existing industry performance data. 4- Summarize in computerized presentation.” If no time requirement has been specified in step one, then it is at this stage that estimates for completion of each task should be made.
    Note: Tasks are basically another type of requirement and should be treated this way.
  4. Repeat as necessary. At this stage, each task may become a goal in itself, which is why it is ok not to need to get too specific with the Requirements. Let us take an example of Task 4: “Summarize in computerized presentation.”
    1. (Goal)- Not needed as the above requirement statement is the "goal" here.
    2. (Requirements)- Computer #2 (laptop), LCD projector, the data summaries from Task Group 3, Presentation software (OpenOffice available), John Smith (qualified in presentation software, including O.O.), Jake Jones, Authorized speaker and geologist.
    3. (Tasks)- a) Create overhead presentation (Smith), b) Give presentation (Jones).
    4. (Repeat as necessary) - At this point, both Smith and Jones can create their own lists of requirements and tasks.
  5. Ecology Check. This is a routine check to ensure that all processes, tasks, and resources fit into the established requirements, as well as the overall goal. If two competing methods are being explored, this is the point when they would be compared. Also, it is a good time to ensure that this operation does not conflict with any other operations currently underway, or expected to begin with in the established time-frame. Each operation should be evaluated as to its conforming to the overall goals and procedures of the organization, such as those outlined in in any organization bylaws or regulations. Lastly, once all else looks good, someone will need to compare lists of resources to those in other plans, or other parts of the overall plan, to establish availability and scheduling.

This may all look at little daunting at first, but once you have been through it a couple of times, it becomes second nature, like riding a bicycle. By then you will also have undoubtedly discovered the benefits first-hand of this process. The end result of it, you will see, is a step-by-step list of instructions for each person involved to carry out. This makes everything in the operation quite clear, and thus easier for each person to perform their tasks within it, without worries of confusion or conflict. And also this procedure for doing things may also be used in the future by you or other people, as well as refined and made better from your experiences of having gone through it.

But this process is not set in stone, either. It will evolve with time, and the more it is used, the more it can be improved as well.


Special mention should be made about Step 2 involving Requirements. This is not a procedure so much as something to be aware of when developing your list of requirements. In every operation or project, there are six categories of requirements that need to be considered. Not every operation will require components from all six, but usually this will be the case.

  1. Information
  2. People
  3. Processes
  4. Materials
  5. Quality
  6. Task
When considering what requirements are needed, first write down (or otherwise record) whatever first springs to mind. Then after that, go down this list of types and ask yourself (or your group) if there are any requirements of this type that may be needed. When done, proceed to the next type and do it again until you have covered all six types. It will often help to do this so that you have less chance of missing anything important.

If you examine the example in Step 3 above, you will see these categories included: “Energy data accurate to within 5 years (information); 2 computers for data processing and storage; a presentation medium for the resultant data (materials); 4 people, two qualified in geology, one in spreadsheet/database design, and one in presentation software (people).” In this case, no processes, qualities, or tasks were needed at this level. They may end up being required at a lower level.

A special note about the last two requirement types. A "quality" is any requirement that is neither a physical thing (noun), nor a thing to do (verb), but rather an adjective or possibly even an adverb. An example might be "That this presentation be as appealing as possible to its intended target audience." Notice the underlined adjective of "appealing" in the statement. Preferably these requirements should be as objective as possible so that they can be measured. If we do not have a quantitative measure of how "appealing" something is or should be, then it will be much harder to figure out when this requirement is fulfilled. Sometimes this is unavoidable, but it should be minimized as much as possible.
Often you will need other requirements to have certain qualities about them. Below that quality requirement, other, more physical requirements may be needed.

A Task differs from a Process in that it is only done once. Once it is done, it can be considered finished and in the future ignored, unless it is itself part of a process (processes are often made up of smaller tasks). An example might be: "Lay out the chairs in the room in a circular fashion." Once that is done, it obviously does not need to be done again, at least not until that meeting or event process is itself performed again.

It is often good practice to mark down the type of requirement with it when documenting and designing katascopic plans, however you are doing it.


So that you have a better idea of how this fits into a typical operation, I will give some more examples of how this works, to get you better acquainted with the idea.

Suppose that a small group of Technocrats decide that they require some office space in which to conduct their work. Let’s start with Step 1:

Step 1: Goal. The goal is to acquire a space for use as an office to perform work for Technocracy. This sounds like a pretty good goal, but we can do better. If we check this goal is only part of a larger one, and that is the group’s overall goal create a Section. Thus, whatever is put into this process, must also take into consideration that larger goal as well. As we continue you will see the differences made if we do this, or if we do not.

So, our revised goal is now: To acquire a space for use as an office to create a Section.

Step 2: Requirements. Here we start asking questions about what we will need in an office. How much space will we need? Will we need furniture, and what kind? What about office supplies? Phone line? Some form of high-speed Internet connection, through a local LAN, or Wi-Fi? For how long will the office be needed? Is there a specific time period, or are there other conditions under which the office should be abandoned? These may seem to be heavy questions, but this kind of preparation will save you a lot of headaches later down the road.

Now this group is small, only about 6 people, of which perhaps 4 may be working at any particular time. Will there need to be space for the 6 of them to hold meetings? This will come up in the question of what kinds of activities will be performed there. We decide that there should be someone to answer phone calls and take messages, as well as answer questions about the group and Technocracy in general. Some space should be included for writing and otherwise dealing with paperwork, and another for a computer and work on it. Thus we decide that three desks would be optimal. There will need to be a computer, at least one telephone, and various office supplies. A filing cabinet for records (such as financial forms and Membership Applications), and a bookshelf for reference books would be handy as well. Will research be conducted here? This could have a big impact on the space and items required. The group decides that it is too small and that it should concentrate on promotion and outreach. For group meetings they decide that having three additional fold-out chairs would be sufficient and would save money, rather than getting a bigger space with a meeting table. What about newcomers? Will classes or presentations be made there? If so, this could impact the requirements as well.

Now, we have the workings of a good set of requirements. However, what we have not taken into consideration yet is the bigger or “parent” goal of building a Section. Obviously more members will be signing up and likely will be taking on responsibilities and needing space for work. The little space this group was planning on suddenly appears inadequate. Should they get a space big enough for 50 people? It is unlikely that the entire section will be working in one place at one time, but perhaps a bit more space would be useful. Also, what sort of timeframe are these new members expected? If many new members are not expected for quite some time, then perhaps the smaller space will do, and a larger space acquired when necessary, or better yet when the need is anticipated.

For now the group decides that a space of approximately 225 square feet should suffice. They establish a lower limit of 200 square feet, and an upper limit on cost.

Location is also an important decision. Should this be in an office building, or should it have a street-level storefront, with big glass windows for setting up displays to passers-by? Should it be downtown, or in a part of town where rents are cheaper? For this the group decides to look at a number of places and compare the relative merits of each.

Now we look like we are just about done. Or are we? Let us look at our Requirement category list and see if we are missing anything. Well, we have the Materials. What information are we lacking? Obviously first we’ll need a list of available places for rent or purchase. Also, a list of the groups assets and expected income should help too. People will be needed to discover this information, to acquire the space legally, and later move all the appropriate materials into the office and set it up for use. Someone will also be needed to acquire these materials.

What about processes? There are not many established Technocracy processes when it comes to acquiring office space, but perhaps some could be devised that might prove useful. For instance, if they are building the office space, then land lease and building permits will need to be acquired, so a process for doing that could be discovered. Another helpful idea is to ask for advice from other Technocrats based on their experiences of doing the same. Once this project is completed, you may want to consider another project, that of collecting and processing all the data you’ve gained during the process, and submitting it for standardization within the organization, to be then stored in a central repository for Technocracy Processes and Procedures.

When one is made your contribution will be invaluable to future groups just starting out. This is part of how our organization “learns” and becomes more “intelligent” as we grow. Keeping information to ourselves creates duplication of effort, and thus waste and inefficiency. This is not only untechnocratic in concept, but harmful to the organization as a whole, as it slows down our process of achieving our overall goal of teaching Technocracy to the people of North America.

Once all this is completed, a final list of requirements is drawn up and made available to the people who are to decide the next phase of this process.

Step 3: Tasks. As stated in the previous step, people will be needed to handle the various tasks needed to accomplish this goal. First, a list of all the needed tasks should be drawn up. Next, this task list should be compared to the list of available HR assets (people), and then tasks assigned to people. Preference should be given to people most qualified or experienced in that type of task, or if not then something related. Care should be taken not to overload one individual just because they are multi-talented. Compare estimated task durations and workloads with each member’s availability and resources. Always try to optimize the use of all your resources in order to get the best result. Note that in some cases more than one task can be assigned to one person, or more than one person can be assigned to a single task.

Step 4: Repeat as necessary. Each of these tasks will have several tasks within them that need to be done. For the sake of brevity we will only use one of the above tasks for an example.

  • Task #1 says: Obtain list of places available for rent within specified requirements, and has been assigned to John. This would be the overall Step 1: Goal.
  • Step 2: Requirements: Since John is going to use several methods, including using a phone book, looking around town, and asking people he knows, he compiles the following list of Requirements:
    • Information: Phone book. Addresses of various agencies. Phone numbers of people he wishes to contact. Map of the city.
    • People: Contacts of John’s that may know of places he can use.
    • Processes: Devised: Call people he knows first, then use the phone book, then look around town for signs.
    • Materials: Telephone, notepad and pen (for writing down things he sees while driving), car (he has one of his own), gas for car.

Once John has collected these things, he may proceed.

  • Step 3: Tasks. 1) Call contacts. 2) Check phone book for advertised rental places. 3) Drive around town looking for signs of places for rent. Note here that if any of these tasks did not, for example, fit his time requirement, it would need to be altered, or rejected in favor of something else.
  • Step 4: Repeat as necessary. Each of these tasks may further require this process, as John deems necessary. He decides that from here he knows what to do.
  • Step 5: Ecology Check. John needs to go over each step again and ensure that it falls into the goals and requirements of this project, and all the goals above it as well. If anything does not fit, then it will need to be changed, even if the entire process needs to start from scratch. It is laziness here that leads to inefficiencies and lack of effectiveness, and we as an organization cannot afford that.

Step 5: Ecology Check. Just like as John did, the group must go over every aspect of the project to ensure that it fits the project’s Goal. Also, it must fit the Parent Goal of creating a Section, and ultimately the even higher goal of Teaching Technocracy. So how do you keep track of all these goals? By use of a Project Ecology Chart (click on thumbnail for full image).
Example of the Project Ecology Chart (PEC) used in Katascopic Planning.