- Procurement Options
For the modern citizen of the world, there may be no day that go by without a peep from N.J. Woodland. Rather, make that a beep.
Woodland never became a household name in any other than his own, but the inventor and longtime IBM engineer, plays a steady role in the life of anyone who shops at a grocery store, retail store or lives in anything other than a mud hut in a faraway desert. Or to put it another way: everyone.
Woodland, who passed away at 91 in December, was the person most responsible for the introduction of the modern bar code, the picket fence DNA of supply chains everywhere. Woodland’s idea, first hatched in 1947, would later launch the age of the UPC, the unmistakable series of spaces and dashes which are as indecipherable to the human eye as a Jackson Pollock painting, but which allow your bag of pretzels to talk neatly with the checkout machine, updating inventory and explaining just how much you owe for all those hard crystal salt pellets you’ll soon be spilling down your shirt.
As a result, more than 60 years after his idea for a bar code, Woodland’s legacy is everywhere, punctuated only by the steady, insistent beep of chekcout lines everywhere.
Nowhere has his impact been more profound than the modern supermarkets, where the story of the bar code is less trivia and more tent pole technology.
Grocery stores are a story of unseen logistical success that ranks with Xerxes’ spanning the Hellespont, and tracking the many turns Jodie Foster’s Golden Globes speech.
According to a 1999 study by PriceWaterhouseCoopers on the 25th anniversary of the ubiquitous UPC code, the invention was saving the American grocery store industry more $17 billion per year. With the large-scale improvement of IT infrastructure within grocery stores, savings have hockey-sticked upward since, thanks in no small part to the UPC and its bard code cousin the EAN.
|Charles G. Davis|
Additionally, bar codes (coupled with the move to larger supermarkets) have allowed grocery stores to stock a more complex, diverse inventory. When the UPC code was introduced in 1974, the average grocery store stocked 9,000 types of items (Stock Keeping Units, or SKUs). According to 2011 market research by the Food Marketing Institute, that number is now 38,718 per store. (This would explain why you can get kraut juice or pickled pig’s feet from six different manufacturers. Why anyone buys them, however, is a mystery even the mighty barcode can’t decipher.)
And all that efficiency, the increase in available SKUs, the modern castor oil to motor oil grocery store all began because of an idea NJ Woodland hatched while idly running his hands in the sand on a Florida beach, turning Morse code beeps into the now omnipresent bar codes.
Yet the story of Woodland, his bar code and the UPC which followed aren’t just a story of lucky inspiration, they’re a parable of effective program management.
Someone Asked Why
The story of the inspiration for the bar code may be apocryphal in its telling, but is useful in its narrative. Creation of the bar code started with a “Why?” According to the often told story, Bernard Silver, then a fellow graduate student of Woodland’s at Philadelphia’s Drexel University, overheard a local grocery store owner asking how items could be tracked. At the time, grocery stores relied on individually marked labels, which could easily be manipulated or removed, price books, which were cumbersome and difficult to update, and the cashier’s own memory, perhaps the faultiest method of all.
So, the greatest revelation in supply chain management in 90 years started with a why.
Effective program management, too, starts with a why. Program management – truly difference making program management – isn’t simply about rubber stamping or paper shuffling. Effective program management is about why, from requirements through deployment and sustainment. It’s about asking
Of course, gains may not always be realized. But enough whys eventually make a why not.
A Real Solution for a Real Problem
Because program management doesn’t entail touch labor, such as building widgets, turning screws or writing software code, there exists a temptation to either gold-plate work, that is needlessly and expensively dress it up with no real value add, or, a term we use here at TeAM, lead-weight it, that is actually make the process slower and more cumbersome in the name of making your work apparent. Consider the process-slowing way many companies oversee Information Assurance for a fine example of a lead-weighted process, even when attached to a valuable service.
The bar code, however, was a specific product created to solve a specific and well-defined problem. In program management, it’s a simple trap to talk about the value of ITIL or Agile and get enraptured in process at the expense of product. Many companies will talk about Agile development without a specific plan for how it will increase value. Many program management companies offer services which don’t merit the time and energy consumed simply in the name of doing …. something.
The bar code, though, was a product created to fill a specific need. Highly targeted. Effective. Tenaciously developed.
At TeAM, our program management philosophy is geared to structured innovation and efficiency creation. We seek out problems and propose specific solutions with tangible benefits then follow through until those benefits become the new baseline.
Insistence on Improvement
Woodland’s bar code was no overnight success. He first pursued the concept in 1948, drew his lines in the sand in 1949 and turned his elongated Morse code into a symbol by 1950. In 1952, he and Silver were awarded a patent for what was titled, in the thoroughly antiseptic way achievable only by the Patent Office, the “Classifying Apparatus and Method.” But the barcode, at that point a large bulls' eye of thick and thin lines, was commercially untenable, prone to smudging and requiring expensive scanner equipment. The patent was later sold to Philco, but Woodland kept working at the idea while at IBM. Eventually, in 1974, George Laurer and IBM published the UPC and the rest is beeping history.
In program management, rigid reliance on previous work is counterproductive, particularly in IT, where the technological revolution occurs at a rate even the UPC scanners would have a hard time tracking. At TeAM we practice repeatable processes rather than rote action, but it requires an honest audit. If a process or product doesn’t yield sufficient value, keep trying. Great is an ongoing evolution.
Each step in the creation of the UPC was drawn from a different wellspring of knowledge. Its creation was an idea chain, each link forged from different backgrounds and expertise. The seed was planted by a grocery store executive, identifying the problem. The genesis of the solution, those lines in the Florida sand, were born from Woodland’s knowledge of Morse Code, something he’d picked up years before in the Boy Scouts. When the circular code Woodland patented in 1952 proved unworkable due to the technology of the time (It required a 500-watt light, which is bright enough to light a street corner and/or tan the cast of Jersey Shore), the expertise of fellow IBM engineers and advances in microprocessor and laser scanning technology made the concept possible by the early 1970s. It took a village to raise an idea.
Effective program management requires a broad base of ideas, to shepherd products and services through the full lifecycle. The release of any product requires many levels of expertise, from requirements documentation through sustainment. At TeAM, we a wide range of professionals, from systems engineers to web developers, from medical doctors and web developers to WAN and LAN installers. Through established advisory channels, the expertise of every employee is available to all program management contracts, providing unique depth of expertise to those overseeing major federal programs.
Yet beyond technical expertise, a successful program management company brings institutional knowledge and experience, like TeAM’s 28 years in support of the Federal Government, which helps bring a historic perspective to the constant temblors that stress Federal projects. After all, it was Woodland’s boyhood of knowledge of Morse code that sparked the UPC revolution.
Before there was check out, there was buy-in, and a lot of it. The deployment of the UPC was a study in teamwork. In 1970, six industry groups representing both manufacturers and retailers formed the Grocery Industry Ad Hoc Committee, tasked with studying and reporting the economic potential of the UPC along with potential problems involved in its implementation and use. The group faced a challenge which a 1999 PricewaterhouseCoopers study summed up in decidedly program management terms, calling it a “formidable task of resolving problems that required a significant understanding of both existing business practices and new technologies.”
The committee overwhelmingly decided to adopt the UPC, but, in an eye towards scalability, opted that checkout systems “not be the sole justification of the business case.” That is, the committee recognized the potential impact of the UPC for manufacturers and retailers beyond the grocery industry. So the committee formed a subcommittee to create the standards for a code whose length and structure could accommodate third parties beyond the aisles and shelves of grocery manufacturers and retailers.
However, the Committee still had to gain widespread agreement among additional groups, including smaller grocers concerned implementation cost would prevent their use of the UPC, consumer groups who worried about consumers ability to make sure the price on the shelf matched the code, and unions, which felt the code would result in a loss of jobs. They treated buy-in from all participants as an “absolute requirement,” as the Pricewaterhouse Cooper’s report recalls. The Ad-Hoc committee then created specific value documentation addressing each of the concerns and went to work convincing decision makers at multiple corporations and associations of the beneficial impact of the code. Once agreement was reached, the committee then set about documenting the affordability and functionality of the symbol to be used. As a result, in 1974, four years after the committee began its work, the first UPC code beeped out a pack of chewing gum in a Troy, Ohio grocery store.
In effective program management, a great idea, no matter its potential value, is only as useful as your ability to build consensus for it. IT ideas are not viruses. They cannot grow without the consent of hosts.
And, lest the UPC code seem like an idea so obvious and beneficial that it’s acceptance was pre-ordained regardless of the above efforts, consider that the United States’ planned conversion to the metric system, which had an act of Congress behind it, vied for widespread acceptance at roughly same point in history. Nonetheless, despite the advantages of the metric system, what other than soda bottle sizes and military ammunition, have changed?
Effective program management isn’t a matter of paper shuffling. Effective program management is about leveraging technical expertise, extensive corporate experience, professional curiosity, and consensus building. Effective program management is not just processes, it’s solutions, it's managing the now but building to the future.
It's what turns lazily drawn lines into the greatest efficiency in the modern history of supply chains.
At TeAM, it's what we do every day.
Next project, please.
Technology, Automation and Management, an ISO 9001:2008 registered, Veteran-Owned Small Business (VOSB) is a premier solutions provider to the Federal Government. Specializing in program management, information assurance, systems engineering and web development, TeAM has served as a partner to the U.S. Government since 1985 and as proud ally of the Military Health System continuously since 1991. With offices around the National Capital Region as well as San Antonio, TeAM provides a flexible, responsive support system for Federal allies, combining big-business expertise with small-business agility.
|*Inpatient Auditor – Remote (BUMED)|
|*I&O - Training Specialist - Junior (BOB)|
|*I&O - Technical Writer - (EDD)|
|*I&O - System_Software Integration Engineer – Junior - (EDD)|
|*I&O - Subject Matter Expert (Technical) Transition Management- (EDD)|
|*I&O - Subject Matter Expert (Technical) Release Management- (EDD)|
|*I&O - Subject Matter Expert (Technical) Deployment Management- (EDD)|
|*I&O - Subject Matter Expert – Technical 2 (Software Asset Management) (O&S)|