LitheSpeed : Lean & Agile
LitheBlog: Exploring Lean and Agile

Wednesday, January 28, 2009

IT Program and Project ROI in Uncertain Economic Times

Warning:
  • We are in a deep economic slump.
  • The economic future is more uncertain than ever.
  • Predictive, plan-driven waterfall processes for IT Program and Project Management can be dangerous to your ROI.

The first two warnings are obvious, the third is less so. But, as this article explains, selecting and executing large IT software projects using plan-driven, waterfall processes limits flexibility, and defers the recognition of benefits, both of which are dangerous to Corporate ROI in this weak, unpredictable economic environment.

Part two of this series will cover how agile processes provide the options to abandon, switch, defer or grow a project, providing the responsive, flexible approach that IT needs in today’s difficult and uncertain times.

Poor Economy and Increased Uncertainty

Much of the world is the grip of a deep economic slump, and future conditions are uncertain. Economists in the U.S. had first been concerned about inflation, then with a deflationary spiral, and now hyper inflation may be on the horizon—due to Federal Reserve pumping in liquidity.

As an example of uncertainty, on July 4th 2008 Americans were celebrating the Independence Day holiday, but they were not cheering the price of gas, as crude oil was trading at over $137 a barrel, and many were predicting that a $200 a barrel oil price was just around the corner. Seven months later, in January of 2009, crude is now trading in the forties-- the price fell off a cliff, with a decline of over 70% in six months (U.S. Energy Information Administration chart).


Other commodities have similarly dropped precipitously leading to concerns about a deflationary spiral (e.g. your house dropping in value 75%). In response, central banks are flooding the financial system with money, and this liquidity may result in hyper-inflation (e.g. your food costs rising 25% in one year) after the economy rebounds.

Making decisions on large IT Projects is difficult when you don’t know if:
  • Your competitors will be cutting prices or going out of business?
  • Which of your customers will still be able to purchase from you?
  • If the cost of raw materials will spike up or down?
  • If you will have access to the funds needed for large IT investments?
Moved to Survival Mode, Still Using Predictive Processes???

As a result of this uncertainty and the poor economy, many companies have moved into survival mode, scaling back plans, cutting projects, calling in lines of credit, reducing headcount, etc. But, many still rely on predictive, plan driven processes for selecting and executing projects.

These processes assume it is possible to accurately forecast a benefit that will be achieved in the distant future and as a result they don’t provide the flexibility or responsiveness required with the increasing levels of uncertainty most business’s are experiencing today (granted predictive processes can make sense for some classes of projects in more stable environments).

Let’s review a typical plan driven process for turning an idea into an approved project that gets delivered. We will call our hypothetical project, Project-X. The idea for Project-X was hatched in May and then discussed informally using PowerPoint slides. Then a set of formal documents describing and justifying the project were created, including a ROI (Return on Investment) analysis.

A basic ROI formula is: ROI = (Benefit – Cost) / Cost

The ROI showed the ratio of forecasted gain relative to the forecasted investment. Project-X also calculated a net present value of the ROI, to account for the time value of money, and documented non financial benefits in respect to customers, staff and internal process, to provide a comprehensive basis for project approval.

In August, Project-X received departmental approval, and it then became the centerpiece of a Roadmap that was presented to a Corporate Council in October. With some additional work in November and December, corporate approval was gained in early January of the following year.

At that point, Project-X had been bouncing around for over six months. The project began executing in February using rigid: plans, requirements and designs; in a sequential waterfall process.

Unlike most projects, Project-X was executed to perfection, delivering exactly as planned, with no budget overruns, delivering all requirements exactly as they were originally requested.

On Time, On Scope and On Budget, but a Financial Disaster

Project-X was delivered on time, on scope, and on budget. From the Project Manager’s standpoint, it was an incredible success. But, unfortunately for the company, Project-X was a financial disaster.
  • The requirements were completed just as they were originally asked for, but they made little sense at delivery time as the business environment had considerably changed.

  • Competitors had gotten in ahead of Project-X, stealing away most of the forecasted benefits.

  • During the 18 months that Project-X was being executed, capital became increasingly scarce and costly. The company had so much money tied up in Project-X that they couldn’t work on other key initiatives.
The scenario is hypothetical but the outcome is typical.

Questions:
  • Is it appropriate to base project approval on forecasted benefits that won’t be achieved for another 18 months?

  • Is it appropriate to use a process that requires two years to convert an idea into a production release?

  • Is it appropriate to use a process that provides little in the way of flexibility (i.e. options) for course correction in response to changes in the environment?

There are classes of projects, such as some in the DoD, where you can answer “yes” to the questions, but, for most corporate projects the obvious answer to these question is “no”. Despite this, many organizations continue with predictive plan-driven approaches whose lack of flexibility and slow speed to market often result in failure.

Development Processes Must Offer Options

In the book Extreme Programming Explained, Kent Beck describes one way to view the economics of software project management, as a series of four options:
  • Abandon – You can cancel a project, but still gain some value.
  • Switch – You can change direction, the more often that requirements can change the better.
  • Defer – You can wait until the situation is clarified before investing, the longer you can wait the better
  • Grow – You can grow quickly if the market takes off.
Kent goes on to explain that using a project management process that supports these options becomes increasingly important as the level of uncertainty increases. I agree with Kent’s statement and believe that now, more than ever; agile processes are the appropriate choice for many corporate IT Software Projects.

Summary: Plan Driven Approaches Aren’t Flexible Enough

With the increased uncertainty inherent in today’s business environment, predictive plan driven processes for selecting and executing large IT Software Projects will often fail to deliver the forecasted business value. These approaches focus on meeting the scope, budget and schedule constraints that are defined at the start of a project, but they delay the time to the recognition of benefit and they don’t adequately account for a changing business environment.

Part two of this article will further define how iterative, agile processes, deliver the flexibility (i.e. support options to abandon, switch, defer or grow), and the speed to market, required in today’s economy.

4 comments:

PM said...

A very interesting article, I was thinking when I was first reading the article that you were implying that you're setting the budget early in the project and then the costs increase.

Anyway, I agree that Agile methodology is THE hot thing at the moment, but it is yet to be tested (heavily) in large organizations. Waterfall has been there since the beginning of time (although it wasn't called waterfall back then) and was resilient for many many years. I'm wondering if these calls to put it to sleep are wise. Anyway, Waterfall still can used in conjunction with Agile, I have published an article about combining waterfall with agile. Take a look whenever you have time.

David Bulkin said...

PM / Gina,

In respect to the comment about waterfall being there since the beginning of time, as Sanjiv Augustine will point out, key agile elements, like continuous improvement via retrospectives have their roots in statistical process improvement work of Shewart and Deming (early 1900s).

Other elements of Agile, like small integrated teams, have their roots in Lean, and have been around since the Toyota Production System was introduced in the 1950s.

If you read this great paper by Vic Basilli and Craig Larman you will see agile approaches being used since the early days of software development, including Project Mercury from the 1950’s which used short, half day, time boxed iterations and test first development.

In respect to your comment about budget and cost, you are correct that the post does not presume that waterfall leads to higher cost. The argument proposed in the post is focused on the benefit.

Assuming that cost is the same with both approaches, plan driven waterfall deliverables are less valuable because the recognition of benefit (i.e. time value of money) is deferred, and there is increased risk that the benefit will never be achieved (i.e. due to changes in the environment).

Thanks for your input, and I will separately comment on your article.

Gina Lijoi said...

Dear David,
Unfortunately, it seems someone is falsely claiming to post comments as me! I did write the original article, and it was published with permission on PM Hut, but I did not leave the comment on your blog, which clearly sounds as though it came from me. This is extremely unfortunate - I believe in sharing collective knowledge, but when we take such liberties as representing ourselves incorrectly, we've lost all moral grounding. Very disappointing indeed.

David Bulkin said...

Gina,

Unfortunate indeed, and it is duly noted that you did not write the post.

On the positive side, the post brought up some interesting topics, and it did get me to review your blog.