Search This Blog

Friday, August 22, 2014


- Using a “Common Core” analogy to explain why our “PRIDE” Methodology is still far ahead.
To use this segment in a Radio broadcast or Podcast, send TIM a request.
It is a strange feeling when you realize you are noticeably ahead of the industry on something. At first it is rewarding, followed by a sense of frustration when you face competition from inferior products, particularly if they are based on pseudo-scientific technology. This leads me to make the boastful claim…
“What we introduced in 1971 as our original “PRIDE” Methodology for System Design, is still light years ahead of the industry.”
It’s not bragging when it is a fact. Our original product back then was based on simple, commonsense principles based on engineering and manufacturing. Since then, we introduced many other concepts and software to support it, such as automated systems design, software used to deduce a system design based on information requirements. I know of no other product or company who was able to emulate our products. This is primarily due to the fact we consider system design as a science as opposed to an art form. By clearly defining our terminology, and proving our concepts, we were able to do such things as automated system design, not to mention priority modeling, organization analysis, impact analysis, and a lot more.
The difference between “PRIDE” and our competitors is analogous to how mathematics is to be implemented under the new “Common Core” curriculum. To illustrate, let’s consider the concept of subtraction:
“Old Fashioned” Way -

However, the proponents of Common Core now recommend a new convoluted approach:
The “New” Way
12 + 3 = 15
15 + 5 = 20
20 + 10 = 30
30 + 2 = 32
20 <-answer p="">

Instead of encouraging simplicity and practicality, the proponents of Common Core want to twist the logic using a more esoteric approach. The same is true in system design. Instead of a standard and simple approach, the industry appears to be content reinventing the wheel. Now we hear about such things as “Agile” or “Extreme”, and “Scrum masters.” Although such concepts were invented specifically for programming, there are those who are trying to apply it to systems.
In 1971, we introduced the following concepts to the world:
1. A system is a product that can be engineered and manufactured like any other product. We applied the concept of a 4-level bill of materials to represent the system hierarchy. From there, the system was designed top-down, and tested and implemented bottom-up, a common engineering/manufacturing technique. This became the rationale for the structure of our methodology which allowed parallel and concurrent development, a radical departure from the classic 5-step “waterfall” approach.
It also provided for the concept of “stepwise refinement,” meaning specifications were defined from the general to the specific in a progressive order, much like what is found in blueprinting.
This concept of thinking of a system as a product is a departure from the mainstream where most developers think of it as nothing more than a collection of programs.
2. Information = Data + Processing. This concept meant there were two basic components to information. If the data was wrong and the processing was correct, the information would be wrong. Conversely, if the data was correct and the processing was wrong, the information would also be wrong. This led to the premise that if the information requirements are incorrect, everything that ensues, in terms of data and processing, will be incorrect. It also led to the idea of sharing and re-using data and system components.
Again, this is still a foreign concept to most people today who do not understand the properties of information and how to use it for design purposes.
3. The only way systems communicate is through data. This implies the need to standardize data for the purpose of eliminating redundancy and promoting information consistency.
Despite the sophisticated data base technology, which has evolved over the years, data redundancy still plagues most companies.
For more on these concepts, see: “Information Systems Theory 101″
These simple concepts led to the embodiment of the “PRIDE” methodology which we introduced in 1971, over 40 years ago. As simple as these concepts were, people resisted them as it was contrary to the thinking of the day, and still is. In particular, programmers had difficulty grasping these simple concepts. In reality, they would be the beneficiaries of the programming specifications resulting from this process. Nonetheless, they would often say, “This is all well and good, but we do not have time to do it right.”Translation: “We have plenty of time to do it wrong.”
Whereas we still think in terms of the “Old Fashioned” way (“PRIDE”), the industry now thinks in terms of the new “Common Core” way. I have no explanation for this other than it must sell a lot of books and seminars. Whereas others offer magic, we offer commonsense.
Yes, “PRIDE” is light years ahead of the industry today, and probably will still be well after my demise.
For more information on the “PRIDE” Methodologies for IRM, see:
Keep the Faith!
Note: All trademarks both marked and unmarked belong to their respective companies.
Tim Bryce is a writer and the Managing Director of M&JB Investment Company (M&JB) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at
For Tim’s columns, see:
Like the article? TELL A FRIEND.
Copyright © 2014 by Tim Bryce. All rights reserved.
NEXT UP:  A JOB DESCRIPTION FOR BUSINESS ANALYSIS – What are the duties and responsibilities of the BA?
LAST TIME:  WHO SHOULD WATCH “AMERICA,” THE MOVIE?  – Certainly not just conservatives.
Listen to Tim on WJTN-AM (News Talk 1240) “The Town Square” with host John Siggins (Mon, Wed, Fri, 12:30-3:00pm Eastern), and KIT-AM 1280 in Yakima, Washington “The Morning News” with hosts Dave Ettl & Lance Tormey (weekdays. 6:00-9:00am Pacific). Or tune-in to Tim’s channel on YouTube.