Thursday, October 26, 2006

October 30, 2006


A few years back, I was at a Comdex show exhibiting our "PRIDE" Methodologies for IRM and gave a brief overview to an inquisitive attendee. He listened to me patiently, but at the end asked me pointedly what language "PRIDE" was written in. He looked at me dumbfounded when I told him it was written in English. I guess he thought "English" was some new programming language. I could have gone on with the charade and said that it was, but honesty got the better of me and I explained to him our corporate slogan, "Software for the finest computer - the Mind."

The language of systems is no different; No, it is not C++, Java, COBOL, etc., but rather simple English (or whatever your native language happens to be). In the past I have described the differences between Systems and Software, the two are simply not synonymous. Whereas systems include business processes implemented by human beings, computers and other office equipment, software is simply instructions for the computer to follow. Systems are for people who must also take an active role in its execution. In fact, systems will fail more for the lack of people procedures than they will for well-written computer software. There are more people procedures in a system than you can probably imagine. Overlooking their role in a system is a serious error. Let me give you an example...

We had a large manufacturing customer who designed a new "state-of-the-art" shop-floor control system whereby they wanted to spot errors along the assembly line and then quickly react and correct the hiccup. From a software perspective, it was a well thought-out and elegant solution coupled with an integrated data base. There was just one problem; it didn't work. Consequently, we were called in on a consulting basis to try and determine what was wrong with it. We carefully examined the architecture of the system overall, not just the software, and quickly found the problem; Whenever an error occurred on the shop-floor, an error message was displayed on a computer screen for the shop-floor supervisor to act on. Unfortunately, nobody told the supervisor about the computer screen, the messages, or procedurally how to respond to it. We wrote a simple administrative procedure for the supervisor who then read and responded to the errors properly and the system then ran perfectly.

As my example demonstrates, clearly written administrative procedures immeasurably improve the processes of system implementation and operation. Often, preparation of these procedures has been eliminated in order to expedite system start-up. Experience has shown this approach can cause considerable expense, frustration and problems.


Even when administrative procedures are considered, they are often sloppily written in an inconsistent manner. Unlike the computer who will do anything you instruct it, right or wrong, writing for the human being is actually more difficult. People are more emotional and can be lazy and uncooperative at times. Writing for people, therefore, can be an arduous task. Instituting writing standards can materially help in bringing about consistency to this task and should be encouraged.

Whenever writing administrative procedures, they should answer these basic questions for the end-user:

* What is the purpose of the procedure?

* Who should perform the procedure? When?

* How should the procedure be accomplished?

* What is needed to accomplish the procedure?

* What are some examples?

* What should be done after the processing is accomplished?

As any writer will tell you, you must write in terms your audience will understand. As such, you should consider the intelligence level of your audience. For example, most newspapers in the United States write for people at the 6th grade level. You may possess a sophisticated vocabulary, but does your audience? When it comes to writing administrative procedures, write so your audience can understand the instructions and implement accordingly.


One of the most effective techniques for the preparation of procedures, is the "Playscript" technique as developed by Leslie H. Matthies, the legendary "Dean of Systems." There are basically three parts to a Playscript procedure:

1. PURPOSE SECTION - Containing the Business Purpose of the procedure.

2. SETUP SECTION - Listing all of the inputs, outputs, and files that will be used during the execution of the procedure.

3. OPERATION SECTION - Enumerating the instructions required to perform the procedure. Each operation is described using action verbs and nouns.

For some examples of Playscript, see our "PRIDE" web site.


Help text is normally associated with interactive processing at the computer screen where the user requires instructions from the computer to guide them through processing. This is needed to answer both common and technical questions regarding processing. Development of help text is almost a prerequisite for all PC processing.

There is basically three areas requiring HELP text:

  1. For Window/Screen Processing - providing tutorial describing the purpose of the screen, who it serves, and the basic processing action of the screen. In the industry, this is often referred to as "general help" or "extended help." System, sub-system and procedure narratives are useful for this purpose, as well as "Playscript" instructions.

  2. The user will also require help in making field entries. This includes acceptable values, what the values mean, and the physical characteristics of the entries (e.g., length).

  3. Special function keys - like field entries, HELP text should be provided to explain special keys (function keys or combination keys (e.g., CTRL + C)).

Help indices are also very useful for reference purposes, such as by subject, by field entry, by keys, etc. Fortunately, standards are emerging in the industry for writing help text which can be implemented using such things as MS Windows HLP files and Web files.

There is absolutely no incompatibility between "Help" text and "Playscript." In fact, "Help" text makes a convenient vehicle for accessing "Playscript" instructions.


If you are following a top-down design approach, such as the "PRIDE"-Information Systems Engineering Methodology (ISEM), administrative procedures can be written upon the completion of sub-system design (where business processes are defined). This also means the administrative procedures can be developed in parallel with software design. Some people have difficulty imagining this. I don't. I'm a firm believer of having your systems documentation completed before system startup. This greatly assists in educating the end-user and helps overcome problems during startup. Whether you believe in pre-documentation or post-documentation, it has to be completed nevertheless.


In summary, administrative procedures should receive the same attention as procedures written for computers. Without these procedures, which represent the critical human interface to systems, a well designed and programmed system may be useless.

In reality, there is little difference between an administrative procedure and a computer procedure. The only difference is the "actor" assigned to perform the task. To appreciate this, one should understand how Les Matthies came about devising his "Playscript" technique. Les graduated from the University of California at Berkeley in the early 1930's with a journalism degree. This was during the midst of the Depression where work was hard to find. For a while, Les tried his hand at writing Broadway plays and became intimate with writing scripts (where actors enter, speak their lines, and exit). When World War II broke out, Les was too old for military service and, instead, was recruited by an aircraft manufacturer in the U.S. mid-west where he was charged with establishing procedures for the production of aircraft thereby expediting the development and delivery of planes to the war front. Using his writing skills, he devised "Playscript" with actors and actions which proved effective to procedurally produce aircraft.

Let's fast-forward to the 1950's and the advent of the UNIVAC I. Computer programming languages had moved from machine language to assembly languages, both of which were difficult to program in. Enter Grace Hopper who was looking for an easier and more intuitive approach for programming. As such, she invented an English language compiler called "Business Compiler Zero" (B0) which ultimately became the COBOL programming language. To do so, she modeled the language after a procedure language she was familiar with, "Playscript." Think about it. Playscript defined the environment, the files to be used and its use of verbs and nouns are easy to assimilate. What this ultimately means is that "Playscript" is the mother of all third generation procedural languages and that our premise, that there is little difference between an administrative procedure and a computer procedure, is true.

In the end, it all comes down to verbs and nouns - the Language of Systems.

OUR BRYCE'S LAW OF THE WEEK therefore is...
"Systems will fail more for the lack of administrative procedures than well written computer procedures."


Friends, the "PRIDE" Methodologies for Information Resource Management (IRM) is a common sense solution for Enterprise Engineering, Systems Engineering, Data Base Engineering, and Project Management. The methodologies include defined work breakdown structures, deliverables, and review points that promote quality and the production of industrial-strength information systems. Building information resources is a science, not an art form. Our methodologies clearly explain the concepts that govern them, which remarkably, is derived from engineering/manufacturing practices. Now you can get these acclaimed methodologies for free at our corporate web site at:


The International Institute of Business Analysis will be holding their World Congress for Business Analysts (in conjunction with ProjectWorld 2006) on November 6th-9th at the Caribe Royale Hotel in Orlando, FL. For information, call 212/661-3500 x 3702 or visit their web site at:

The Association of Management Consulting Firms will be holding their 60th Annual Meeting on December 6th-8th at the Harvard Club in New York City. For information, contact AMCF headquarters in New York at 212/551-7887 or visit their web page at:

If you have got an upcoming IRM related event you want mentioned, please e-mail the date, time and location of the event to


We've just introduced a new free service for managers to perform a self-analysis of their style of management, including leadership and corporate culture. Check it out at:


Also be sure to check out our new "MBA Daily Productivity Analyzer" which is a free calculator to evaluate a person's personal productivity during the day. It is also available at our corporate web site.


As many of you know, I like to analyze words and names, such as how they are derived and what they are based on. For example, I was recently up in Cincinnati and saw an election campaign sign for an Appeals Court Judge named Dinkelacker. That's right, Dinkelacker. I don't want to go into too much detail now, but suffice it to say I found the name amusing and wondered how it originated. I wonder if someone has problems getting a date with a name like Dinkelacker.

Nonetheless, my pet peeve this week is the word "Dude." Recently, I received an e-mail from a well meaning young man who wrote me regarding one of my editorials. Interestingly, he began his letter by saying, "Dude - I've been meaning to ask you about your comments about this or that." "Dude?" First, I haven't used the word "Dude" since I was in 8th grade. Second, I have written and read literally thousands of business letters over the years, and practically all of them have begun with "Dear Sir" or something like "Dear Mr. Bryce" or perhaps "Dear Tim." But "Dude"? This was a first for me and I was taken aback. I believe the writer had the best intentions but he immediately lost all credibility with me. Frankly, I got the impression I was dealing with a teenager and not a credible professional business person. As a result, I dismissed his note out of hand. What worries me is that this may very well become a trend and, if so, says a lot about the deterioration of our corporate cultures. I understand the need for brevity in our correspondence, but I also recognize the need for business etiquette which shows respect and reflects our character. It is one thing to be clever in our correspondence, quite another to reflect a slovenly character. As an aside, the word "Dude" refers to an inexperienced or naive person, and I don't think the young man who wrote me intended it this way.

Such is my Pet Peeve of the Week.


Folks, we've just released a new book on management entitled, "The Bryce is Right! Empowering Managers in today's Corporate Culture." This is a frank and candid description of the state of the art in management and includes essays on the problems in management today, along with some pragmatic advice on how to deal with them. Basically, this is a condensed course in management. As such, it is suited for managers, either those aspiring to become a manager or for those who need a refresher course. It will also be of interest to young people entering the work force, and is excellent for college curriculums.

Charles Cole of Lyndhurst, OH, said it is a "Very interesting book. Good work! It reminds me of some of the early works I read by W. Edwards Deming. Too bad the American corporate gurus of his day didn't pay him heed."

And Wolf Hager of Fort Myers, FL, says it is "A very impressive publication which requires careful reading and reminds me somewhat of Peter Drucker."

The price is just $20 plus tax. For more information on our book or to order on-line, see:

We have also just produced a new one-day training program of the same name. For more information on both the eBook and course, please visit our web site at:

While there, look for our new MS PowerPoint presentation describing both the book and the training program.


I received an e-mail from a Jon Harris in New York who wrote me regarding last week's essay entitled, "Managing Consultants."

Jon writes:

"I have run into a situation where I have a consultant who I want to use on a special project using a new technology we're inventing. This is all highly proprietary and he will become an important part of its development. The problem is he refuses to sign a non-disclosure agreement. What should we do?"

Thanks Jon for your note,

Unless you are allowing him to own a part of this technology, thereby making him a partner, he should be required to sign a non-disclosure. Otherwise you are opening Pandora's Box and providing him with an opportunity to walk away with your technology. Over the years I have seen consulting firms balk at signing non-disclosure agreements. They shouldn't. Its your product and your knowhow. If they are let off the hook, God only knows where your technology will end up and who will profit by it, probably your competitors. If he adamantly refuses to sign the non-disclosure, show him the door.

Again, Thanks for your e-mail. Keep those cards and letters coming.

MBA is an international management consulting firm specializing in Information Resource Management. We offer training, consulting, and writing services in the areas of Enterprise Engineering, Systems Engineering, Data Base Engineering, Project Management, Methodologies and Repositories. For information, call us at 727/786-4567. For a complete listing of my essays, see the "PRIDE" Special Subject Bulletins section of our corporate web site.

Our corporate web page is at:

Management Visions is a presentation of M. Bryce & Associates, a division of M&JB Investment Company of Palm Harbor, Florida, USA. The program is produced on a weekly basis and updated on Sundays. It is available in versions for RealPlayer, Microsoft Media Player, and MP3 suitable for Podcasting. See our web site for details. You'll find our broadcast listed in several Podcast and Internet Search engines, as well as Apples' iTunes.

If you have any questions or would like to be placed on our e-mailing list to receive notification of future broadcasts, please e-mail it to

For a copy of past broadcasts, please contact me directly.

We accept MP3 files with your voice for possible inclusion in the broadcast.

There is no charge for adding a link to "Management Visions" on your web page, for details and HTML code, see the "Management Visions" web site.

Management Visions accepts advertising. For rates, please contact yours truly directly.

Copyright © 2006 by M&JB Investment Company of Palm Harbor, Florida, USA. All rights reserved. "PRIDE" is the registered trademark of M&JB Investment Company.

This is Tim Bryce reporting.

Since 1971: "Software for the finest computer - the Mind."



Post a Comment

Subscribe to Post Comments [Atom]

<< Home