Tuesday, December 19, 2006

December 25, 2006


Back in the late 1970's and early 1980's when the Structured Programming movement was in full swing, there was an emphasis on "Structured Walkthrus" whereby a programmer and a team of his peers would review the source code for maintainability and design correctness. Unfortunately, the code was often cluttered and complicated making such reviews cumbersome and led to the phrase "Ruptured Stalkthrus." Today, code reviews are rarely performed, but this leads me to discuss the importance of reviews in general.

Conducting reviews is an essential part of any effective systems development project. Some application developers believe it has an adverse effect on project delivery schedules and, as such, avoids reviews at all costs. This, of course, is absurd. The development of any system or major software project involves many people and, as such, communications and consensus are vital for tackling complex projects.

For additional information, see:
No. 52 - "Understanding the Vicious Circle of Complexity" - Nov 28, 2005

In addition to communications, reviews promote cooperation and trust between the parties involved, but more importantly they are intended to assure developers are building the right product for the right business problem. "Design correctness" is the primary purpose of any review in application development which, of course, is an important part of an overall quality assurance program. Reviews are not intended to criticize the developers but rather to make some important business decisions during a project, such as: accept the design as proposed, modify or correct the design before proceeding, or to cease development.

Periodically stopping and reviewing designs benefits both developers and end-users alike (the clients). For the developer, a second set of eyes is invaluable; to illustrate, being imbued in a development project, problems and errors can become transparent to the developer and are sometimes overlooked. By having others review your work, they may have little trouble in spotting such errors or recommending alternatives. In other words, reviews should not be avoided, but rather welcomed by the developer. For the end-users, reviews are necessary to assure their interests are being represented, that the system and software satisfies their needs. Frequently, end-users abdicate attendance at design reviews because they are often fraught with technical gobbledygook that alienates the user. However, if project reviews are presented in a standard and consistent manner, avoiding technical jargon, users are more apt to attend. Further, having a standard evaluation/acceptance criteria (such as in the form of review checklists) can greatly facilitate the review process for both developers and end-users. Bottom-line, reviews are intended for people to reach consensus as to the proper direction for a development project.


"Free-for-all" reviews are pointless and tends to alienate all involved. Instead, reviews should be structured and well organized thereby maximizing the use of time for all involved. Here are some tips for conducting an effective review meeting:

* Meetings should be conducted by the Project Manager. Participants should include assigned developers, end-users, quality assurance personnel, and perhaps development management (depending on the type of review).

* Schedule the meeting for a time and place convenient to all.

* Have a printed agenda for the meeting describing its purpose, and highlighting the points to be discussed. Start the meeting on time and get to the point, do not ramble.

* Provide the design documents (deliverables) to the participants prior to the meeting. Allow them ample time to study it and formulate questions prior to the review. Ideally, deliverables should be well organized and packaged, complete with a table of contents and a review checklist. Depending on the level of detail involved, technical jargon should be avoided and presented in a form that all will understand.

* If the deliverable is accepted, have all participants sign a master copy of it thereby denoting they have reviewed and approved it. I cannot stress the need for signatures strong enough; they represent commitments.


At the beginning of a project or at the end? Neither. Review meetings should be held throughout the life of the project at specific stages of development. By doing so we accomplish two things: we are inspecting quality into the product during design (not checking for it afterwards), and we are can confirm we are building the right product according to specifications thereby assuring customer satisfaction.

Let me give you an example of incremental reviews using our "PRIDE"-Information Systems Engineering Methodology (ISEM). Please keep in mind "PRIDE"-ISEM considers a system to be a product that can be engineered and manufactured like any other product. Consequently, it has different levels of abstraction in the system hierarchy and, as such, has different deliverables to specify each level (this is sometimes referred to as "stepwise refinement").

The hierarchy of the "PRIDE" System Structure consists of:

Level I: System
Level II: Sub-Systems (aka Business Processes)
Level III: Procedures (both manual and computer)
Level IV: Steps for manual procedures and Programs for computer procedures.

The early phases of "PRIDE"-ISEM are used to design the system top-down and the latter phases are used to test and install the system bottom-up. For each phase in the project, the methodology defines the Deliverables to be produced, be it reports, files or code; Who is to perform the work and in what sequence; Who is to perform the review and how; and How to review the deliverables, including acceptance criteria. During the early phases of "PRIDE"-ISEM, the test plan of the various elements of the system are specified for reference during the latter phases of the methodology.


Of course we have similar review points in our "PRIDE"-Enterprise Engineering Methodology (EEM) and "PRIDE"-Data Base Engineering Methodology (DBEM). However, this essay is primarily concerned with the systems development process.

Because of the complexity of systems, certain tools should be used to assist in the review process. For example, Review Checklists should be devised for evaluating deliverables. Such checklists represent the standard acceptance criteria of each deliverable. Another useful tool is an IRM Repository (aka Dictionary) for cataloging and controlling information resources. Such tools are invaluable for substantiating completeness of designs. Down in the programming phases, certain software testing/debugging aids are useful for diagnosing problems in a program. The use of such tools should be encouraged to promote confidence in the integrity of designs.

As mentioned earlier, systems can be complex in terms of the number of information resources involved and the people participating in the project. Consequently, reviews are essential to assure that the product being produced conforms to its specifications; that problems can be spotted and corrected early on as opposed to afterwards. Reviews at the beginning and end of a project are nice, but incremental reviews are necessary for quality assurance and customer satisfaction purposes. In this way, we can avoid "Ruptured Stalkthrus" and deliver a quality product to the customer.

For additional information, see:

OUR BRYCE'S LAW OF THE WEEK therefore is... "Quality must be built into the product during design, not inspected in afterwards."


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:


I was hesitant to write an article on the evils of Voice Mail; so much has already been written over the last few years. But I decided to give my spin on it after trying to contact a variety of shopping cart vendors to ask them questions about their products. I literally contacted dozens of companies and except for one, all used some sort of Voice Mail. The one exception had a pleasant and personable receptionist who answered the phone and routed me to the right person to talk to. The others put me in Voice Mail jail and rarely did anyone return my calls. I find this all rather ironic; whereas people love to yak on cell phones in heavy traffic, they refuse to answer the phone in their own office. Voice Mail vendors call this productivity; I call it stupidity. It seems the only way to effectively communicate at the corporate level these days is by text messaging or e-mail. And even then, its questionable whether you will ever get a prompt and intelligent response. This has all led to some rather bad work habits and contributed to making our work force socially dysfunctional. Even worse, it frustrates the consumers who cannot get the answers they need.

The other thing that gets me is when you reach an automated Voice Mail answer that says, "You have reached Joe Blow of the ABC company. I can't come to the phone right now, but if you leave a message after the beep I'll be sure to call you back." Come on, don't insult my intelligence; I haven't reached Joe Blow, I've reached some idiot machine; and don't expect me to be happy about it either. Instead, how about a more honest response like, "Sorry, I don't want to take your message right now and even if you leave something on my machine I won't be answering it anytime soon. You'll have better luck contacting me by going outside of your front door and screaming my name at the top of your lungs. Have a nice day."

I believe we have taken Voice Mail too far and have developed an aversion to talking to human beings. In my office we still answer the phone, regardless if it is a legitimate inquiry or some huckster trying to sell us something. As for the latter, you can't imagine the satisfaction I get of slamming a phone down on a caller. I don't need Voice Mail to chase people away for me.

Such is my Pet Peeve of the Week.


Folks, be sure to check out our eBook 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 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 MS PowerPoint presentation describing both the book and the training program.


I received an e-mail from Mike Jones in New York who wrote me regarding last week's essay, "The IRM Infrastructure."

Mike writes:

"Thanks for the tip on the functional descriptions as contained in your "PRIDE" methodologies. They have been handy for helping me develop job descriptions in my shop."

Thanks Mike for your note,

Yes, we have had a lot of people use them to build full job descriptions. A lot of people don't know how to write a good job description anymore and this points them in the right direction. The descriptions include a Scope, lists Specific Duties and Responsibilities, as well as Required Knowledge/Skills/Experience, an Evaluation of Performance, and describes the relationship between other IRM functions.

You can find our "Functional Descriptions" in the "Supplemental Narratives" section of the "PRIDE" Methodologies for IRM at our corporate web site.

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