People ask me why I seem to be “black and white” on so many issues. Two reasons come to mind: first, I learned early in school that you do not get credit for making a mistake. If this has changed, please let me know. Second, the nature of my work in the information systems world has taught me there are right ways of doing things, as well as wrong ways. I am also not embarrassed to admit, “I do not know,” when I am unsure of myself, and will endeavor to find the answer. Failure to admit this is a sign of weakness, as is fabricating an excuse or leading someone down the wrong path.
In the many industries I have consulted with, I have learned there are right ways and wrong ways for conducting business:
* In manufacturing, there are defined methodologies for assembling just about any type of product, be it electronics, automobiles, ships, jet engines, or jets themselves. If the manufacturing sequence is not performed correctly, quality will suffer and defects will likely ensue.
* In the restaurant business, there are defined methodologies for cooking and customer service. If the cook mixes up the sequence of the recipe, believe me, you won’t want to eat it.
* The construction industry is no different. Regardless of what you are building, there is a defined sequence of tasks. As a hint, when you are building a house, it is generally a good idea to lay the foundation before you start constructing the roof.
* In information systems, you better have a clear understanding of the information requirements before designing the business processes, data base, work flows, and software. Unfortunately, most systems projects are doomed from the outset as they skip over requirements and begin to program almost immediately.
The lesson here is simple; if you perform the wrong task at the wrong time in a methodology, you are doomed. As any craftsman can tell you, it is not so much about the tools you use as it is about the methodology. Skipping steps represents a calculated risk to the success of a project. Believe it or not, people in the systems field fail to comprehend this simple concept. They are convinced specifying requirements and performing the steps for design is a colossal waste of time, with the the real work being in programming. This is like suggesting we build a bridge without first studying the problem and laying out the architectural plans; that the builders should show up at the job site and begin hammering and cutting the pieces of the bridge together without a set of blueprints. Let’s face it, if we built bridges in the same manner as we build systems in this country, this would be a nation run by ferryboats.
There is a science to building just about anything, be it a skyscraper, a bridge, an automobile, or an information system. It is all based on proven principles of design, it is hardly an artistic endeavor. This is not to suggest design is void of creativity; hardly, but a science is teachable and does not rely on a person’s intuition. Basically, it requires discipline which is something sorely lacking in the IT industry where people prefer “shooting from the hip” as opposed to learning the proper mechanics of a methodology.
As an aside, I have a friend in the art world who teaches illustration at a Midwest College. He too appreciates the need for methodology. As he adamantly instructs his students, it is not simply about starting to draw an illustration using paper and pencil, but the necessary steps for producing a proper graphic. So you see, even in the artwork there are “right” ways and “wrong” ways for doing something. It’s called a “methodology.”
Yes, it really is that “black and white.” Next question?
Keep the Faith!
Note: All trademarks both marked and unmarked belong to their respective companies.
Author: 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 [email protected]
For Tim’s columns, see: timbryce.com
Copyright © 2015 by Tim Bryce. All rights reserved.