April 1st represents a significant milestone for M. Bryce & Associates; 30 years in business and 30 years of "PRIDE," our proprietary methodology for designing systems. When we began, Nixon was in the White House, Leonid Brezhnev was Chairman of the old Soviet Union, large mainframes were the norm (PC's were a pipe-dream of some inventor somewhere), keypunch equipment (chads and all) was the predominant means of data entry, Data Base Management Systems (DBMS) were becoming the rage, and Bill Gates and Steve Jobs were still in High School. A lot has changed since 1971, the country has changed, the technology has changed, "PRIDE" has changed. Interestingly, the problems addressed by "PRIDE" have not changed, if anything they have festered and gotten worse.

In a nutshell, "PRIDE" started off as simply a standard and phased approach for building systems. We added software to it over the years to expedite the development process and, consequently, set a lot of industry firsts for our innovations which were often copied with varying results. Regardless, one must understand the reasons for "PRIDE" being introduced, and the times. Back in the late 1960's, companies were interested in building large "MIS" systems (Management Information Systems), womb-to-the-tomb type systems for doing everything from manufacturing to finance, to inventory control, to forecasting, etc. Consequently, companies had large development staffs running around helter-skelter doing more "fire-fighting" (maintenance) than actually conquering the problems of the business. "PRIDE" was, therefore, introduced as a means to bring law and order to the process of building Information systems.

To better understand the nature of the times when "PRIDE" was introduced, consider the following excerpt from the December 1974 issue of Dick Canning's EDP ANALYZER (a reputable research journal of the time):

"The process of designing and building new application systems has not progressed much in the past fifteen years. As is well recognized, the bulk of data processing budgets are people costs; the hardware has long since ceased to be the main cost item, in most organizations. Development cycles for application systems are still too long, and even then, many projects are completed behind schedule. Cost overruns are not uncommon. And when the application systems are installed, revisions are often needed immediately to correct for oversights and errors in the design. Further, maintenance of these systems continues to be a serious, if not a severe, problem.

What accounts for this failure to greatly improve the system building process? For one thing, the application systems themselves have become more complex. Prior experience does not provide all the answers in a shifting environment. Also, increased complexity means that it is easy to overlook important requirements. For another thing, there is no theoretical foundation for application systems, in the sense that the laws of physics are the foundation of engineering. There is nothing to guide us toward the design for an application system. The process is really one of trial and error, and hence the system building process can have false starts in it."

(EDP Analyzer, December 1974, (Vol 12., No. 12)

Sounds familiar doesn't it? Today's trade press is full of such stories of project cost overruns and slipped schedules, design snafus, data redundancies, systems lacking integration, quality problems, documentation woes, poor user involvement, etc. Frankly, these types of problems are no different today than they were 30 years ago. But why do such problems persist? I primarily attribute it to:

1. Misplaced focus on software and technology as opposed to total systems. The concept of major systems has fallen by the wayside, because...
   a. Other than "PRIDE," there is no industry standard for systems theory. Hell, we can't even agree about our terminology in this field. All of the systems practitioners and institutions of the past (e.g, Association for Systems Management, Infosystems magazine) have either retired or moved on, taking their wisdom with them.

   b. Because companies typically reward their employees for short-term as opposed to long-term goals, it is much easier to produce a simple program than engineering major system. We have been lulled into accepting "quick and dirty" solutions to the most irritating problem of the moment. This is analogous to applying band-aids when major surgery is required. Long-term thinking about our systems is a foreign concept to most corporations.

   c. Our colleges and universities have let us down miserably in teaching and producing qualified systems personnel. Instead of total systems theory, the emphasis has only been on software. Further, the turf wars between business schools and computer science schools continues to rage over management and development principles, with no consensus between the two camps.

   d. The current "Nintendo generation" tends to have an obsession with technology. Our preoccupation with technology causes companies to suffer from a bad case of tunnel vision, whereby the only legitimate problems worth addressing are those that can be solved by the computer. Instead of looking for a solution to a business problem, we tend to look for a business problem to satisfy a certain solution. In other words, the tail tends to wag the dog, not the other way around.

2. Management abdicating control over the development process. This is actually not new. For a long time, companies have been at a loss as to how to reign in their IT departments. Frustrated, or simply confounded by the technical gobbledegook, they have washed their hands of trying to control development efforts and keep their fingers crossed that something useful will be produced.

   Quite often, the wrong person is selected to run the IT department: someone more in tune with technology than of managing the affairs of others or of understanding the needs of the business. Technicians are not necessarily equipped to be managers, and managers are not necessarily equipped to be technicians; both require distinctly different skill sets. Naively, corporate management appoints someone who speaks the language of the technicians in the hope that corporate objectives will be properly translated into system solutions. I say, put in a manager who knows how to get things done and hire yourself a translator to assist the manager. Some of the best IT managers I've seen over the years didn't have a technical background and came from end-user departments. Believe me, there is no magic required to be an IT manager. You just need simple discipline, organization, and accountability.

   But the root of the problem in this area is the misconception that systems development is an art form as opposed to a science. I contend it is otherwise. An art form requires special creative people with particular skills and knowledge. It is extremely difficult to teach someone how to make brush strokes like Leonardo da Vinci or sculpt like Michelangelo. Regardless, IT people like to cultivate the image of themselves as free-spirited artists who cannot be bridled with discipline or deadlines. Hogwash! As we have demonstrated with "PRIDE" over the past three decades, systems development is a science based on certain governing principles that can be taught and applied on a consistent level.

Except for Japan (where we are celebrating our 25th year of business), the use of "PRIDE" has unfortunately diminished over the last ten years. Why? It is not technically elegant for starters; its just good old fashioned management principles based on engineering/manufacturing concepts.

Second, companies balk at the up-front work required by "PRIDE" to properly define business information requirements and design integrated systems before engaging in programming. The mindset still persists that "We are not being productive unless we are programming." After all, software is more visible than systems analysis and design; whereas it is easy to demonstrate a prototype of a screen or a report, analysis and design is much less tangible other than some requirements documents and flowcharts that nobody wants to read.

Our answer to this is represented by the following equations:

Good Systems Analysis/Design + Good Programming = Great Systems
Good Systems Analysis/Design + Bad Programming = Good Systems
Bad Systems Analysis/Design + Good Programming = Bad Systems
Bad Systems Analysis/Design + Bad Programming = Chaos

The common denominator for success is the up-front work of Systems Analysis and Design. Some would argue that the second equation "Good Systems Analysis/Design + Bad Programming = Good Systems" would not result in a good system. True, we might not have the most technically elegant program, but we would still have something that correctly satisfies the business need.

If 85% of your systems development time is being spent in programming, than you are doing systems analysis at the wrong time. Just remember, an elegant solution to the wrong problem solves nothing.

Today we have a PC on every desk with some rather remarkable visual programming aids, powerful data base tools, and collaborative software. However, I would say, "No Virginia, there is no panacea." We may know how to write software rather well, but we still do not have a clue how to specify requirements and design total systems.

In 1977, the EDP ANALYZER (July 1977, Vol. 15, No. 7) published a study on the relative percent of errors in project requirements:

34% - Incorrect requirements
24% - Missing/incomplete/inadequate
22% - Unclear/ambiguous
  9% - Inconsistent/incompatible
  3% - New/change
  4% - Outside scope of project
  4% - Typographical errors

Again, I doubt that today's development projects are any different. If our requirements are wrong, than everything that ensues is wrong, be it in-house developed code or a packaged solution. So is the up-front work necessary? Absolutely. Yet, this is what most companies tend to overlook with the excuse, "We don't have enough time to do it right." (Translation: "We have plenty of time to do it wrong." )

As we have always contended with "PRIDE," the problems in the computer field are not technical in nature, but management instead. Unfortunately, management is not in vogue these days, consequently, neither is "PRIDE." In the hands of a real manager, you can do wonders with "PRIDE," but if you work in a political environment with a lot of finger pointing, back-biting, and suffer from a bean-counter short-term "quick and dirty" mentality, than "PRIDE" can do nothing for you.

To those of you who have used "PRIDE" over the years, we greatly thank you for your business. "PRIDE" is still alive in various forms all over the world. Some of our earliest customers still teach the concepts and framework of "PRIDE" to new employees (if you have one of the old original "gray manuals" or the framed "PRIDE" System Concept Diagram or a "PRIDE" flowcharting template, you have some really good collector's items). Others still use our mainframe based software, particularly the Japanese. "PRIDE" has allowed them to develop major integrated systems, control changes (it was particularly well used to control "Y2K" problems), and reduce developments costs. All because we asked people to, Shapeth up and geteth thine act together!

If you would like to know about the principles and practices of "PRIDE," you can still buy our book, "The IRM Revolution: Blueprint for the 21st Century." We still lecture and consult on "PRIDE" related matters. Please do not hesitate to contact us if you would like us to visit or speak. We still don't do it for free; we're still not a charitable institution.

Bottom-line, we are pleased to report that "PRIDE" has stood the test of time; 30 years is a damn good testimonial to the product. We have seen several sets of competitors come and go, but like an Errol Flynn swashbuckling movie where he sailed his warships through the smoke and fire of battle, "PRIDE" keeps sailing through the mist.

Happy anniversary "PRIDE" and congratulations to those of you who had the wisdom to follow us over the years.

Keep the Faith!