The words “policy,” “plans,” “programs,” “projects” and “orders” are often used interchangeably one for the other, incorrectly.

To handle any confusions on the words and substance of “policy,” “plans,” “programs,” “projects” and “orders” the following DESCRIPTIVE DEFINITIONS (see Sen Logic No. 5) are laid down for our use.

POLICY: By this is meant long-range truths or facts which are not subject to change expressed as operational rules or guides.

PLANS: Short-range broad intentions as to the contemplated actions envisaged for the handling of a broad area to remedy it or expand it or to obstruct or impede an opposition to expansion. A plan is usually based on observation of potentials (or resources) and expresses a bright idea of how to use them. It always proceeds from a REAL WHY if it is to be successful.

PROGRAM: A series of steps in sequence to carry out a plan. One usually sees a program following the discovery of a Why. But in actual fact a plan had to exist in the person’s mind, whether written or not, before a program could be written. A program, thus, carries out the plan conceived to handle a found WHY. A plan and its program require authorization (or okay) from the central or coordinating authority of the general activities of a group before they can be invested in, activated or executed.

PROJECTS: The sequence of steps written to carry out ONE step of a program. Project orders often have to be written to execute a program step. These should be written but usually do not require any approval and often are not generally issued but go to the person or persons who will accomplish that step of a program. Under the category of PROJECT would come orders, work projects, etc. These are a series of GUIDING STEPS which if followed will result in a full and successful accomplishment of the program target.

ORDERS: The verbal or written direction from a lower or designated authority to carry out a program step or apply the general policy.

In short:

POLICY = the rules of the game, the facts of life, the discovered truths and the invariable procedures.

PLANS = the general bright idea one has to remedy the WHY found and get things up to the ideal scene or improve even that. (Approval.)

PROGRAM = the sequence of major actions needed to do the plan. (Approval.)

PROJECT = the sequence of steps necessary to carry out one step in a program. (No approval.)

ORDERS = some program steps are so simple that they are themselves an order or an order can simply be a roughly written project.

Thus, by these definitions a data analysis would look like this:

POLICY: (What brings the evaluation into existence in the first place.)

SITUATION: (Departure from or improvement of the ideal scene expressed in policy.)

DATA: (Observations leading to INVESTIGATION.)

STATISTICS: (The independent continuing survey of production or lack of it.) WHY: (The real reason found by the investigation.)

IDEAL SCENE: (The state of affairs envisioned by policy or the improvement of even that.)

HANDLING:

A PLAN whether written in full or not based on the WHY to use the resources available to move the existing scene toward the ideal scene.

A PROGRAM: A sequence of broad steps to get the plan executed.

PROJECTS: Any sequence of steps ordered or written to get a program step completed.

ORDERS: The program step itself or the verbal or written project to get the program step fully done.

Thus a handling could look like this:

HANDLING:

Plan: To use Bob Bartlett to replace the incompetent exec found in the WHY.

1. Find a replacement for Bartlett. PERSONNEL.

2. Program Bob Bartlett to get his incomplete cycles caught up. DIR OF PERSONNEL ENHANCEMENT.

3. Train Bob Bartlett. DIR OF TRAINING.

4. Write Garrison Mission Orders for Bartlett. ACTION MISSION WRITER.

5. Write recall orders for G. Zonk (the incompetent found in the WHY). PERSONNEL.

6. Send Bartlett to relieve Zonk. ACTION.

7. On Zonk’s return assign to bilge cleaner. PERSONNEL.

his of course is a very simple plan and simple program.

The orders are seen as “PERSONNEL,” “DIR OF PERSONNEL ENHANCEMENT,” “ACTION MISSION WRITER,” etc., at the paragraph ends. The program step itself is an ORDER to the person or unit named at program step end. But IT ALSO AUTHORIZES THAT PERSON OR UNIT TO DO THE STEP OR ISSUE ORDERS TO DO THE STEP OR EVEN WRITE A PROJECT AND GET IT DONE.

That final end word on the program step is an AUTHORITY as well as being an order to the person or unit named.

A copy of a full program marked MASTER is placed in a folder. The folder is marked on the edge with the program name and number. The program itself is stapled along its left edge to the inside left cover of the folder.

A “Flag Rep” is responsible for “LRH programs.” A Deputy Executive Director or Deputy Commanding Officer is responsible for an ED’s or C/O’s programs.

The responsibility lies in seeing that each step is FULLY effectively DONE.

All related papers, copies of projects’ orders, etc., are collected in that folder and as each done is reported and investigated as DONE it is marked off on the MASTER program sheet.

When all those projects or orders bred by the program steps are DONE then the PROGRAM is considered DONE.

One does not “report progress” but only DONES and when something is NOT done yet it is chased up by the “Flag Rep” or Deputy ED or C/O and “debugged.”

The word “bugged” is slang for snarled up or halted.

DEBUG is to get the snarls or stops out of it.

This itself requires an evaluation. The evaluation may be done at a glance or it may take a full formal evaluation by form.

The ideal scene here is the program step DONE or even improved.

So the WHY here would be the REAL reason it was not being done or couldn’t be done and that may require hours to locate and sometimes days to remedy.

When “debugging” one usually finds the persons assigned the target already have a “WHY” and it is usually a false Why for if it was the right one the program step would get done.

Thus debugging usually begins with finding “their Whys” — which is to say reasons, excuses, apologies, etc. Getting these into view is a main part of the program step evaluation.

A project, often written, comes out of this DEBUG EVALUATION.

In extreme cases it will be found that the whole program is based on a wrong WHY and rapidly needs redoing by the original authority. Example: The WHY found was that the JINX OFFICE WAS NOT MAKING MONEY. In doing one step of the program: “3. Survey past invoices to find where money is coming from and why they don’t get it now. MISSION,” the mission sent finds Jinx Office was making money by the ton but it was being wasted by their having bought a huge building whose rent is three times normal rental “in the hopes new subtenants would pay the rent but nobody wants the place.” Rapid debug is needed because the target can’t really be done. They ARE making money and they do get it now.

In such a case doing the program unearthed a new REAL WHY and scrubbed that program.

A super-frantic hysterical communication would be sent to the authority of the

program, “New WHY found by Pgm 891 target 3 observation. Jinx Office paying $80,000 a quarter for skyscraper. Obvious real Why ED has delusions of grandeur, is a bad business head. Suggest Pgm 891 redone on new Why and suggest plan of mission here for instant offload of this skyscraper and office into proper quarters and replacement of ED.” At which the Flag Rep" or Deputy ED or Deputy C/O will approach the authority for the pgm to get immediate cancellation of 891 and all program targets and a new Program 891R based on the REAL REAL WHY.

Debug, however, is not always so dramatic. “We don’t have anyone to put on it” is the usual excuse as they sit lazily chatting amongst their piled up dev-t.

So one evaluates the area against the program target and finds a WHY that, executed as a project will get that target done.

The PERFECT DEBUG EVALUATION (a) gets the target done (b) improves the area (c) leaves no dregs of human emotion and reaction behind it.

Just plain screaming often works. But if one has to, there is a real WHY there someplace that should be found, a project handed out and done.

You can find out all the SITUATIONS and WHYS in the world but if there isn’t a PLAN and PROGRAM and if these are not DONE fully, then nothing beneficial will happen. Indeed the not-dones, half-dones and backlogs will mount up (per HCO P/L 26 Jan 72, Admin Know-How 29, Executive Series 5) and set the whole thing a step backwards.

Bad programs and clumsy projects develop useless traffic (dev-t) and tie people up all over the place, pull them off normal needful actions and send the existing scene even further from the ideal scene. They make people very busy but nothing beneficial is gained and as the useless actions distract from normal duties, the whole place is at risk.

Staffs subjected to programs that are not based on sound observation evaluation, a REAL WHY and the points in Data Series 23, become apathetic as they see no result.

So programs that are bad and programs that are right but don’t get fully done are alike deadly. THERE IS NO SUBSTITUTE FOR CORRECTLY DONE DATA ANALYSIS.

THERE IS NO EXCUSE FOR NOT GETTING CORRECT PROGRAMS DONE.

In this way and only in this way can one raise the existing scene toward an ideal scene.

Data analysis is a powerful tool. YOU CAN USE IT.