May 28, 2007

"WHAT PRICE QUALITY?"

We now live in a fast paced society where we expect products and services to be delivered rapidly (some say "yesterday"), cheaply, and with a high degree of quality. This is particularly true in the systems and software industry. If we lived in a perfect world, systems and software would be developed rapidly and inexpensively, they would effectively satisfy business needs, and would be easy to maintain and modify. There is only one problem with this scenario: it is a fantasy. In reality, we live in a "disposable" world where systems and software are slapped together in the hopes everything will hold together and will pacify the end-user for the moment. Some people believe striving for a Utopian world is an impossibility and, as such, resign themselves to rewriting systems and software time and again as opposed to designing them to be industrial strength.

Improving speed in the development process is relatively simple to accomplish; e.g., the plethora of programming tools available. But adding quality into a product is something entirely different. From the outset we must recognize that quality doesn't come naturally to people anymore. Back when there was a sense of craftsmanship, quality was rarely a problem. This is back when people identified with their work products, and strove to seek perfection as it was a reflection of their character. Corners were not cut and products were made to last. Unfortunately, we no longer live in such times and people tend to disassociate their work from their personal lives. Further, the speed and sophistication of our tools leads us to believe we are producing quality products. The reality is that our tools are only as good as the people using them, not the other way around.

A PERFECT WORLD

How one person perceives quality may be entirely different than another's. This is because we tend to have different perspectives in how to build something, e.g., whereas one person may build a product one way, another may build it using an entirely different approach. This means products are commonly built using inconsistent methods. Let me give you some examples:

• If we lived in a perfect world, we would have a standardized approach for defining requirements, thereby everyone would be operating with a standard approach for scrutinizing requirements. But the reality is our approach to requirements definition is redefined with each development project, thereby making it impossible to validate requirements with any consistency.

• If we lived in a perfect world, developers would be working with standard data definitions that would include validation/editing rules, among other things. This would result in a consistent approach in the use of data (aka "Data Cleanliness") and would promote system integration through data sharing. But the reality is that each programmer specifies the use of data (including its physical characteristics and validation/editing rules) on a program by program basis, thereby defeating the opportunity to share and reuse data in a consistent manner. Even worse, implementing changes on a consistent basis is difficult at best (e.g., the Y2K problem).

• If we lived in a perfect world, programs would be designed in a standardized manner so they may be easily modified or maintained by any other programmer at a later date. But the reality is that programs are written based on the personal nuances of the programmer, making it next to impossible to maintain or modify by another person. Consequently programs are discarded and rewritten.

• If we lived in a perfect world, developers would adhere to a standard and consistent approach (methodology) whereby uniform work products could be produced and reviewed, thereby improving communications among the staff and allowing for the interchangeability of workers in the development process. But the reality is, the development process is defined on a project-by-project basis, thereby uniformity and interchangeability is defeated.

The reality is we live in an imperfect world. What would appear to be obvious approaches to development seldom occurs in most systems and software shops. It is simply unnatural to developers who prefer to operate independently as opposed to adopting a shop standard. This of course means development organizations tend to "reinvent the wheel" with each project.

Because of such inconsistencies, the only option for improving quality is to try to inspect the product after it has been built, not during development. Under this approach, inspection is complicated as each person has designed the product according to their own personal interpretation of development, not as a standard body of work.

BUILDING QUALITY INTO THE PRODUCT

It is obviously cheaper and more sensible to arrest a product defect early during development as opposed to trying to catch it afterwards. To do so, the development process has to be subdivided into defined units of work specifying what is to be produced (work products, aka "deliverables"), how it should be produced (using accepted tools and techniques), and its acceptance criteria (including review points). Such a work environment is in sharp contrast to "The Black Hole" approach used by most organizations today; e.g., requirements are fed into an unknown development environment and the resultant product is inspected afterwards. This approach concentrates only on the final deliverable and not on the overall process by which the product is to be developed. By the time the final product is produced, it may be unrecognizable to the user and the project may have exceeded estimated cost and schedule. Even worse, the product may have to be redesigned and rewritten over and over again. Interestingly, this is the approach advocated by today's "Agile" proponents.

In other manufacturing practices, the definition of the work environment is the responsibility of an Industrial Engineer who defines the units of work in the development of a product (assembly line), the standard tools and techniques to be used, the work products, and the acceptance criteria. Although the concept of Industrial Engineering is applicable to systems and software, few development organizations are familiar with the concept.

THE PRICE OF QUALITY

Regardless of what you call it, Industrial Engineering or Quality Assurance, quality requires a dedicated group of people to define the overall development process, monitor progress, and constantly research new ways to improve it (tools and techniques). This does not mean quality is the sole responsibility of such a group. It is not. Quality is the responsibility of every person involved in the development process. The group simply provides leadership in this regards.

In terms of costs, the truth is that quality is free (as the likes of Philip Crosby have pointed out to us). True, it requires an outlay of money upfront to embark on a quality assurance program, but this will be offset by reduced costs later on in terms of reduced development time and fewer defects requiring rework. By having everyone working according to defined processes and work products, errors are caught and corrected early in the development process. Further, work products are easier to maintain and modify later on, this specifically includes systems and software. Such a program, therefore, does not add overhead to the development process, it reduces it.

To make this work though requires commitment from management and herein lies the rub. As I mentioned earlier, we live in fast-paced times. Implementing an effective quality assurance program takes time to cultivate, it cannot be installed overnight. There is more to it than mechanics; standards have to be devised, attitudes have to be adjusted, consciousness' raised, etc. In other words, it is the people-side of quality that takes time to mature and become ingrained in the corporate culture. As such, a quality assurance program requires management vision and long-term commitment to see it come to fruition. This is difficult to sell to managers who have trouble thinking past the next financial statement. But if executives understand that a company truly runs on systems and software, then they will be more amenable to investing in industrial strength applications.

CONCLUSION

Its interesting, the systems and software industry is one of the few industries that resists standardization as opposed to embracing it. Standardization is an inherent part of any quality program. It means devising and applying craftsman-like rules in the development of a product or service. Such rules substantiates completion of work in a prescribed sequence and is measurable. And maybe it is this kind of accountability that developers resist.

Some developers even go so far as to question the necessity of a quality assurance program since many companies rewrite their systems and software year after year. Maybe they are right, but I tend to see this as a defeatist attitude, that we can do nothing more than produce mass mediocrity. I believe we can do better. But to do so, we need to invest in ourselves and our future. Remember, you must first plant the seeds in order to harvest the crop. Unfortunately, most companies tend to eat the seeds and then there is no crop to harvest. Somehow I am reminded of the old expression, "You can pay me now or pay me later, but you're going to pay me."

For additional information on "PRIDE" Quality Assurance, see: http://www.phmainstreet.com/mba/pride/spqa.htm

OUR BRYCE'S LAW OF THE WEEK therefore is... "Quality must be built into the product during design, not inspected in afterwards."

"PRIDE" METHODOLOGIES FOR IRM

Friends, the "PRIDE" Methodologies for Information Resource Management (IRM) is a common sense solution for Enterprise Engineering, Systems Engineering, Data Base Engineering, and Project Management. The methodologies include defined work breakdown structures, deliverables, and review points that promote quality and the production of industrial-strength information systems. Building information resources is a science, not an art form. Our methodologies clearly explain the concepts that govern them, which remarkably, is derived from engineering/manufacturing practices. Now you can get these acclaimed methodologies for free at our corporate web site at: http://www.phmainstreet.com/mba/pride/

MY "PET PEEVE OF THE WEEK" IS "LITTLE LEAGUE"

I've been a baseball fan for most of my life. It seems like I played it nonstop in my youth, and marveled at the major leagues in the early 1960's with the Yankees and watched the Big Red Machine roll on to victory in the 1970's. I still have a pretty impressive baseball card collection which I hope to pass on to a grandchild some day.

When my children came of age, I was glad to see them express an interest and join the local Little League. Because of this, I got involved with the local program and served it for ten years in a variety of capacities: as coach for both boys baseball and girls softball, as umpire, and as a member of the board of directors. I got involved because I saw it as a rare opportunity to be actively involved in the lives of my children, especially in something we all enjoyed.

As coach, I had modest success. Unlike a lot of my contemporaries, I never suffered under the illusion that we played in a World Series every weekend or that any of my kids would someday reach the Hall of Fame. Instead, I taught teamwork, the fundamentals of the game, and hopefully an appreciation for it. Frankly, we had a blast. I never made my kids run laps after a defeat, and we often had ice cream after a victory. But my signature as a manager was to line the kids up before the game and give the pledge of allegiance to the flag. Since baseball is truly America's game, I thought this was important. Interestingly, there were a lot of coaches who thought this was plain silly and refused to join us in the pledge of allegiance. I thought this was particularly strange.

The one thing I objected to as a coach was how parents tended to treat us as baby-sitters. They weren't so much interested in whether their child learned anything, as much as they saw this as an opportunity to occupy the kid's time. This never did set well with me.

As an umpire, I learned the importance of managing the game, being fair, and good sportsmanship. I only had one instance where I had to eject a manager for being a loudmouth. I guess I did such a good job at this that nobody dared challenge me thereafter. The lessons I learned as umpire followed me into my professional career, as well as my participation in other nonprofit organizations.

As a member of the Board of Directors, I produced the club's first web page, cleaned up the governing docs, and straightened out their finances. When I started on the finances, I was given nothing more than a shoe box with receipts and nothing else. This made me suspicious of how finances were being handled prior to my term.

More than anything, what I learned from my Little League experience was that it is run by well meaning people with some time on their hands, but haven't got a clue as to how to run a business. Little League is essentially no different than any other nonprofit organization in this regards, complete with politics, a lack or organization, and some power hungry fool trying to run everything. The scope of an organization like Little League is such that it is virtually impossible to try to micromanage everything, but that doesn't stop people from trying to do so. Consequently, they do nothing but alienate the volunteers and discourage people from participating. Instead, they should be empowering people and hold them responsible for their actions. As I like to say, you should "manage more, and supervise less."

Little League is nothing more than a forum for kids to get some organized physical activity, learn some fundamental lessons about teamwork and sportsmanship, and an appreciation for the game. Nothing more, nothing less. Yet there are those parents who go beyond this and teach cutthroat tactics and to win at all costs; If this includes cheating, so be it. Actually, its a shame parents have to get involved with something like Little League; the kids would probably have a better time without them.

Such is my Pet Peeve of the Week.

"BRYCE'S IS RIGHT!"

Folks, a couple of years ago I started to include my "Pet Peeve of the Week" in these "Management Visions" podcasts. They have become so popular that I now syndicate them through the Internet and they are available for republication in other media. To this end, I have created a separate web page for my writings which you can find at phmainstreet.com Look for the section, "The Bryce is Right!" Hope you enjoy them.

AND FINALLY...

My Pet Peeve on "Tattoos" generated a lot of comments:

A B.T. writes:

"I am of the older generation too, and initially found tattoos distracting and disturbing. After seeing enough of them, I stopped being distracted and disturbed by them. Now I find interesting tattoos attractive.

It disturbs me that many of the older generation who cannot accept change are so upset by them. Someone said, in 40 years there will be a lot of fat, wrinkly old women in tattoos. Hey, in 40 years there will be a lot of fat, wrinkly old women whether they have tattoos or not. At least the tattoos will remind them of the good times.

Tattoos and body piercing go back to prehistory. They have come and gone before. People should get over it.

That said, my 14 year old son will not get one until he has proven himself mature enough to make a decision that will live with him the rest of his life."

A G.T. also wrote:

"My father was a brilliant man, one of the most interesting men I've known. My children also thought of their grandpa as the smartest person they ever knew. He was also heavily tattooed in the military. He had a hula dancer on his thigh, a blue bird on each pectoral, a snake on his forearm and a growling tiger on his bicep. When he was young and muscular, he used to entertain us by making the hula dancer dance by flexing his thigh muscle. The blue birds fluttered when he flexed his upper body. As he aged, the hula girl sagged, the blue birds didn't flutter. It gave my kids a first hand look at what decades do to body art. They still thought grandpa was a cool old man. It is unfortunate that people have those preconceived notions that can make or break a career. I've seen brilliant candidates for jobs that 'just don't fit' because of piercings or body art."

And finally, an E.S. in Tampa wrote:

"I agree with Tim and grew up thinking the same way. My Dad taught us the same philosophy that Tim has and thus no one in my family has tattoos until recently; my 21 year old niece whom my Parents practically raised got a tattoo in exactly the same place as the waitress on her lower back below the waist...hmmm...must be some stupid fad or something. In any event the tattoo was met with much resistance from dear old Dad and as for my Mom she couldn't say much it was already there... and my sister my niece's mother thought it was 'cool'; what a retard. So, there you go, we were both brought up in the same household and she lets her daughter do this. Next thing you know she'll be letting my nephew go pierce his 'whatever' which I hear is also a new 'fad.' So much for my opinion on the tattoos, of course I have seen some that are just so beautiful you have to comment on them."

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

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. For a complete listing of my essays, see the "PRIDE" Special Subject Bulletins section of our corporate web site.

Our corporate web page is at:

http://phmainstreet.com/mba/

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

For a copy of past broadcasts, please contact me directly.

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

There is no charge for adding a link to "Management Visions" on your web page, for details and HTML code, see the "Management Visions" web site.

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

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

This is Tim Bryce reporting.

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

END