We will examine here one problem encountered in planning and scheduling projects: communication through abstract artwork. (1)** Graphic schedules (barcharts, logic, networks, flowgraphs) are indeed abstract artwork. It is common knowledge that the kind of artwork which is “pleasing to the eye” has greater appeal than that which offends the viewer. When this artwork is a barchart or logic net, we use terms such as “professionally” prepared, or “simple” and even “crude,” denoting a different visual impact. The same schedule can be presented in a variety of formats and layouts; here we will try to establish which factors seem to increase comprehension and acceptance of this schedule.
Planning and scheduling have many similarities with intelligence operations. These are: gathering intelligence (“data”), testing for accuracy, integrating or finding coherence, encoding the information and sending it. The encoder (scheduler) assumes that the recipient of his coded communication is capable of deciphering his message (schedule). Some schedules contain a key to this effect so that anyone can interpret their contents. Others, however, do not contain a key and presumably every recipient of this latter kind of schedule is initiated in the art of interpreting (decoding) its meaning. The problem here is message-recognition; which is essential for communication to occur.
Elements of graphic communication
Graphic schedules may contain four basic elements: identifiers, code, key and noise.
IDENTIFIERS: this category includes logo or company name, project, client name, date prepared, revision number, page number, distribution, etc.
CODE: this category includes the actual schedule elements: time scale, activities, durations in bars, arrows and/or special symbols.
KEY: this category includes notes and references on how to interpret the bars, arrows and/or special symbols.
NOISE: this category includes any code for which no key is provided, therefore its meaning cannot be found, or if found, may prove to be irrelevant or confusing to the user or recipient of the schedule.
We will now explore the three latter categories in some more detail.
CODE. Most code conventions follow some basic rules such as time progression (left to right), work progression (tasks listed in starting sequence), logic flow (restraints, relationships) and qualitative attributes (criticality). (3)
KEY. References and indications on how to interpret the coding scheme (length, color, organization and sorting of scheduled items) may be part of the schedule form (explicit) or supplied elsewhere in a manual or memo letter (implicit, since it assumes the schedule user has memorized the key).
NOISE. Noise is all coding which either: A) has no key for interpretation, or B) does not convey a useful message to the recipient of the schedule. In this category we find I-J or WI labels, strange coding or abbreviations used by programmers or schedulers, cryptic notes intended as reminders or flags to other project personnel, etc. (4)
Depending on how these four elements combine, we may expect a variety of effects and reactions by the user or recipient of the schedule.
EFFECTS. An attempt is made to identify a few important ones:
- DECODING SPEED. The speed at which the message(s) (schedule) can be interpreted. This is influenced by the following items:
A) density of coding.
B) familiarity with key or coding scheme.
C) presence or absence of noise (5)
Density of coding. Borrowing from Gestalt psychology, we know that each element or activity should be distinctly identifiable but related to the total picture. Each activity, thus, really only should relate to the whole (project, timescale, etc.) as far as decoding is concerned. Relationships, lags, restraints are necessary for scheduling but frequently represent a hindrance in interpreting the schedule. The necessity of relating the part to the whole picture may be satisfied with “summary” or “milestone” schedules, which contain highly condensed, (summarized) abstract messages. There are economic incentives to achieve the highest degree of density without sacrificing decoding speed. (6)
Familiarity with coding key or scheme. It obviously slows down a person to have to frequently consult a key to decode all the special abbreviations, symbols, etc. Changing the meaning of the symbols or abbreviations has an even more drastic effect: it causes the user to either ignore, reject or misinterpret the message. Even after some exposure to the new coding key, the credibility of the message may be impaired. It is common knowledge that familiarity favors both recognition and acceptance. (7)
Noise. Presence of abbreviations, symbols or coding incomprehensible to the user raises questions which may not be satisfied immediately. This definitely affects decoding speed, since the user may get “hung up” on the extraneous coding, or use it as an excuse to reject the schedule or to otherwise negotiate the schedule to his terms. On a different level, noise is obviously an indication of the scheduler’s (or programmer’s) failure to produce a clear and unmistakable message, or a failure in understanding the needs of the user. (8)
- CREDIBILITY. We have mentioned earlier that familiarity paves the road to credibility. A frequently changing scheme usually causes anxiety, and impairs credibility (changes are associated to lack of control and in-decisiveness).
Crediblity in the schedule can be impaired by only one activity in error. This contaminates (“pars-pro-toto”) the error to the entire schedule. In this case, re-examination of the entire schedule may be necessary to reestablish confidence in it. (9)
- ACCEPTANCE. A schedule is more likely to be accepted if as a product, it is easy to “sell.” The concepts that apply to the user or Project Manager also apply to the members of his team. If the Project Manager has a document which he can fully understand, interpret and defend, he will more readily accept it and use it. (10)
There is another aspect to the impact of graphic communication: the emotional one. It is easy to see how a user will react to a “sloppy” schedule (full of erasures, obliterations), and “offending” schedule (names and words misspelled), as opposed to the reactions caused by clean, neat, sharp-looking products, with attention to the seemingly “insignificant” details. I would like to point out here that this type of reaction is different from acceptance which we discussed earlier. We may accept the schedule if the data is basically correct, but we may reject the format because of erasures, etc. (11)
Conclusion
It seems imperative to tailor the product to the user’s specifications. Since it may be impractical to poll every Project Manager as to what a barchart or network should look like, the following comments may be of some help:
FORMS: Whenever possible, standardized and pre-printed forms should be used. The layout should allow for reasonable density of information, easy reference to overall time schedule and to selected milestones. The variety of forms should be kept at a minimum. The same forms should be used on all projects. All forms should repeat all identification or statistical information on the main sheet of the schedule body. Whenever possible, forms should be submitted for criticism by the company’s art or advertising department for improvements. (12)
SYMBOLS. Symbols used for graphing must be standardized, and a key to their meaning also preprinted on each scheduling form. Symbols should be clearly different in shape, but must be of the same approximate size. Otherwise a differentiated connotation or emphasis may inadvertently be expressed. It would be desirable to standardize on symbols and their meanings throughout the industry.
NOISE. Must be eliminated completely. To achieve this, one must look at the finished product (barchart, timescaled network) with a critical eye and test each mark, symbol, abbreviation or number for possible elimination without impairing the encoded message.