January 30, 2006

"TESTING 1, 2, 3"

Not long ago you heard me whine about how poorly commercial software is being tested by the major vendors. Normally, shoddy workmanship results in clients distrusting the products and vendors. Surprisingly, this is not the case in the IT Industry. Instead of holding vendors accountable by their customers, sloppy workmanship has become an acceptable form of behavior in this field.

Let me share with you the standard approach to testing as used by today's software companies:

1. Announce a general release of the product to the press.
2. Write a section of code and test/debug it.
3. Assemble the code and issue it to customers in "Beta" form.
4. Let the customers play with it and report problems as they occur.
5. From this, the vendor develops and prioritizes a punchlist of corrections.
6. The punchlist is addressed with the product delivery date in mind.
7. The first release of the product is issued with much fanfare (even though the punchlist has not been fully corrected).
8. More errors are reported by the customer base and added to the punchlist.
9. The second release of the product is issued as a fixpak. This release, in reality, represents the finished product.

The intent of beta code is more for public relations and publicity as opposed to delivering a viable product offering. Instead of thoroughly testing their products themselves, vendors let their customers do it for them. It shouldn't be this way.

I don't have a problem with the beta-test concept as such, so long as the vendor has legitimately tested the product themselves prior to issuing the release. They're not. Is it that they are incapable of testing it themselves? Maybe. Most likely though, it is cheaper to have outsiders test it for them. However, beta testing represents a disorganized test of the product. Something much more structured should be done prior to this by the vendor.

As we have discussed on more than one occasion, a system is a product that can be engineered and manufactured like any other product. Let's think about the design of a product, such as an automobile. The overall product is first broken down into a series of assemblies, such as the chassis, body, engine, drive train, and so on. Each assembly is then "exploded" (or sub-divided) into subassemblies, and components.

After the product has been decomposed top-down into its assemblies, parallel teams of designers concurrently refine their portion of the product with little interaction between assembly design teams.

Parts such as nuts and bolts are carefully identified, classified, and reused not only within the product but with other products. One classic example of this is years ago when General Motors was able to slip a Pontiac Engine into an Oldsmobile. This demonstrated the power of standardization and the reusability of parts.

After a product has been fully designed, the product assembly line "implodes" the product (bottom-up) with components making up subassemblies, and then the subassemblies into assemblies, and then assemblies into the final product. Again, think about the assembly line for automobiles where the pieces and parts of the car are built in smaller increments until the final assemblies are put together and the key is turned and the car is driven off the assembly line.

This approach to product design is obviously an old one, but it can be easily adapted to the design and development of an information system.

Under "PRIDE"-ISEM an information system is a 4-level hierarchical structure consisting of the system (representing the product) which is decomposed into sub-systems representing business processes. Each sub-system is divided into procedures (both administrative and computer). Administrative procedures are broken into operational steps or manual tasks. Computer procedures are broken into programs.

As in the product analogy, the system is designed top-down into sub-systems. Once this has been done, parallel teams of designers can work concurrently developing separate sub-systems.

When the final pieces and parts have been designed, they are developed and tested "bottom-up." For example, unit tests are performed on programs, a string test of the programs within a computer procedure is then performed; this is followed by a test of all of the procedures in each sub-system, and finally parallel testing of all of the sub-systems in the system is performed. If successful, the key is turned and the car is driven off of the assembly line.

The so-called "parts" of the system-product are the data components representing data elements, records, and files. Like product parts, the data resources should be carefully identified, classified, and reused not only within the system, but with other systems, thereby promoting integration.

The point is, like products, systems are designed by explosion (top-down if you will) and tested and implemented by implosion (or bottom-up).

The early phases of "PRIDE"-ISEM are primarily used to design the system into refined components. They are also used to specify the testing criteria for the later phases; to illustrate.

PHASE 2 - SYSTEM DESIGN - The Test Plan at this level will be used later in Phase 8 and should cover how parallel testing of the sub-systems should be performed. Key file maintenance sub-systems should be tested and installed prior to simple "read-only" sub-systems.

PHASE 3 - SUB-SYSTEM DESIGN - The Test Plan at this level will be used later in Phase 7 and should address human/machine interaction. Since inputs and outputs should be fully defined by this phase, the Test Plan should include:

- Design standards to be observed for Graphical User Interfaces and report layouts. This includes the use of Help text.
- Default values and validation rules for collecting data.
- Ease of use (intuitiveness).
- The processing of optional parameters.
- Verify the overall processing logic.
- Benchmark tests.

PHASE 4-II - SOFTWARE ENGINEERING - The Test Plan at this level will be used later in Phase 6 and should check operational dependencies between programs and stress testing. Input/File/Output layouts should be verified as well as volume testing. The assemblage of test data should be included.

BOTTOM-UP TESTING

The remaining phases in "PRIDE"-ISEM are used to test the system from the bottom-up.

PHASE 5 - SOFTWARE MANUFACTURING - Following the production of the executable program, the programmer assembles pertinent test data to test and debug the individual program. To do so, the programmer consults the Test Plan, Program Specifications, and pertinent Software Structure Diagrams resulting from Phase 4-II. This becomes the "roadmap" for testing the program.

There are a variety of testing and debugging tools available on the market. Use of such tools should be encouraged.

When the program has been tested to the satisfaction of the programmer, the results are reviewed with the computer procedure designer and Quality Assurance. This review assures that all standards have been followed, and the program has been tested to conform to specifications. The test data is saved for later reference and the test results are filed for future reference.

PHASE 6 - SOFTWARE TESTING - The purpose of this phase is to test and correct errors in the overall computer procedure. This is sometimes called a "string test," "job stream test," or "stress test." Whereas the "unit test" performed in Phase 5 was concerned with data format, the emphasis in Phase 6 is on volume testing.

It is the objective of the Computer Procedure Designer to assure that the procedure meets the sub-system specifications. In addition to testing for correct processing logic, they also check the operational considerations of timing, re-start, etc.

Following testing, the results are reviewed with Quality Assurance and the Sub-System Designer. This assures compliance with all standards and that the Sub-System requirements are met. When the testing is satisfactorily accomplished, the test data is filed for future reference.

PHASE 7 - SUB-SYSTEM TEST - Testing in Phase 7 is performed in a similar manner as in Phase 6, except at a higher level. Whereas Phase 6 "Software Testing," is performed by Software Engineering for all of the programs within the computer procedure, Phase 7 is performed by Systems Engineering for all of the procedures in the sub-system, both administrative and computer.

During Computer Procedure Design, Software Engineering prepared the computer procedure that will be used by DP Operations. In order to test this procedure, it is recommended that DP Operations actually perform the tests under Software Engineering's direction. In this way, the operating procedures are tested along with the programs used to implement the procedure. Often the operating people will point out areas for procedure improvement.

During Phase 3, Systems Engineering specified a testing criteria for the overall sub-system. This included the validation of input/output processing, along with anticipated transaction volume for the sub-system. Phase 7, therefore, is used to verify the test criteria and benchmarks.

Following Phase 7, the sub-system is essentially ready for operation. However, considerable care should be exercised to avoid a premature installation of the sub-system for day-to-day operation. This situation could cause panic conditions if other parts of the system are not ready. This is why Phase 8 is used to release sub-systems.

PHASE 8 - SYSTEM OPERATION - A final test of the system is performed where the various sub-systems are tested in parallel. This is similar to the testing in Phases 6 and 7, but at the highest level. It is not uncommon to invite user personnel and DP operations to participate in the test. The Administrative Procedure Manuals and Computer Run Books, as created in the various Phases 4-I's and 4-II's, are used as part of the formal walk-through. The test data as created in previous phases is assembled and used as the basis for the test. Where available, actual data should be tested to simulate actual system situations. If any errors are discovered, they are corrected immediately and testing is resumed. Changes to the sub-systems may also be proposed; however, these should be considered carefully. In some instances, it may be more appropriate to suspend any modifications or improvements temporarily until use of the new system has settled into routine operation.

CONCLUSION

Whether you use "PRIDE"-ISEM or not, the concept of defining refined levels of test plans "top-down", and performing corresponding tests "bottom-up" is a simple and effective approach. It offers a structure that is easy to manage and provides for a rigorous test of the system. Test data generators and debugging aids are useful and should be encouraged, but simple organization and a methodical approach to testing can have a more dramatic effect. Following this, if you still want to perform a beta test, you have my blessing.

Always remember this, most beta test programs are designed more for promoting the product as opposed to actually testing it. Think about it; its a "no-brainer" for the vendor. Customers begin to talk about the product while assuming the testing costs of the vendor. Even if something were to go wrong (and frequently does), the vendor is not liable and simply shrugs off the snafus due to beta code.

I used to beta-test software products for vendors, but I no longer have the time nor inclination to do the manufacturer's work for them anymore. Further, I no longer rush out to buy the latest release of "any" software product; I have been burned too many times by the vendors. As far as I'm concerned, the software vendors really need to clean up their act when it comes to testing. If they really want us to test their products for them, let us know where we should send the bill.

OUR BRYCE'S LAW OF THE WEEK therefore is...
"Most beta test programs are designed more for promoting the product as opposed to actually testing it."

IN OUR "DOWN THE ROAD" SECTION

A special conference entitled "Cincinnati Technology: the Next Generation" will be held on Saturday, February 18th at the Netherlands Hilton in downtown Cincinnati, OH. Among the speakers will be yours truly to discuss the "PRIDE" approach to Information Resource Management. For information or to register, contact the First Rule Group at 513/375-3291.

On March 6th-8th, the Gartner Business Intelligence Summit 2006 will be held at the Hyatt Regency in Chicago, IL. For info, contact Gartner at 203/316-6757

The 17th International Conference of the Information Resource Management Association will be held May 21st-24th at the Wyndham Hotel in Washington D.C. For information, call IRMA headquarters in PA at 717/533-8879

If you have got an upcoming IRM related event you want mentioned, please e-mail the date, time and location of the event to timb001@attglobal.net

MY "PET PEEVE OF THE WEEK" IS "AUTOMOTIVE REPAIRS"

Recently, I had to replace the battery in my GMC Envoy. I haven't had to replace a car battery in quite some time. Back in the 1970's when I worked at a gas station on my summer vacation from school it used to take me about 5-10 minutes to replace a battery. But this time it took me at least an hour to undo the safety box and bar around the battery and undo the cables which were strategically placed in an awkward position to make it as difficult as possible to use a wrench to unscrew the posts. I just couldn't get over how the car manufacturers have complicated such a simple and mundane task as changing a battery. Small wonder the dealerships are charging us excessively for repair work.

Another thing that bothers me is how the major automotive repair shops try to rip us off for excessive work. For example, I took my other car into a repair shop recently to have a headlight replaced. After the service shop looked it over, they called me with a long list of other items they wanted to replace, including shocks and tires. They were embarrassed when I told them I had both the shocks and the tires replaced just last year. As a consumer, I feel like I am being harvested every time I bring a car into these shops. Not only do they want to fix your immediate problem, but they go out of their way to find new ones. What bothers me is that many people fall for this old gag. What these service shops don't realize is that they are creating more distrust and suspicion than good service. It has taken me a long time to find a good mechanic that I trust and believe me, I have seen a lot of mechanics, most looking for nothing more than a quick buck. The guy I've got now knows his stuff and charges a fair price. And believe me, he is worth his weight in gold.

Such is my Pet Peeve of the Week.

AND FINALLY...

I received an e-mail from a Martin Dimond in Cincinnati who wrote me regarding last week's interview with Mike Snyder.
Martin writes:

"Mike mentioned the types of skills people need in the corporate IT world for Systems Development. Could you elaborate on this?"

Thanks Martin for your note,
Good question. Mike and I have talked about this at length. Basically, we see true systems people as somewhat extroverted in nature and programmers as introverted. A systems person is also more of a generalist who understand business and total systems. The programmer is more of a detailist and in tune with technology. Because the systems person is more related to people, he or she must have good interpersonal communication skills for such things as interviewing, making a presentation, and salesmanship. They also have to have good writing skills in order to develop proposals and record information requirements. They must also have basic business skills such as how to develop a cost/benefit analysis, return on investment, and calculating break even points, or being able to perform work measurement and work simplification. They also have to be able to effectively communicate systems requirements to the programmers. In this capacity, they play the role of translator.

Unfortunately, the schools are not producing such people. Instead, they are producing more and more technicians who have to be debriefed in order to make them productive in the workplace.

Interestingly, some of the best systems people I have met do not have a computer background and come from the fields of music, engineering, and library science; which are all creative fields based on discipline and organization. Also, I have found very few people who are both good at systems as well as programming. Each requires a different set of skills and perspective. Typically, a person is good at one job but not the other.

Again, Thanks for your e-mail. Keep those cards and letters coming.

Folks, don't forget to check out our BRYCE'S CRASH COURSE IN MANAGEMENT which is a free on-line multimedia presentation offering pragmatic advice on how to discharge the duties of a manager, whether it be for a commercial or non-profit enterprise. Frankly, for someone aspiring to be a manager or for a new manager, it will be the best 45 minutes you can invest in yourself. Check it out on the cover of our corporate web page at: http://www.phmainstreet.com/mba

For a complete listing of my essays, see the "PRIDE" Special Subject Bulletins section of our corporate web site.

MBA is an international management consulting firm specializing in Information Resource Management. We offer training, consulting, and writing services in the areas of Enterprise Engineering, Systems Engineering, Data Base Engineering, Project Management, Methodologies and Repositories. For information, call us at 727/786-4567.

Management Visions is a presentation of M. Bryce & Associates, a division of M&JB Investment Company of Palm Harbor, Florida, USA. The program is produced on a weekly basis and updated on Sundays. It is available in versions for RealPlayer, Microsoft Media Player, and MP3 suitable for Podcasting. See our web site for details. You'll find our broadcast listed in several Podcast and Internet Search engines, as well as Apples' iTunes.

If you have any questions or would like to be placed on our e-mailing list to receive notification of future broadcasts, please e-mail it to timb001@phmainstreet.com

We accept MP3 files with your voice for possible inclusion in the broadcast.

Management Visions accepts advertising. For rates, please contact yours truly directly.

Copyright © 2006 by M&JB Investment Company of Palm Harbor, Florida, USA. All rights reserved. "PRIDE" is the registered trademark of M&JB Investment Company.

Our corporate web page is at:

http://phmainstreet.com/mba/

This is Tim Bryce reporting.

Since 1971: "Software for the finest computer - the Mind."

END

January 23, 2006

"AN INTERVIEW WITH MIKE SNYDER"

Michael B. Snyder, a corporate management consultant originally from Connecticut who now resides on Anna Maria Island in Florida. I've known Mike professionally for a number of years. He has served in a wide variety of corporate I.T. positions over the last 30 years, everything from programmer to Project Manager to Systems Manager. Currently, Mike consults with major corporations in the New York area. This was an interesting interview where we covered a variety of topics, such as:

* How the I.T. industry has changed over the years.

* How the younger generation is being prepared to take over in application development.

* The short-term planning mentality in I.T.

* The state of Systems Methodologies.

* The cost of implementing changes to systems.

* The impact of requirements definition.

* How the universities are preparing the next generation of I.T. workers.

And much more. Mike's comments are always fresh, candid, and very insightful. Sit back and relax, I think you will enjoy this.

If you have a question for Mr. Snyder, you can contact him at: 941/932-5640 (repeat) or by dropping me a line at timb001@attglobal.net

IN OUR "DOWN THE ROAD" SECTION

A special conference entitled "Cincinnati Technology: the Next Generation" will be held on Saturday, February 18th at the Netherlands Hilton in downtown Cincinnati, OH. Among the speakers will be yours truly to discuss the "PRIDE" approach to Information Resource Management. For information or to register, contact the First Rule Group at 513/375-3291.

On March 6th-8th, the Gartner Business Intelligence Summit 2006 will be held at the Hyatt Regency in Chicago, IL. For info, contact Gartner at 203/316-6757

The 17th International Conference of the Information Resource Management Association will be held May 21st-24th at the Wyndham Hotel in Washington D.C. For information, call IRMA headquarters in PA at 717/533-8879

If you have got an upcoming IRM related event you want mentioned, please e-mail the date, time and location of the event to timb001@attglobal.net

MY "PET PEEVE OF THE WEEK" IS "HISTORY"

As a kid I always enjoyed History class. I guess I always found it interesting to see how events were triggered and could have been prevented or altered. I guess this is why I like the History Channel so much. But this love of history is not being passed on to our youth. The schools seem to be obsessed with either teaching the basics of reading, writing and arithmetic or indoctrinating our youth with the latest technology. Consequently, topics such as Public Speaking and History have fallen by the wayside. I guess its more important to know how to make an MS PowerPoint presentation than to know how to effectively communicate with people or understand how Churchill forged an alliance with the United States in order to save freedom in Europe, or why Truman relieved MacArthur, and why we failed at the Bay of Pigs, etc. These are all important lessons, yet our youth learns nothing about them which is resulting in a generation with absolutely no sense of history.

Even more disturbing is that there is no sense of history in the corporate workplace either. Young people are not questioning their work environment or the evolution of their products and services anymore. This is very apparent in the Systems world. Let me give you some examples; programmers don't understand the evolution of programming languages, from the 1st GL (Machine Language), to 2nd GL (Assembly Language), to 3rd GL (Procedural Languages), and to 4th GL (Specification Languages). Nor are they aware of the evolution of design techniques, such as structured programming, and object oriented programming. Consequently, they do not properly understand the philosophy of programming. Nor do people understand how and why data base concepts evolved, such as the hierarchical model as used in IBM's IMS, to the CODASYL standard network model, to relational, and object oriented. For systems, they have no concept of the Systems and Procedures Departments of yesteryear with their process diagrams and techniques in work simplification, to the introduction of modern methodologies. But even more disturbing than all of this is the failure of management in Information Technology, whereas in yesteryear companies boldly tackled mammoth systems projects, today they are content with simple programming assignments.

In 2006 we are celebrating the 35th anniversary of the introduction of the "PRIDE" methodology. We have seen a lot over the last 35 years; we have seen a raft of methodologies come and go, we have seen numerous data dictionaries and repositories, CASE tools and countless application development aids (anyone remember AD/Cycle?) Interestingly, the problems we face today in I.T. are essentially no different than when "PRIDE" was first introduced in 1971 - Systems lack integration, we rarely share and reuse information resources, redundancy issues remain, nothing is documented, and projects are still late and over-budget. You would think that after 35 years, the industry would wise-up a little. Instead of trying to take a tool oriented approach to solving our problems, how about trying a management approach? As we all know, "If we fail to learn from the past, we are doomed to repeat it." The Information Technology industry will continue to struggle until such time as it standardizes their terms and applies a scientific method to solving their systems problems. All it takes is a little sense of history.

Such is my Pet Peeve of the Week.

AND FINALLY...

I received an e-mail from a Judy Thurman in New Jersey who wrote me regarding last week's essay on "Systems: What's in a Word?"
Judy writes:

"I liked your formulas of: Good Systems Design + Good Programming = Great Systems
Good Systems Design + Bad Programming = Good Systems
Bad Systems Design + Good Programming = Bad Systems
Bad Systems Design + Bad Programming = Chaos

It stresses the need for the upfront systems work, something that is sorely needed. Why do companies resist Systems Design?"

Thanks Judy for your note,
Management today naively believes application developers are not being productive unless they are programming. Consequently, there are many Software Engineers out there but very few Systems Engineers anymore. Frankly, Systems Analysis and Design is considered "old hat" by today's I.T. management.

Some time ago, our Japanese representatives taught me an interesting concept regarding the cost of development; they demonstrated it by drawing two pyramids, one regular and another inverted, both drawn with a horizontal line in the middle of each. The top portion of the pyramid represents systems design, the bottom portion represents programming. The regular pyramid represents the state of application development as it is today, where we do a superficial job in systems design and spend an inordinate amount of time and money in programming. The Japanese contend the bottom of the pyramid is actually bottomless. In contrast, the inverted pyramid represents how development should be performed, with more emphasis on design resulting in superior specifications for programmers to implement. But to pull this scenario off, I.T. management has to have a true understanding of systems, unfortunately that is not the case today.

Again, Thanks for your e-mail. Keep those cards and letters coming.

Folks, don't forget to check out our BRYCE'S CRASH COURSE IN MANAGEMENT which is a free on-line multimedia presentation offering pragmatic advice on how to discharge the duties of a manager, whether it be for a commercial or non-profit enterprise. Frankly, for someone aspiring to be a manager or for a new manager, it will be the best 45 minutes you can invest in yourself. Check it out on the cover of our corporate web page at: http://www.phmainstreet.com/mba

For a complete listing of my essays, see the "PRIDE" Special Subject Bulletins section of our corporate web site.

MBA is an international management consulting firm specializing in Information Resource Management. We offer training, consulting, and writing services in the areas of Enterprise Engineering, Systems Engineering, Data Base Engineering, Project Management, Methodologies and Repositories. For information, call us at 727/786-4567.

Management Visions is a presentation of M. Bryce & Associates, a division of M&JB Investment Company of Palm Harbor, Florida, USA. The program is produced on a weekly basis and updated on Sundays. It is available in versions for RealPlayer, Microsoft Media Player, and MP3 suitable for Podcasting. See our web site for details. You'll find our broadcast listed in several Podcast and Internet Search engines, as well as Apples' iTunes.

If you have any questions or would like to be placed on our e-mailing list to receive notification of future broadcasts, please e-mail it to timb001@attglobal.net

We accept MP3 files with your voice for possible inclusion in the broadcast.

Management Visions accepts advertising. For rates, please contact yours truly directly.

Copyright © 2006 by M&JB Investment Company of Palm Harbor, Florida, USA. All rights reserved. "PRIDE" is the registered trademark of M&JB Investment Company.

Our corporate web page is at:

http://phmainstreet.com/mba/

This is Tim Bryce reporting.

Since 1971: "Software for the finest computer - the Mind."

END

January 16, 2006

"SYSTEMS: WHAT'S IN A WORD?"

What's in a word? Plenty. One of the most troublesome words used in our field is the word "System." What's so troublesome? Doesn't everyone know what an Information System is? Maybe the obvious isn't as obvious as you might think.

Let's begin with a definition:

An Information System is a prescribed set of processes operating routinely to produce information for users to fulfill business actions and decisions. Information Systems are used to pay employees, manage finances, manufacture products, monitor and control production, forecast trends, process customer orders, etc. These are all excellent examples of how systems support information requirements.

But what is a Computer System? What does it produce? Information about computers? Or, are we merely trying to describe how a system was implemented? I beg the issue as to what is more important; the system or how it was implemented? To many in the field, implementation is more important than what is being implemented. Many also believe the word "application" is synonymous with the word "system." Think about it. What does the word "application" really mean? It has come to mean the application of the computer to some task within an overall Information System. It could be just a small portion of the system, perhaps just a single program.

Recently we were involved with a large aerospace and electronics conglomerate who was trying to develop a complete business systems architecture. Obviously, this requires a well thought out systems oriented methodology and IRM Repository to define and maintain the information resources to be built.

Unfortunately, the company's I.T. organization had been engrossed in the use of CASE tools and had come to the erroneous conclusion that software engineering was no different than systems engineering. Because of this, they convinced management that this programming approach, coupled with a consultant conversant with the technology, will be able to achieve their business systems goal. This is a classic example of a tool oriented approach as opposed to a management oriented approach to solving systems problems. What is more disturbing is this has become more prevalent in today's corporate world.

Software is obviously the opposite of "hardware". Software is machine processable instructions permitting the hardware to perform specific functions. Software has the same relationship to systems as robots have to a manufacturing process. Even if the robot performs properly or a program executes correctly, it does not necessarily mean you are producing anything worthwhile. What is more important in this situation is whether the logical system design is correct or not. We have always subscribed to the following formulas:

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

The physical implementation can be less than perfect and you can still produce good results; it may not be the most elegant technologically, but it does solve the business problem adequately. Vise versa is not true. Also remember that a system can be implemented manually and, in many cases, manual implementation of certain business processes is still a cost effective alternative.

The intent of CASE tools is to build "software," not "systems." They are particularly well suited for organizing programming specifications and producing the software. CASE tools include diagramming aids, screen prototyping aids, program generators, and test/debugging aids. But make no mistake about it, they do not alleviate the need for the important up-front systems work. In fact, most CASE tools acknowledge and support the need for the proper front-end systems design. However, when you're obsessed with a particular technology, as the aerospace and electronics company was, you tend to lose objectivity and begin to believe the tool can work miracles.

"Systems" and "software" are as dissimilar as "information" and "data" (which represents another point of mass confusion). It is like comparing apples with oranges. As such, CASE tools are an "ineffective" way to perform true systems work and a misapplication of the tool. We have no problem with their use (in fact we applaud the developments in this area) but we balk at their use where they are not suited.

So how do you know if your I.T. department is overtly software oriented? Look for these simple signs:

* THERE IS A 2:1 RATIO OF SOFTWARE ENGINEERS TO SYSTEMS ENGINEERS

This is a classic sign. In fact, my ratio may be too modest. It is not uncommon to find shops where there is a 3:1, 4:1, or 5:1 ratio; or, even worse, no systems people at all.

What this means is that systems analysis is being performed at the wrong time. Instead of receiving meaningful design specs from a systems person, programmers must deduce requirements from cryptic notes). In other words, they are forced to do the systems design work backwards. Unfortunately, this approach leads to disjointed software that doesn't interface well with other programs.

This trend needs to be reversed. There should be at least a 2:1 ratio for systems engineers to programmers. The systems engineers should be viewed as the architects of the systems, laying out the blueprints for the carpenters (programmers) to implement. Better system designs (logical design) leads to better software specifications and physical design. Unfortunately, this type of person has historically been sacrificed by companies over the years in favor of hiring additional programmers. This leads us to the next sign...

* 85% OF THE TIME IN A DEVELOPMENT PROJECT IS SPENT IN PROGRAMMING

This is an environment where an inordinate emphasis is placed on software development (particularly coding and testing). I.T. management, under pressure to produce, forces a system through to programming before it is ready. Further, both I.T. management AND corporate management naively believe the development staff is not being productive unless they are programming. Consequently, the systems design work is sacrificed.

Naturally, the system, if it is ever finished, is fraught with errors and inconsistences requiring extensive maintenance. "Firefighting" thereby becomes the standard mode of operation.

* STILL USING THE CLASSICAL "5 STEP" APPROACH FOR SYSTEMS DEVELOPMENT

The same rudimentary approach taught to every student in college when they are learning programming (not systems) is still in vogue today:

I. Feasibility Study/Requirements Definition
II. Analysis/Design
III. Programming
IV. Testing/Implementation
V. Maintenance

This basic approach, which originated in the 1960's, is still prevalent today. It is often erroneously referred to as the "System Life Cycle." As we should all know by now, systems do not have a life cycle, only projects do. This is another example of the sloppy thinking persevering in our industry.

Admittedly, some form of methodology is better than none. Organization of any sort is better than sheer chaos. But when your methodology emphasizes software (as this one does) then true systems design work will be impaired.

Obviously, these "signs" are related to each other. Whenever you encounter them, you will probably find a company who has invested heavily in programming tools and training in the hopes a better mousetrap will somehow solve their problems. If a company has gotten too engrossed in their technology, they will inevitably lose sight of some very basic management concepts and systems principles.

SO, IS THERE A WAY OUT?

Of course there is. But it requires a change of perspective and culture. First, you have to recognize that a problem exists. There is an old adage in psychology stating, "You cannot treat a patient if he doesn't know he is sick." If the corporate culture is such that no one perceives a problem, particularly management, it is highly unlikely anything will ever change. Only after a few significant snafus does management typically perk up and pay attention, such as:

* Excessive overhead due to an overstocked inventory.
* Production slowdowns due to insufficient supplies.
* Loss of customer data (particularly orders).
* Customer service is impaired and complaints consequently arise.
* Billings or statements to customers fall behind in delivery thus affecting cash-flow.
* Financial data is improperly calculated (such as payroll, accounts receivables or accounts payables).
* Data bases are corrupted with erroneous or outdated data making its validity highly suspect.
* Strategic systems are never brought in on time or schedule.
* Automation is viewed as unreliable and the company reverts back to tried and proven manual procedures.

To pacify angered executives, I.T. management has historically applied superficial remedies, such as the acquisition of additional tools which offer the promise of improved results. As any surgeon will tell you, do not try to apply a band-aid when a tourniquet is required to stop the bleeding. If you are content with treating symptoms, the more severe problems will probably be overlooked.

What is necessary is to step back and take a new perspective on the problem. This can be extremely difficult for some people to do. It is not unusual for people to lose their objectivity when they have become too intimate with a problem, particularly technicians who tend to recommend a solution that is technically elegant, but not practical to implement. You need people who can get up on the mountain and see the whole picture. This is one reason why many Japanese companies use end-users to assume the role of I.T. Director. With no computer biases, they are able to bring pragmatic solutions to their systems management problems.
 

Let's take it a step further; there is a lot of discussion about the job titles used by today's development personnel. In the old days, we simply had "Systems Analysts" and "Programmers." This eventually gave way to "Software Engineer" which hints at the change of focus mentioned above. Today, there is a realization there should be someone concerned with the overall architecture of the corporate systems, hence the use of the title "Systems Architect" representing the successor to "Systems Analyst." I don't have a problem with this off-hand but, instead, opt to use the title "Systems Engineer" based on our observations of the engineering/manufacturing principles needed to design a system. Sorry, "Analyst/Programmers" do not qualify as systems engineers; they are still programmers in sheep's clothing.

The difference between the use of the title "Engineer" and "Architect" is minuscule in comparison to the use of "Systems" and "Software." Whereas the former is an argument of semantics, there are significant differences with the latter.

The skills required to perform "Systems Engineering" are distinctly different than "Software Engineering." True, both agree there are principles involved derived from engineering, but each has a separate focus and orientation. Whereas the "Systems Engineer" requires a more extroverted personality with people and business oriented skills, the "Software Engineer" tends to be more inclined towards an introverted personality with technical skills. Interestingly, there are few people who can adequately perform both job functions adequately. One person may be good in one and lousy in the other. Frankly, sharpening the skills in one tends to lessen the skills of the other.

Most people entering the I.T. field usually start out on the software side, then graduate to systems. Inevitably, they still see things through the eyes of the programmer. Then, as they are promoted to manager, they still have a programming perspective. Universities are essentially no different; their curriculum begins with software and ends in systems. What kind of focus does the student have at the end of their college career? That the only legitimate problems worth solving are those that can be conquered by technology, not by systems.

IN CONCLUSION

Over the last thirty years I have observed the subtle shift of the industry from systems to software. For example:

* We no longer talk about "M.I.S." or "I.S." but, rather "I.T."

* Publications such as "Infosystems" and the "EDP Analyzer" have been superseded by computer hardware/software rags.

* Industry associations have changed their focus, the classic example being the "Data Processing Management Association" (DPMA) renaming itself the "Association of Information Technology Professionals." Other groups, such as the Association of Systems Management (ASM) have gone the way of the dodo bird.

* The change in job titles as mentioned above.

Most of this can be attributed to sloppy terminology in the industry and marketing glitz. Regardless, we now have an industry with a focus on technology where we try to implement the latest technological innovation to our businesses (this is what I call the "solution looking for a problem" phenomenon or "cart before the horse"). Instead, a systems perspective defines the problem, then seeks a suitable and cost effective technical implementation. One drives the other. Which do you embrace?

Just remember, it is all a matter of perspective.

OUR BRYCE'S LAW OF THE WEEK therefore is...
"Do not try to apply a band-aid when a tourniquet is required to stop the bleeding."

IN OUR "DOWN THE ROAD" SECTION

The IT Executive Retreat will be held at the Don CeSar Beach Resort on St. Petersburg Beach in FL on January 23rd-24th. For information, call the IMF in Atlanta at 770/455-0070

A special seminar entitled "Cincinnati Technology: the Next Generation" will be held on Saturday, February 18th at the Netherlands Hilton in downtown Cincinnati, OH. Among the speakers will be yours truly to discuss the "PRIDE" approach to Information Resource Management. For information or to register, contact the First Rule Group at 513/375-3291.

On March 6th-8th, the Gartner Business Intelligence Summit 2006 will be held at the Hyatt Regency in Chicago, IL. For info, contact Gartner at 203/316-6757

The 17th International Conference of the Information Resource Management Association will be held May 21st-24th at the Wyndham Hotel in Washington D.C. For information, call IRMA headquarters in PA at 717/533-8879

If you have got an upcoming IRM related event you want mentioned, please e-mail the date, time and location of the event to timb001@attglobal.net

MY "PET PEEVE OF THE WEEK" IS "PROGRESS BARS"

You know, those annoying lines on your PC screen indicating that something is happening, like an upload or download, or the installation of a software package. I guess the idea is to demonstrate to you that something is actually happening on your machine and that you should be patient as it works. Gee, is it it just me or do you find these progress bars irritating as well? I always find it amusing when the progress bar runs rapidly through its completion rate of 25%, 50%, 75%, only to stop cold and get hung up at 99% with theoretically one second remaining to complete the task. That one second seems to take forever to complete. I think the worst offenders of such progress bars is Microsoft and AOL. Don't they have programmers who know how to calculate something as simple as completion times? I guess not. While the progress bar is running, how about entertaining us for awhile with either some multimedia presentation or some sort of text program. Knowing how long it takes to load Windows, I think "War and Peace" would be an easy read.

Such is my Pet Peeve of the Week.

AND FINALLY...

I received an e-mail from a Bernie DeMarco in Chicago who writes:

"I'm curious, why do you use Eric Copeland's 'Fanfare for the Common Man' as your opening theme?"

I guess I use it because it is symbolic of the need for providing advice for the common man. I am a believer in the dignity of the individual worker and that he/she should be treated fairly and respectfully regardless what their job might be. This is why our corporate slogan is 'Software for the finest computer - the mind' because, in the end, it is the human-being that has to make it all happen.

Again, Thanks for your e-mail. Keep those cards and letters coming.

The only other announcement I have is the release of a free new on-line multimedia presentation I've entitled, BRYCE'S CRASH COURSE IN MANAGEMENT which offers pragmatic advice on how to discharge the duties of a manager, whether it be for a commercial or non-profit enterprise. Frankly, for someone aspiring to be a manager or for a new manager, it will be the best 45 minutes you can invest in yourself. Check it out on the cover of our corporate web page at: http://www.phmainstreet.com/mba

For a complete listing of my essays, see the "PRIDE" Special Subject Bulletins section of our corporate web site.

Folks, In case you haven't heard, the "Management Visions" is now available in the MP3 file format suitable for Podcasting or other audio devices. It is also available in versions for RealPlayer and Microsoft Media Player. See our web site for details. You'll find our broadcast listed in several Podcast and Internet Search engines, as well as Apples' iTunes.

MBA is an international management consulting firm specializing in Information Resource Management. We offer training, consulting, and writing services in the areas of Enterprise Engineering, Systems Engineering, Data Base Engineering, Project Management, Methodologies and Repositories. For information, call us at 727/786-4567.

Management Visions is a presentation of M. Bryce & Associates, a division of M&JB Investment Company of Palm Harbor, Florida, USA. The program is produced on a weekly basis and updated on Sundays. If you have any questions or would like to be placed on our e-mailing list to receive notification of future broadcasts, please e-mail it to timb001@attglobal.net

We accept MP3 files with your voice for possible inclusion in the broadcast.

Management Visions accepts advertising. For rates, please contact yours truly directly.

Copyright © 2006 by M&JB Investment Company of Palm Harbor, Florida, USA. All rights reserved. "PRIDE" is the registered trademark of M&JB Investment Company.

Our corporate web page is at:

http://phmainstreet.com/mba/

This is Tim Bryce reporting.

Since 1971: "Software for the finest computer - the Mind."

END

January 9, 2006

"CRAFTSMANSHIP: THE MEANING OF LIFE"

When I entered the work force back in the mid-1970's it seemed everyone dressed in a suit and tie, drank black coffee, smoked their brains out, and worked their butts off. Today, golf shirts have replaced suits, herbal tea and bottled water have replaced coffee, nobody is allowed to smoke, and rarely does anyone work past 5 pm. More importantly, we used to care about the work we produced; there was a sense of craftsmanship, regardless of the job.

My Brother-in-law in Cincinnati conducted me on a tour of his company's machine-tool shop years ago and showed me how he could take a block of aluminum and convert it into a high-precision machine tool. It was a pleasure to watch him work, as it is to watch anyone who knows what they are doing, be it a waitress, a programmer, a laborer or a clerk.

Quality and service used to be considered paramount in this country. If it wasn't just right, you were expected to do it over again until you got it right. We cared about what we produced because it was a reflection of our personal character and integrity. But somewhere along the line we lost our way and craftsmanship has fallen by the wayside. Why? Probably because we no longer care.

In today's litigious society, employees are acutely aware that it is difficult to be fired due to poor performance. They know they will still get paid and receive benefits, regardless of the amount of effort they put forth. Consequently, there is little to encourage people to perform better. Money isn't a motivating factor anymore. People now expect bonuses, raises and other perks to be paid out regardless of how well they perform during the year.

We've also become a nation content with doing small things. America used to be known as a powerhouse that could tackle large projects, such as building skyscrapers, designing innovative bridges and tunnels spanning substantial bodies of water, engineering transcontinental railroads and highway systems, conquering air and space travel, and defending freedom not just once but in two world wars. If you really wanted something done, you talked to the Americans and no one else. Now we get excited over iPods, cell phones, and other electronic trinkets.

Many believe Craftsmanship is in decline due to the general apathy found in today's society. Maybe. I tend to believe it is due to an erosion of our moral values. Let me give you an example. Having a child in college, my interest was piqued recently by an article describing the pervasiveness of cheating and plagiarism in our schools. It is not my intent to make a political statement here but many of the students mentioned in the article rationalized their cheating on the fact that one of our past Presidents cheated and lied under oath, and got away with it. They figured if it is okay for the Commander-in-Chief to act this way, it was an acceptable form of behavior.

Arnold Toynbee, the famed English historian, observed, "Civilizations die from suicide, not by murder." If the moral fabric of our society dies, our story is told as evidenced by other great civilizations that long preceded us. Our perspective needs to be realigned: Our personal and professional lives must be viewed as one. As Toynbee remarked, "The supreme accomplishment is to blur the line between work and play." By doing so, we identify more closely with our work and assume a greater pride in workmanship. We do not need to hear this from our boss, but rather from within. As strange as it may sound, I see Craftsmanship as being patriotic in nature; doing a good quality job is part of leading a good and honorable life and builds on the individual's esteem, the company he works for, and the country he lives in.

The biggest problem though is that we have forgotten how to manage people. The manager's primary goal is to create the proper work environment for employees to produce the desired work products. This is different than a supervisory capacity that directs how each person performs the various tasks of a job. In fact, I encourage managers to manage more and supervise less. I cringe when I see a manager try to "micromanage" either a Fortune 500 company or a non-profit organization. Yes, people need to be trained in order to properly perform their work but following this, employees should be mature enough to supervise themselves. In the old days, management stressed discipline, accountability, and structure; three ugly words in today's workplace.

Some might say craftsmanship is a simple concept that we should intuitively know. Not true; most people today have no comprehension as to what makes up a good craftsman; they have either forgotten or it has simply passed them by. Craftsmanship can be found in any field of endeavor imaginable, be it in the product sector or service industry. Craftsmanship, therefore, is universally applicable to any line of work.

Craftsmanship is not "workmanship", nor is it synonymous with quality, although the three concepts are closely related. Let's begin by giving "Craftsmanship" a definition: "The production and delivery of quality goods or services from highly skilled workmen."

Quality relates to the absence of errors or defects in the finished product or service. In other words, finished goods operate according to their specifications (in other words, customers get precisely what they ordered). Such products are normally durable and require minimal maintenance. Craftsmanship produces quality products. In the absence of craftsmen, a rigorous methodology or assembly line process is required to produce quality goods using workers without the expertise of craftsmen. Such processes detail "Who" is to perform "What" work, "When", "Where", "Why" and "How" (5W+H), thereby assuring a quality product or service is produced. Such is the underlying rationale of the ISO 9000 certification as used by many companies today. The point is, quality is not the exclusive domain of the craftsman.

Craftsmanship is also a human trait. Some might argue a computer or industrial robot can produce quality products and are, therefore, craftsmen. However, we must remember these devices are programmed by human beings in accordance with the rules of the craftsman. As such, they are an extension or tool of the craftsman.

Craftsmanship can be found in either the overall work process or a section of it. For example, there are craftsmen who are intimate with all facets of building furniture, such as a table, a chair or desk, and can implement the product from start to finish. However, as products grow in complexity, it becomes difficult to find people suitably qualified to build them from the womb to the tomb. Consider military weapons alone, such as the complicated ships, tanks, and airplanes we now use, with thousands or millions of parts to assemble. Such complexity makes it impossible for a single person to have the expertise to build the whole product. The same is true in the service sector where different types of expertise and capabilities may be required. In other words, craftsmen have a specific scope of work. The scope of work may relate to other types of craftsmen through a chain of work dependencies, e.g., Craftsmen A, B and C concentrate on separate sub-assemblies which are eventually joined into a single product.

So, what are the attributes of a craftsman? What makes a craftsman a craftsman? There are three basic attributes described herein:

1. Possesses the necessary knowledge and skills to perform the work.

The craftsman is an expert in his field of endeavor; so much so that he could easily serve as an instructor in the subject matter. But the craftsman is also smart enough to know that education is not a one time thing, that his world and field evolve as new tools and techniques are introduced. As such, the craftsman is a student of his profession and is constantly looking to improve himself. This is exercised through such things as continued education, routine certification, studying books and trade publications, and industrial groups. The craftsman willingly participates in trade groups, often at his own expense, in order to network with his peers.

It is Important to note that the craftsman does not need to be told he needs periodic training to sharpen his skills. Instead, he takes the personal initiative to stay on top of his game. Further, the craftsman has no problem with a periodic job review; in fact, he welcomes it for it might bring out a weakness in a skill he needs to sharpen.

2. Attention to detail.

The craftsman understands and respects the process of building/delivering a product or service and is acutely aware of the penalties for cutting corners. Earlier we discussed the need for a methodology that specifies 5W+H. The craftsman is intimate with all details of his scope of work, so much so, he could probably write the methodology himself. Further, his intimacy of the work process means he can produce a reliable estimate of time and costs to perform the work.

Although many of the craftsman's tasks may be repetitive, it doesn't mean he easily falls into a rut. Instead, he is constantly looking for new tools and techniques to improve the work process. As such, he plays the role of Industrial Engineer who is normally charged with such a task.

The craftsman's attention to detail also means that he demonstrates patience in his work effort. Again, wary of cutting corners, the craftsman must possess such patience in order to produce the product the right way.

3. Views professional life as an extension of his personal life.

The craftsman identifies with the end product which is where pride in workmanship comes from. In his mind, the craftsman has been charged with the responsibility of producing something, and wanting to satisfy the customer, puts forth his best effort to produce it. In other words, craftsmen take their work personally. This is a difficult trait to teach particularly in today's society where the focus is more on financial compensation than on the work product itself. It may sound naive, but the craftsman believes he will be suitably compensated for producing superior results.

Years ago, Dick Butkus of the Chicago Bears (NFL) confounded sports writers who could never understand why Butkus played as hard as he did year after year for a losing football team. True, Dick loved the game, but beyond that, the sports writers didn't understand one thing about the seven time All-Pro linebacker: Butkus took his job personally. It was important to him that his opponents know that they had been tackled by the best player; as he said, "When they get up from the ground I want them to say 'it must have been Butkus that got me'." Dick Butkus was a craftsman.

The craftsman has a burning desire to produce a superior product/service because he sees it as a reflection of himself. As such, the lines delineating their personal life and professional life are blurred. This is a significant characteristic that clearly separates a craftsman from the average worker. The craftsman's work is his life. He does not shirk responsibility, but rather embraces it with confidence and embosses his name on the finished product. Conversely, making a work related mistake of any kind pains a true craftsman.

Job titles are normally inconsequential to the craftsman who is more interested in delivering a quality product/service enjoyed by the customer. Instead, the craftsman takes pleasure in being touted as the best in his craft. He appreciates recognition; when someone makes a compliment about a product, the craftsman views it as a personal compliment. This too runs contrary to today's corporate world where people desperately seek recognition through simple job titles. Want someone with an inflated ego? Give them a title. Want something done right? Call a craftsman.

"Dependable", "professional", and "resourceful" are adjectives that aptly describe the craftsman. He is not one who fabricates excuses but, rather, always finds a way to get the job done. The craftsman is typically your most productive employee. He is mindful of the concept of productivity that we have touted for years:

Productivity = Effectiveness X Efficiency

Most people fallaciously equate productivity with efficiency, which simply gauges how fast we can perform a given task. Effectiveness, on the other hand, validates the necessity of the task itself. There is nothing more unproductive than to do something efficiently that should not have been done at all. An industrial robot, for example, can efficiently perform such tasks as welding. But if you are welding the wrong thing, then it is counterproductive. Going back to our description of a methodology, effectiveness defines "Who/What/When/Where/Why", efficiency defines "How." The craftsman is well aware of the difference between the two and knows how to apply both. As such, the craftsman is in tune with his work environment and corporate culture.

So how do we make craftsmen?

Not easily. Because of the human dynamics involved with the craftsman, you will need to be a pretty intuitive manager or industrial psychologist to make it happen. Selecting suitable candidates is the logical first step. Devise an aptitude test to determine the candidate's suitability to become a craftsman. After all, "you cannot make a silk purse from a sow's ear." Aside from specific knowledge and experience in a given field (e.g., programming, woodworking, construction, accounting, etc.), here are some other important traits to look for:

* Fertility of mind - judge his ability to learn, to adapt to changing conditions, and to look beyond his scope of work. Evaluate his professional curiosity.

* Confidence - judge how well the candidate knows himself, particularly how well he knows his own limitations. He should admit his deficiencies and not fabricate excuses.

* Dedication - judge his loyalty and determination to accomplish something. What is his attendance record? What outside clubs and organizations does he belong to and how active is he in them?

* Entrepreneurial spirit - judge his personal initiative. Is he driven to succeed (but not to the point of reckless abandon)? Does he have a problem with accountability? This says a lot about assuming responsibility.

* Attention to detail - judge his ability to focus on a subject. Does he have a problem with discipline or organization? A person's dress, mannerisms, and speech says a lot about a person.

* Reliability - judge his ability to assume responsibility and carry a task through to completion.

* Resourcefulness - judge his ability to adapt to changing conditions and persevere to see a task through to completion. The candidate cannot be inflexible; he must be able to find solutions to solve problems.

* Socialization skills - does he work better alone or as a team player? His position may depend on his answer.

When you have selected suitable candidates, here are three areas to concentrate on:

1. Develop their skills and knowledge by allowing such things as: participation in trade groups, outside certification and on-going training, subscriptions to trade journals, continued education, etc. Some companies even go as far as to develop an in-house school to teach the company's way of doing things. If the in-house school is good, it will promote confidence through consistency. Even if people leave the company, they will recommend your company because they know the quality of the work produced. Supporting the education needs of our workers is not only smart, it is good business.

2. Teach them the need for producing quality work; they should become intimate with all aspects of their work process (5W+H). Further, instill discipline and patience in their work effort.

3. Change their attitude towards development so they become more focused on delivering a quality end-product. This is perhaps the most difficult element to teach. However, it can be realized by having them become intimate with the needs of the customer (have them visit or work with a customer for awhile - "let them walk in the customer's shoes"). It may also be necessary to change their form of remuneration by going to a reward system for work produced (as opposed to guaranteed income regardless of what is produced). Changing the mode of financial compensation is highly controversial in today's business world. But, as an example, can you imagine the change of attitude of today's professional athletes if they were paid based on their accomplishments (e.g., runs or points scored, hits, rebounds, etc.) rather than having a guaranteed income? Their motivation and attitude towards their profession and team would change radically.

Candidates must learn to respect their institution, the process by which they work, fellow human beings, and themselves. They must also learn not to be afraid to TRY; that they must put their best foot forward, win or lose. Bottom-line: they must learn that their work has meaning and worth. If they don't enjoy their work, they shouldn't be doing it.

Teaching the elements listed above probably cannot be done in one fell swoop. Further, companies simply don't have the time or money to wait for the craftsman to be produced. Instead, they must understand the human spirit needs to be cultivated and be allowed to grow over time. Because of this, it is strongly recommended that an in-house certification program be devised specifying what the candidate should know and what skills and talents he should demonstrate. This should be divided into classes of progressive expertise; e.g., apprentice, intermediary, and craftsman. The ancient builders in Egypt, Rome, and Greece understood this concept and devised such classes of workmen. Other disciplines and schools follow similar tactics (the various degrees or belts in martial arts for example). Each degree is based on specific prerequisites to master before moving on to the next level.

An in-house certification program has the added nuance of making people feel special which greatly enhances their self esteem. If they are made to feel like a vital part of the company, regardless if their work of a large magnitude or trivial, they will strive to do what is best for the company overall, not just themselves. Consequently, their work adds meaning to their life.

There is one pitfall to all of this; today's "go-go" management style fails to see how craftsmanship adds value to the company. In fact, there were companies back in the 1980's that shut down such programs simply to reduce costs. As a result, quality suffered, repeat business was lost, products were more in need of repair, absenteeism on the job escalated, etc. Want value? How does a loyal customer base who has confidence in your products or services sound? And what effect would employee harmony have, particularly if they believed in the work they were producing? It would be mind-boggling, all because we had faith in the human spirit to produce superior results.

A final note: craftsmanship is not a one time thing. After it has been instilled in people, it has to be cultivated and perpetuated. If a manager slips even for a moment, it will go right out the window and it will take time to bring it back to life. As for me, I like to post motivational reminders kind of like the one recently spotted in the Hickey Freeman manufacturing facility in New York, "Excellence is Tolerated."

OUR BRYCE'S LAW OF THE WEEK therefore is...
"Manage more, supervise less."

IN OUR "DOWN THE ROAD" SECTION

The IT Executive Retreat will be held at the Don CeSar Beach Resort on St. Petersburg Beach in FL on January 23rd-24th. For information, call the IMF in Atlanta at 770/455-0070

On March 6th-8th, the Gartner Business Intelligence Summit 2006 will be held at the Hyatt Regency in Chicago, IL. For info, contact Gartner at 203/316-6757

The 17th International Conference of the Information Resource Management Association will be held May 21st-24th at the Wyndham Hotel in Washington D.C. For information, call IRMA headquarters in PA at 717/533-8879

If you have got an upcoming IRM related event you want mentioned, please e-mail the date, time and location of the event to timb001@attglobal.net

MY "PET PEEVE OF THE WEEK" IS "CLOCK WATCHERS"

As a follow-up to my essay on "Craftsmanship," I have noticed that the younger workers today have a different orientation than their predecessors in the work place. Today, the typical worker pays more attention to the clock as opposed to what they produce during the day. This is driving managers from my generation crazy. For example, it is common to hear someone say, "Boy, I worked hard today; I must have worked eight hours today with hardly any breaks." That is most definitely what managers do not want to hear. Instead, they are interested in results. I don't care if you spent 24 hours working during the day; if you don't produce the product or service you are charged with, than it is all a colassal waste of time. The day a person starts to pay more attention to results, is the day when they lose track of time and start to solve meaningful problems. Consider this, have you ever wondered why you don't see clocks in gambling casinos? Its because they want you concentrating on the job at hand. This is why I recommend to clients that they also remove clocks from the office, regardless if they are exempt or non-exempt workers. Time is irrelevant, results are where its at.

AND FINALLY...

I received an e-mail from aan A.C. Kemper of Athens, Ohio who wrote me regarding last week's essay on "Some New Year's Resolutions." A.C. writes,

"Tim I enjoyed your broadcast last week. I have been tuning in to your broadcast for the last couple of months and I have appreciated your insight. I call you the Rush Limbaugh of management."

Thanks A.C. for the compliment. I've had a lot of fun with the broadcast and have tried to be a straight-shooter on my essays with a dash of humor. I just hope it is helping to raise the consciousness of management.

Again, Thanks for your e-mail. Keep those cards and letters coming.

The only other announcement I have is the release of a free new on-line multimedia presentation I've entitled, BRYCE'S CRASH COURSE IN MANAGEMENT which offers pragmatic advice on how to discharge the duties of a manager, whether it be for a commercial or non-profit enterprise. Frankly, for someone aspiring to be a manager or for a new manager, it will be the best 45 minutes you can invest in yourself. Check it out on the cover of our corporate web page at: http://www.phmainstreet.com/mba

For a complete listing of my essays, see the "PRIDE" Special Subject Bulletins section of our corporate web site.

Folks, In case you haven't heard, the "Management Visions" is now available in the MP3 file format suitable for Podcasting or other audio devices. It is also available in versions for RealPlayer and Microsoft Media Player. See our web site for details. You'll find our broadcast listed in several Podcast and Internet Search engines, as well as Apples' iTunes.

MBA is an international management consulting firm specializing in Information Resource Management. We offer training, consulting, and writing services in the areas of Enterprise Engineering, Systems Engineering, Data Base Engineering, Project Management, Methodologies and Repositories. For information, call us at 727/786-4567.

Management Visions is a presentation of M. Bryce & Associates, a division of M&JB Investment Company of Palm Harbor, Florida, USA. The program is produced on a weekly basis and updated on Sundays. If you have any questions or would like to be placed on our e-mailing list to receive notification of future broadcasts, please e-mail it to timb001@attglobal.net

We accept MP3 files with your voice for possible inclusion in the broadcast.

Management Visions accepts advertising. For rates, please contact yours truly directly.

Copyright © 2006 by M&JB Investment Company of Palm Harbor, Florida, USA. All rights reserved. "PRIDE" is the registered trademark of M&JB Investment Company.

Our corporate web page is at:

http://phmainstreet.com/mba/

This is Tim Bryce reporting.

Since 1971: "Software for the finest computer - the Mind."

END