HCO PL 18 Aug. 82 Reiss. 8.9.82 Admin Know-How Series 42 TARGETS AND PRODUCTION HCO PL 9 Jan. 80 Executive Series 20 DEPARTMENTAL MINI PROGRAMS: THE KEY TO ACHIEVEMENT HCO PL 19 Aug. 71 PROGRAMS, USE OF — HOW TO SAVE USELESS WORK HCO PL 23 Oct. 69 PROGRAMING)

(The data in this issue has been excerpted from CBO 129, WRITING PROJECTS for issue as a policy letter as it contains pertinent and valuable data for hatting those engaged in writing programs or projects.)

Some years back in hatting an aide, I asked her to visualize a project she had written being read and done at the receipt-point — in other words to assume the viewpoint of the receiver, and to see if she would then do the project.

After a study of this, she wrote the following excellent analysis of the action.

Dear Sir,

I reread five of my projects to visualize a project of mine being done and to see if I would do it and could easily do it if I received it.

I then also read some LRH written projects to see the difference and compare.

1. I found I would not do a project or would not be interested in doing it if

a. I didn’t understand it well at first reading (unclear).

b. If it was too long and complex and therefore unconfrontable.

c. If the reality of WHY it was needed and what improvements it would bring to my post or area was not clearly expressed in the INFO or SITUATION of the project. In other words if the purpose of the project wasn’t real.

d. If, just in reading the project, I didn’t KNOW what I was supposed to DO with it or while it was underway.

2. Then I would have difficulty doing it

a. If each target didn’t call for an ACTION, a DOINGNESS.

b. If each target called for more than one action (confusing).c.If each target was not specifically directed to or assigned to one person (me) or to somebody else on my orders.

d. If NO ONE in particular was responsible to get the project done.

e. If it went in such detail that it didn’t give me any leeway to operate in the existing scene and achieve the target, and if I was left without any initiative to do it.

f. If each target wasn’t a START-CHANGE-STOP with a definite time sequence, it would be more difficult to put it in.

From this I get some POSITIVE points to look for when writing a project:

1. Clearly assign project responsibility to one terminal or group of terminals.

2. Make the info and the situation REAL to the person by showing what the existing scene is.

3. Show why the project needs to be done and what it will accomplish, and sell it by doing so.

4. Have one ACTION per target and not more than one.

5. Have the time sequence properly indicated and visible in the project and make it a clear start-change-stop cycle.

6. Don’t go into too many details. Better even — refer to a PL where details on HOW to do an action are contained.

7. On the other hand, don’t assume that the receipt-point knows policy at the fingertip. He most probably doesn’t. Don’t skip gradients on the receipt-point.

8. Make it very clear as to who does what target.

9. Keep it short and simple, and each target short and words simple.

10. Watch for outpoints.

There are also the regular policies about targets and their types and how they relate, which are observed.

I’m not saying all my projects were bad and not getting done! FEBC Projects are a bit too long maybe, but do have lots of doingness in them. One project is too detailed. One project, as you indicated, has good info but is unclear as to who does what.

A good one, which had most points above in, got completed well.

Thank you for the hatting action.