The Business Case for Agility

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


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

AgileConnection is a TechWell community.

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