The Agile Manager
Friday, December 28, 2007
  Mitigating Capability Risk

With the cost of capital on the rise, the need to focus on returns is much more acute. Unfortunately, IT has not traditionally excelled at maximising returns. Industry surveys consistently show that a third to a half of all IT projects fail outright or significantly exceed their cost estimate.1 Delays are costly: IRR craters 25% if a $5mm / 12 month project with an estimated annual yield of $30mm is 4 months late. Monte Carlo simulation that factors the most common project risks, including schedule, turnover, and scope inflation, will consistently show that the probability of delivery being made 3 months late or later is greater than the probability that delivery will occur early, on time, or within one month of delivery.2

Given the significant contribution of technology to just about every business solution, IT risk management is a critical practice. But IT risk management practices are not mature. Planning models tend to be static representations of a project universe, regardless the time horizon. Risks are managed as exceptions. When things change, as they inevitably do, we try to force exceptions back into compliance with the plan. Given all the variables that can change – core technologies and compatibilities, emergent best practices, staff turnover, and a business environment that can best be described as “turbulent” - traditional approaches of “managing to plan” have a low risk tolerance.

To manage risk in our environment, we must first understand the nature of risk. Market risk offers the possibility of returns for invested capital. The yield depends on a lot of factors which an investor may influence, but over which the investor likely has little control: that a market materialises for the offering, that the company is not outmaneuvered by competitors, and so forth. Some market risks have potential to generate breakaway returns – yields well above a firm’s cost of capital. These opportunities represent the most strategic investments to a firm. IT doesn’t face market risks, IT faces primarily execution risk: that it can deliver solutions in accordance with feature, time, cost and quality expectations. Execution risk factors that are substantially within the control of an investing company because it had more direct control over them.

Execution risk is the risk of committing an unforced error. Poor execution depresses returns (again, consider the impact to IRR for a late delivery), whereas competent execution does little more than maintain expected returns. Maximising execution can amplify yield. Using the example above, making incremental deliveries beginning at 3 months can increase project IRR between 5 and 10%. This is, obviously, a significant competitive weapon. But this capability can be monetised only if it can be exploited by the business itself. This, then, is the impact of IT on returns: highly capable execution can create extraordinary returns, but only if the business can put it to use, and the market opportunity exists in the first place. The yield ceiling is dictated by the potential in the business opportunity itself, not in how it is executed. Execution risk, then, is a threat to returns, not an enabler of them.

Execution risk is not simply the risk that things don't get done; e.g., that excessive days out of office prevent people from performing tasks by specific dates. It is the risk that the organisation has the fundamental capability to identify, understand and solve the problems and challenges it faces in realisation of a solution. This means that execution risk is substantially capability risk: that IT brings the right level of capability to bear to minimise the risk of execution failure and thus maximise returns.

Breakaway market opportunities present the greatest challenges to fulfillment. They involve things that haven’t been done before: a product, service, or business competence that doesn’t currently exist within a firm or even an industry. The business processes that need to be defined, modeled and automated to fulfill that market opportunity will not be established at the front end of a project. They will change significantly over the course of fulfillment as they become better understood. Breakaway opportunities tend also to be highly sensitive to non-functional requirements, such as performance, scalability and security. It is subsequently highly likely that there will be new or emergent technologies applied, if not outright invented, over the course of delivery. All together, this means that the problem domain will be complex and dynamic. These are not problem domains that lend themselves to a divide-and-conquer approach, they are domains that require a discover-collaborate-innovate approach. This calls for people who are not only intelligent, but strong, open-minded problem-solvers with a predisposition to work collaboratively with others. It isn’t a question of engaging experienced practitioners; it is a question of engaging high-capability practitioners.

If we fail to understand the capability demands of breakaway opportunities, and similarly fail to recognise the capability of the people we bring to bear to fulfill them, we amplify capability risk. Consider what happens under the circumstances described above if we take a “mass production” approach to delivery. We define a static set of execution parameters for a largely undefined domain. We make a best effort decomposition of an emergent business problem into compartmentalised task inventories. We then look to fulfill these using the lowest cost IT capacity that can be sourced, grading it on a single dimension of capability – experience – which constitutes the extent of our assessment of team strength. Because the situation requires a high degree of problem solving skills and collaboration, this approach quickly over-leverages the highest capable people. This leaves the mass of executors wasting effort on misfit solutions, or it leaves them idle, waiting for orders. A recent quote from Shari Ballard, EVP of Retail Channel with Best Buy, highlights this:


Because capability isn’t present in the decision frame, we run a significant probability of defaulting into a state of capability mismatch. This obliterates any possibility of cost minimisation (over-running the mass production model) and jeopardises the business returns.

IT is a people business, as opposed to an asset or technology business. The assets produced by IT – that is, the solutions bought by the business – are the measurable results produced by capability. Capability risk management is a byproduct of effective IT Governance. While it has a stewardship responsibility for the capital with which it is entrusted, IT Governance is primarily concerned with sourcing, deploying and maturing capability to maximise business returns. It looks to trailing indicators – which with Agile practices can be made “real time” indicators – that evaluate the quality of assets produced and the way in which those assets are produced. These allow it to determine whether current capability delivers value for money, and delivers solutions in accordance with expectations. It must also look to leading indicators that assess the skills, problem solving abilities and collaborative aptitude of its people, no matter how sourced: employee, contractor, consultant or outsourcer. By so doing, IT becomes a better business partner as it can unambiguously assess and improve its ability to maximise returns.


1There is the classic mid-90s Chaos Report by the Standish group that posited that as many as 50% of all IT projects fail. See also, “Reduce IT Risk for Business Results,” Gartner Research, 14 October 2003

2The seminal work in this area is Waltzing with Bears by Tom DeMarco and Tim Lister. They published a Monte Carlo method in a spreadsheet called Riskology that allows you to explore risk factors and tolerances and their impact on a project forecast.

3Ms. Ballard was quoted by Anders, George. “Management Leaders Turn Attention to Followers” The Wall Street Journal, 24 December 2007.

Labels: , ,

 




<< Home
Agile approaches to IT leadership, governance and management

About Me
    Name:
      Ross Pettit
    Location:
      Worldwide
 
Recent Work
  • alphaITjournal, 13 May 2009: Governing IT Restructure
  • Baltic Dry Posse, 11 May 2009: Stress Test Grade Inflation
  • Webinar, April 2009: Restructuring IT
  • alphaITjournal, 24 February 2009: Restructuring IT: Changing Fundamentals In-Flight
  • alphaITjournal, 21 January 2009: Come the Hour, Come the Leaders
  • The Cerebral Dad, April 2009: Extraordinary Accomplishments
  • Previous Posts
  • Market Power Increases Exponentially with IT Veloc...
  • IT Governance Maximises IT Returns
  • Investing in Strategic Capability versus Buying Ta...
  • Good Management Can Work Miracles
  • Alpha Returns Require an Alpha IT Capability
  • Strategic IT Does More than Assume Technology Risk...
  • Just as Capital Has a Static Cost of Change, So Mu...
  • Patterns and Anti-Patterns in Project Portfolio Ma...
  • Agile under Sarbanes-Oxley
  • Corporate Mental Health
  • Selected Articles and Publications
  • alphaITjournal, 19 November 2008: States of Governance
  • alphaITjournal, 22 October 2008: Volatility and Risk of IT Projects
  • Webinar, 19 September 2008: An Agile Readiness Assessment
  • alphaITjournal, 17 September 2008: Is Your Project Team "Investement Grade?"
  • alphaITjournal, 25 July 2008: Are You Marking IT Projects to Market, or Meltdown?
  • Press release announcing the launch of alphaITjournal.com, July 2008
  • ThoughtWorks CIO Update Video, June 2008: Taking Agile Maturity to the Next Step
  • Webinar, June 2008: Agile Made Us Better, but We Signed Up for Great
  • ThoughtWorks Studios Blog, June 2008: Metric-Driven Management versus Management-Driven Metrics
  • Webinar, June 2008: Agile Reporting and Metrics: Project Intelligence for Successful Software Delivery
  • Agile Journal, April 2008: Quality Assurance: Value Added Partner, not Blunt Instrument
  • The Wall Street Journal, Letter to the Editor, 25 March 2008: IT Leaders Must Change, Not the Business Side
  • Agile Journal, February 2008: Management Driven Metrics Versus Metrics Driven Management
  • Agile Journal, January 2008: The Dichotomy of Change
  • Agile Journal, December 2007: Building High Performance Capability
  • Agile Journal, November 2007: Mythical Agile Shortcuts
  • Agile Journal, June 2007: The Agile Organization
  • Agile Journal, January 2007: Business Value Applied: Aligning the Day to Day with Business Imperative
  • Agile Journal, December 2006: An Agile Approach to IT Governance
  • Agile Journal, October 2006: So You've Decided to 'Go Agile' - A Pragmatic Approach to Onboarding Agile Project Management
  • Agile Journal, June 2006: An 'Agile Maturity Model?'
  • Agile Journal, March 2006: Agile Processes: Making Metrics Simple
  • A complete listing of articles published on alphaITGovernance on alphaITjournal.com
  • A complete listing of articles published on The Agile Manager on Agile Journal
  • Translator (Spanish to English), 1999. Homestyle Recipes for Financial Management Candioti, Eduardo. 5th Edition (Bilingual). Universidad Adventista del Plata Press.
  • Presentations
  • Webinar, 5 November 2008: The Agile PMO - Real Time Metrics and Visibility
  • Webinar, June 2008: Agile Made Us Better, but We Signed Up for Great"
  • Webinar, June 2008: Metric-Driven Management versus Management-Driven Metrics
  • Zürich, March 2007: Swiss Testing Day 2007 - A Pattern for Continuous Testing in Dynamic Domains
  • Munich, January 2007: OOP 2007 - Forge behind the Firewall
  • San Francisco, December 2006: SDForum - The Future of Open Source Communities: The Impact of Exchanges, Forges and Marketplaces
  • Sydney, Melbourne, November 2006: ThoughtWorks Australia - Quarterly Technical Briefing
  • Toronto, October 2006: e-Financial World Expo - Trends in Financial Services Application Development
  • Webcast, July 2006: Agile Journal - Enabling Global Business Success
  • Blogroll and Links
  • Mike Ward's blog.invoke(m2ward);
  • Mike Ward's Waffle: A faster way to develop Java web apps
  • Paul Hammant's Inversionism
  • Paul Julius
  • Muness Alrubaie's Mundane Essays
  • Adrian's Tech Blog
  • Mike Roberts' Blogtastic
  • Miško Hevery's Testability Explorer
  • Brad Cross
  • Zoonabar
  • Joe Z's The Agile Project Manager
  • Sean Doran's IT is All About the Delivery
  • Shaun Jayaraj's What to do? We are like this only
  • Carl August Simon's Corporate Sex Therapy
  • Carl August Simon's Consulting Adventures
  • Tom Looy's Conversations with Andrew
  • Archives
    July 2006 / August 2006 / September 2006 / October 2006 / November 2006 / December 2006 / January 2007 / February 2007 / March 2007 / April 2007 / May 2007 / June 2007 / July 2007 / August 2007 / September 2007 / October 2007 / November 2007 / December 2007 / January 2008 / February 2008 / March 2008 / April 2008 / May 2008 / June 2008 / July 2008 / August 2008 / September 2008 / October 2008 / November 2008 / December 2008 / January 2009 / February 2009 / March 2009 / April 2009 / May 2009 / June 2009 /


    Content © Ross Pettit 2006-2008

    Powered by Blogger