Open Innovation - Not As Different As You Think

Open innovation has been a fad in industry the last few years.   There are consultants who are doing seminars and writing books about it. (Heck, I’ve even addressed it in some seminars that I teach.)  But when you peel aside all the hype, it is not that different from how many companies have approached innovation for years.  But here is the problem.  While open innovation isn’t different from what has often been done, it is often done badly.  Innovation has been poorly managed for years and we are finally waking up to that fact.

Let me take a minute to clarify what I include in the term “Open Innovation.”  The term has been defined by many individuals in many different ways.  For my purposes, I will go with Henry Chesbrough’s definition, (1) “Open innovation is a paradigm that assumes that firms can and should use external ideas as well as internal ideas, and internal and external paths to market, as the firms look to advance their technology.”  Let’s look at how innovation is often managed today in the areas of using external product ideas, external process ideas, and external paths to market.

External Product Ideas

A driving principle in product development is to address your customer’s needs.  This idea has been embedded in innovation efforts for hundreds, if not thousands, of years.  The marketing departments in the 21^st century industry conduct focus groups and market research to determine what the customers want. They then turn to R&D and ask them to create it.  In some cases, companies will even let the engineers and scientists talk with the customers to better understand the potential use and application.  Occasionally, customers will even adapt a product to create an entirely new innovative productive category.  An example of this is the mountain bike industry.  Mountain bikes, as a market segment, did not exist in the 1970s.  Some cyclists started to modify ordinary street bikes and as their numbers and enthusiasm grew, the bicycle manufacturers finally took notice and began to build the new style bicycle.

The challenge for most companies with respect to open innovation of new products is the old “not invented here” syndrome.  The product managers and technologists have invested time, energy, and sometimes their reputation on their products.  Their job is to create innovative new products.  If someone else comes up with the idea, it is perceived as a threat to them.   They have no ownership in the new innovation that is suggested by the customers.  They are willing to embrace the customer needs that “tweak” the current product or that align with the innovation projects they have underway.  However, there is often resistance to any truly novel product idea that comes from a customer. 

So what should a business do?  A significant portion of the innovation effort (that means budget and people) should be focused on customer innovation.  This is not to exclude internal innovation efforts, but rather to create a parallel path that will intersect with selected product and customers.  This is an organizational response to the challenge of open innovation for new products.  There needs to be an advocate in the business for the open innovators; an advocate whose primary purpose and measurements are the identification and adoption of open innovation ideas. 

External Process Ideas

Many companies are already using a form of open innovation for process innovation.  Companies benchmark their processes for speed, cost, and quality against competitors or industry norms.  When they see a performance gap, they hire a company to fix their process.  This may be an IT firm to bring in a new application.  That is the reason many companies transitioned to ERP.  This may be a process automation firm to re-engineer a manufacturing or business process.  Often the entire process is outsourced to a company that specializes in that process.   Numerous companies have outsourced their entire delivery process to companies such as FedEx and UPS.   This is open innovation.  A company is using an innovative technology to fundamentally change the way they do business.

The challenge here is that many companies don’t think of this as a technology innovation activity, but rather as a sourcing activity.  They let their purchasing department manage the innovation.  Now, I like the people in purchasing, but their processes typically are not optimized for managing innovation contracts.  They usually want to negotiate and manage a contract with a fixed and specific definition of what is being purchased, a specified schedule, and no changes.  However, when conducting open process innovation, there is only a general description of what must be done – the details must be discovered, the timing of many activities is unpredictable, and there are numerous changes.  It is not surprising that chaos, frustration, and animosity are often the by-products of this approach.

So what should businesses do?  They need to create a process or procedure for how process innovation contracts will be managed.  They need to train the purchasing people who will be responsible for these contracts in the nature of innovation and how they can accelerate it and refine it with the terms of the contract.  In many cases, a process innovation contract will also require the oversight of an in-house technical expert.  The roles of that individual with respect to supplier interaction and direction must also be clearly defined.

External Paths To Market

The last area of open innovation is the use of an innovation partner to expand your products into new markets.  Again, may companies have at least tolerated this if not out-right promoted it for years.  They create a distribution network and let the distributors becomes the experts on product application in their local market segment.  A recent twist on this approach is the creation of an open platform that allows others to create applications that they sell using the platform as a foundation.  The more items they sell, the greater the need for the basic platform.  A perfect example is the App Store at Apple.

The typical challenge in this area has been one of managerial neglect.  As long as the distributor kept ordering product, the parent company often did not pay much attention to how the distributor sold the product.  The distributor may make modifications to the product or prepare additional product literature that is customized to the local application.  That was not of concern to the parent company.  What is missed here is that one distributor’s good idea may be of value to other distributors in other markets, but often there is no avenue for sharing that information.

So what should a business do?  Open up a forum, either face-to-face or online, where distributors and retailers can share their ideas and get credit for them.  Unless there is “something in it” for the distributor, there is no incentive to share ideas.  This innovation forum should reward and recognize innovative applications on a regular basis.

The concept of open innovation is not difficult to understand.  It just isn’t something that most companies do.  The organization and management systems do not encourage or reward it.   

(1) Chesbrough, Henry William (1 March 2003). Open Innovation: The new imperative for creating and profiting from technology. Boston: Harvard Business School Press.

PI - An Inspiration For Innovation

Well we have just past the best PI-Day of the century.  I made certain to tweet “Happy PI Day” when it was 9:26 am on my watch last Saturday.  (3.14.15.9.26)  And I had a piece of pi(e) for dinner that evening.  I am sure many of you are saying, “I still don’t know what you are talking about – and I don’t think I care.”

Well if you remember back to your middle school geometry class you learned that the ratio of the circumference of a circle over the diameter always equalled the value for π, 3.1415926….  And unless you are an engineer or scientist, you probably never used that useful piece of information on anything since you took the SAT exam.  This past Saturday was PI-Day because the date represented the first five digits of PI, 3/14/15, and at 9:26 am we had eight digits of pi. 

By now you are probably thinking I was the inspiration for the Big Bang Theory TV show.   But I really do find that pi is an inspirational number for innovators.  Not the actual value of pi but the concept of certainty and infinity mixed together.  The ratio of the circumference divided by the diameter for every circle is always pi.  It doesn’t matter how big or small the circle.  It doesn’t matter what part of the world you are in.  It doesn’t matter what the circle is enclosing or representing.  The value is always the same.  And yet the value is infinite.  There are endless possibilities for the value of pi.   How can that be?

Pi is an irrational number.  It cannot be represented with a finite number of digits or a common fraction.  The digits to the right of the decimal point have no repeatable pattern.  The precise value of pi is only limited by how far you want to go with your division.  I went out to the first eight digits and sent a tweet.  There is a website that has the first one million digits to pi – and there are still more digits after that.

So why is pi an inspiration for innovation?  It reminds me that innovation can occur even in the standard everyday things that are part of our life.  The ratio for the circumference over the diameter is always the same but the actual number can change by just looking past what you have right now.  

Let’s take an example.  For thousands of years people moved stuff around on land in carts drawn by horses and oxen.  Then came the innovation of steam and soon there were locomotives pulling carloads of stuff across country.  Numerous smaller innovations happened with locomotives and rail cars to improve their capacity, speed, and reliability while lowering costs.  But this innovation required rails to be laid in order to get stuff where you wanted it to go.  Something else was needed and a new innovation using an internal combustion engine with the cart became another method for moving stuff was available, the car and truck.  Again multiple innovations have continued to improve speed, capacity, and reliability while lowering costs.  Of course we also have the innovation of powered flight which moves stuff even faster across long distances.  And who knows what the next innovation may be.  The basic function is unchanged – move stuff from one location to another, but innovation has been constantly changing and improving how that is done. 

That is just one field.  There is also tremendous innovation that has occurred over the centuries in agriculture, medicine, household appliances, and the list can go on and on.  The function that is served by the innovative product is the same as earlier products, but the innovation finds a better way to do that function.  Just like the ratio of the circumference over the diameter stays the same for every circle, but the precise value for pi can be continually refined and improved.   

So when you want to noodle about a new innovation, you don’t have to start reading science fiction and imagine what life would be like in a galaxy far, far away. Just take a current, everyday activity or function and try to find the next best way to do that.  Assume that for everything we do in life, there are an infinite number of ways to do it.  Just go to the next one and see if it can make life a little easier, faster, cheaper, or more fun.  

It is like finding the next digit to the answer for the value of pi.    

  

Put A Stake In It!

I was recently asked a question about the role of stakeholders in project closure.  This is a great question.  Many projects get close to completion and then fumble at the end.  The project doesn’t formally close; people just stop working on it.  Deliverables are almost, but not quite, completed.  Project records and archives are not consolidated and made searchable.  While some individuals may have personal learning from the project, formal lessons learned are not identified and disseminated throughout the organization.  This failure can be directly tied to a failure by project stakeholders.

There are many different stakeholders on a project.  The identity and quantity of stakeholders varies based upon the goals of the project and the project management methodology.  For the context of project closure, there are three categories of stakeholders.  One category is the customers or users of the project results.  The second category is the sponsor or senior managers who provide project oversight.  The third category is the project team itself.  Each of these categories has a unique role and responsibilities during project closure.  Some individuals may be in multiple categories; but that is because they have multiple roles on the project.  For example, a member of a project team may also be the user of the project result.  Let’s look closer at each category.

Customer or User Stakeholders

These stakeholders typically have a leadership role at the beginning and end of a project.  At the beginning they must set the requirements or expectations for the product, service or result created by the project. At the end of the project, when project closure approaches, they review and either approve the project results or reject them.  Depending upon the complexity of the project result, this review may take a significant amount of time and effort and should be an identified activity in the project plan.  The responsibility of the stakeholder is to engage with the team and do a thorough review in a timely fashion.

Several problems can occur with these stakeholders.  They are listed below with solutions.

·        Often during the review of the project result the stakeholder will identify something that is not satisfactory to them.  In fact, I now expect that to occur.  Suggested solution: I normally plan a two-step review.  The first review occurs near the end of the project, but completes soon enough that there is time for the project team to resolve any minor issues or misses in the project product, service or result without delaying the project end date. 

·        A second problem is the stakeholder who keeps asking for, “One more thing ….”  This will lead to scope creep.  Suggested solution: A technique I use to limit this effect is to create a “Punch List.”  This is a list of specific items that must be completed.  When those items are done, the project deliverables are complete.

·        A change of stakeholder from the beginning of the project until the end of the project leads to a shift in the user requirements expectations.   Suggested solution: Document the requirements at the beginning of the project.  If stakeholders change during the project meet with the new stakeholder to review the requirements.  If using a stage-gate methodology, review the requirements at the beginning of each stage.

·        Stakeholder does not conduct a thorough review until after the project is terminated.  At that time they find critical defects but there is no team available to work on these issues. Suggested solution: Ensure the commitment from the stakeholders to do a review before the end of the project.  Provide a test/inspection plan for them to use that demonstrates all aspects of the project product, service or result.   

Sponsor or Senior Management Stakeholders

The role of these stakeholders is normally defined within the project management methodology.  They often are responsible for approving the project and setting project priority.  They may conduct periodic reviews or gate meetings.  Normally they are also responsible for providing timely access to the resources needed to complete the project.  At the end of the project, there is usually a final gate review meeting and a reassignment of resources.  

This leads to the problems listed below and the suggested solutions.

·        The disappearing project team occurs when core and extended team members are reassigned before their work is complete.  The activities at the end of the project are often documentation or administrative in nature; which some people feel is not important.  The stakeholders are anxious to assign the team members to other projects that have needs.  Suggested solution: Stakeholder should conduct a functional review to ensure completion of all functional activities before reassigning resources.

·        The final gate review never occurs.  The absence of this review means that a formal handoff of responsibility for issue resolution from the project team to the sustaining organization does not occur.  Suggested solution: Link the rewards and recognition for the core team to the final gate.  They will then be motivated to ensure that the gate meeting occurs.

·        Lessons learned session is not completed and the results disseminated throughout the organization.  The stakeholders do not require a retrospective look at the project to build on the good points and improve the weaknesses in the approach.  Suggested solution: In my experience this session will not occur unless the stakeholders demand a lessons learned report from the project team.  Therefore, demand one.

Project Team Member Stakeholders  

Project team members are also project stakeholders.  Their role at project closure is to complete all of the closeout activities.   They need a plan for closure and the commitment to implement the plan.  Many times they are already thinking about their next project or next job, and they closeout activities are neglected.

This leads to the problems listed below and the suggested solutions.

·        The project team needs a plan for closure and transition.  Often the project plan just goes to the completion of the key deliverables and then stops without closing down the project activities, such as completing documentation, archiving project records, conducting a lessons learned session, and resource reallocation.  Suggested solution: The project management methodology must spell out the need for the closeout and transition plan.  When the project plan is approved, the senior management stakeholders must ensure that portion of the plan is appropriately staffed and scheduled. 

·        Core team members transfer off the project before closure.  Suggested solution:  A strong core team will often hold each other accountable to ensure that all work is done as the project approaches closure.  Another technique I have used is to link rewards and recognition to full project closure.  The core team incentives do not begin for any of them until the project reaches complete closure.

When stakeholders engage and fulfil their responsibilities through closure, the probability of project success is increased in addition to the opportunity for organizational learning.

Project ROI Deception

Most organizations that I work with require a Return on Investment (ROI) calculation before making a decision to start an innovation or new product development project. This makes sound business sense.  We should consider the cost and benefit of a project before undertaking it. But with innovative new products, these ROI techniques can sometimes deceive us. 

The problem is that the most commonly used ROI techniques are built upon a set of project conditions that often are not valid for your innovation project.  If those conditions are not understood and accounted for, the wrong decision can be made.  You may choose to do a project you shouldn’t do, choose not to do a project you should do, or take the wrong approach for a project.  Let’s look at the most commonly used project ROI measures.

Breakeven Analysis

The Breakeven Analysis places the emphasis of the ROI calculation on the size of the market opportunity.  Breakeven Analysis answers the question, “How many units must I sell to generate enough money to pay for this project?”  It is determined by dividing the cost of the project by the gross margin of a unit of the product.  If it is likely that you can sell more than the breakeven point; do the project.  If not; don’t do the project.

The deception with this technique is estimating the size of the market.  For truly innovative products, the market size is unknown.  There is no existing product or service that can be used to estimate the size of the market.  Ken Olsen, the founder of Digital Equipment Corporation (DEC) is famously quoted as saying in 1977, “There is no reason that anyone would want a computer in their home.”  But the market forecast is not always underestimated.  Alex Lewyt, the president of Lewyt Vacuum Company said in 1955, “Nuclear powered vacuum cleaners will probably be a reality in ten years.” 

So how do you estimate the size of the market?  This is one where I recommend that you do a three point analysis, best case, worst case and most likely.  Consider the opportunity and risk with each case.  But don’t overlook the need to stimulate demand.   You can create a market with advertising, product placement, endorsements, and marketing events.  Innovative product development projects need to be about more than just the cool technology.  Include in your product development project the promotion efforts to make your product go viral in the market.

Payback Analysis

The Payback Analysis places the emphasis of the ROI calculation on time to market.  Payback Analysis answers the question, “How long until I have generated enough money to pay for this project?” It is determined by dividing the cost of the project by the amount of gross margin the new product sales generate every month (or year, or day, or fortnight).  The answer is the number of months until payback.  The business must then decide if they can wait that long to get all the money back.

There are two points of deception with this technique. The first is the cost of the project.  The easiest way to get a rapid payback is to have a very small project cost.  Of course that typically means that you won’t do a truly innovative new product, but instead just make a minor incremental improvement on an existing product.  The second point of deception is that Payback Analysis doesn’t take into consideration what happens after the payback point in time.  Do product sales grow exponentially or do they flatten out and quickly die off?  We don’t know with Payback Analysis, we only know how fast we earn our money back.

With these inherent deception points, why would anyone use Payback Analysis?  If your company is in a cash flow bind, Payback Analysis is very helpful.  But if you are not strapped for cash, using Payback Analysis to decide which project to do will almost always decide against innovation.  The Payback Analysis is the most risk adverse of the ROI calculations.  Frankly, I don’t recommend it for new product development.  It is good for incremental improvement projects and “one-off” projects; but it does not adequately consider the benefit of new innovation.

Net Present Value/Internal Rate of Return

I will discuss Net Present Value (NPV) and Internal Rate of Return (IRR) together since they use the same equation, just solving for a different variable in that equation.  These techniques consider the long term value of the project.  They are a time value of money calculation.  They sum the incremental cost of the project and the incremental benefit of the project over some period of years and discounted at some time value of money discount rate.  Using the formula you either solve for the value using a fixed discount rate, or you solve for the rate which results in the cost being equal to the benefit.  A high value or a high rate means you have a good project.

The point of deception in this technique is determining the window of opportunity.  The calculation assumes some number of years of sales that is usually based upon an estimated product lifecycle.  What is often overlooked is the effect of competition on the sales during the lifecycle.  Innovative products normally have little or no competition at the beginning of their lifecycle.  The gross margins at this time are usually higher than later in the life cycle when competition is in the market.  I have often heard the discussions about whether the product life cycle could or should be extended and additional years added to the calculation.  I seldom hear the discussion about what could be done to radically accelerate the project so that the time period in which benefits start is much sooner.  Those early benefits are during the window of no competition.  The company can dominate in the market and lock is such a commanding share that competitors look for other opportunities.

When using NPV or IRR I strongly recommend that you challenge the team to provide an alternative plan that cuts the development time in half.  Yes, this plan is likely to cost more.  But innovative projects often are multi-year projects.  Getting to market a year sooner with no competition can be extremely profitable, even with the higher project cost.  The long time frame used with NPV and IRR can lead to a lack of urgency on completing the project.  With that lack of urgency is lost opportunity.

Conclusion?

So whether it is Breakeven Analysis with its market focus, Payback Analysis with its time focus or NPV/IRR analysis with the value focus; there are potential points of deception to consider.  Understand these, account for these, and you will make better business decisions concerning innovation projects.

Project Management Failure – The Story of Centralia (Part 3)

The mine fire in Centralia, Pennsylvania, USA, started in May of 1962.  In the first two blogs in this series (here and here) I reviewed the project management failures on the part of the city of Centralia and the Pennsylvania Department of Mines and Mineral Industries.  Both tried to extinguish the fire and failed and responsibility for leading the effort was turned over to the US government Bureau of Mines.

Failure #1 - The Project Management Methodology Inhibits Project Action 

In the summer of 1965, three years after the fires started, the federal Bureau of Mines created a plan to address the fire.  This two phase plan would cost $2.5 million. The plan was approved, but bureaucracy and red tape slowed things down so that Phase I did not start until September of 1966. First project management failure by the federal government – the project management methodology inhibits project action instead of enabling it.

Failure #2 - Changing Scope To Fit The Budget; But Not Achieving The Project Goal

Phase I took longer and cost more than planned.  When it was finally time to start Phase II, in October of 1967, a re-estimate of Phase II indicated that the project would now cost $4.5 million.  Rather than spend the money, the project was redefined.  The Phase I activities were expanded and the Phase II activities were cancelled.  This was done despite the report issued in 1965 that said both phases were needed to control the fire. The expanded Phase I was completed.  A project success clained, but the fie was still raging. Next project management failure – changing the project scope to fit within the available budget and claim a “success,” without considering the impact on the project goal.

Failure #3 - Refusing Help

By December of 1967 the fire had spread into an adjacent coal field.  The company that owned that unmined coal was naturally quite concerned that the coal would be consumed before they could dig it out.  But because the Bureau of Mines was involved in fighting the fire, the company was prohibited from doing any mining without Bureau approval.  The company offered to put the fire out at their own expense if they would be allowed to dig out their coal.  They even offered to let the Bureau of Mines supervise the effort.  However, the federal agency rejected the offer.  Next project management failure – refusal to accept help from others.

Abandoned house in Centralia, PA

Failure #4 - A Partial Success Leads To A Declaration Of Victory And Abandoning The Project Goal

With the fire still burning and spreading, the Bureau of Mines decided to try a new technique for building a barrier around the fire, using fly ash.  This innovative technique had worked well in several tests.  In May of 1969 this project was started in combination with yet another small excavation trench.  This effort was partially effective in stopping the fire from spreading further towards downtown Centralia, although the fire could continue to burn and spread in other directions, Therefore the project was of limited scope and did not completely surround the fire and extinguish it.  Although the fire was no longer spreading towards downton Cetnralia, by this time, three houses that were nearest to the fire had already been condemned because they were full of carbon monoxide venting from the fire.  Next project management failure – a partial success occurs and the team declares victory without achieving the full project objective.

Failure #5 - Not Aligning Stakeholders Creates Delays And Confusion

Move forward now to 1976; periodic monitoring revealed that the fly ash barrier constructed in 1969 had not sealed the fire.  Hot gases, primarily poisonous carbon monoxide, had jumped the barrier.   Although it did not appear that the fire had jumped the barrier, it was creeping around the edges of the trench.  The Bureau of Mines determined to conduct a repair project of the barrier and trench.  Again bureaucratic red tape delayed the start until July of 1977.  Phase I repaired the fly ash barrier and closed some vent holes.  Phase II of the repair project required more excavation.  This time a bigger, longer trench would be dug and now it was close to the town.  In fact, the line of the trench went through several houses.  Twenty-five families would need to move.  Needless to say there were was an uproar on the part of the citizens of Centralia.  Phase II was delayed.  Finally, by the end of 1978 the town decided to go along with the plan, only to find that the Bureau of Mines had again changed their mind and had a new plan.  Once again they were proposing to pump the area full of water and crushed rock.  Next project management failure – not aligning the project with the needs of key stakeholders will create delays, conflict, and confusion which leads to even bigger problems.

The Federal Government Gives Up

Well the story has a tragic ending.  While everyone was arguing over what to do, homes in Centralia were starting to be contaminated with toxic gases from the fire.  The government paid to put a carbon monoxide monitor in each home.  Many homes were repeatedly exceeding safe levels.  By 1984 the bureau of Mines gave up on controlling the fire. The US congress authorized $42 million to relocate the remaining residents of Centralia.  While many families took advantage of the buyout, a few families refused to accept the money and move.  In 1992 the government condemned the entire town and invoked imminent domain.  After years of appeals, the seven remaining residents are allowed to live out their lives in Centralia, but upon their death their property reverts to the state.

How The Feds Failed

We have seen the failures on the part of the city and state in the first two blogs in this series.  So let’s review the final project management failures made by the Bureau of Mines: 

1. The project management methodology inhibits projects instead of assisting them. 
2. Project scope is changed to fit the budget so that a “project success” can be claimed but the scope no longer accomplishes the project goal.
3. A refusal by the project team to accept help from others. 
4. A partial success is hailed as a complete victory and the full project goal is never achieved. 
5. When in the midst of a crisis, not aligning the project approach with all the stakeholders only deepens the crisis.

One final ironic note about Centralia; it has now become a tourist attraction.  Visitors from around the world come to see the smoke and steam pouring from the cracks in the roads and holes in the yards of the abandoned homes.  The town has even been featured on the Travel Channel.  Due to the ongoing stream of project management failures, people all over the world have now heard of Centralia, Pennsylvania.

References:  DeKok, David. Fire Underground: The Ongoing Tragedy of the Centralia Mine Fire. Guilford, CT: Globe Pequot Press, 2010.  

Project Management Failure – The Story of Centralia (Part 2)

The mine fire in Centralia, Pennsylvania, USA, had been burning for nearly two months.  In my previous blog post I covered the actions and project management failures on the part of the city.  After several months of fighting the fire, the city council has given up and turned the responsibility for fighting the fire over to the state Department of Mines and Mineral Industries (DMMI).  Let's consider how they approached this problem.

Failure #1 - Unwilling To Think Outside The Box

By the time the state DMMI got involved, there was smoke and steam coming from fissures in the ground.  In early August, 1962, the DMMI held a meeting in Centralia.  At the meeting a small mining company offered to dig out the fire for free if they could then have the rights to any coal that they dug out at the same time.  The offer was rejected because that approach did not go through the normal state procurement processes.  First project management failure by the state – unwilling to consider innovate responses to unique project problems.

Failure #2 - A Rigid Allegiance To The Project Plan Overlooks The Project Goal

Another month passed and now the state hired a company to excavate the burning portion of the mine for $20,000. (Yes, they did follow the normal procurement process this time.)  But this contractor was not allowed to test to see where the fire had moved, but was required to dig the area that was specified in the contract.  Unfortunately the contract did not correctly guess the direction and speed of the fire.  Further, the contractor was only allowed to work one shift a day and was not allowed to work on weekends or holidays.  Unfortunately, the fire did not stop burning at night or on weekends and holidays, so it grew to a size much larger than what was in the contract.  Next project management failure – a rigid focus on the scope document ignores the goal of the project.

Failure #3 - A Re-baseline Of The Project Doesn't Consider The New Project Environment

By November, five months after the fire started, a new plan was initiated.  DMMI decided that the abandoned underground mines around the fire would be pumped full of crushed rock and water to isolate the fire.  This effort would cost an additional $40,000.  But there were several problems. There was no local source of sufficient water to do the work, so it had to be pumped in.  It was now winter; and winter in the Pennsylvania mountains can get cold.  The water lines and equipment for creating the crushed rock slurry froze so the pumping was delayed and sometimes curtailed.  Meanwhile, bore holes for locating the edge of the fire were actually creating paths to let the fire move into new areas. This part of the project finally finished in March of 1963.  By the middle of April it was clear that the fire was raging beyond the enclosing circle of crushed rock.  Next project management failure – poor planning of a rebaseline over-looked obvious constraints and risks.

Rescuing injured survivors from the Centralia mine fire

Failure #4 - Inability By The Team To Explain The Project Impacts To Management

The next proposal considered by DMMI to put the fire out was a three-pronged effort that could cost over $500,000 if all three prongs were followed.  That would have to wait until the state’s new fiscal year started on July 1.  The fire had now been burning for over 13 months.  Unfortunately, the DMMI budget was cut in the new fiscal year, so this project was not funded.  Next project management failure – inability of the team to explain the project impacts (threat or opportunity) to management, leading to a short-sighted decision. 

The DMMI did eventually allocate $40,000 for fighting the fire and in July of 1963 another small project similar to the first one the DMMI funded was undertaken with the same results.  The state now ignored the fire and it continued to burn until the federal government finally decided to step in.

The State Tries And Fails

In the first blog in this series I looked at the failures on the part of the city.  This time we considered the state agency. In my last blog I will talk about the response of the federal government.  But let’s review the project management failures by the DMMI:

1. Unwilling to consider non-traditional alternatives to address risk. 
2. A rigid focus on the original scope documents ignores the project goal. 
3. Poor planning of a re-baseline ignores obvious constraints and risks. 
4. Inability of the team to explain the project impact leads to short-sighted decisions by management.

References:  DeKok, David. Fire Underground: The Ongoing Tragedy of the Centralia Mine Fire. Guilford, CT: Globe Pequot Press, 2010.  

Project Management Failure - The Story of Centralia (Part 1)

Let me tell you a story of a tragedy; an avoidable tragedy.  It is a case study in what not to do when managing a project with a problem.   It is the story of the mine fire in Centralia, Pennsylvania, USA.  The fire was intentionally started by the city on May 27, 1962.  It is still burning over 50 years later, and it is expected to burn for another 250 years.  It has grown so large that it can’t be extinguished.  It has made the town of Centralia and the neighbouring town of Byrnesville virtually uninhabitable.  The population of Centralia has dropped from over 2700 in 1980 to just 7 in 2013.  The fire now encompasses an area of 3700 acres, is 300 feet deep, and it is still growing.

Why is this fire a study in failed project management? It is an almost endless string of bad project management decisions.   I am not talking about Gantt charts and responsibility matrices.  I am talking about decisions by the stakeholders concerning whether and when to do a project and the approach that is taken.  I am talking about the risk management, scope management, and stakeholder management associated with a project.  In fact, there are so many project management failures to discuss that I will need to break this blog post into several parts. 

It All Starts.

According to most accounts, the fire was intentionally started on May 27, 1962 as part of a town clean up to prepare for the upcoming Memorial Day celebrations.  The new town landfill, which had only been open for a few months, was next to the cemetery where the memorial service would be held.  It was both ugly and smelled bad.  It was common practice in the town to “clean up” a landfill by heaping the combustibles and burning them. So, under the direction of the town council, the fire department did a controlled burn at the landfill that day.

Failure #1 - Not Understanding The Project Environment

This landfill was in an old strip mine that was above abandoned underground anthracite coal mines.  In fact the whole area around Centralia is honeycombed with these underground mines that had been in operation for over 100 years.  The strip mine was a surface mine.  According to state regulations, for it to be used as a landfill, any openings into the underground mine would need to be closed and sealed with non-combustible materials.  The city had sealed five holes and received a permit to operate the landfill.  Project management failure number one – not recognizing a high risk environment and taking that into consideration in the project plan.  The large number of holes indicated that the area around and under the strip mine was porous.  It was high risk area for breakthroughs into the underground mines.  Filling the strip mine with rubbish could easily destabilize some of the underground chambers leading to a collapse and more openings.

Failure #2 - Not Double-checking New Or Unique Tasks

The fire department regularly set and monitored landfill fires at landfill sites around the community.  Although this was the first fire at this site, there was nothing else unusual about May 27, 1962.   But the fact that it was a brand new site meant that there were unknowns associated with doing a controlled burn.  The rubbish was piled, the fire set, it burned for several hours and then the fire department hosed it down to put the fire out. Project management failure number two – when doing something for the first time, double check the results to be sure they are what you expected.  The fire department should have provided extra monitoring for this fire since it was the first fire at this site.  They didn’t. 

Failure #3 - Putting A "Band-aid" On A Problem Trend Instead Of Getting To The Root Cause

Several days later, the cemetery manager contacted the fire department to say the landfill was on fire again.  Once more the fire department hosed it down and said it was out.  Once more they left with no follow-up plan.  The following week the fire flared up again.  Again the fire department hosed it down.  Project management failure number three – when you have a problem trend, you need to take preventive action to get to the root cause or things will get worse.

Failure #4 - Not Spending The Resources To Resolve A Problem When It Is Small

Centralia 1962

Finally the city became concerned that there might be a problem. The fire had been burning for nearly three weeks.   They hired a contractor with heavy earth-moving equipment to essentially turn over the rubbish in the landfill and allow the fire department to hose down the inner core of the landfill.  As the rubbish was turned over, flames were everywhere, and that is when the firemen discovered another hole from the strip mine into the underground coal mines; a hole that was almost 5 meters long and nearly a meter wide.

The city notified the State officials, but their initial response was slow and they didn’t send anyone to investigate until July 19.  In the meantime, the city contacted a contractor who had handled mine fires in the past.  He came to Centralia and investigated the situation.  He said he could dig out the problem and stop the fire for $175.  But the city council said a project like that would need “to go through channels” which could take months.  Next project management failure – being so tight with resources that even small issues cannot be resolved.

The City Tries And Fails

Let me stop here.  The fire has been burning for almost two months.  The city has tried several approaches and failed.  Now they are turning the response over to the state.  In my next blog I’ll discuss the project management failures on the part of the state agency.  But just a quick review of the project management failures so far: 

1. Failure to acknowledge a high risk environment, 
2. Doing something for the first time without checking to see if it gives the result you want, 
3. Experiencing a problem trend and continuing to do quick-fix actions instead of preventive actions, 
4. Unwillingness to commit resources to an unplanned but necessary risk response.  

References:  DeKok, David. Fire Underground: The Ongoing Tragedy of the Centralia Mine Fire. Guilford, CT: Globe Pequot Press, 2010.