Does Operations Research Need A Practice Methodology?

Over the past few years, as IT has grown to become a key enabler across business functions, software engineering practice has focused on implementation methodology. Frameworks such as Agile Programming, Rational Unified Process (RUP), and more recently, Eclipse Process Framework Project (EPF), promise to improve IT implementation by distilling industry best practices into usable tools and artifacts. The ultimate goal for these methodology frameworks is to industrialize IT project work, to make it scalable, repeatable and predictable. There is some evidence of success: the Standish Group estimates that over the 1994-2004 period, US IT project success rates more than doubled, to where one in three of all projects are deemed successful. They explicitly credit new IT methodologies: “Doing projects with iterative processing as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step forward.”

Figure 1: Standish Group 2006 US IT Survey

Note that even armed with full-featured methodologies such as RUP, IT projects are high-risk. As Figure 1 (above) shows, though the US success rate was up to 35% by 2006, one in five project still failed outright. The remaining 46% are condemned to the purgatory of “late, over budget, or below requirements”, presumably enroute to shelfware status.

In Competing on Analytics, a 2006 Harvard Business Review article (available here in research report form, and here as a teaching aid) Tom Davenport argues for a cross-Enterprise approach to integrating Operations Research (OR, also sometimes referred to as Advanced Analytics, Management Science or Quantitative Analysis) into a company’s decision-making. As organizational decision-making becomes increasing IT-based under competitive pressures, more tactical and operational decision-support systems (DSS) have cores built on integer programming, advanced forecasting, Monte Carlo simulation, ant colony optimization, and similarly complex techniques. Moving from piston aircraft to turbines to jets to rockets requires increasingly complex power plant engineering and operating regimes. Similarly, going from simpler rule-based systems that automate decision trees to optimization-driven systems that implement OR technology require a re-examination of IT development processes.

As Davenport documents with examples from companies such as Marriott and Procter & Gamble, OR can maximize value extraction from a company’s resource base. But it also throws up new risks and challenges in implementation. For instance, the major challenges in implementing a database query-driven system (for instance, a standard CRM) involve business process mapping, user adoption, server and bandwidth sizing, etc. However, turbo-charge that application with an OR engine (for example, by embedding a constraint programming-based product configurator,) and you now need to worry about reliable search performance, solution persistence, and other optimization artifacts. Though high-value in concept, OR-powered IT implementations increase project risks along new dimensions. As OR capabilities become checklist items on RFPs, the need for a robust, scalable, and practical OR-aware implementation methodology becomes more urgent.

In upcoming articles, I will discuss practice methodology development for OR-powered systems, starting with a review of how practitioners view practical OR.

This entry was posted on 26 April 2008 at 17:53 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.