OR Methodology Lessons from INFORMS

In 2001 INFORMS, the Operations Research professional society, hosted its first national conference on OR Practice in San Diego. Some 300 OR professional attended. Since that tentative beginning, the conference has become a “can’t miss” for OR professionals and practice-minded academics, nearly 500 of whom attended the 2008 conference in Baltimore, MD.

Among its other benefits, the Practice conference has been significant in triggering a wholesale appraisal of OR methodology. The discussion can be said to have been kicked off by Karl Kempf at the 2003 meeting in Phoenix, AZ. Karl’s talk in Phoenix, titled Optimization of a Semiconductor Supply Chain: Technical & Cultural Issues, identified numerous maxims to speed adoption of OR at Intel, his employer. He ended with the declaration that while technical issues (modeling, algorithms, software implementation, etc.) were – in his words - “enough to keep us busy for the foreseeable future”, they “pale in comparison with the organizational dynamic issues”.

Karl returned to his theme the following year in Cambridge, MA, where he focused specifically on Organizational Barriers to Applying Optimization in Business Operations. The key take-away from that presentation was the need for the OR professional to focus on the algorithm to solve the business problem, without being bound by a specific software tool or approach. At the same conference, Jeff Winters from UPS spoke on Why OR Projects Fail, a crab-wise approach to identifying what is not good methodology!

Over the next four years, presentations on the theory of OR practice became among the best-attended and most talked-about part of the Practice conference. Many highly respected thinkers of the field, both practitioners and academics, have taken their turn at bat. Selected highlights:

• Palm Springs 2005
  
  • Harlan Crowder in Stuff Happens: Why Practical OR Projects Fail, fingered “cognitive friction” in the difficulty of implementing OR because of its opacity for the non-technical user.
  • The late Rick Rosenthal in Secrets for Success with Optimization, suggested that solution persistence should be the default choice in optimization modeling.
• Miami 2006
  
  • Marshall Fisher in Eight Habits of Highly Effective OR Implementers laid out his best practices, while pointing skeptically to the goal of creating an actual theory of OR practice.
  • Glenn Wegryn in Sustaining a Vibrant OR Practice at Procter & Gamble, focused on the essentiality of communicating the value created by OR methods.
  • Gary Cross in OR Based Client Engagements, spoke of the need for gradual expansion of scope, and of project-integrated learning, while acknowledging the higher risk inherent in OR-based IT.
  • Harlan expanded on his rules of thumb for successful implementation in Practical OR.
• Vancouver 2007
  
  • Peter Kolesar in Creating a Theory of OR Practice, focused on consultative OR rather than IT implementation, with recommendations drawn from the broader world of business consulting.
  • Tom Baker in OR’s Curse & How to Deal with it, warned against narrow technique-orientation and reiterated the importance of communication, technical demystification, and risk management.
  • Karl Kempf drilling down on Collaborating with IT, hammered on the need for structured development methodology and iterated development.
• Baltimore 2008
  
  • Jean Pommier described the philosophy and artifacts underlying ILOG’s Methodology Implementation of Decision-Support Systems and how Ilog uses its methodology framework to better sell and deliver optimization technology.

(I also spoke in the “theory of OR practice” track in Baltimore on Towards a Theory of OR Practice: Are We There Yet? Material from that talk forms the basis of this and other recent blogposts on methodology.)

Over the years, the discussion on Theory of Practice has emphasized both types of value delivery: consultative (one-off analysis) and systems-based (IT-embedded). However the tenor of the discussion has trended from the general to the specific. Increasingly actionable best practices have been proposed by speakers such as Crowder, Rosenthal, Fisher and Kolesar, among others. Modes of integrating into broader IT implementation currents have been proposed by Cross, Kempf, Pommier, etc. Summarizing brutally, the main lessons from seven years of discussion are:

1. Customer-focused orientation: This can best be described by the directive – “get over your expertness!” It’s seductively easy for an OR professional to fall back on technology that is, to the non-technical end-user, indistinguishable from magic. It is not enough to conjure up an “optimal” solution. The solution also needs to be explicable to the planner who generates them today using decades of first-hand experience of the overlying process and after days of hacking with spreadsheets. The focus of the OR professional needs to be on the problem, not on her technical toolbag. (An especially difficult chore if the practitioner works for a software vendor or a consulting firm that closely identifies with a narrow technical approach!)
2. Communication: Nearly every speaker places the need to clear, regular, and structured client communication near the top of the OR practitioner’s checklist. Is OR special in this regard, different from, say, mainstream IT? The consensus is yes, based on its unique combination of technology “magic” and the expected unfamiliarity of the typical end-user with OR. Client buy-in comes from developing a shared vision for the project, at the managerial and the end-user levels. Maintaining that buy-in requires ensuring that ongoing end-user education is not sacrificed to the tyranny of delivery dates and feature commitments.
3. Methodology: While the notion of a development methodology is not native to the OR community, a consensus on the need for a formal framework appears to be developing. Given the early stage of evolution of an OR-specific methodology, one finds almost as many specific recommendations as recommenders. The need to rigorously assess data requirements and availability tops many lists. As does the inevitability of an iterative implementation framework. Some “technical” recommendations, such as Rosenthal’s emphasis on modeling solution persistence, also appear. (An interesting recommendation from more than one speaker, to “avoid failure”, appears to be a bromide. But it makes perfect sense in the context of the perception of OR as “black magic”; unfamiliar and disruptive technology is rarely allowed more than one strike. Perhaps this will change once – if? - OR captures the mainstream.)

Conclusion

The INFORMS Practice conference has been the locus of methodology-related discussion in the OR community. Based on the popularity of theory of practice-related talks, the need for a usable delivery methodology for OR – presumably based on a descriptive theory – is widely shared. As clearly, there is neither an existing theory of practice, nor a methodology based on a proto-theory. There are good-sounding suggestions for best practice frameworks, but nothing validated except by personal (”expert”) experience.

In the next post in this series, we will examine possible next steps for methodology development.

This entry was posted on 29 May 2008 at 16:51 and is filed under Methodology, Operations Research. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response or trackback from your own site.