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 2,064 other followers


  • "BRYCE's UNCOMMON SENSE SERIES"
    4 New Printed Books & eBooks from Tim on:
    Change/Technology, Management, Politics, and the American Scene
    Click HERE.

  • Categories

  • Fan Page

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

    Follow me on Twitter: @timbryce

    hit counter

     

  • Subscribe

WHO IS DESIGNING YOUR SYSTEMS?

Posted by Tim Bryce on July 14, 2014

BRYCE ON SYSTEMS

– Hopefully not your programmers.

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

I have seen a lot of Information Systems in my lifetime. Most are rather simple if you take the time to study the problem, and create the logical design, then determine the most suitable physical implementation and develop the specifications for the software and manual steps. It’s actually a rather simple process, regardless of the intricacies of the data involved.

Problems arise though when the critical front-end work is performed by programmers who are more in tune with technology than business. From their perspective, they see everything in terms of zeroes and ones, not in dollars and cents. Not surprising, they only think in terms of elegant technical solutions, not necessarily what is practical from a business perspective. Let me give you two stories to illustrate my point.

First, we had a large manufacturing customer who designed a new “state-of-the-art” shop-floor control system whereby they wanted to spot errors along the assembly line and then quickly correct the hiccup. From a software perspective, it was a well thought-out and elegant solution coupled with an integrated data base. There was just one problem; it didn’t work. Consequently, we were called in on a consulting basis to try and determine what was wrong. We carefully examined the architecture of the system overall, not just the software components, and quickly found the problem; Whenever an error occurred on the shop-floor, an error message was displayed on a computer screen for the shop-floor supervisor to act on. Unfortunately, nobody instructed the supervisor about the computer screen, the messages, or procedurally how to respond to them. We wrote a simple administrative procedure for the supervisor who then read and responded to the errors properly and the system ran perfectly.

The programmers of the system were thunderstruck as to how quickly we found the problem and devised such a simple solution. They were convinced something was wrong with the logic of the software and focused their energies there to find the problem. In contrast, we stepped back and looked at the overall system architecture and found the problem in the basic design of the system.

Then there is the story of how simple data calculations can upset systems. Les Matthies, the legendary Dean of Systems, was fond of telling this story:

According to Les, a widow one day received a bill in the mail that read:

FIRST NOTICE – You are in arrears in the amount of $0.00, please make restitution as soon as possible. Have a nice day.

“This is stupid,” she thought to herself, and discarded the bill.

One month later, she received another bill from the same company:

SECOND NOTICE – You are in arrears in the amount of $0.00; to avoid problems, please make restitution as soon as possible.

Again, she thought this was silly and discarded the bill.

One month later, she received yet another bill from the same company:

THIRD AND FINAL NOTICE – You are in arrears in the amount of $0.00. If you do not make restitution as soon as possible, we will be forced to turn this matter over to our bill collectors.

Although she still thought it was ridiculous, the widow didn’t want any trouble, nor did she want a blemish on her credit report. Consequently, she wrote a check to the company in the amount of $0.00.

“There, that should take care of the problem,” or so she thought.

One month later, she received a form letter from the company:

Thank you for your recent payment of $0.00. However, you failed to pay the interest penalty of $0.00 …

Although Les loved to tell this as a system parable, there are many instances of such miscalculations in corporate systems which ultimately drive end-users bananas, for two reasons; lack of adequate system testing, and because of the focus on programming as opposed to systems.

Whenever systems are designed by programmers, you will likely see:

* Poorly defined information requirements as programmers are not trained in how to study the actions and decisions of the business, only computing requirements.

* Superficial data definitions thereby resulting in erroneous information, not to mention considerable data redundancy.

* Lack of documentation defining the overall system architecture, just basic programming specifications.

* Insufficient design reviews and testing which leads to product defects thereby causing problems in quality.

* Project Management delays and cost overruns as many parts of the system have to be redeveloped due to the lack of the other elements mentioned herein.

To prove my point, ask your systems people to design a manually implemented system. If they cannot, they are programmers and should not be serving as a systems analyst. As I keep insisting, it is not that system design projects are complicated, it’s because we have the wrong people trying to perform the task. As a perfect example, consider the recent Obamacare system which was delivered late, was fraught with bugs, and cost the taxpayers well over $600 million, an outrageous amount of money.

What this points out is there are significant differences between systems analysts and programmers. Their emphasis and interests are simply different. Whereas the analyst is more of a generalist who understands business, the programmer is rightfully more in tune with technical detail. One tends to be an extrovert, the other is an introvert. The interests and skill sets are simply different. It is difficult, if not impossible to do one, when you are a master of the other; they are that different.

To illustrate, we have always subscribed to the following formula:

Good Systems Design + Good Programming = Great Systems

Good Systems Design + Bad Programming = Good Systems (it may not be elegant, but it serves the business needs)

Bad Systems Design + Good Programming = Bad Systems

Bad Systems Design + Bad Programming = Chaos

The common denominator for success is “Good Systems Design” which happens to be an area most companies neglect. Consequently, programmers are asked to compensate for poor specifications.

“If we built bridges the same way we build systems in this country, this would be a nation run by ferryboats.” – 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:  OBAMA’S SCORECARD – An excellent representation of the president’s record.

LAST TIME:  SOME MORE CULTURAL CHANGES  – Strange things affecting our culture.

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.

Advertisements

3 Responses to “WHO IS DESIGNING YOUR SYSTEMS?”

  1. Tim Bryce said

    A K.K. of Hudson, Quebec, Canada wrote…

    “I suppose it would not hurt to render explicit “Good User Interface” to give “Good Systems Design + Good Programming + Good User Interface = Great Systems”.

    We see lots of Good System Designs with poor User Interfaces.

    A “poor” UI is one that users refuse to use.

    Sometimes the UI is ok but the implementers simply fail to show the users how it makes things easier for them to do their work and get them on board.

    If the users are not on board, then a Great System is likely to fail.”

    Like

  2. Tim Bryce said

    An M.M. of Romania wrote…

    “Excellent, Tim! Your article is the best. Hopefully businesses will understand why they have to pay enormous consulting fees to system vendors for implementation. Also, the system vendors who keep using programmers instead of business process generalists for system analysis.

    The ideal for a business (Good Systems Design + Good Programming = Great Systems) is guaranteed if “the generalist that understands business”, as a Project Manager who’s delivered the good system design, stays in charge for leading the programming too.

    Actually, designing a business information system is just part of the business process (re)design”

    Like

  3. […] WHO IS DESIGNING YOUR SYSTEMS? […]

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: