THE BRYCE IS RIGHT!

Software for the finest computer – The Mind

  • Tim’s YouTube Channel

  • Enter your email address to follow this blog and receive notifications of new posts by email.

    Join 965 other followers

  • Categories

  • Fan Page

  • Since 1971:
    "Software for the finest computer - The Mind"

    Follow me on Twitter: @timbryce

  • Subscribe

Archive for the ‘Systems’ Category

THE TEN COMMON MYTHS OF INFORMATION TECHNOLOGY

Posted by Tim Bryce on July 31, 2018

BRYCE ON TECHNOLOGY

– Have you heard any of these?

Click for AUDIO VERSION.
To use this segment in a Radio broadcast or Podcast, send TIM a request.

Whether you are in the Information Technology field or not, you have likely heard these excuses before. They particularly arise whenever quality work is required or when organization and management control is imposed. Of course, I’m talking about the ten common myths of I.T. Ten common rationalizations people in the Information Technology world turn to whenever their authority or professionalism is challenged. They are neither new or limited to a specific geographical location. They have been around as long as the modern computer and they transcend all cultural and industrial boundaries. What’s worse, they have proven to be effective.

The following is the ten most popular myths in the field. Obviously, it is not all inclusive. It is simply the ten most commonly used. Let’s look past the facade of each of these for a moment and see what they really mean.

#1 – “OUR PROBLEMS ARE UNIQUE”

This is perhaps the most popular of the myths and is probably used to pacify the ego of I.T. Management. I discovered it several years ago when I happened to do some consulting for three separate companies from the United States, Japan and Brazil. In all three instances, the I.T. Managers insisted their problems were unique to their company. They pointed at the overwhelming pressure they operated under, uncooperative users, insensitive management, and some cultural constraints. The parallelism was incredible. Here were three separate companies, geographically separated by thousands of miles, all of which describing the same problems, yet viewing themselves as unique.

In studying this further, I discovered most companies share the same problems, such as:

– A substantial backlog of user requests (three to five years seems to be the norm).

– Poor communications internally within the I.T. staff and externally with end-users.

– Project cost overruns and slipped schedules.

– Employee dependencies to maintain and support systems.

– Hardware/Software dependencies; systems are tied too closely to a particular vendor, making upgrading difficult.

– Redundant data throughout an organization (we know of one state government who conservatively estimated NET-PAY is calculated at least 100 different ways).

– Lack of adequate documentation (thus providing job security for the staff).

– High staff turnover.

– Design inconsistencies.

– Systems personnel clash with data base personnel.

– Information Systems do not meet users needs.

And so on, and so forth. Bottom-line, I.T. organizations suffer from low productivity and poor performance.

Inevitably they end up in a “fire-fighting” mode of operation constantly patching problems. However, the problem here is the chief fire-fighters are also the principal arsonists. It is unfortunate the “fire-fighters” enjoy higher visibility than those who work quietly in a methodical manner. This is a situation where the guilty are promoted and the innocent are prosecuted.

Instead of imposing management discipline and control, I.T. managers resign themselves to a life of chaos. It is no small wonder their average tenure in office is less than three years.

#2 – “WE NEVER SEEM TO HAVE ENOUGH TIME TO DO THINGS RIGHT”

This implies “we have plenty of time to do things wrong.” There is an interesting relationship between the quality of a product and the speed by which it is developed. This phenomenon is true of any product being built.

The faster the delivery of a product, the greater the chances are for inferior quality. The slower the delivery, the greater the chances are for superior quality. Neither extreme is acceptable; an even balance must be maintained to assure one doesn’t have an adverse effect on the other.

Instead of developing a long range plan that incorporates an information strategy, management nurtures the problem by saying they need everything “yesterday.” Software vendors prey on companies like this by offering miracle products promising to accelerate development while producing quality results. Without the appropriate management environment, they deliver neither and compound problems further. These tools concentrate on efficiency, not effectiveness. Before you can streamline your operation, you must first know what you are doing.

#3 – “YOU ARE STIFLING OUR CREATIVITY”

This scapegoat is a favorite among the “techy set.” It is a defensive expression that springs up whenever discipline or change is mentioned. What is ironic is these same people do not hesitate to reorganize a user’s department. The hypocrisy is incredible. Systems people, who are supposed to be the agents of change in an organization, are the most resistant to it.

#4 – “SYSTEM DESIGN IS AN ART FORM”

Closely related to the “stifling” myth is the view of system design as an exotic art form. Most systems developers like to be viewed as free-spirited souls who do not like to be encumbered with organization, discipline and accountability. The fact is, many of these so-called “Rembrandts” are nothing more lousy house painters. They hide behind the mystique of their technology in the hopes it will conceal their poor performance.

Systems design is a proven and teachable science. This is not to suggest science lacks creativity. For example, there is considerable creativity in the sciences of architecture, engineering, music, etc. Science simply establishes the governing principals and rules to be observed in your work.

#5 – “TECHNOLOGY WILL SOLVE OUR PROBLEMS”

This is more of a train of thought as opposed to an actual expression. It is based on the belief that hardware and software will correct all of the ills of a company. The belief that technology, not management, will solve problems is just as prevalent today as it was when the computer was first introduced.

It is fascinating to watch companies throw millions of dollars at solving a problem through technology, yet balk at spending money for management, a sort of “penny-wise and pound foolish” mentality. Corporate management genuinely believes that I.T, management controls and tools can be developed inexpensively, if not free.

To some companies, technology is purchased more as the latest status symbol, as opposed to its practicality. It is purchased more to “keep up with the Jones'” than anything else. What they don’t realize is the Jones’ are in as much trouble as they are.

#6 – “A DBMS IS A PREREQUISITE FOR DATA BASE”

I remember meeting an I.T. Director from a large regional bank from the U.S. southwest who insisted his company didn’t have a data base. What he meant to say was he didn’t have a Data Base Management System. With the propagation of DBMS packages in the field, most companies now sincerely believe a DBMS is a prerequisite for data base. Although DBMS software offers tremendous leverage for file management, it is far from being a mandate for data base.

All companies have a data base, some are managed, most are not. A data base is nothing more than a collection of all of the data required to produce information. Obviously, this definition transcends the computer. It is a recognition that data is a resource which must be managed like any other resource; e.g., money, people, materials, etc.

A DBMS offers great capability when managing data stored on mass storage devices. But it must be realized that data is used throughout an entire organization, in manual and computer applications, in a variety of files (manual, tape, microfiche, disk, etc.). Data Base Administration activities typically cover only the data used by a DBMS. What is necessary is a higher level position that manages all of the data, regardless of where used or how stored. The Data Management function should behave in a manner similar to Materials Management, Financial Management, and Human Resource Management. This is the Achilles’ Heal for most I.T. organizations, the failure to recognize data as a valuable and re-usable resource.

To compound problems further, even when DBMS technology is introduced to a company, it is rarely used effectively. Instead of utilizing a DBMS to share data among applications, most apply it as an access method only.

I conservatively estimate that less than 5% of all I.T. organizations in the world have successfully implemented a managed data base environment, DBMS or not.

#7 – “THERE IS AN INFINITE AMOUNT OF DATA IN AN ORGANIZATION”

Some people would have you believe there is an inordinate number of unique data elements used in an organization and to catalog and control them is a mammoth undertaking (therefore, they believe they shouldn’t waste their time). Instead of documenting a data element and re-using this intelligence, people typically redefine data with each application. This leads to inconsistent definitions and redundant work effort. But worst of all, it makes implementing a change to a data element extremely complicated.

In reality, there is a finite number of data elements in any given organization, probably in the neighborhood of 3,000 to 5,000. And although it is no small effort to document the data, it is a wise investment in the future. Once it is defined, a data element can be re-used in multiple applications, which leads to a shared data base environment. Capturing this intelligence must evolve over time with each application, it cannot be captured over night.

#8 – “OUR COMPANY RUNS ON DATA”

This is one of the most naive statements in the business, one rooted in ignorance. The person using this expression obviously doesn’t grasp the inherent differences between data and information. They are not synonymous. The differences are simply too numerous to list here but essentially Data by itself is meaningless; it is the representation of a fact or an event. It is the raw material by which information is produced. Contrary to this, Information is the intelligence or insight gained from processing data to support specific business functions.

A company runs on information, not data. In fact, information is the most important asset a company has. All actions and decisions are predicated on information. Organizations progress when the impact of good actions and decisions outweighs the impact of bad actions and decisions. Information gives us the means to make these actions and decisions.

Those who do not understand the differences between information and data are probably the same people who do not understand the differences between an information system and computer software.

#9 – “USERS OWN THE DATA”

This is a typical attitude found in companies who do not understand the concept of managing data as a resource. In this situation, data is jealously guarded by each user. As a consequence, redundant files and applications are the norm. The sooner you get past this stage, the better off your organization will be.

Does the Controller “own” the money? Does the Human Resources Manager “own” the employees? Does the Materials Manager “own” the parts? Of course not; they simply administer the resource. A comparable position to manage data resources must also be created.

#10 – “USERS DON’T KNOW WHAT THEY WANT”

Translation: “I don’t know what I’m doing so I’ll just keep hacking away at the problem.” This type of comment is a sign the person is not properly trained in Systems Analysis. Users didn’t get their job by default; they must know a little bit about their end of the business, otherwise they are not going to have it for long. The problem typically stems from the analyst’s inability to define business problems, specify information requirements and to effectively communicate with the user. Instead of asking how the user wants to view their screen, try to understand their problem first. An elegant solution to the wrong problem solves nothing. Only when the Systems Analyst can walk in the moccasins of the user, does the analyst have the right to build a system for the user.

IN CONCLUSION…

You would think after forty years of promoting these myths, we could invent some new ones that are a little more imaginative. The fact they have survived this long is indicative that management is not facing up to their problems and are still baffled by technical gobbledygook.

“Beware of your fire-fighters, they may be your chief arsonists.” – Bryce’s Law

First published: June 02, 2006

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 40 years of experience in the management consulting field. He can be reached at timb001@phmainstreet.com

For Tim’s columns, see:   timbryce.com

Like the article? TELL A FRIEND.

Copyright © 2018 by Tim Bryce. All rights reserved.

Listen to Tim on WZIG-FM (104.1) in Palm Harbor,FL; Or tune-in to Tim’s channel on YouTube. Click for TIM’S LIBRARY OF AUDIO CLIPS.

 

Advertisements

Posted in Software, Systems, Technology | Tagged: , , , , , | Leave a Comment »

INFORMATION DRIVEN DESIGN

Posted by Tim Bryce on April 18, 2016

BRYCE ON SYSTEMS

– a return to basics in system design.

(Click for AUDIO VERSION)
To use this segment in a Radio broadcast or Podcast, send TIM a request.

PREFACE: A few months ago I made a promise to some of my techie friends I would describe the concept of “Information Driven Design” as used in our “PRIDE” Methodology for system design. This concept originated in the original version of our product in 1971 and was successfully used by our customers to build enterprise-wide systems. The reason I bring this up is that it appears to me people still have trouble defining information requirements and, as such, they are at a loss as to how to build total systems. Thereby, they are content building either a single business process or a program. Therefore, here is the conceptual foundation for all system design…

Information Driven Design begins with a simple concept:

INFORMATION = DATA + PROCESSING

Information is the intelligence gained from the processing and/or analysis of data. This means information is a product based on two variables, data and processing. We do not store information, we produce it based on these variables. Whereas data represents “what” is to be processed, processing (or systems) represents “how” it is to be processed, using formulas, algorithms or calculations. An invalid calculation is just as misleading as invalid data; both will produce erroneous information. From this perspective, both data and processing must be carefully designed and controlled as resources for producing information, and as resources, they can be shared and reused to produce information for other uses. In this way they should be identified and controlled like any other resource, hence the need for “Information Resource Management,” a concept very much akin to “Materials Resource Planning” as found in manufacturing.

Since the intent of an information system is to produce information, the more we understand about information requirements, the better we can accommodate its implementation. This is why we refer to this concept as “Information Driven Design,” a system design derived from the inherent properties of information.

INFORMATION DRIVEN DESIGN CONCEPT

Information requirements should be defined in such a way as to explain the Business Functions they serve, their Business Purpose, the Actions and/or Business Decisions they support, and the benefits derived from the use of the information. In this way, it a textual justification for the information. Now let’s take it further…

There are three types of information:

Policy Information – To implement executive decisions.

Control Information – To monitor policy and manage operations.

Operational Information – To implement the routine day-to-day activities of the business.

Information is a dynamic and perishable commodity. It only has value at the time it is required. Whereas the definition of data is constant, information requirements can change for a variety of reasons, such as politics, government, competition, economics, people, etc. Ultimately, corporate survival depends on providing users with accurate and timely information.

TIMING

In order to properly specify information requirements, it is not sufficient to merely determine what data is required to support it; it is also necessary to define the timing of the information (to support the actions and/or decisions). This timing will ultimately dictate how data will be collected, stored, and retrieved to produce information.

Failure to recognize timing as an important element of design will result in the data base being out of synchronization with the system. For example, consider a situation where data is collected on a routine weekly basis (just once a week). Daily analysis of the data will be inappropriate since the data will remain constant until the next weekly update. To resolve the conflict, data collection should be changed to at least a daily basis.

All information systems operate in time frames, such as instantaneous, daily, weekly, monthly, quarterly, annually, etc. If this is true, why not make use of this timing consideration during system design as opposed to discovering it afterwards while trying to correct the data base design?

There are three aspects to timing: frequency, offset and response time.

FREQUENCY defines “how often” the information is required, e.g., upon request, hourly, four times daily, once a week, twice monthly, quarterly, semi-annually, etc.

OFFSET defines when processing should begin, such as the beginning of the week, end of the month, etc. However, if the frequency is ‘upon request,’ then there is no scheduled offset; this is because the information can be requested at any point in time.

RESPONSE TIME defines how fast the information must be delivered to the user. For example, five seconds, two hours, one day, etc. This should not be confused with computer ‘response time’ or ‘throughput’ which is concerned with machine speed. Rather, response time is concerned with the maximum amount of time that will transpire between the request and delivery of the information, so the user can make the necessary decisions and/or take action. This implies that if the response time is exceeded, it is no longer information, only historical data.

Timing ultimately defines data availability and accessibility issues. Availability specifies, “Is the data there when I need it?” (a function of Input/Data Collection). And Accessibility specifies, “Can I get to the data when I need it?” (a function of Output/Information Retrieval). Understand this, you cannot access data (retrieve information) if it has not been made available (collected) in a timely manner.

DATA

Data comes in two forms, Primary and Generated. Primary data is what is collected and inputted into the system. Generated data represents calculations derived from primary values. To illustrate, suppose we need the generated data element, “Net Pay,” as used in payroll. It would be necessary to define all of the other data dependencies, e.g.;

NET PAY = GROSS PAY – FICA – CITY TAX – UNION DUES – (ETC.)

Other data elements used in the formula may also be generated, such as:

GROSS PAY = HOURS WORKED X PAY RATE

What this means is that in order to arrive at the correct value for “Net Pay,” we must be able to reach all of the primary values, such as “Hours Worked” and “Pay Rate,” in a timely manner. If we cannot do this, “Net Pay” will be incorrect.

Defining these data dependencies has typically defaulted to the programmer who redefines the relationships with each application and buries it in the program source code, making maintenance and change considerably difficult. Consequently, It is not unusual to find “Net Pay” defined differently in multiple applications throughout a company.

The timing nuances of the Information Requirements ultimately dictate the various sub-systems of the system (the business processes). Some will be used to exclusively input data (aka “maintenance”), some to produce information (aka “queries”), and some for both maintenance and query purposes.

The basic operations that can be performed on data include “create,” “update” and “reference” (“delete” is the opposite of “create”). In programming terminology, a “create” represents a “write,” an “update” represents a “read/write,” and a “reference” represents a “read” only.

The timing and data specifications resulting from the information requirements will ultimately dictate the type of sub-systems to be created. For example, if information is needed upon request and within a matter of seconds, this will probably result in an “interactive” type of process. However, if the information is required upon request but within a few hours, this will probably result in “batch” type processing (it may even be processable manually). These specifications are the basic building blocks for all systems and software design.

Producing an information system design that correctly satisfies requirements is a vital part of Information Driven Design. If the information requirements are correct, the resulting system design will be correct. However, if the information requirements are wrong or incomplete, the resulting system design will be incorrect. With this approach, the emphasis is on business analysis as opposed to technical detail.

This approach to system design ultimately recognizes, “No amount of elegant programming or technology will solve a problem if it is not defined or understood correctly.”

Keep the Faith!

MB – “Est superbia”

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 timb001@phmainstreet.com

For Tim’s columns, see:   timbryce.com

Like the article? TELL A FRIEND.

Copyright © 2016 by Tim Bryce. All rights reserved.

NEXT UP:  UNDERSTANDING TRUMP’S ANTAGONISTS – The louder they get, the stronger the candidate gets.

LAST TIME:  JURY DUTY: A NECESSARY EVIL  – Why we hate to be called for duty.

Listen to Tim on WJTN-AM (News Talk 1240) “The Town Square” with host John Siggins (Mon, Wed, Fri, 12:30-3:00pm Eastern); WZIG-FM (104.1) in Palm Harbor,FL; KIT-AM (1280) in Yakima, Washington “The Morning News” with hosts Dave Ettl & Lance Tormey (weekdays. 6:00-9:00am Pacific); and WWBA-AM (News Talk Florida 820). Or tune-in to Tim’s channel on YouTube.

Posted in Systems, Technology | Tagged: , , , , , | Leave a Comment »

IS THE TAIL WAGGING THE DOG?

Posted by Tim Bryce on April 11, 2016

BRYCE ON SYSTEMS

– Do we have enough Systems Analysts or too many programmers?

(Click for AUDIO VERSION)
To use this segment in a Radio broadcast or Podcast, send TIM a request.

Whenever I’m asked to discuss the subject of Information Systems in the corporate world, I am inevitably asked, “Where does the programmer fit in?” I think this is an odd question as I see programming as only a small part of the overall puzzle. People are startled when I mention this, particularly programmers, who tend to see themselves as the center of the systems universe. I counter by asking, “What exactly does a programmer do?” After much discussion, we end up with the same answer, “a programmer takes human understandable specifications and converts it to a machine executable program, either by writing and compiling source code or through some interpreter capable of generating the program.” This, in turn, leads to an interesting discussion as to what is meant by “requirements” (it seems everyone has their own spin on this). More importantly, it leads to a discussion as to what exactly a system is.

I like to follow this by posing the question, “How many programs make up a system? One? Two? Three? Is a suite of programs a system?” Again, after much discussion we conclude there is no finite number of programs in a system, it is as many as satisfies the system’s needs (and again we’re back to “requirements”).

I finally ask if a system can be implemented without computer assistance (without programs). The programmers typically balk at this one, but grudgingly admit an information system can be implemented manually or through the use of other equipment. Actually, information systems have been used for hundreds of years, well before the advent of the computer. As one of our more famous Bryce’s Laws points out, “The first on-line, real-time, interactive, data base system was double-entry bookkeeping which was developed by the merchants of Venice in 1200 A.D.” In other words, computer programming is but one way to implement an information system, but certainly not the only way. This premise implies information systems are much larger in scope than programming, and that systems have two dimensions, a logical side and a physical side. The logical side defines the various business processes comprising the system (aka, “sub-systems”). These processes can be implemented through manual processing, use of other equipment, with computer assistance, or combinations of all three. The physical processing changes more dynamically than the logical simply because technology changes.

To pull this all together requires a type of person more knowledgeable about the business than about computers. Historically, this type of function has been referred to as a “Systems Analyst” or more recently a “Business Analyst.” Regardless, the analyst is a precursor to the programmer. In the absence of an analyst, programmers must try to understand the overall system architecture, a talent they are not necessarily well versed in.

The day a company starts its business is the day when its systems are born. Even a company in name only requires systems support in order to report to the government on their activity (or inactivity). As businesses begin, a “natural” system is devised whereby work is distributed among employees, hopefully in a cohesive manner. Without orchestration though, there is a tendency for the natural system to develop inconsistencies and redundant work effort, particularly if the business blossoms. Data duplication is unavoidable thereby causing inconsistencies in information. If the information is “dirty” inferior business actions and decisions will ensue thereby causing an adverse affect on the company’s bottom-line.

The point is, no amount of elegant programming can solve a system problem without someone who understands the overall system architecture, someone who understands how the business works. Attacking systems development without such orchestration, such as one program at a time, will not produce the desired results. That would be like trying to build a bridge without a set of blueprints; it would probably be disjointed and one end would likely not connect with the other in the middle. I for one would not want to travel across such a bridge. Yet, this is precisely what is happening throughout corporate America today. If we built bridges the same way we build systems in this country, this would be a nation run by ferryboats. If you consider how counterproductive it would be to try and build a bridge without a set of blueprints, you get a good idea how counterproductive a lot of systems development organizations are. A lot of time and money is lost simply trying to deduce what is to be built in a concerted manner.

It is the Analyst’s job to understand the business, not the programmer’s.
It is the Analyst’s job to develop and maintain the system architecture, not the programmer’s.
It is the Analyst’s job to develop the specifications for programming, not the programmer’s.
It is the Analyst’s job to develop the data specifications for the Data Base Administrator, not the programmer’s.
And it is the Analyst’s job to test and install systems, not the programmer’s (although they should be performing unit and string tests of their software prior to system tests).

Programmers should be consulted to review the feasibility of a system design, but make no mistake, it is up to the Analyst to develop such plans. And if the Analyst performs his job properly, he will greatly simplify the life of the programmer, thereby making that person more productive. Regrettably, corporate management has little appreciation for the Analyst’s duties and responsibilities. Consequently, the Analyst is pressured to short stroke his work effort and turn it over to programming prematurely, thereby causing the programmers to act on poorly defined specifications which inevitably results in project delays and increased development costs.

So, is the tail wagging the dog in your company or the other way around? Do you have a sufficient number of Analysts to properly design systems before turning the specifications over to programming? Consider this, if done properly true programming should take no more than 15% of your development time and costs. If you are expending more than this, I suspect you do not have enough Analysts.

Remember this, anytime you have a systems development project involving multiple business processes, multiple people, and multiple programs, you damn well better design a system architecture first.

Originally published: Febraury 9, 2011

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 timb001@phmainstreet.com

For Tim’s columns, see:   timbryce.com

Like the article? TELL A FRIEND.

Copyright © 2016 by Tim Bryce. All rights reserved.

NEXT UP:  WHAT MAKES US HAPPY? – Is it how we act or how we perceive life?

LAST TIME:  MY LAST PUFF  – Quitting is not easy.

Listen to Tim on WJTN-AM (News Talk 1240) “The Town Square” with host John Siggins (Mon, Wed, Fri, 12:30-3:00pm Eastern); WZIG-FM (104.1) in Palm Harbor,FL; KIT-AM (1280) in Yakima, Washington “The Morning News” with hosts Dave Ettl & Lance Tormey (weekdays. 6:00-9:00am Pacific); and WWBA-AM (News Talk Florida 820). Or tune-in to Tim’s channel on YouTube.

Posted in Systems, Technology | Tagged: , , , , , | Leave a Comment »

NOBODY THINKS BIG ANYMORE

Posted by Tim Bryce on February 24, 2016

BRYCE ON SYSTEMS

– particularly in the systems world.

(Click for AUDIO VERSION)
To use this segment in a Radio broadcast or Podcast, send TIM a request.

If you think the physical infrastructure of our country is bad, its bridges and highways, you should see its systems. Like it or not, we are a nation run by systems developed as far back as the 1960’s. No wonder COBOL programmers are still in demand. Over the years I have heard one horror story after another, be it in banking, insurance, manufacturing, or government. I have also written about such snafus, such as at the United States Department of Agriculture (USDA) and the National Security Agency (NSA). Another that comes to mind is the Obamacare health system which was delivered late and horribly over budget. These are mammoth systems wasting taxpayer dollars in the millions and billions. The big question is, Why?

Whereas other countries have cleaned up their messes, such as the banking systems of Japan and Europe, we are just the antithesis. While others are moving forward introducing new banking products, the Americans find themselves in the role of constantly fighting fires. You cannot move forward until you put your house in order by bringing standard practices and discipline into your work effort. This is what happens when you treat system design as an art form, as opposed to a science.

Until the 1980’s, there was an abundance of trained systems people in the work force. We then began to see our focus shift from total systems to how to write a single program efficiently, meaning the Structured Programming and CASE movement (Computer Aided Software Engineering) of that period. This led to a void of systems people and, without such talent, major system projects began to die in the 1980’s and 90’s. So much so, nobody is willing to try it anymore, primarily because they have forgotten how to do so and settle for building smaller things, such as an “app.”

For example, developers no longer know how to write information requirements or project scopes. They may know how to produce a program spec, but have no idea how to develop the high level requirements needed to satisfy the actions and decisions of a business. Without such requirements, developers waste considerable time building the wrong system. Without a well defined project scope, developers frequently wander outside the boundaries of a project and either perform too little or too much work.

Systems design is to programming what architects are to carpenters. Without a proper set of blueprints, the carpenters will likely build the wrong product, regardless of the elaborate tools they may use. Unfortunately, the systems architects disappeared in the 1980’s which explains why we lack the know-how to build systems anymore.

A major system can take several months, if not a couple of years to build, but we now possess the attention span of a gnat. If we cannot produce something quickly, such as in a couple of days, we tend to lose interest. This is why long-term planning is usually no longer than thirty days and why we find ourselves in a reactionary form of management.

When you talk with programmers about doing something bigger and better, the excuse typically is, “We do not have time to do things right.” Translation: “We have plenty of time to do things wrong.”

Like any discipline, in order to perform systems design properly, a standard body of knowledge is required featuring common sense concepts, principles, and defined terminology. Such knowledge should be tested and proven. This is the purpose of a standardized methodology, like “PRIDE,” which is aimed at bringing uniformity to the design and development process. By doing so, it can turn a heterogeneous environment into a homogeneous one, thereby forcing people to speak common language and perform work in a standard manner.

So, the reason nobody thinks big in the systems field anymore is simple; they do not know how to.

“If we built bridges the same way we build systems in this country, this would be a nation run by ferryboats.”
– Bryce’s Law

Related article:
“Too Many Carpenters, Not Enough Architects” (Sep 10, 2012)

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 timb001@phmainstreet.com

For Tim’s columns, see:   timbryce.com

Like the article? TELL A FRIEND.

Copyright © 2016 by Tim Bryce. All rights reserved.

NEXT UP:  GREETINGS FROM PLANET NINE – The new Hollywood.

LAST TIME:  WASTING TIME WITH MY CREDIT CARD COMPANY  – Actually, the programmers are at fault.

Listen to Tim on WJTN-AM (News Talk 1240) “The Town Square” with host John Siggins (Mon, Wed, Fri, 12:30-3:00pm Eastern); WZIG-FM (104.1) in Palm Harbor,FL; KIT-AM (1280) in Yakima, Washington “The Morning News” with hosts Dave Ettl & Lance Tormey (weekdays. 6:00-9:00am Pacific); and WWBA-AM (News Talk Florida 820). Or tune-in to Tim’s channel on YouTube.

Posted in Systems | Tagged: , , , , | 3 Comments »

TRUSTING OUR BANKING SYSTEMS

Posted by Tim Bryce on November 23, 2015

BRYCE ON SYSTEMS

– Do we really trust the banks to manage our money?

(Click for AUDIO VERSION)
To use this segment in a Radio broadcast or Podcast, send TIM a request.

Let me preface my remarks by saying I’ve been involved in the I.T. industry for over 40 years and have seen a lot, particularly banking systems. In the United States I watched mainframe based systems evolve into today’s version where people access their accounts through smart phones and move money around accordingly. These systems are still based on legacy systems which are less than impressive if you study them. Legend has it they are all based on the same program source code from the 1960’s which was modified and patched together to suit local needs. I have found banking overseas has been more stable, innovative, and forward thinking, particularly in Europe and Asia. In fact, the Japanese used our “PRIDE” methodologies to design their latest generation of banking systems which are considered state of the art and ahead of their American counterparts.

With this said, I recently went to my bank to make a deposit. I know most of the tellers there and enjoy a good relationship with them. However, on this occasion there was a new teller who dutifully processed my deposit and upon looking at my account said, “Mr. Bryce I see you are not taking advantage of all of our on-line banking services. Do you want a pin number or a debit card? How about direct deposit and on-line payment of bills?”

I politely declined the offer and said, “No, that won’t be necessary.”

She kept pressing the issue and said, “Don’t you want to know what your up-to-the-minute balance is?” I told her I shouldn’t have a bank account if I didn’t know what was in it. The reality is, I simply do not trust American banking systems based on what I have witnessed over the years.

This got me thinking about today’s on-line banking systems and how people interact with them. I’ve been writing checks and balancing a check book manually for over 40 years. I don’t find it complicated and actually enjoy balancing my check book; it’s good mental gymnastics for me. I particularly like it when I find a bank error. My children though are different and make active use of on-line banking systems. They can’t be bothered with balancing a bank account, they like direct deposit and auto-bill payments, and often use their debit cards. I guess to each their own.

Somehow I’ve always had a problem with allowing others to electronically tap into my bank account and have resisted it for years. I know they have some good security measures over transactions, but I still have an uneasy feeling about allowing others to directly tap into my account. Call me old fashioned.

Another problem is communicating with your financial institution. Recently, my mother had a question about her back account. To solve the problem, she tried calling the local branch office where she was met with voice mail. After saying she spoke English and entering her bank code, she was presented with many options, none of which involved speaking to a human being. This was very frustrating and she had to visit the branch office to solve a simple problem. In other words, she discovered she could no longer speak to a human being on the telephone regarding her finances. Under this scenario, you get the uneasy feeling there is just one person running the whole bank, and probably located in Piscataway, New Jersey. This is very disturbing as we want to trust the people who handle our finances, not a machine.

Actually, I don’t find banking to be very complicated. I probably write 10-15 checks a month and make a couple of deposits. To me, writing a check and updating my register doesn’t require a rocket scientist. True, I have to apply postage to pay my bills by mail, but I see this as a very nominal charge. I also have to visit my bank to make a deposit, but I find this to be a pleasant distraction from work.

I’m sure these on-line banking systems provide some handy services, but I don’t believe in change simply for the sake of change. If this is how I like to operate, what’s wrong with that?

I remember years ago when my grandfather passed away in Buffalo, New York, we went up to help my grandmother tidy up his affairs. My father was rooting around in the basement and found a small box containing quite a sum of money. My Dad confronted his mother with it and said, “Mom, why are you keeping such a large wad of cash laying around?”

“Well Sonny,” she explained, “Don’t forget the banks failed one time (a reference to the Great Depression), and they can fail again.”

I guess I feel somewhat the same way and basically don’t trust on-line banking systems. Even though I’ve been intimate with banking systems for a long time, I’ll probably be the last person to make use of them.

Yea, I know what you’re saying, “This guy is out of step with the times.”

Maybe, but I also know what’s in my bank account and know how to pay my bills on time. Like I said, call me “old fashioned.”

Parts of this column was originally published on October 12, 2007.

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 timb001@phmainstreet.com

For Tim’s columns, see:   timbryce.com

Like the article? TELL A FRIEND.

Copyright © 2015 by Tim Bryce. All rights reserved.

NEXT UP:  STUFFING – a unique family tradition.

LAST TIME:  REINVENTING THE WHEEL  – And why we should avoid doing so.

Listen to Tim on WJTN-AM (News Talk 1240) “The Town Square” with host John Siggins (Mon, Wed, Fri, 12:30-3:00pm Eastern); WZIG-FM (104.1) in Palm Harbor,FL; 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.

Posted in Business, Systems, Technology | Tagged: , , , , | 2 Comments »

UNDERSTANDING BUSINESS PROCESS DESIGN

Posted by Tim Bryce on November 9, 2015

BRYCE ON SYSTEMS

– A primer; it’s not what tools you use, but rather knowing what you are doing.

(Click for AUDIO VERSION)
To use this segment in a Radio broadcast or Podcast, send TIM a request.

There are several interpretations of Business Process Design, which is concerned with devising a cost-effective approach for the various tasks to be performed in a business. Here is mine which has worked effectively for me for several years. It’s not a matter of what tools I use, but rather understanding the principles behind the design process itself.

An inherent part of any Information System is the business processes (or as we originally referred to them as “sub-systems”). An Information System consists of two or more of these business processes representing how information is used to support the actions and decisions of a business, be it a commercial enterprise or a not-for-profit institution, such as a government agency. Actually, an information system is a grouping of processes dedicated to a specific purpose, such as to serve the needs of Accounting, Payroll, Manufacturing, Order Processing, Customer Service, etc. These processes are first defined logically as to who they serve, the information requirements they support (thereby defining the purpose of the process), its timing (how often it occurs, when it starts, and the amount of time necessary to complete the task), and the inputs, outputs and logical files associated with each. This simply represents “what” must occur and “when,” representing a relatively stable logical model (it will only change if the information requirements change). Consider Payroll for example, something we have been processing in different physical forms for many years, yet the logical model is stable; to illustrate: Employee setup or termination, Reporting of Hours worked (reported either on a daily, weekly or monthly basis), Employee Payment, Government Reporting, etc. These processes do not change as much as you may think. However, the physical implementation of each process does. For example, Payroll used to be implemented manually using ledgers and spreadsheets; then computerized versions implemented the processes on mainframes, minis, and personal computers; and now we hear of “cloud” implementations. Yet, the basic logical processes remain the same.

So, when we discuss “business process design,” we are actually discussing its physical implementation. The logical design of the sub-system, of course, should be considered a precursor. Assuming it is in place, the challenge is two-fold: to physically define both the work flow and data flow. In terms of the work flow, the intent is to procedurally define how the business process will be executed from start to end, and by whom. Here, there are three types of procedures used: Administrative (to reflect manual processing), Computer (to represent programming), and Office Automation (“OA”; to represent the use of certain office equipment, such as optical or audio scanning, fax, key entry, etc.). Within a business process, there must be one
or more Administrative of OA procedures, and one or no computer procedures (in other words, a manually implemented business process). The basic processing constructs in the work flow are Sequence (linear), Iteration (repetition), and Choice (selection). These can be combined in a single business process as required.

Data Flow is defined through the various inputs, outputs, and physical files used in the process, each includes records. In terms of inputs, records represent transactions, referring to some sort of action or event, such as a purchase, a return, a back-order, a debit or a credit, etc. Most of what we do in business is process transactions, be it a query, or to update files. This means there are three fundamental actions performed: Create (C), Update (U), and Reference (R). Some would argue there is also a “Delete” to be considered, but this is the opposite function of a “Create.” In programming parlance, a “Reference” is considered a “Read,” and an “Update,” is a “Read/Write.”

One of the fundamental considerations for both work flow and data flow is timing, which should be defined for the overall sub-system in terms of “Frequency” (how often the business process is executed, such as “Twelve Times a Day,” “Once a Month,” or “Upon Request” (whenever desired)). “Offset” represents when the process is to start, such as at the end of the month, first day of the week, etc. As an aside, there is no “Offset” when the “Frequency” is “Upon Request.” Finally, “Response Time,” represents the total amount of time allowed to execute the business process; for example, ten seconds, one day, etc.

These timing nuances will ultimately influence the processing of transactions. To illustrate, if the “Frequency” is once a month, beginning on the last day of the month, with an hour or more “Response Time,” this will likely result in a “Batch” process which is still actively used today. However, a Frequency of “Upon Request” with a five second response time will likely result in an “Interactive” process, where transactions are processed one at a time.

As an aside, when we consider the performance of a business process, we are basically measuring time versus transactions. If the transactions cannot be processed in the allowed time, perhaps it is necessary to devise a new physical implementation.

Through these rules, the Analyst defines the physical implementation of the business process from start-to-end. This can be depicted using common flowcharts drawn from left-to-right, or top-down.

After the business process has been designed, now is the time to write its testing criteria. This will be used after the Administrative and OA procedures have been detailed in terms of steps in execution, and the software engineering for the computer procedure has been written and tested. This ultimately represents a “string” test whereby the whole business process is tested from start-to-end. In addition to basic testing procedures, the criteria should also specify default values for data to assume, invalid values, and the conditions for resulting error/warning/information messages.

Bottom-line, the Analyst’s objective in business process design is to devise the most cost effective physical solution to satisfy the logical specifications of the overall sub-system.

Business process design is less about knowing what tools to use to physically design the process, but rather having the analyst know more about the logical specifications and the mechanics of design (the methodology). To me, I look upon such work as more of a science as opposed to an art form. You can only treat it as a science if you are willing to define your terms and principles. When this is done, you can go even further by automating the design process, not just by pretty pictures, but by automatically deducing the design based on specifications (aka, “inference”).

Related articles:

Process Templates – Apr 06, 2015
It’s All About Transactions – Oct 21, 2013
Logical Systems – June 16, 2014

“PRIDE” Methodologies for IRM

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 timb001@phmainstreet.com

For Tim’s columns, see:   timbryce.com

Like the article? TELL A FRIEND.

Copyright © 2015 by Tim Bryce. All rights reserved.

NEXT UP:  ACADEMIC QUACKS – “Theorists” versus “Practicals.”

LAST TIME:  THE COUPON SHELL GAME  – A clever way to conceal inflated prices.

Listen to Tim on WJTN-AM (News Talk 1240) “The Town Square” with host John Siggins (Mon, Wed, Fri, 12:30-3:00pm Eastern); WZIG-FM (104.1) in Palm Harbor,FL; 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.

Posted in Systems | Tagged: , , , , | 4 Comments »

MANAGING COMPLEXITY

Posted by Tim Bryce on September 28, 2015

BRYCE ON MANAGEMENT

– It’s really not difficult as long as we use a little common sense.

(Click for AUDIO VERSION)
To use this segment in a Radio broadcast or Podcast, send TIM a request.

In a recent Information Technology discussion group I am involved with, someone posed the question, “What is complexity?” I was surprised by the question as I thought it was understood what complexity was all about. Evidently not. The person posing the question was primarily concerned with complexity in system design, but I think it goes beyond systems, to all facets of business, be it related to products or services.

Complexity deals with the number of variables a human can successfully juggle at one time. Each of us possess an intellectual capacity to multitask, but there are mental limitations for all of us. It is like a juggler who takes on one too many balls which forces him to drop the lot. Some people can juggle more objects than others, but we all have limitations.

There are three variables in juggling complexity:

1. The volume of components in a product or service. For example, the number of parts in a product, the number of information resources in a system or program, or the number of customers to serve, employees, or vendors. For example, in an information system there are approximately 2,000 components to manage, and approximately 100 in a single program, which is still significant.

2. The characteristics of each component has to be defined. For example, height, length, width, weight, color, etc. Different components, different types of characteristics, e.g.; how we define the characteristics of a girder of steel is different than the characteristics of an employee, or a data element.

3. The number of relationships to other components. For example, how a wheel is related to an axle, how a worker is used on various projects, or how the data element, “Customer Number,” relates to records, files, programs and other system components. The problem is compounded when parts are standardized for use in multiple products, as General Motors did years ago in standardizing engine parts across their product line.

Based on these three variables, the human being must manage hundreds, if not thousands of variables in a work assignment. In an average information system design, there are approximately 50,000 variables to manage, and for a single program, there are about 2,000 variables. Workers are selected for assignment, in part, based on the number of variables they can juggle at one time.

The next obvious question becomes how to manage all of these variables. If we’re lucky, a person will use a reliable method of documentation to record them, such as blueprints in architecture and engineering, ledgers in accounting, or a “bill of materials” for a product. A bill of materials is a schematic depicting the parts in a product, how they relate to each other, and the characteristics of each component. Anyone who has a product warranty book for home appliances or major garden tools can find such a schematic, it is a common and effective technique for managing complexity. This concept is so effective, it was used as the basis for developing the data dictionary and Data Base Management System (DBMS) as used in application development work. However, the discipline to share and reuse components in the systems world, as logical as it may sound, is still the exception as opposed to the rule. Consequently, it is common to find considerable redundancy in system and data components, e.g; data elements, records, files, programs, business processes, etc. Consider this, it is highly likely there are multiple interpretations of “Customer Number” in a single company, as is “Product Number,” “Part Number,” the calculation of “Total Sales,” etc. Such redundancy complicates system integration thereby adding to the complexity problem.

The final problem is assembling the right parts to form the right products. This explains the rationale for such things as assembly lines and methodologies which define “Who” is to do “What,” “When,” “Where,” “Why” and “How” (the 5W’s + H). Such assembly lines/methodologies are devised by Industrial Engineers who are charged with assembling products in the most expeditious way possible.

There is actually nothing magical in managing complexity. It is just a matter of admitting our limitations and embracing a standard approach for documenting components, their characteristics, and interrelationships. The biggest danger is when we try to manage all of the variables in our head which, unfortunately, is how many programmers work today. Unfortunately, this results in considerable redundancy, lack of system integration, thereby complicating complexity further. All that is needed is little common sense, a standardized approach to documenting components, and some discipline to make it all happen.

Related articles of interest:

Managing Design Complexity – Feb 7, 2005
Communication Complexity – Sep 07, 2010
The Five Elements of Mass Production – Feb 11, 2013

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 timb001@phmainstreet.com

For Tim’s columns, see:   timbryce.com

Like the article? TELL A FRIEND.

Copyright © 2015 by Tim Bryce. All rights reserved.

NEXT UP:  THE DISPARITY BETWEEN CAPITALISM AND SOCIALISM – Do young people know the difference between the two?

LAST TIME:  OUR PERMANENT RECORD  – You can run, but you cannot hide from it.

Listen to Tim on WJTN-AM (News Talk 1240) “The Town Square” with host John Siggins (Mon, Wed, Fri, 12:30-3:00pm Eastern); WZIG-FM (104.1) in Palm Harbor,FL; 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.

Posted in Management, Systems, Technology | Tagged: , , , , | 6 Comments »

“SOFTWARE FOR THE FINEST COMPUTER – THE MIND”

Posted by Tim Bryce on August 17, 2015

BRYCE ON LIFE

– It’s about people, not machines.

(Click for AUDIO VERSION)
To use this segment in a Radio broadcast or Podcast, send TIM a request.

Now and then, I am asked about our corporate slogan, “Software for the finest computer – the Mind” which we have used since our company’s inception in 1971. “What does it mean, where did it come from?” I am asked. At first, it was used in connection with our “PRIDE” methodology for system design. There was nothing remotely like it on the market at the time. Consequently, people asked my father, Milt Bryce, what it was, “Is it hardware or software?” Recognizing their confusion, he said, “It’s neither, actually it is software for the finest computer – the Mind,” meaning it provides instructions so people could build information systems. At first, “PRIDE” consisted of nothing more than some manuals and forms for people to follow during system design. When asked what language it was programmed in, we said “English,” which amusingly confused the techies. Later we added computer software to help expedite the methodology, but make no mistake, “PRIDE” is a thinking process, a way of looking at systems and how to build them. Since then, the expression has gone on to represent other aspects of management and life in general, which is why I use it in my writings.

Keep in mind, machines will do whatever you program them to do, right or wrong, and with incredible efficiency. Humans, on the other hand, tend to be more emotional and illogical, only doing what they feel comfortable with, which is not necessarily the proper course of action.

For computer programming, it is necessary to provide explicit instructions regarding the definition of such things as transactions, the default values of data and editing rules, its physical characteristics (length, justification, picture, label, etc.), processing constructs such as sequence, iteration, and choice, and the layout of inputs, outputs and files. If the slightest thing is not properly defined, the program will not function correctly.

Humans are slightly different, they need to be taught concepts and terminology, techniques and methodologies, as well as the corporate culture. To do so, it is necessary to use persuasion to instruct them to perform the proper action using the three canons of speech: ethos (based on the character of the speaker), logos (logical argument), and pathos (emotional argument). Actually, a good argument makes use of all three to get a point across. Winston Churchill, for example, often relied on his reputation as elder statesman, as well as presenting arguments appealing to both logic and emotion. A careful blend of the three canons of speech, spoken at the right time and place can work wonders. Despite all of this, mankind can be indifferent, lazy, or just plain thick.

Consider this, regardless of how well our “PRIDE” manuals were written, and the lessons taught in our training classes, if a person didn’t read the books or pay attention in class, they would not execute the methodology correctly and produce inferior results. I only wish I had learned Spock’s Vulcan “Mind-Meld,” it sure would have simplified the transfer of knowledge.

Our slogan is also a reminder that people are of paramount importance in business and life. Some believe management is about analyzing numbers in spreadsheets, or the use of technology. In business, it is about customers, employees, and vendors. In life, it is about family, friends, neighbors, and the people we come in contact with while shopping, participating in clubs, traveling, and in our government.

It is true our technology addiction is making us more robotic in our mannerisms and thinking processes. It is also making us insensitive to our fellow human beings. As I have always contended, “As the use of technology increases, social skills decrease.” This concerns me greatly.

If you have observed my writings over the years, be it regarding management, technology, politics or whatever, you will notice it has always been about the human spirit. It is not about some new gimmick or number crunching, it is about “Software for the finest computer – the Mind.”

For more information on “PRIDE”, click HERE.

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 timb001@phmainstreet.com

For Tim’s columns, see:   timbryce.com

Like the article? TELL A FRIEND.

Copyright © 2015 by Tim Bryce. All rights reserved.

NEXT UP:  HILLARY CAN BE BEATEN – She is certainly not invincible as our president has already proven. In fact, she is quite vulnerable.

LAST TIME:  THE WORLD’S BEST  – Come on, who is kidding who?

Listen to Tim on WJTN-AM (News Talk 1240) “The Town Square” with host John Siggins (Mon, Wed, Fri, 12:30-3:00pm Eastern); WZIG-FM (104.1) in Palm Harbor,FL; 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.

Posted in Life, Management, Systems | Tagged: , , , , , | 2 Comments »

THE USDA’S SYSTEM SNAFU

Posted by Tim Bryce on July 22, 2015

BRYCE ON SYSTEMS

– Another example of government waste and incompetence in building systems.

(Click for AUDIO VERSION)
To use this segment in a Radio broadcast or Podcast, send TIM a request.

Another major system snafu was recently reported by the press, “$444 Million Later, USDA Only Achieved 1.5 Percent of its Goal to Update IT System,” (Washington Free Beacon – June 4, 2015). The project was sponsored by the United States Department of Agriculture (USDA) and reported to be two years late, $140 million over budget, achieved only 1.5% of its goals, and finally scrapped. Footing the bill for the disaster was, of course, the American taxpayer.

Named, the “Modernize and Innovate the Delivery of Agricultural Systems” (MIDAS), the system was intended to replace an earlier system, “Web Farm,” which tracked information on farmers receiving aid from the USDA’s 31 programs.

According to a recent audit by the Office of Inspector General (OIG):

“In response to a longstanding need to modernize the delivery of farm programs, the United States Department of Agriculture’s (USDA) Farm Service Agency (FSA) initiated a business enterprise solution called Modernize and Innovate the Delivery of Agricultural Systems (MIDAS). FSA reported to Congress in 2010 that $305 million would allow it to consolidate its 31 farm programs into MIDAS by the end of fiscal year (FY) 2012.

MIDAS is 2 years overdue and approximately $140 million over budget and has not delivered the promised enterprise solution. As of April 1, 2015, FSA had obligated over $444 million to this project and had retired only 1 of the 66 applications which were to be replaced by MIDAS. By 2022, the program is projected to have a total cost of nearly $824 million. In July 2014, Secretary Vilsack directed that future MIDAS development cease.”

The OIG’s biggest finding from their audit was, “MIDAS is Overdue and Over Budget Because of Ineffective Project Management and Oversight.”

This is only partially correct. Understanding and applying the mechanics of project management is one thing, devising a road map to travel to your destination is another. From the audit, it was apparent the project lacked a systems design methodology to define the work breakdown structure, deliverables, and review points. Not surprising, developers were allowed to do whatever they wished with no direction. In an attempt to reign in control over the project, they kept reducing the scope to try and break it into more manageable pieces. The fact remains, you cannot effectively perform project management without an overall methodology. As we like to say, “Having a Project Management system without a methodology is like attaching a speedometer to an orange crate; it measures nothing.”

Even though I know nothing about the system, other than what I have read in the audit, I can conclude the system suffered from such things as:

Poorly defined requirements – According to the audit, “The current project manager stated that, at that time, there were only high-level project requirements defined and those were never put into a detailed system requirement specifications document for the project.” Without a proper set of requirements, what in the heck are you building? This means the developers wasted considerable time second-guessing what was needed. This, of course, lead to a plethora of “do-overs.”

No analysis of the current system – Had developers truly understood the aging “Web Farm” system, they would have known the requirements they supported, the data collected and calculated within the system, its strengths and weaknesses, the business processes involved, and could have devised an effective transition plan. It seems rather obvious this was simply not done.

No test criteria or test plan – According to the OIG audit, there were numerous known defects in the new system, which caused users to become dissatisfied. Both the test criteria and test plan should have been devised earlier in the project so programmers understood how their programs should perform.

No documentation – Although it wasn’t specifically mentioned in the audit, I suspect no documentation of any substance was ever devised. Without a set of blueprints, what in God’s name are you trying to build? Or is this based solely on the builder’s intuition? Obviously, documentation is needed for designing the product, as well as for maintenance and modification purposes later on.

Data redundancy – if there is no documentation, it is safe to assume data redundancy plagued the system. If the data is “dirty,” the information produced will be inconsistent and unreliable.

Here is what I believe happened with the system: They took a software approach for designing MIDAS as opposed to a system approach. For example, they probably created a data base quickly, then tried to figure how to get data in and out of it. I would suspect the program source code was well written, probably using “Agile” techniques, but the fact remains none of it was designed to work in a concerted manner.

If you were to ask the MIDAS developers why they didn’t concentrate on the important up-front planning and design phases, they would probably lament, “We do not have time to do things right”; Translation: “We have plenty of time to do things wrong.” Had they spent more time in the initial design stages, there would have been less second-guessing, and the system would have likely come in on-time and within budget. The eternal question, to me, is why do people prefer to do things wrong? The truth is, today’s systems developers do not get it, do not want to get it, and never will get it, which explains why we will never be able to build enterprise-wide systems again. Even if they did “get it,” they wouldn’t understand it as they simply do not care.

What occurred at the USDA is typical of the systems being built in this country today. For example, the highly touted Obamacare Health Care system was also well over budget, late, and cost taxpayers in excess of $400 million. This could have been done more competently and at greatly reduced expense.

Aside from not possessing the expertise to perform this work, developers simply do not want to, preferring to try and program their way to success. After watching this for forty years, I can tell you authoritatively, “It doesn’t work.”

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 timb001@phmainstreet.com

For Tim’s columns, see:   timbryce.com

Like the article? TELL A FRIEND.

Copyright © 2015 by Tim Bryce. All rights reserved.

NEXT UP:  WHAT EVER HAPPENED TO CIVICS? – Is it gone with the wind?

LAST TIME:  1976 REDS VERSUS 1927 YANKEES  – Which was the best team in Major League Baseball?

Listen to Tim on WJTN-AM (News Talk 1240) “The Town Square” with host John Siggins (Mon, Wed, Fri, 12:30-3:00pm Eastern); WZIG-FM (104.1) in Palm Harbor,FL; 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.

Posted in Systems, Technology | Tagged: , , , , | 5 Comments »

THE “SYSTEMS” INDUSTRY

Posted by Tim Bryce on June 15, 2015

BRYCE ON SYSTEMS

– “Tim, just what, the heck, are you talking about?”

(Click for AUDIO VERSION)
To use this segment in a Radio broadcast or Podcast, send TIM a request.

Whenever I mention I am in the “Systems” business, people generally look at me befuddled, smile, and shake their heads. I can tell they haven’t got a clue what I am talking about. Many assume it has something to do with computers, and those in the technology sector assume I am referring to software. Frankly, no. What most people do not comprehend is that we are surrounded by systems. Life, as we know it, would be unfathomable without them.

Recently, I had a routine medical checkup, and as I was driving back to my office I started thinking about all of the systems around us and how oblivious most people are to them. I started by thinking about transportation systems, particularly to regulate traffic. We use a plethora of signals, signs and street markings directing people to turn, stop, slow down, etc. There are also law enforcement personnel who issue tickets for infractions of the rules and to assist motorists in the event of accidents. All of this has to operate routinely and predictably in order to provide a fair and balanced means to expedite traffic.

Transportation systems also include the airlines, trains, buses, and ships, all of which have regular schedules and routes to follow, not to mention ticketing of passengers, the storage of cargo, and preparations for the trip, such as fuel, food and water. Many also offer Wi-Fi service, television, lavatories, and many other creature comforts.

Public utilities maintain extensive systems for such things as water, gas, electric, telephone and cable. These systems are typically run underground or by wire overhead. All operate regularly and routinely. If broken, repairmen are summoned to take corrective action, thereby representing different, yet vital, parts of the system.

There are also medical systems, not just in hospitals or doctors offices, but emergency medical care as well, all of which operate routinely and predictably. Fire departments and police likewise have systems in order to safeguard our communities. Education systems are no different as they operate at both the school level and support school boards. And you cannot escape insurance systems, be they for medical, automobile, health, or life. Companies also follow systems to manufacture products, offer service, manage inventory, and bill the customer. Perhaps the biggest systems can be found in government which are used to regulate about everything, at least so it seems. The fact is, we cannot live without systems.

So, what are the basic elements of a system; that’s easy:

1. They serve a purpose; be it to move motorists in a concerted manner, provide utility services to consumers, produce a product, handle accounting and other economical considerations, producing reports to the government, etc.

2. They consist of two or more components which work cooperatively but separately.

3. They operate routinely and predictably.

Other examples include satellite systems, irrigation systems, communication systems, assembly lines, and information systems (which is my forte). Here, the purpose is to support the information needs of a business so they can perform specific actions and make decisions in a timely and cost effective manner. Over the years, I have seen information systems used to run banks, insurance companies, manufacturing facilities, government agencies, and much more. These systems represent a collection of sub-systems or “business processes,” each charged with performing a specific task, be it to collect data, or act on the information produced. Such processes can be implemented manually or through computer automation (software programming). Despite the emphasis on computers over the last fifty years, there are still a surprisingly high number of manual tasks performed in just about every institution which explains why there are so many people working in a major corporation. Come to think of it, the business world ran for many years using manually implemented information systems.

As we have said, “The first on-line, real-time, interactive, data base system was double-entry bookkeeping which was developed by the merchants of Venice in 1200 A.D.”Bryce’s Laws. How a system is implemented is of little importance if it solves the problem effectively.

The day a company goes into business is the day when its information systems are born. They may start out small, but they will inevitably grow and evolve. All systems do.

So, next time I mention I am in the systems business, I hope you will know what I mean.

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 timb001@phmainstreet.com

For Tim’s columns, see:   timbryce.com

Like the article? TELL A FRIEND.

Copyright © 2015 by Tim Bryce. All rights reserved.

NEXT UP:  REFLECTIONS OF JAMESTOWN, NY – Nestled in the western tip of the state of New York.

LAST TIME:  OUR LEGACY  – Will we be remembered for tangible objects or the people we come in contact with?

Listen to Tim on WJTN-AM (News Talk 1240) “The Town Square” with host John Siggins (Mon, Wed, Fri, 12:30-3:00pm Eastern); WZIG-FM (104.1) in Palm Harbor,FL; 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.

Posted in Management, Systems, Technology | Tagged: , , , , | 11 Comments »

 
%d bloggers like this: