The Business Case for Agility

[article]
Summary:
Too many technology projects fail to deliver the promised value, and some do not deliver at all. Traditional project management methods when applied to software initiatives continue to frustrate financial professionals and offer poor risk mitigation. In the current economic environment, businesses are forced to reduce their capital budgets and cannot afford to make significant investments without more certainty of appropriate return.

Agile practices are enabling organizations to gain more value, sooner and with a better return. Indeed, an Agile approach may be the most effective step an organization can take to ensure viability and increase success.

The Trouble with Traditional Project Management

Missed deadlines, over budget, and outright failure are what financial professionals expect from IT projects. These low expectations resulted from the drubbing they have taken over the years from so-called "slam-dunk" projects with "can't miss" 100% budget contingencies. These often didn't deliver as expected, provided no value-and at times even jeopardized the organization's viability.

Non-technical people in control of the organizational purse strings face an arduous task in helping make the right choices regarding IT projects. They are forced to approve, recommend, or support projects where the need, value, or likely outcome is uncertain. Managers attempt to control what they can by establishing rigid guidelines for scope, schedule, and budget. However, after decades of "perfecting" the software development process significant failures still persist:

  • 30-40% of systems projects fail prior to completion1
  • Half of all systems projects overrun their budgets and schedules by 200% or more1
  • 64% of features are rarely or never used2
  1. B.P. Lientz and K.P. Rea, "Breakthrough Technology Project Management"
  2. Standish Group, "Chaos Report" (2002)

Today financial professionals must improve project and portfolio return by focusing on fundamental elements:

  • Reduce cash tied up in work-in-process
  • Reduce project risk
  • Reduce overall project investment

Unfortunately, traditional project controls (of fixing scope, schedule, features, and then monitoring progress) not only don't accomplish this goal, but make things worse.

Traditional project management seeks to identify, monitor and limit risks. However, these methods result in bigger IT projects that last longer, creating greater risk in costs, schedule, and delivery. These risks stem from:

  • Lack of enough information upfront to make effective large and detailed scope decisions
  • Inaccurate estimates and schedules
  • Unplanned change
  • Scope and focus drift

Business measures progress against the project schedule, budget burn rates, hourly burn rates, and phase completion gates. But these controls do not tell if the project will be on time, on budget, or on target-only that "work is getting done". If something does go wrong (the market changes dramatically, or a large project problem is exposed), what can the business do? It usually comes to either:

  • Spend more and wait longer (further increase risk) or
  • Take the hit and kill the project

    jr0509-1

Traditional IT project management methods lockup capital for a long time by having significant work in process before seeing any realization of business value. Each stage of the process requires additional cash investment-analysis, design, engineering, test, and deployment. As the project proceeds, more cash is tied up, but the business does not start to realize financial benefits until the project is entirely complete.

When work-in-process increases, risk goes up, and project investment increases the overall project and portfolio decreases. Furthermore, this approach locks in waste, increases time to market, and decreases the likelihood of meeting business and market needs.

There Has To Be A Better Way
By releasing incrementally we open up the opportunity to obtain business value much earlier than would otherwise be possible and prior to the completion of the overall project. This can be done by breaking the project into "feature chunks" that are delivered every two to four weeks.

Every few weeks, the business can shift priorities based on the changing reality of the market, customers, and competition. Managers can respond to project problems, issues with vendors, and validate project return expectations. More options are generated, which allow a business to:

  • Fail fast and stop early
  • Succeed early and increase project investment
  • Shift funds from lower to higher value projects

Unlike the Waterfall process where the cash is locked up until the end of the project, an Agile project is broken into smaller deliverable "chunks". The goal is to get value from delivery as early as possible in the process. Once the value recognition begins, the project starts to pay for itself. With subsequent releases, value compounds, increasing the cash generated by the project and reducing the amount of net cash required to support the ongoing development. Therefore, the overall cash investment necessary to fund an Agile project can be dramatically lower than what is necessary for a waterfall project if releases start early and occur frequently.

jr0509-2

In the above diagram you can see that in the Agile project cash investment increases during the first iteration of development. In this example, the aggregate cash investment does not increase during the second iteration because cash resulting from the first release offsets the development costs. Thereafter the aggregate cash investment continues to be reduced as additional value is received from subsequent releases. Project cash flow more than covers ongoing development costs. By the fourth release, the net cash investment is zero and the project is starting to generate net positive cash flow to the company. At this point in the waterfall project, no cash has been received and the overall investment continues to climb.

Frequent releases allow the business to realize a return faster, frequently so that the business receives value sooner and realizes a return faster. This reduces work-in-process and frees up cash, conserving capital. This capital can be invested or accelerate another project.

Let's compare the traditional approach versus an Agile approach:

jr0509-3

More frequent releases mean more opportunities throughout the life of the project to use current market information to shape the project design and outcome. This greatly expands project management options to change features based on real time information. The business gains flexibility in managing the project portfolio and has the opportunity to make strategic and tactical changes at known intervals. The business can now choose to:

  • Expand scope by adding new features thereby accelerating received business value.
  • Reduce scope and decrease project investment.
  • Reprioritize features.

With heavy design up front and a "big bang" release, traditional projects are designed to be larger and will take more time to complete. With a fixed capital budget, larger projects mean fewer projects. When no return is available until the waterfall process is complete, longer projects increase the likelihood that no return will be obtained during the annual budget cycle. This leads to fewer investments and limited opportunity to offset losing projects with winning projects. Unlike the stock market where you can actively manage your stock portfolio on a daily basis, using a traditional approach limits the kinds of changes you can make without jeopardizing what you have already invested.

jr0509-4

With an Agile portfolio approach, the business can break down long-term projects into short-term projects. This provides more frequent opportunities to both evaluate and adjust investments so that you can:

  • Adjust portfolio on the basis of market changes and customer feedback
  • Actively reprioritize the project portfolio.
  • Reallocate funds to stronger performers.
jr0509-5

In comparing the traditional and Agile approaches to software development, it's easy to see why Agile adoption is becoming more mainstream. Companies want real options and flexibility at a time when adaptability is critical.

 

jr0509-5

Now Is the Time

In the current economy, a company's ability to adapt quickly keeps the business viable. Businesses that embrace an Agile approach can actively manage the portfolio of projects, making it easier to reevaluate and reshuffle priorities, start and stop projects, and recognize increments in value. Your portfolio return increases through:

  • Increased diversification with more and smaller projects.
  • Ability to monitor and manage performance within the budget cycle.
  • Redirecting funds from losers to winners every few weeks.
  • Optimizing the portfolio within the budget cycle.

Agile practices are not new and are no longer a grassroots movement. They are being adopted widely because they deliver practical business benefits. The Gartner report, "Current State of Agile Methods Adoption" indicates:

  • Wider adoption of Agile practices among Fortune 1000 companies.
  • 75-80% of IT organizations use some Agile practices.
  • 15-25% of organizations have established a repeatable Agile process.

The current world economic situation hit most businesses hard and fast with little warning. For many companies, their pre-crisis portfolio of projects became obsolete overnight with projects that became too expensive, off target, or a lower priority. A portfolio process that leads to fewer, bigger, and less flexible projects, does not allow for an effective way to quickly adjust and address these changes.

An Agile approach can provide many options that can quickly be applied to a company's portfolio. In addition to allowing more effective management of your project portfolio, this approach will free up capital, reduce unnecessary cost, and allow you to recognize return earlier, while adapting your project plan through customer and market feedback.


About the Author

John Rudd, President and CFO of SolutionsIQ, an industry-leading Agile organization. Rudd was formerly a partner in a boutique financial consulting and investment banking firm where he led the firm's financial practice specializing in advisory services, mergers and acquisitions, and interim management. He has filled multiple interim executive roles including CEO, president, CFO, and chief restructuring officer. Earlier in his career, Rudd was CFO of a West Coast oil company and a commodity lender for ING. John received his B.S. in Economics from the University of Minnesota and his MBA from the University of Southern California.

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.