THE BRYCE IS RIGHT!

Software for the finest computer – The Mind

Archive for the ‘Software’ Category

« Previous Entries

PRODUCTIVITY IMPROVEMENT?

Posted by Tim Bryce on January 16, 2020

BRYCE ON TECHNOLOGY

– Does computer technology truly improve life?

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

I have been using computer technology since the 1970’s. I have used mainframes of all kind, e.g., IBM and the rest of the BUNCH (Burroughs, Univac, NCR, CDC, and Honeywell); minis including DEC VAX/VMS (a personal favorite), HP-3000/MPE, and AS/400; and PC’s with Windows and the world’s best operating system, OS/2. And, Yes, I have also used smart phones and smart televisions. All of these machines are intended to improve productivity, and perhaps they have, but the jury is still out as far as I’m concerned. The fact remains, the government does not have analytical data to demonstrate whether technology honestly improves productivity. Perhaps the closest thing is the Gross Domestic Product (GDP), but that is a measure of output only, not the process by which it is produced.

Technology has undoubtedly improved communications, but it has also caused more traffic accidents through abuse of smart phones. It has improved our ability to wage war, but at an incredible cost, thereby adding to the national debt. Even though technology is intended to improve life, it often becomes counterproductive due to misapplication by users, but blame the programmers who fail to make it intuitive to use.

Let me give you three simple examples to demonstrate my point:

First, as many of you know, I have served on over 50 Nonprofit Board of Directors. Along the way, I have opened quite a few bank accounts for the various organizations. This typically required some simple paperwork, the signing of an application and signature cards. Elapsed time, fifteen minutes (tops). Just recently, as the new Secretary of my Homeowners Association, I helped open a new account with a local reputable bank with a big name. I was joined by the President and Treasurer on our visit to the bank. We dutifully supplied the necessary paperwork, but spent considerable time setting up the account on the computer, along with prepping for electronic banking. Elapsed time, 2.5 hours. Needless to say, this ruined the rest of our afternoon.

Second, I wanted to begin working out again at a local gym. I discovered my Medicare supplement insurance provider would pay for my monthly membership, which makes sense as it encourages a healthy lifestyle. So, I Called my provider to apply for a special code to join the gym. I thought this would be rather quick and simple. Wrong. After traversing voice mail jail and waiting in queue, I was transferred to four different people throughout the United States. I finally found the right person who issued my special code, but it tested my patience. Elapsed time, 20 minutes for a simple code number.

Third, my mother tried to order some new book shelves from one of the Mega-Garden stores. The on-line order somehow aborted in mid-session, and asked us to call an 800 number. I was selected to make the call. They first asked for the order number, which I gave them. So far, so good. Then they asked for the last four digits of my mother’s Social Security Number, which I dutifully entered. Unfortunately, it didn’t accept it, I was allowed to try it again and again, but still no luck. My head was ready to explode with anger. Having no alternative, and no human being to talk to, I cancelled the order completely.

I also have a problem with this same store where you are supposed to do self-checkout. I personally prefer the classic checkout procedure where you work with a clerk who is concerned about customer satisfaction. I find it rather ironic the self-checkout still requires a human being to make sure you check out properly (and don’t steal anything). Where is the improved productivity here?

If our technology is so good, it would seem we would see a noticeable leap in productivity in our country. Unfortunately, there is nothing at the US Department of Labor to substantiate this.

To me, technology simply represents the tools we use at work and home, and like any tool we can either use it properly or improperly (like shooting ourselves in the foot). Even the finest tool in the wrong hands will produce inferior results. This implies there is more to productivity than the technology itself, that it depends on how the human being uses it. In other words, management is an integral part of the equation, and something sorely lacking in recent times.

Consider this, number crunching has always been one of the prime benefits of computing. If this is true, then why does it take so long to compile a financial report or budget? After all, everything should be available at the push of a button, right? Unfortunately, corporations and government agencies operate with poorly designed systems and data bases, thereby the reliability of data is doubtful, thus requiring rechecking.

So, for those companies claiming their technology improves productivity, “SHOW ME THE PROOF!” Not your test runs, but a company actually using it.

For more information on Productivity, click HERE.

Keep the Faith!

P.S. – Also do not forget my books, “How to Run a Nonprofit” and “Tim’s Senior Moments”, both available in Printed and eBook form.

Note: All trademarks both marked and unmarked belong to their respective companies.

Tim Bryce is an author, freelance 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 timb1557@gmail.com

For Tim’s columns, see:   timbryce.com

Like the article? TELL A FRIEND.

Copyright © 2020 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.

 

Advertisement

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

THE PROBLEM WITH PROGRAMMERS

Posted by Tim Bryce on August 15, 2019

BRYCE ON TECHNOLOGY

– How they affect society.

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

Years ago I wrote a technical paper titled, “Theory P: The Philosophy of Managing Programmers,” which was aimed at providing assistance to managers in reigning in their people. In a nutshell, I contend the best way to improve programmer productivity was to give them better specifications and create a uniform process (methodology) for them to conform to. I received mixed reviews on the piece; whereas managers loved it, a furor ensued among programmers. Nonetheless, I still stand by the conclusions of the paper.

It occurs to me though, programmers have a profound impact on society. Perhaps the most visible sign of this is our addiction to smart phones, where people are plugged in and tuned out. For example, we see people preoccupied with them on the road, which is quite dangerous, in stores, in the office, even in the gym where they are “tuned out” while they exercise. As an aside, I learned a long time ago not to try and strike up a conversation with anyone in the gym as they are all “plugged in.” This suggests our socialization skills are changing.

There are many other examples, such as remote control devices for TV, cable, DVD, radio, and Yes, old tape machines (e.g., VHS), all of which are as “user friendly” as a Ouija board. In my family room, I have four devices; one for the television, one for streaming channels, one for my DVD/VHS player, and one I’m really not too sure about. I hesitate to dispose of it as it might serve some purpose, kind of like an old metal key you do not want to throw away yet.

As an aside, you would think they would have invented a universal remote by now, but they haven’t. Actually, it shouldn’t be that difficult, a button for power, a button for volume, a button for tone (treble/bass), and a button for channel selection (Gee, it kind of sounds like the old TV’s and radios, doesn’t it?). This should be followed by a series of programmable function keys as on a keyboard (e.g., F1, F2, F3, etc.) which could include device selection, fast forward, reverse, pause, stop, etc.

This brings up a point, people use only a fraction of what these devices are capable of performing, primarily because we have specific needs and only use the devices as such. In addition, programmers tend to make such devices robust, with little consideration for “ease of use.” This is not new as we noted this phenomenon years ago with computers; we simply do not use them to their full potential.

You must remember, programmers are detailists who possess a myopic view of their particular problem. No, they do not see the big picture, just their small part of the overall puzzle. This is why it is important to provide the programmer with precise specifications, which has historically been the responsibility of Systems Analysts to provide. Unfortunately, such people are an endangered species and programmers are left to figure out both the problem and solution on their own. Not surprising, they will inevitably do what is easiest for them to do as opposed to how the end-user will implement it. This explains why devices appear complicated to the rest of us.

You should also understand programmers typically abhor standards as they consider it inhibiting their creativity. Let me give you an example, years ago IBM devised the Systems Application Architecture (SAA) standards which was intended for use on all of their computing platforms, including mainframes, minis, and PCs. This included standards for Graphical User Interfaces (GUI) for window design. The intent was to design windows in a uniform manner so that if a user mastered the use of one window, the user would know how to use all windows, thereby simplifying training and improving productivity simply by developing a common “look and feel” to all windows, regardless of the computing platform. Frankly, it was brilliant, but alas programmers resisted it and fought the standards until IBM backed away from them. Today, there is little continuity in how web pages work, much to the chagrin of the end-user.

We see other examples of technical snafus all around us:

* Web pages simply do not work correctly with no explanation (Help text is severely lacking). How many times have we seen a web page die on us, particularly when we are ordering something on-line? Quite often, the data we entered earlier has to be re-keyed into the page, only to die a second time, maybe because we didn’t upshift or downshift a letter in the proper sequence. Such editing rules should be accommodated by the programmer, but again, they ignore this and take the easy way out.

* In the event there is a power outage, or some other problem with television cable, we have to re-boot our cable box. This takes us down a cryptic path whereby we do not know what we are doing, and have no clue whether the repair process is occurring properly. I still find it rather amusing when customer service reps admonish us to unplug the device, wait 30 seconds, and plug it back in (whereby it takes us on a countdown to nowhere).

* Voice Mail jail is still the norm for just about all companies. I cringe when I hear, “Press-1 for this, Press-2 for that, etc.” Even after you entered your name, rank and serial number two or three times, the customer service agent will inevitably ask you to repeat it all over again, assuming someone returns your call. They throw up these electronic walls intentionally as they do not care about Customer Service.

Instead of simplifying the user experience, programmers make it more complicated, again, because it is what is easier for them to program, not what is convenient to the end-user. Such a mindset forces us to expect less, not more, from sales and customer service.

Here is the point: Instead of adapting technology to human behavior, humans have to adapt to the technology. We are the ones truly being programmed, not the machine. This is like putting the cart before the horse, all because we bow to the creativity of the programmer, not because it is right.

All of this influences social behavior. For example, we are less likely to engage in conversation, we lose respect for the human spirit, we lose patience, and we become more irritable and prone to heated arguments and fights. All because we resist properly managing programmers and allowing them to do whatever they please.

One last note, I recently had to swap out the SIM card for my mom’s aging flip-top phone, a process I estimated would take maybe five minutes, at most, to perform. First, I discovered I couldn’t lift off the back cover as easily as the instructions indicated. I basically needed a hammer and chisel to break in, but I also considered a little nitro. I then pulled out the battery to access and replace the SIM card in the back. After reinstalling everything, I turned on the phone, only to discover it claimed the SIM card wasn’t installed. I again brought out the hammer and chisel, pulled everything apart, and found I had indeed installed the SIM card properly. In desperation, I called the company’s customer service who explained to me the phone had to be activated. Note: There was no mention of activation in the documentation I received. Nonetheless, the phone finally became operational. So, a five minute operation ended up taking just over an hour to complete. Is it any wonder why I despise programmers?

“As the use of technology increases, social skills decrease.”
– Bryce’s Law

Keep the Faith!

P.S. – Also do not forget my new books, “How to Run a Nonprofit” and “Tim’s Senior Moments”, both available in Printed and eBook form.

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 timb1557@gmail.com

For Tim’s columns, see:   timbryce.com

Like the article? TELL A FRIEND.

Copyright © 2019 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.

 

Posted in Software, Technology | Tagged: , , , , | 4 Comments »

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.

 

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

IS SOFTWARE HARD?

Posted by Tim Bryce on September 20, 2017

BRYCE ON TECHNOLOGY

– “Systems are logical, programming is physical” – Bryce’s Law

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

For something that is supposed to be “soft”, computer software exhibits some pretty “hard” characteristics. The original premise behind the COBOL programming language was to devise a language that could be easily ported to several computers. This never truly happened due to computer manufacturers who tweaked the language to suit their particular needs. What ran on an IBM machine, for example, didn’t necessarily run the same on Honeywell, UNIVAC, or the rest of the BUNCH. Consequently, software developers had to maintain different versions of source code to suit the particular needs of the various computer compilers. This plagued all third generation languages until Sun introduced JAVA in the 1990’s. The JAVA premise that a programmer should “write once, run everywhere” was the right idea and the language began to gain momentum, until it ran into Microsoft who didn’t want to turn the operating system into an inconsequential afterthought. JAVA lives on, but not to the extent it should have, and developers are back to managing separate versions of source code.

The point is, software does in fact exhibit some very “hard” characteristics as it is married to the host computer configuration which doesn’t make it very portable. As mentioned, this creates headaches for those of us, particularly commercial software vendors, in terms of maintaining consistency in the different versions of our products.

What to do?

Back in the 1970’s and 1980’s our company was faced with the dilemma of managing a single product on over a dozen different computer platforms. We quickly came to the realization we would go stark raving mad managing multiple versions of source code and came to the conclusion we had better come up with a solution pretty quick. Because of our experience in converting software, we became well versed in the nuances of the various compilers and devised a Repository (we called it a “filter program” at the time) which maintained the rules of the various compilers. We were also very disciplined in writing code to specific standards and embedded certain switches in the base source code. When we were ready to produce a new release of our product, we would feed the base code into our “filter program” which would then create the different versions of the source code ready for compilation. This saved us an incredible amount of time and brought consistency to all of the versions of the product. In other words, our programming staff worked with only one set of programming code (not multiple variations). The “filter program” then analyzed it and created the necessary permeation for a targeted platform. As compilers changed, we would update the “filter program” accordingly.

We also learned to maintain print maps, screen panels, messages and help text separate from the source code, which greatly enhanced our ability to create a new version of the product to suit a foreign language and culture; see “Creating Universal Systems.”

Let us take it a step further, for years we have touted there are logical and physical dimensions to Information Systems. We look upon Systems and Sub-Systems (business processes) as logical constructs, and Procedures and Programs as physical constructs. Further, data components such as inputs, outputs, files, records and data elements can be specified logically and implemented physically many different ways. Let me give you an example; back in the 1980’s one of our customers (a large Fortune 500 electronic conglomerate) bought into our logical/physical concept and decided to put it to the test. Working from their headquarters, they designed a complete Payroll System which they wanted to implement as the corporate standard across all of their divisions and subsidiaries. They completed the system with a recommended programming solution they wrote themselves (no packages were used) which I believe was an IBM MVS solution using COBOL. However, they recognized this implementation wouldn’t work across the board in the company. Consequently, they gave the system specifications to all of their divisions who would then program it themselves in-house. The project turned out to be a major success and the company ended up with multiple implementations of the same system under IBM MVS, VM, Honeywell GCOS, UNIVAC Exec, HP MPE, DEC VAX/VMS, and Prime; all working harmoniously together. Other customers experienced similar successes, particularly in Japan.

All of this drives home the point that systems are logical in nature, and that programming is physical. If systems are designed properly, there is no reason they shouldn’t behave identically on whatever computer platform you come up with. Better yet, it allows us to easily migrate our systems from one configuration to another. Uniformity and consistency in execution; and portability to boot. Imagine that.

First published: January 24, 2005

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 © 2017 by Tim Bryce. All rights reserved.

Also read Tim’s columns in the THE HUFFINGTON POST

NEXT UP:  FUN WITH HAIR BLOWERS – How to kill a few birds with one stone.

LAST TIME:  LESSONS LEARNED FROM IRMA  – A lot of the problems were our own doing.

Listen to Tim on 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). Or tune-in to Tim’s channel on YouTube. Click for TIM’S LIBRARY OF AUDIO CLIPS.

 

Posted in Software, Technology | Tagged: , , , , | 2 Comments »

HOLDING A JOB HOSTAGE

Posted by Tim Bryce on September 16, 2015

BRYCE ON MANAGEMENT

– How programmers do it, but why does management accept it?

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

For as long as I can remember, people in the Information Technology business have enjoyed relative immunity from being fired from their job. This is primarily because when they write source code (text which is compiled into electronic format) it is difficult to read and understand the logic behind it. In most cases, if a programmer has written a program featuring a special calculation or feature, employers are afraid to release the person as they fear the logic will walk out the door with the person, making maintenance or modification of the source code almost impossible. This can be easily overcome by developing documentation, both within the program using comments, and externally where the purpose, description, and logic of the program is explained, as well as its interfaces to other programs and file structures. Unfortunately this rarely occurs as programmers stubbornly resist writing documentation in fear someone might read it and criticize their work. By doing so, they have safeguarded their job and now hold it hostage.

Think of it this way, it is like an architect being the only person who knows how a building is designed. Who would fire him? After all, there are no blueprints and the design is filed away in the person’s head.

Frankly, I do not understand why managers accept this behavior, but they do. Consequently, it becomes difficult to reprimand an employee. Further, it becomes rather expensive to dissect a program and modify it without disrupting the interfaces to everything else linked to it.

Another problem is when programmers leave a company they often take code not belonging to them. Regardless if it was written by the programmer or another, most programmers feel entitled to the code so they may use it with their next employer. This is incredibly illegal and could do serious harm to the company, as it is their intellectual property, but it is a common occurrence in business today.

What I have described herein is common knowledge inside the Information Technology field. The outside world is generally unaware of this problem. There are other technical positions doing this as well, but it is in programming where it becomes a flagrant problem. Outside consultants also like to play this game and deliver software, but no documentation, thereby creating a dependency on their services. Again, the best way to overcome this problem is to insist on verifiable documentation, but managers either do not understand the problem or naively believe programming is an art form which can only be performed by people who cannot be inhibited by structure or discipline. This is just plain nuts. Under this scenario, the real culprit is the manager for allowing this to happen, not the programmer.

I have always believed the best way to make yourself indispensable to a company is by demonstrating a positive attitude and a professional work ethic (e.g., craftsmanship), not to mention delivering on time and within budget. Alas, this appears to be an attitude from a bygone era.

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:  WHY OLDSTERS ARE MEAN – And, No, we’re not like this all the time.

LAST TIME:  THE THREE TENETS OF MANAGEMENT  – Is there any real management going on anymore?

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 Employment, Management, Software | Tagged: , , , , | 3 Comments »

INFORMATION RESOURCE MYOPIA

Posted by Tim Bryce on May 6, 2015

BRYCE ON TECHNOLOGY

– Segments of Information Technology departments see only what they want to see.

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

In my nearly 40 years through the Information Technology field (IT), I have come to realize the practitioners in this industry suffer from acute myopia regarding their work. Programmers tend to believe their part of the puzzle is the most important, as do business process analysts, data base analysts, network analysts, project managers, enterprise analysts, etc. True, each has an important role to play, but very few people comprehend the big picture, which is why their work is fragmented and lacks harmony. Few companies understand their business from a global perspective, such as the location of all of their business units, the business functions involved, the organizational structure, the human and machine resources, the systems and business processes, programs, data resources, not to mention the information requirements needed to run the business. In a perfect world, these components would all be cataloged and cross-referenced to minimize data and work redundancy and promote systems integration. This is what I refer to as Information Resource Management (IRM) or the “View of the enterprise from 50,000 feet.”

Instead of working cooperatively and in concert, a series of fiefdoms have emerged within IT with different interests, concepts, and vocabulary, thereby leading to a Tower of Babel effect. Each fiefdom speaks a different language which hinders cooperation and productivity. It is a strange phenomenon few business leaders are cognizant of, as well as government officials.

This fragmented look at information resources is compounded by the general belief by IT people the only valid problems to be solved are those that can be automated by computing. Rarely, is there any interest in the manual forms of processing, or data used outside of a data base management system. Believe it or not, companies still print and file purchase orders, contracts, back-orders, and a lot more. However, this is considered inconsequential by IT people. However, if these manual systems and files were properly recorded, a blueprint would emerge in terms of how to make them more productive. Let me be clear about something, not everything needs to be automated. Quite often a manual process or file can solve a problem more cost-effectively than by automation. As an aside, this last statement would be considered heresy by most IT departments.

The benefits of a global IRM perspective are numerous; data redundancy is eliminated meaning it can be shared in multiple systems, which implies end-users would receive consistent information throughout the company. It also means systems would be integrated as opposed to operating with separate and incompatible data bases. In addition, if the systems are integrated, it would reduce repetitious work thereby saving money. To make this all happen, companies need to possess this “View from 50,000 feet” perspective and implement a set of standards all parts of the IT world can implement in a cohesive manner.

Implementing standards in the IT industry has always been its Achilles’ heel. Again, concepts and vocabulary vary within IT from one job segment to the next. This is an old problem. My father first discussed the lack of standards at a DPMA conference in Seattle back in 1970. He put forth the same argument I have described herein and, unfortunately, it fell on deaf ears at the time as well. However, understand this, the technology has obviously changed since 1970, but the problems have not; IT projects are still late and over budget, companies are plagued by redundant data, nothing is documented thereby hindering maintenance and modification efforts, developers are not rowing on the same oar, and they still do not know how to specify information requirements. These are the same problems he articulated nearly half a century ago. This is what happens when you treat a science as an art form.

Some would argue documenting the information resources of a business is an impossible task. Not true. It certainly will not happen over night, but we should always be cognizant of the old expression, “You eat elephants one spoonful at a time.” In other words, it is an evolutionary process holding great rewards for visionaries who want to maximize the productivity of their business. However, if companies are content with IT departments performing “quick and dirty” work, than the problems of 1970 will likely be with us for another 50 years.

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:  CIGARS 101 – IT’S PERSONAL – Sorry, but there is nothing like a good cigar.

LAST TIME:  WHY ARE COMPUTER VIRUSES STILL A PROBLEM?  – Why have we been battling secrutity problems for over forty years?

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 Software, Systems, Technology | Tagged: , , , , | 7 Comments »

ACCEPTING MEDIOCRITY IN COMPUTING

Posted by Tim Bryce on June 23, 2014

BRYCE ON TECHNOLOGY

– Just because you use Microsoft products, doesn’t mean you are “state of the art.”

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

Back in 1996, I helped organize a global effort to promote an IBM operating system for use on the PC; codenamed “Merlin,” it represented Release 4.0 of OS/2 Warp. For those of you ensconced with Microsoft products, there are alternatives to Windows, OS/2 being one. Originally introduced in 1989, OS/2 was a far superior operating system, and way ahead of its time. It offered a true object-oriented desktop, making use of a System Object Model (SOM) which allowed multiple programs to share data at the same time. It also had an easy to use and customizable Graphical User Interface (GUI), a sophisticated High Performance File System (HPFS), symmetric multiprocessing (SMP) support, crash protection, and much more. It could run DOS and Windows apps as well as native OS/2 programs. It was also the first operating system to support JAVA, offer speech recognition, multitasking/multithreading, and was Internet aware. It was an incredibly stable operating platform. After using OS/2 for a number of years, I had trouble adjusting to the Windows world as I found it to be a quantum leap backwards. Everything I took for granted with OS/2 was simply not there in Windows. There was only one problem with OS/2, IBM didn’t know how to market it and inexplicably backed down from Microsoft.

For one day in October 1996 (October 26th), tiny Palm Harbor, Florida was the center of the OS/2 universe. Knowing a storm was brewing between IBM and Microsoft, OS/2 users lept to the rescue in the form of a worldwide demonstration of OS/2 entitled, “Connect the World with Merlin.” (Click for MORE).

Merlin was the codename for the next major release of OS/2 (v4.0), the last issued by IBM. As a show of support, OS/2 users rallied around the product and put on a demonstration of the product at computer stores, Internet cafes, universities, and PC user group meetings. 28 countries participated in the event, all orchestrated by the product’s customers, not the vendor. This is the first time such an event was conducted in this manner, and perhaps the only one to do so. During the 24 hours of the event, volunteers met in our offices in Palm Harbor and communicated with OS/2 users around the globe using the Internet, cameras and native OS/2 software (NOTE: this was way before such things as Skype). I personally gave OS/2 presentations to consumers and students in Australia, Brazil, Norway, Sweden, the United Kingdom and of course throughout the United States. As each OS/2 site called in, we marked their location on a global map which was refreshed on the Internet. Dots appeared going from east to west as people followed the movement of the sun.

When the day was over, 165 sites had been contacted around the world, with over 1,000 volunteers participating in the event, not bad for a customer driven marketing event. IBM thanked us for our support and we garnered considerable publicity in the process, but IBM nevertheless abdicated the product over the next few years. Its loyal customers persevered though and went on to create an annual user conference entitled, “Warpstock,” thereby attaining cult status.

OS/2 may have been dropped by IBM, but it lives on as a hybrid product called “eComStation” (click for MORE), which is developed by IBM, Mensys, Serenity, and various third parties. There are still many proponents who understand the strength of the product and have no intention of sipping the MS Windows Kool-Aid. Even though OS/2 is far and away a better product, Microsoft was able to pound them into submission. The same is true for other products:

* Even though Lotus SmartSuite predated MS Office, it is Microsoft’s offering people are most familiar with. If you worked with Lotus SmartSuite though, you realize the deficiencies in MS Office; it is like night and day. Lotus was purchased by IBM who, again, botched the marketing of the product.

* Adobe “InDesign” and its predecessor, “Pagemaker,” were impressive tools for desktop publishing. Yet, it is MS Publisher (a component of MS Office) the public is more familiar with. Again, if you have used Adobe’s products, you realize the weaknesses of Microsoft’s offerings.

* The RealPlayer multimedia player predated MS Media Player. Further, Real’s peripheral products for recording and editing multimedia are vastly superior.

* The Google Chrome and Mozilla Firefox web browsers are vastly superior to MS Internet Explorer. Likewise, the Mozilla Thunderbird e-mail reader is more effective than MS Outlook, yet it is the latter which dominates market share.

There are many other examples, such as Intuit’s Quicken versus MS Money, and I could go on and on. The point is, if the consumer doesn’t know better, they will accept the status quo as “state of the art,” when, in reality, it is substantially behind it. Products like OS/2, Lotus, RealPlayer, etc. are cleaner, simpler and more easy to use, not to mention more stable. Nonetheless, it is marketing which dictates the state of the art, not technology.

Consider this, I still have two OS/2 Warp computers and they haven’t crashed in decades, that’s right, decades. Can you say the same for your MS Windows machines?

I chuckle when I hear someone say Bill Gates was a technical genius. Someone is taking it in the arm when they say things like this. A technical genius? Hardly. A marketing genius? Definitely.

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 © 2014 by Tim Bryce. All rights reserved.

NEXT UP:  HOW OBAMA IS UNDERMINING DEMOCRATS – With friends like this, who needs enemies?

LAST TIME:  LIFE IS UNFAIR  – Murphy’s Laws have a tendency of upsetting us.

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.

Posted in Computers, Software, Technology | Tagged: , , , , | 6 Comments »

CREATING UNIVERSAL SYSTEMS

Posted by Tim Bryce on June 9, 2014

BRYCE ON SYSTEMS

– Designing systems to cross cultural boundaries.

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

“There is only one problem with common sense; it’s not very common.”
– Bryce’s Law

GENERAL DISCUSSION

In this day and age of “globalization” more and more Information Systems are crossing geographical boundaries. Because of this, serious consideration should be given to making systems universally applicable to any country. Some might consider this an impossible task, but it is actually easier than you might think. It just requires a little common sense and some planning.

First, it is strongly suggested you adopt standards for system development. System Design Methodologies are particularly useful, but consideration should also be given to the “look and feel” of your systems, to assure uniformity in operation no matter where you use it on the planet. We have found the “Common User Access” (CUA) standards developed by IBM excellent for screen design. Beyond this, consideration should be given to all inputs and outputs, including forms, reports, messages and Help text.

The biggest problem in making universal systems is that programmers tend to bury too many of the details of a system down in the program source code, which is not a good place to tinker around in. Instead, certain elements of the system should be placed in separate files thereby making it convenient to translate. Consideration should be given to creating separate files for:

* PRINT MAPS – An output, such as a report or printout, can be decomposed into various sections. When a program is executed, one of the parameters should be the desired language (e.g., English, Spanish, German, French, Japanese, etc.). Based on this, pertinent print maps are called from the “Print Map File” to assemble the requested output.

* SCREEN PANELS – This is similar to the “Print Map File” whereby the sections or a screen can be decomposed into its various panels. As a program is executed, pertinent panels are called from the “Panel File” to build the screen.

* MESSAGES – Messages are too often buried in source code. Instead, they should be placed in a separate file for printing or display in a screen.

* HELP TEXT – Help text should also be maintained separately for easy retrieval based on the selected language.

Separating Maps, Panels, Messages, and Help text from program source code, makes it easy to translate to foreign languages. Further, it encourages developers to share and re-use resources, thereby contributing to integrated systems and expediting development.

A serious consideration in the Far-East is the Double Byte Character Set or DBCS which is used to accommodate Japanese and Chinese Character alphabets with voluminous characters. To construct one such character, two bytes must be stored in a single byte (hence the name “DBCS”). Fortunately, the technology has evolved and DBCS is implemented in most operating systems today. However, developers should be cognizant of this requirement, particularly as they are designing Inputs, Outputs, and Files. Check with your hardware or operating system vendors for specifics. Better yet, check it out on the Internet.

INPUT/OUTPUT DESIGN

During design of the Inputs and Outputs, consideration should be given to the expression of certain types of data elements; for example:

* DATES – How dates are to be expressed may vary from country to country; for example: Nov 13, 2014 – 13 Nov, 2014 – 2014-11-13. How a date is presented to an end-user is different than how it is physically stored.

* TIME – This is similar to dates; some people like to see AM/PM, others like military time, e.g., 14:30 (2:30pm)

NOTE: Regardless of how Dates and Times are to be physically presented to the user, standards should exist to express how dates are to be physically stored, such as “YYYYMMDDHHMMSS” (Year/Month/Day/Hour/Minute/Second). Failure to do so caused the horrendous Year 2000 (Y2K) problem years ago.

* TIME ZONE – Representing local time.

* CURRENCY – What form of monetary values should be expressed; Dollars, Yen, Pounds, Euro Dollars?

* MEASUREMENTS – Accommodate different units of measures for weights (pounds vs. grams), distances (miles vs. meters), and temperatures (Fahrenheit vs. Centigrade).

* TEXT – The Western world prefers viewing text horizontally from left-to-right, but as we go into the Eastern countries, they like to see text vertically, sometimes right-to-left.

Many operating systems today provide the means to capture such settings. However, it might be necessary to establish a separate “Personal Settings File” for a particular Information System.

Attention should also be given to DEFAULT settings, particularly at time of input. Further, where applicable, consider auto “UPSHIFTING” or “downshifting” text as needed. For example, most Internet addresses (such as a URL or e-mail address) should be downshifted.

The techniques mentioned above are simple and effective to implement. It is important that a translation strategy be considered as part of the system design. During design, your mantra should be “Know your audience; make it usable; and think Global.”

NOTE: This paper is excerpted from the “PRIDE” Methodologies for IRM at:
http://www.amazon.com/PRIDE-Methodologies-IRM-Tim-Bryce/dp/097861822X

Originally published: 12/20/2004 (with additional text added)

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 © 2014 by Tim Bryce. All rights reserved.

NEXT UP:  WHERE DO WE GET OUR NEWS FROM? – Is it about accessibility or reliability? Or does anyone care anymore?

LAST TIME:  D-DAY +70 YEARS – WE WILL ALWAYS REMEMBER  – A tribute to our Normandy vets, and a history lesson for our youth.

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.

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

PRE OR POST DOCUMENTATION, WHICH DO YOU PREFER?

Posted by Tim Bryce on May 19, 2014

BRYCE ON SYSTEMS

– Documentation is a working tool and a byproduct of design. – Bryce’s Law

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

In addition to my essays, I have written a considerable amount of documentation for business and systems over the years; everything from Policy Manuals and proposals, to Feasibility Studies, Systems Documentation, Test Plans, software specifications, User Manuals, and Audits for systems and projects. I find such work relatively easy, but I am always amazed by those clients who really do not grasp the significance of technical documentation. It is not uncommon to be asked to come in afterwards and provide a description of the newly created system and software. This is considered post-documentation whereby you test the system to see what it is capable of doing, and writing the supporting documentation.

I have always considered post-documentation to be backwards. It is analogous to asking an architect to draw the blueprints of a skyscraper after it has been built. In other words, I’m a proponent of pre-documentation whereby flowcharts and text are used to record design decisions in the same manner as architects and engineers, in layers whereby you go top-down from the general to the specific. Under this approach, your documentation is completed before programmers begin to write the source code. The same is true where the architect finishes the blueprints before digging the first shovel of dirt. Call me old-fashioned, but I have never seen this approach fail.

Some programmers consider documentation a waste of time (see “Agile programming”), even going so far as to claim it is detrimental to productivity. Instead of getting all the software specifications recorded on paper at the start, they prefer to begin hacking on the program code and keep modifying it until the end-user is satisfied. Someone is then called in to figure out what the software does and write the documentation (post-doc).

Imagine two separate software project teams given the same assignment, one uses a pre-documentation approach, the other post-documentation. From start-to-end, which team do you believe will finish first? The pre-doc group will seem to take considerable time up-front documenting the specifications. However, the programmers should spend nominal time interpreting the specs and writing the programs. When the programming is done, the project is done as the documentation was completed beforehand.

In contrast, the post-doc group will begin programming almost immediately. Yet, because the specifications were incomplete and fraught with misinterpretations, they will inevitably have to rewrite the programs over and over again until they produce something remotely usable to the customer. Finally, they call in someone to write the documentation.

Obviously, the post-doc approach represents a more costly expenditure requiring more time to complete. Programmers appreciate the need for documentation but rationalize, “We do not have time to do it right.” Translation: “We have plenty of time to do it wrong.” Consequently, they abhor the concept of documentation in any form and resist any and all attempts for them to produce it.

The one axiom programmers cannot deny is, “Good specifications will always improve programmer productivity far better than any programming tool or technique.”

I guess I should be thankful for those embracing post-documentation. If everyone was doing it properly, I wouldn’t have too many technical writing opportunities.

“No amount of elegant programming or technology will solve a problem if it is improperly specified or understood to begin with.”
– Bryce’s Law

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 © 2014 by Tim Bryce. All rights reserved.

NEXT UP:  EVALUATING EMPLOYEES AND MANAGEMENT – Two valuable forms for evaluating both management and the workers.

LAST TIME:  SCIENTIFIC FLIP-FLOPS  – What is good for us? Scientists really do not know.

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.

Posted in Business, Software, Systems | Tagged: , , , , | 7 Comments »

THE TRUTH ABOUT PROJECT MANAGEMENT PACKAGES

Posted by Tim Bryce on February 17, 2014

BRYCE ON MANAGEMENT

– Do they truly support project management or are they glorified punch clocks?

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

I was recently researching project management software for a client. Such software is certainly not new and can be traced back to their origins in the 1960’s with mainframe based packages. Some of the earliest applications of computers in the 1950’s were for such purposes, particularly estimating and scheduling. Nonetheless, I was looking for a PC based package that could also be implemented on smart phones, and geared to reporting an employee’s time. Frankly, I was disappointed with what I found.

I looked at dozens of packages, some free, others for a price; some were PC based, others were “cloud” based, and some were implemented over the Internet. The graphical input was easy on the eyes, but virtually none could implement what I was looking for, regardless of how well they were evaluated by software researchers. Frankly, I think they were looking at the wrong features. Instead of determining their suitability for project management, they only consider the programming, and by doing so, they have missed the boat.

The biggest problem I saw was they all supported the concept of “Man Hours,” which has long been considered a fallacious concept in project management circles. “Man Hours” is nothing more than “Elapsed Time” which doesn’t consider how time is utilized, for example, real work (Direct time) versus interferences (Indirect time). The differences are important. Since Direct time represents worker effort, it should be up to the worker to estimate and control. Indirect time keeps the worker away from his/her assignments and, as such, is up to the manager to control. The analysis of time in this regard is considered an “Availability Rate” matching the Indirect time against the total available time. Office workers typically have a rate of 70% (approximately 5.6 Direct hours in a business day), and construction workers typically have a rate of 20% (approximately two direct hours in a day). By analyzing time this way, more realistic project estimates and schedules can be calculated. As an aside, in no way should Availability Rate be considered a measure of productivity or efficiency; it is nothing more than an analysis of the use of time.

This concept originated from the construction industry back in the 1950’s. As simple and effective as it is, virtually none of the software products I studied took this into consideration, consequently they deal only in “Man Hours” and I suspect their customer’s ability to complete project assignments on time is weak. Further, by not distinguishing the differences between Direct and Indirect, it is likely their customers are micromanaging their workers. In other words, workers are managed top-down, not bottom-up where worker input is used to formulate estimates and schedules.

I also observed some of the packages clung to the concept of “percent complete” for a given task, another fallacious concept. Instead of asking workers the amount of time remaining on a task, they are asked to input the duration of the task thus far. As history shows us, even if a task is 99% complete, the last one percent can seemingly take an eternity. For more information on this, see “Estimate to Do versus Percent Complete.”

Again, all of the project management packages I researched looked slick, but virtually none could solve true project management problems. As such, they were nothing but glorified punch clocks. I find it rather ironic that despite the advances we have made in computing, perhaps the best approach to project management is a paper based solution. I guess I’ll just have to keep looking.

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 © 2014 by Tim Bryce. All rights reserved.

NEXT UP:  THE MYTH OF EQUAL PAY – In capitalism, there is no such thing; it’s what the market bears.

LAST TIME:  WHAT’S IN A NAME: TOILETS  – 15 interpretations for the same thing.

Listen to Tim on WJTN-AM (News Talk 1240) “The Town Square” with host John Siggins (Mon, Wed, Fri, 12:30-3:00pm Eastern), KIT-AM 1280 in Yakima, Washington “The Morning News” with hosts Dave Ettl & Lance Tormey (weekdays. 6:00-9:00am Pacific), and KGAB-AM (650) of Cheyenne, Wyoming. Or tune-in to Tim’s channel on YouTube.

Posted in Management, Project Management, Software, Technology | Tagged: , , , , | 4 Comments »

« Previous Entries
 
%d bloggers like this: