Lean Design

For over a decade, a manufacturing metaphor has been used to bring about improvements in software development practices.  But even the originators of the metaphor recognize that it’s time for a change.  From SEI’s COTS-Based Systems (CBS) Initiative we hear:[1]

“Indeed, to many people software engineering and software process are one and the same thing. An entire industry has emerged to support the adoption of CMM or ISO-9000 models, and process improvement incentives have played a dominant role in defining roles and behavior within software development organizations. The resulting roles and behaviors constitute what we refer to as the process regime.

“The process regime was born of the software crisis at a time when even large software systems were built one line of code at a time. With some logic it established roles and behaviors rooted in a manufacturing metaphor, where software processes are analogous to manufacturing processes, programmers are analogous to assembly-line workers, and the ultimate product is lines of code. When viewed in terms of software manufacturing, improvements in software engineering practice are equated with process improvement, which itself is centered on improving programmer productivity and reducing product defects. Indeed, the manufacturing metaphor is so strong that the term software factory is still used to denote the ideal software development organization.

“The process regime might have proven adequate to meet the software crisis, or at least mitigate its worst effects, but for one thing: the unexpected emergence of the microprocessor and its first (but not last!) offspring, the personal computer (PC). The PC generated overwhelming new demand for software far beyond the  capacity of the conventional software factory to produce.

“The response to the growing gap between supply and demand spawned an impressive range of research efforts to find a technological “silver bullet.” The US government funded several large-scale software research efforts totaling hundreds of millions of dollars with the objective of building software systems “better, faster and cheaper.” While the focused genius of software researchers chipped away at the productivity gap, the chaotic genius of the free market found its own way to meet this demand—through commercial software components.

“The evidence of a burgeoning market in software components is irrefutable and overwhelming. Today it is inconceivable to contemplate building enterprise systems without a substantial amount of the functionality of the system provided by commercial software components such as operating systems, databases, message brokers, Web browsers and servers, spreadsheets, decision aids, transaction monitors, report writers, and system managers.

“As many organizations are discovering, the traditional software factory is ill equipped to build systems that are dominated by commercial software components. The stock and trade of the software factory—control over production variables to achieve predictability and then gradual improvement in quality and productivity—is no longer possible. The software engineer who deals with component-based systems no longer has complete control over how a system is partitioned, the interfaces are between these partitions, or how threads of control are passed or shared among these partitions. Traditional software development processes espoused by the process regime and software factory that assume control over these variables are no longer valid. The process regime has been overthrown, but by what?

“Control has passed from the process regime to the market regime. The market regime consists of component producers and consumers, each behaving, in the aggregate, according to the laws of the marketplace.

“The organizations that have the most difficulty adapting to the component revolution are those that have failed to recognize the shift from the process to the market regime and the loss of control that is attendant in this shift. Or, having recognized the shift, they are at a loss for how to accommodate it.

So it’s official, the manufacturing metaphor for software development improvement is needs to be replaced, but with what?  Let’s look to Lean Thinking for a suggestion.

How Programmers Work
A fundamental principle of Lean Thinking is that the starting point for improvement is to understand, in detail, how people actually do their work.   If we look closely at how software developers spend their time, we see that they do these things in sequence:  {analyze–code–build–test}.   First they figure out how they are going to address a particular problem, then they write code, then they do a build and run the code to see if it indeed solves the problem, and finally, they repeat the cycle.  Many times.  This is how programmers work.

An interesting thing about software development is that this cycle:  {analyze–code–build–test}, occurs both in the large and in the small.  Every large section of software will pass through this cycle (many times), but so will every small section of code.  A developer may go through these steps several times a day, or even, many times per hour.  Generally there is no particular effort, nor any good reason, to get the code exactly right the first time.  Try it, test it, fix it is a far more efficient approach to programming than perfection in the first draft.  Just as writers go through several drafts to create a finished piece of work, so do software developers.

The Wrong Metaphor
Because the software development cycle occurs both in the large and in the small, there have been attempts to divide the software development cycle and give each piece of the cycle to a different person.  So for instance, someone does the analysis, another person does the design, someone else writes code, a clerk does an occasional build, and QC people run tests.  This ‘assembly line’ approach to software development comes from the manufacturing metaphor, and basically, it just doesn’t work.

The reason a manufacturing metaphor does not work for development is because development is not sequential, it is a cycle of discovery. The {analyze–code–build–test} cycle is meant to be repeated, not to happen only once.  Further, as ideas and information move through this cycle, two things must be assured.  First,  information must not be lost through handoffs, and second, feedback from the cycle must be as short as possible.

The manufacturing metaphor violates both of these requirements.  First of all, handing off information in a written format will convey at best half of the information known to those who write the documents.  The tacit knowledge buried in the minds of the writers simply does not make it into written reports.  To make matters worse, writing down information to pass along to the next step in the cycle introduces enormous waste and dramatically delays feedback from one cycle to the next. 

This second point is critically important.  The cycle time for feedback from the test phase of the cycle should be in minutes or hours; a day or two at the outside.  Dividing the development cycle among different functions with written communication between them stretches the cycle out to the point of making feedback difficult, if not impossible.

Some may argue with the premise that software development is best done by using a discovery cycle.  They feel that developers should be able to write code and ‘Get it right the First Time”.  This might make sense in manufacturing, where people make the same thing repeatedly.  Software development, however, is a creative activity.  You would never want a developer to be writing the same code over and over again.  That’s what computers are for.

The Difference Between Designing and Making
Glenn Ballard of the Lean Construction Institute (LCI) sheds some light on this topic in a paper called “Positive vs Negative Iteration in Design”.  He draws a clear distinction between the two activities of designing and making.  He points out, “This is the ancient distinction between thinking and acting, planning and doing.  One operates in the world of thought; the other in the material world.”  Ballard summarizes the difference between designing and making in this manner:


The important thing to notice is that the goals of ‘designing’ and ‘making’ are quite different.  Designing an artifact involves understanding and interpreting the purpose of the artifact.  Making an artifact involves conforming to the requirements expressed in the design, on the assumption that the design accurately realizes the purpose.

A striking difference between designing and making is the fact that variability of outcomes is desirable during design, but not while making.  In fact, design is a process of finding and evaluating multiple solutions to a problem, and if there were no variability, the design process would not be adding much value.  As a corollary, Ballard suggests that iteration creates value in design, while it creates waste (rework) in making.  To put it another way, the slogan “Do it Right the First Time” applies to making something after the design is complete, but it should not be applied to the design process.

In the {analyze–code–build–test} cycle, notice that both analyzing and coding are design work.  There are many ways to create a line of code; individual developers are making decisions every minute they are writing code.  There is no recipe to tell them exactly how to do things.  They are writing the recipe for the computer to follow.  It is not until we get to the ‘build’ stage of the cycle that we find ‘making’ activity.  And indeed, all of the rules of ‘making’ apply to a software build:  No one should break the build, and every build with the same inputs, had better get the same outputs.

Cycles
This brings us to the last step of the software development cycle:  test.  Is testing ‘designing’ or ‘making’ or yet a third element?  In fact, designing tests is a creative activity, often part of the design.  Further, the results of tests are continually fed back into the design to improve it.  So in a very real sense, the test step is ‘designing’, not ‘making’.  Further, the ‘test’ step is what causes the cycle to loop back and repeat, it is what makes development work into a cycle in the first place.  In making, it is not desirable to test and rework; however, in development, repeating the cycle is the essence of doing work.  Development is basically an experimental activity.

There are other well-known cycles that bear mentioning here, and all of them end with a step which causes the cycle to repeat.  Some examples are:

1. The Scientific Method:  {Observe – Create a Theory – Predict from the Theory – Test the Predictions}  Graduate students know this well.
2. The Development Approach:  {Discover – Assemble – Assess} This bears a striking (and not accidental) resemblance to the software development cycle.
3. The Demming Cycle:  {Plan – Do – Check} – Act.  This is a three-step cycle {Plan – Do – Check}, followed by – Act once the cycle yields results.   A more complete definition of the Demming Cycle is: {Identify Root Causes of Problems – Develop and Try a Solution – Measure the Results}  Repeat Until a Solution is Proven, then – Standardize the Solution.  Demming taught that all manufacturing processes should be continually improved using this cycle.

In Search of Another Metaphor
If software developers spend their days in a continual {cycle of design–code–build–test}, we might gain insight if we find other workers who use a similar cycle.  In this quest we might eliminate workers in manufacturing, who are not involved in designing the product they produce.  On the other hand, in Lean Manufacturing, workers are continually involved in redesigning their work processes.  Despite this, it seems that software developers more closely resemble product designers than product makers, because a large portion of software development time involves designing the final product, both in the large and in the small.  But unlike product developers, software developers not only design, but also produce and test their product.

We might compare software developers to the skilled workers in construction, who often do a lot of on-site design before they actually produce work.  An electrician, for instance, must understand the use of the room to locate outlets, and must take framing, HVAC and plumbing into account when routing wires.   Software developers might also be thought of as artists and craftsmen, who routinely extend the design process right into the making process.

Learning Lessons from Metaphors
New Product Development, Skilled Construction Workers, Artists and Craftsmen – as we attempt to learn from these metaphors we must also take care not to go too far, as happened with the manufacturing metaphor.  The careful use of a metaphor involves abstracting to a common base between disciplines, and then applying the abstraction to the new discipline (software development) in a manner appropriate to the way work actually occurs in that discipline.   

Three useful abstractions come immediately to mind as we apply design and development metaphors to software development:

Abstraction 1:  Emphasize ‘Designing’ Values, not ‘Making’ Values
Code should not be expected to “Conform to Requirements” or be “Right the First Time”.  These are ‘making’ values.  Instead, software should be expected to be “Fit for Use” and “Realize the Purpose” of those who will be using it.   Disparaging software changes as ‘rework’ exemplifies the misuse of a ‘making’ value.  Since software development is mostly about designing, not making, the correct value for software development is precisely the opposite.  Iterations are good, not bad.  They lead to a better design.

Ballard states that:  “Designing can be likened to a good conversation, from which everyone leaves with a better understanding than anyone brought with them…  Design development makes successively better approaches on the whole design, likegrinding a gem, until it gets to the desired point….”

Abstraction 2:  Compress the {Design–Code–Build–Test} Cycle Time
Once we recognize that the {design–code–build–test cycle} is the fundamental element of work in software development, then principles of lean thinking suggest that compressing this cycle will generate the best results.  Compressing cycle time makes feedback immediate, and thus allows for a system to rapidly respond to both defects and change.

Based on this hypothesis, we may predict that the effectiveness of Extreme Programming comes from its dramatic compression of the {design–code–build–test cycle}.  Pair programming works to shorten design time because design reviews occur continuously, just as design occurs continuously.  Writing test code before production code radically reduces the time from coding to testing, since tests are run immediately after code is written.   The short feedback loop of the {design–code–build–test cycle} in all agile practices is a key reason why they produce working code very quickly.

Abstraction 3:  Use Lean Design Practices to Reduce Waste
Not all design iteration is good; iterations must add value and lead to convergence.  Many times a design will pass from one function to another, each adding comments and changes, causing more comments and changes, causing another round of comments and changes, in a never-ending cycle.  This kind of iteration does not produce value, and is thus ‘negative iteration’ or ‘waste’.

Ballard suggests the following ‘Lean Design’ techniques to reduce negative iteration, or in other words, obtain design convergence:

1. Design Structure Matrix.   Steven Eppinger’s article “Innovation at the Speed of Information” in the January 2001 issue of Harvard Business Review suggests that design management should focus on information flows, not task completions, to achieve the most effective results. The Design Structure Matrix is a tool that answers the question: “What information do I need from other tasks before I can complete this one?”
2. Cross Functional Teams.  Cross-functional teams which collaborate and solve problems are today’s standard approach for rapid and robust design with all interested parties contributing to decisions.  One thing to remember is to ‘let the team manage the team’.
3. Concurrent Design / Shared Incomplete Information.    Sequential processing results in part from the assumption that only complete information should be shared.  Sharing incomplete information allows concurrent design to take place.  This both shortens the feedback loop and allows others to start earlier on their tasks.
4. Reduced Batch Sizes.   Releasing small batches of work allows downstream work to begin earlier batches and provides for more level staffing.  It also is the best mechanism for finding and fixing problems early, while they are small, rather than after they have multiplied across a large batch.
5. Pull Scheduling.  Ballard notes:  “The Lean Construction Institute recommends producing such a work sequence by having the team responsible for the work being planned to work backwards from a desired goal; i.e., by creating a 'pull schedule'. Doing so avoids incorporation of customary but unnecessary work, and yields tasks defined in terms of what releases work and thus contributes to project completion.”
6. Design Redundancy. When it is necessary to make a design decision in order to proceed, but the task sequencing cannot be structured to avoid future changes, then the best strategy may be to choose a design to handle a range of options, rather than wait for precise quantification.  For example, when I was a young process control engineer, I used to specify all process control computers with maximum memory and disk space, on the theory that you could never have enough.  In construction, when structural loads are not known precisely, the most flexible approach is often to design for maximum load.
7. Deferred Commitment / Least Commitment.  Ballard writes:  “Deferred commitment is a strategy for avoiding premature decisions and for generating greater value in design. It can reduce negative iteration by simply not initiating the iterative loop. A related but more extreme strategy is that of least commitment; i.e., to systematically defer decisions until the last responsible moment; i.e., until the point at which failing to make the decision eliminates an alternative. Knowledge of the lead times required for realizing design alternatives is necessary in order to determine last responsible moment.
8. Shared Range of Acceptable Solutions  / Set-Based Design.   The most rapid approach to arriving at a solution to a design problem is for all parties to share the range of acceptable solutions and look for an overlap.  This is also called set-based design, and is widely credited for speeding up development at Toyota, decreasing the need for communication, and increasing the quality of the final products.

These eight Lean Construction techniques, particularly set-based design, is being tested in construction and expected to result in dramatic improvements in design time (~50%) and construction time (~30%).  In addition, work can be leveled throughout the project, better, more objective decisions are expected.

The following two additional Lean Design techniques are particularly applicable to software development:

9. Frequent Synchronization.  It is widely recognized in software development that daily (or more frequent) builds with automated testing is the best way to build a robust system rapidly.
10. The Simplest ‘Spanning Application’ Possible.  This is a software development technique  particularly good for testing component ensembles and legacy system upgrades. The idea is not to implement module-by-module, but implement a single thread across the entire system, so as to test the interactions of all parts of a system along a narrow path.

____________________

[1] From draft version of Chapter 1 of Building Systems from Commercial Components,  [Addison-Wesley, 2001] by Kurt Wallnau, Scott Hissam, and Robert Seacord; downloaded from SEI COTS-Based Initiative website.


Screen Beans Art, © A Bit Better Corporation

Component-Based Software Development

Around 1800, Eli Whitney proposed manufacturing rifles with interchangeable parts, instead of crafting each rifle individually. Widely regarded at the beginning of mass production, the concept of interchangeable parts led to a dramatic increase in rifle production capacity while delivering the additional benefits of consistent operation and easy field maintenance of weapons.

Component-based systems represent a paradigm shift in software development similar to that of using interchangeable parts in manufacturing. A component-based system is built of standard, reusable parts that become the fundamental building blocks of future software. Component-based systems promise numerous benefits, including flexibility, scalability, and maintainability.

The promise of component-based systems has been difficult to realize. The reality is that even through the last decade, monolithic systems have dominated corporate IT. And after a few years, monolithic system become legacy systems, because they are not flexible, changeable, or easy to connect to other systems. A company will get acquired or acquire other companies or spin off divisions, and all of a sudden, the monolithic systems get in the way of progress.

During the 1990's more software by far was developed for the Internet that was developed for all the corporations in the world. But Internet software was typically developed vary rapidly, with expediency taking over where architecture once reigned. And guess what - Internet software is largely component-based. It may seem like heresy to 'true' software developers, but an Internet startup could get a shopping cart and a search module and a merchant account and a product display package from other Internet startups. There is Mapping software and travel planning software and collaborative filtering software, and when you look at it closely, these are true components. Web sites can be rapidly manufactured with 85% components, 15% glue.

Now it's time to bring components to the corporate world, and they are headed our way under the name of Web Services. Here's a quote from the January 3, 2002 CBDi forum newsletter:

Web services provide formalized separation of concerns at a usable level of abstraction and you can implement web services right now with most of the current versions of platforms and software tools. Web services are fundamentally a low-cost technology investment that easily extend what you already have to provide real business value. First look for internal applications, there are many opportunities to simplify internal integration. Second look externally at public (non secure) or private B2B applications, and make sure those security and privacy budgets address the needs of Web services. Look at the Web services that IBM and Microsoft’s customers are already delivering.

The Impact of Logistics Innovations on Project Management

A project is a “temporary endeavor undertaken to create a unique product or service” (Project Management Institute, 1996). Projects include building a structure, developing a product, and executing a contract. Logistics “plans, implements, and controls the efficient, effective flow and storage of goods, services, and related information from the point of origin to the point of consumption” (Council of Logistics Management, 2000). Logistics is usually thought of in connection with military or manufacturing operations. However, there can be projects involved in logistics (eg. building a bridge to move troops) and logistics involved in projects (eg. supplying material to a construction site). It is not surprising, then, that these two disciplines interact and learn from each other. In this paper, great events in logistics are examined to uncover their impact on project management.

Great Logistics Feats of Antiquity
In May of 218 BC, 29 year Hannibal led about 40,000 troops, thousands of horses, and 38 elephants over the Pyrenees and Alps from Spain to Italy, a feat which had been considered impossible. During this 15 day ‘project’, his troops built jetties and rafts for the elephants to cross the Rhone River, raided towns for provisions, and struggled through avalanche-blocked mountain passes while under attack. Many of the troops and most of the elephants were lost, but even in this weakened conditioned, Hannibal defeated the Roman army that awaited his arrival. (Encyclopedia Britannica: Hannibal)

Hannibal has been singled out as a forerunner of grand strategy in military campaigns. His superb logistics while crossing the Alps is a precursor of military logistics today, a discipline in which the US military is considered the world leader. The routine logistics of military operations are interspersed with unique, temporary ‘projects’, of which Hannibal’s crossing is a prime example. The project management challenges of crossing the Alps included fixed resources, limited time, physical obstacles and troops with mixed allegiances who were ill-suited to the task. The techniques Hannibal used to meet these challenges (planning, field engineering, rapid movement, periodic re-supply, and attentiveness to troops and animals) are standard military practice today. (Encyclopedia Britannica: Strategy)

There are other great feats of antiquity which are forerunners of today’s project management practices. Building the pyramids comes immediately to mind. The Great Pyramid in Egypt was built around 2500 BC. It took about two decades and somewhere between 20,000 and 100,000 laborers to erect. Stone was cut with crude hand tools, transported without wheeled vehicles, and put into place without lifting machinery. This “masterpiece of technical skill and engineering ability” remains “perhaps the most colossal single building ever erected on the planet”. No taller building was built until the 19th century. (Encyclopedia Britannica: Giza, Pyramids of; Building Construction)

Construction projects today are not significantly different than those which built the pyramids. An architect designed the building, materials were obtained from quarries and transported to the site, experts in various ‘trades’ prepared the materials and constructed the pyramid. Built to a fixed plan, time and resources were more or less unlimited for the pyramids (unlike today).

There is another impressive feat that has been executed from the most ancient of times and continues to this day: The Event. Perhaps it is a wedding or a funeral or a coming-of-age ceremony – just about any large gathering has always required serving a lot of food to a lot of people in a very short time. Perhaps several clans gathered once a year, and there was a woman who was particularly good at organizing such events. Planning, gathering food, attending to living quarters, cooking, serving, might be a tradition or a ritual, but the event always came off best if someone behind the scenes was coordinating it all. In some sense, the most seasoned project managers throughout various cultures and times might be the event organizers who really knew how to throw a good party on a inflexible schedule with limited resources.

From Logistics to Project Management
All of the knowledge areas of project management were are developed in these three examples of logistics from antiquity: staging a celebration, managing construction, and executing a military movement. A celebration required excellent procurement, scheduling, quality and resource management. Construction projects required superior planning, managing a fixed scope over a long time, procurement and human resource management. Military movements needed excellent execution, careful management of fixed resources, precise timing, superior human resource management and continual risk assessment.

Viewed from a different perspective, advances in logistics might be thought of as starting with project management. For instance, military logistics may start with unique projects, like ferrying elephants over a river, but once the technique is developed, it can be reused to ferry other large items over a river. Feeding a large number of relatives may be a project the first time it is done, but feeding hundreds of people a sit-down dinner in fifteen minutes is routine logistics at conventions held every day. Even the pyramids were more or less standard burial structures for a period of over 500 years. (Encyclopedia Britannica: Pyramid)

The disciplines of logistics and project management overlap in such a way that it is not always possible, or even necessary to tell them apart. Projects that are repeated and standardized may become exercises in logistics, while the first implementation of a logistical solution might be considered a project. Since both disciplines often address similar problems, there is likely to be a significant transfer of ideas from one discipline to the other.

Traditionally, logistics has been the focus of much study and innovation. Since logistics is usually applied to on-going operations, improvements in logistics usually result in increasing benefits over time. If, for example, the cost of a single car can be reduced by a dollar, then in a factory making 250,000 cars annually, a quarter million dollars will be saved each year.

The author has observed that major advances in logistics usually make their way into project management in ten or fifteen years, since the same forces that spurred the paradigm shifts in logistics are usually at work in the broader economy. Below are two examples of logistics innovations moving from manufacturing to construction in one or two decades.

Standardized Parts
Two hundred years ago, the US military wished to procure 40,000 rifles. At the time, rifles were made by skilled workers who fashioned one rifle at a time. Each rifle was different from the next, so maintenance required individually fashioned parts. Unfortunately, there were not enough skilled workers in the country to make the necessary rifles, let alone maintain them.

In 1798, Eli Whitney, the inventor of the cotton gin, proposed that he could make an incredible 10,000 rifles in two years by designing machinery (templates and fixtures) to make standardized, interchangeable parts. This was a major paradigm shift for manufacturing. It took Whitney over ten years to perfect his manufacturing system, which is regarded as the birth of the tool and die industry. Ultimately the system was successful, and the rifles in the war of 1812 were produced much faster, had higher quality, could be more easily maintained, and cost a great deal less than previous rifles. (Encyclopedia Britannica: Eli Whitney; Tool and Die Making) (Taylor, 1990)

In the 1820’s, US sawmills began producing standard dimension lumber in quantity, and in the 1830’s cheap machine-made nails became available. The first ‘balloon’ frame building is thought to be a warehouse in Chicago built in 1832. Standard construction techniques rapidly evolved: 2x4 studs placed 16 inches on center, 2x10 joists spanning up to 20 feet, stability provided by ¾” sheathing through which windows and doors were cut. Machine-made nails were easily driven into the soft wood and a building could be rapidly assembled from manufactured materials by (relatively) unskilled workers. Houses are still built this way, almost two centuries later. (Encyclopedia Britannica: Building Construction)

It’s easy to visualize how standardized, interchangeable manufacturing parts influenced the development of standardized, interchangeable building parts. The entire direction of the construction industry was heavily influenced by Eli Whitney’s rifles. Although a construction project was still a unique and temporary event, it took on many of the features of standardized manufacturing.

Mass Production
In 1908, Henry Ford introduced the Model T Ford. It was so successful that Ford had to continually invent faster, cheaper ways to manufacture the car. Over the two decades of the Model T’s life, Ford perfected the assembly process, introducing the first moving assembly line in 1913. In 1927, the River Rouge plant received just enough iron ore each morning to make a day’s worth of cars; 28 hours later the ore had become the steel in a finished car. In two decades, Ford produced almost 17 million Model T’s, displacing many horses in the process. The Model T precipitated one of the most rapid and pervasive changes of the lifestyle of common people in history. (Encyclopedia Britannica: Henry Ford)

The steel coming into Ford’s plant also moved into the building industry. During the 1920’s between World War I and the Depression, steel framed high-rise buildings came to the cities of America. As these buildings went up, specialized trades became more important, since framing, sheathing, plumbing, heating, elevators, etc. each required full time specialists. (Encyclopedia Britannica: Building Construction) The various trades required someone to sequence their activities, supply materials, assure safety standards were met, and generally manage the project. Thus the construction project manager emerged to coordinate a complex series of specialized but interrelated construction tasks, each of which contributed to the completion of the building. A well-managed construction project bears quite a few similarities to an assembly line.

Just In Time
Henry Ford’s River Rouge plant was an excellent example of Just-in-Time manufacturing, but his ideas on inventory were not widely held. After World War II, operations research developed theories on inventory management which determined optimized lot sizes, reorder points, and distribution stocking levels. In the 1970’s, a radically different theory was developed in Japan, spearheaded by Toyota Motor Corporation. (Shingo, 1981) The concept that inventory should be kept at a minimum, lots should be very small, and products should be built ‘on demand’ rather than stocked, ran contrary to the current manufacturing ‘wisdom’ in the US. However, Just-in-Time models proved to have significant advantages in capital reduction, plant throughput, quality assurance and market responsiveness.

The benefits of Japanese manufacturing techniques began to dawn on the US manufacturing community in the 1980’s. Eliyahu Goldratt’s 1984 novel, The Goal, popularized Just-In-Time concepts and introduced the ‘Theory of Constraints’. (Goldratt, 1984) This theory suggested that finding and ‘feeding’ the bottleneck workstation in a manufacturing plant would allow all other processes to hold to a steady and predictable pace. Pacing manufacturing with the ‘constraint’ workstation required the manufacturing logistics community to abandon many long-held beliefs about inventory management. But the new logistics paradigm worked so well that it rapidly became standard practice in manufacturing and distribution logistics.

If the author’s thesis that logistics innovations make their way into project management in about a decade is true, then Just-In-Time concepts or their derivatives should have impacted project management in the mid 1990’s. Sure enough, in 1997, Goldratt published Critical Chain, a novel in which he applies the Theory of Constraints to Project Management. (Goldratt, 1997)

The Theory of Constraints is useful in project management when multiple projects are competing for the same resources. Similar to its application in manufacturing, Theory of Constraints project management finds and ‘feeds’ critical path tasks and bottleneck resources. Most of the ‘common wisdom’ embodied in project scheduling techniques must be re-thought for this to work in the project environment. For instance, task durations are planned at 50% probability of completion. Thus it is expected that half of the time, tasks will be late. Indeed, it has proven to be difficult to abandon the perception that it is ‘good’ for all tasks to be completed within their estimated time.

Just-In-Time and Theory of Constraints focus on optimizing the entire flow of material or work, instead of sub-optimizing individual areas. The organizational structure and reward system in the US is often set up to reward individual effort, without much regard to (or understanding of) the impact of that effort on the ‘big picture’. Since World War II, the US economy has became increasingly globalized, and countries with different cultures and reward systems are selling products in the US. Unconstrained by ‘standard practice’, these countries consider and optimize manufacturing from a different, often broader perspective. This globalization of the economy has played a large role in bringing Just-In-Time and the Theory of Constraints to logistics.

Globalization has influenced project management also. In the electronics industry, very rapid time-to-market with ‘cast-in-stone’ release dates are required for new products, and Theory of Constraints project management is being widely applied to meet these challenges.

Lessons for the Information Industry
One of the fundamental driving forces behind paradigm shifts in logistics is an overwhelming need for lower cost and less specialized labor, which leads to standardization. This is often followed by an opposing force, the desire for customization.

Standardization
In 1800, the lack of enough skilled workers to make rifles in the face of an impending war was an unacceptable situation that demanded the invention of standardized, interchangeable parts. In the early 1900’s, the demand for inexpensive transportation that allowed ordinary people to travel great distances was a key forcing function in the emergence of mass production.

It’s easy to see this drive for standardized, interchangeable parts at work in the information industry. In 1983, the IBM PC took the world by force, rapidly becoming the standard of the industry and soon outstripping IBM’s ability to maintain control. (One can imagine that Henry Ford had to invent the assembly line to avoid the same fate as IBM.)

Standardized Internet access, embodied in standard web browser capability, has driven the on-line revolution that is sweeping the country. A single cell phone frequency in Europe has spurred European cell phone use to a far greater level than in the US, which has multiple cell phone frequencies. In the face of a huge demand for a standardized document format, Microsoft jeopardized its position by releasing incompatible versions of Microsoft® Word, while Adobe® Acrobat® filled the vacuum with a standardized ‘Portable Document Format’ (PDF).

Standardization is driven by an insatiable need which cannot be satisfied at an acceptable price by the available techniques or skilled people. Today the software industry has an enormous gap between the need for programming and the available programmers. It should be obvious to students of economic history and that the software development environment is ripe for a massive switch to standardized, interchangeable, mass-produced components.

Mass Customization
As brilliant as Henry Ford was, he missed out on a major trend that overtook the success of his Model T. After two decades, people began to get tired of black (the only color of the Model T). Copying Ford’s methods, other manufacturers figured out how to make inexpensive cars, and they started adding new features. Ford’s failure to recognize the shift in customer desires caused his company to loose its overwhelmingly dominant position in the industry. (Encyclopedia Britannica: Henry Ford) In the 1970’s the same thing happened to the US car makers – their failure to respond rapidly to the huge demand for fuel economy and high quality allowed Japanese car-makers to gain a large market share.

It is not surprising that one of the latest logistics innovations is mass customization, enabled by the information revolution. Dell Computer builds computers only after receiving an order, and ships the customized computer within days. Anderson Windows custom-builds windows to fit individual residential houses. Mass customization, a key advance in new product development and logistics, requires modular architectures and standardized components that are not assembled until individual customers place orders. Sophisticated information system support, especially in order management, is necessary for successful mass customization. (Gooley, 1998)

Products are not the only things that can be customized; the Internet has abundant examples of customized marketing, customer service, and information delivery. ASPs (Application Service Providers) are rapidly positioning themselves to ‘rent’ applications through the web. ASPs sell common applications that can be rapidly configured to meet individual customer requirements. In fact, the appearance of ASPs is probably a direct result of the pressure to produce ‘standard’ software in the face of a severe programmer shortage. ASPs success will depend on how they manage to retain the advantages of standardization while moving toward mass customization.

Software project management is also being influenced by mass customization. Instead of finalizing system requirements at the beginning of a project, it is considered good practice these days to allow users and customers to modify the requirements on-going basis as the software is being developed. The concept of continuing user feedback during software development started with the spiral life cycle, originally proposed in 1988 (Boehm, 1988), and evolved to The Unified Software Development Process (Jacobson, 1999). Common wisdom today holds that IT projects should iterate toward an increasingly competent set of capabilities through incremental builds which allow continued customization of the software during its development lifecycle.

Summary and Conclusion
Logistics innovations are not accidents. They are driven by economic forces which demand a paradigm shift to keep an undesirable situation from overwhelming the economy. Once the paradigm shift occurs, the forces that caused it continue to exert pressure on other areas. Over time, the new paradigm will make its way into project management practice.

Often the economic driving force behind innovation is an overwhelming need for something in far greater quantities at far cheaper prices than current practices allow. This drives innovation in the direction of standardization. However, once standardization becomes the common paradigm, a shift in expectations usually occurs. Customers begin to expect tailored products, without increasing the cost, of course. This drives innovation in the direction of mass customization.

Another driving force behind innovation is globalization, which brings unique perspectives to logistics and project management. A fresh look at a problem by someone who doesn’t know the ‘right’ answer can lead to out-of-the-box thinking and new approaches.

By looking for trends in economic driving forces and noting innovations in logistics, project managers can predict the forces which will drive project management practices in the future.
____________________
References
Barry W. Boehm, “A Spiral Model of Software Development and Enhancement”, IEEE Computer, Volume 21, Number 5, May, 1988, Pages 61-72

Council of Logistics Management, “Definition of Logistics”, retrieved March 29, 2000 from http://www.clm1.org/

Goldratt, Eliyahu, Critical Chain, North River Press, 1997

Goldratt, Eliyahu, The Goal, North River Press, 1984

Gooley, Toby B., “Mass Customization: How logistics makes it happen”, Logistics Management and Distribution Report, April, 1998, retrieved on March 29, 2000, from ‘Logistics Online’

Jacobson, Ivar, Booch, Grady and Rumbaugh, James; The Unified Software Development Process, Addison-Wesley, 1999

Project Management Institute, Guide to the Project Management Body of Knowledge, 1996, The definition of ‘Project’ is in Section 1.2, Page 4.

Shingo, Shigeo, Study of ‘Toyota’ Production System form Industrial Engineering Viewpoint, Japan Management Association, 1981

Taylor, David, Object-Oriented Technology, A Manager’s Guide, Addison-Wesley, 1990, Reference to Eli Whitney, Pages 85-87

Published in Proceedings of PMI Seminars; Symposium 2000; Houston, Texas, September, 2000

Screen Beans Art, © A Bit Better Corporation