Agile Zone is brought to you in partnership with:

I run a small development firm which specializes Microsoft technologies. Ted has posted 12 posts at DZone. You can read more from them at their website. View Full User Profile

Technical Debt - Part 5: Governance

01.17.2011
| 4830 views |
  • submit to reddit

debt_clockCorporate governance programs have taken on a much more significant focus since the latest wave of high profile corporate failures. Companies with tremendous history and prestige like Bear Stearns, AIG, and Lehman Brothers collapsed practically overnight because the desire for short term performance overshadowed the need for prudent risk management.  There were governance and oversight processes in place designed to prevent this type of outcome.  However, the misguided corporate cultures at these organizations had much more influence on decision making.

In 2004 MIT’s Center for Information Systems Research did a global study (CISR Working Paper No. 349) that found that companies with effective IT governance are 20% more profitable.  The study concluded that the single best indicator of effective IT governance is awareness of governance processes.  On average, only 38% of senior managers understand how technology is governed compared to 60-80% of senior managers at top performing firms.  The gap between the top performing firms and the average company is driven by ineffective risk management cultures.  It isn’t difficult to make a business case for addressing this gap with one fifth of a company’s overall profitability at stake.  Below is an excerpt from the first paragraph of the MIT study.

Companies with effective IT governance have profits that are 20% higher than other companies pursuing similar strategies.  One viable explanation for this differential is that IT governance specifies accountabilities for IT-related business outcomes and helps companies align their IT investments with their business priorities…Ignorance is not bliss.  In our research, senior management awareness of IT governance processes proved to be the single best indicator of governance effectiveness…Taking the time at senior management levels to design, implement, and communicate IT governance processes is worth the trouble – it pays off.

Many organizations think of governance as a collection of committees, policies, and enforcement mechanisms.  These are important components but are largely ineffective without the appropriate culture to support them (Grant 12).  Organizations must establish corporate cultures that promote equal focus to both sides of the risk/reward equation.  Towers Watson defines the six key drivers of risk management culture within organizations as follows.

  1. Communication
  2. Leadership Commitment
  3. Teamwork and Collaboration
  4. Resourcing
  5. Rewarding Behaviors
  6. Risk Controls

Driving an effective risk management culture clearly goes well beyond drafting policies and enforcing compliance.  Implementing policies and procedures without addressing corporate culture won’t be any more effective than the Sarbanes-Oxley Act (SOX) was at preventing the financial crisis.

P/PC Balance

In his best seller, The 7 Habits of Highly Effective People, Dr. Stephen Covey discusses the importance of maintaining the balance of production with production capability.  He calls this maintaining P/PC balance.  Covey points out that it is not enough to be productive; we must constantly sharpen the tools we use to achieve greater productivity.  In technology, we can think of production as the creation and maintenance of features needed to support our operating environment and production capability as our ability to create and maintain these features.  If we focus all of our resources on implementing new features, technical debt increases and our ability to create new features diminishes.  Effectiveness lies in the balance of production of desired results, and the production capability to achieve those results.

Capital Structure

So how do organizations decide what levels of technical debt are acceptable?  Unfortunately, there is no magic threshold that applies universally.  It is a similar question that CFOs face when determining the best capital structure for their business.  Deciding the right amount of debt and equity capital is dependent upon a number of factors specific to the business.  This includes the cost of capital, projected free cash flow, volatility and risk tolerance.  CIOs must evaluate a similar set of considerations when determining appropriate levels of technical debt.  While the capital structure metaphor isn’t perfect, there are many useful parallels to help us think through the problem of determining appropriate debt levels.

If we think of technical debt as debt capital, and portions of the technology infrastructure not affected by technical debt as equity capital, we must determine the appropriate debt to equity (D/E) ratio to maintain a healthy balance sheet.  In Part 1 we defined free cash flow as the amount of resources available to maintain and enhance systems.  The challenge with debt capital is that interest payments must be made to service that debt.  Therefore, if there are fluctuations in your free cash flow (available resources) that could interfere with your ability to make interest payments and lead to insolvency and eventually towards technical bankruptcy.  Additionally, if your operating environment is volatile (i.e. subject to frequent change), the interest rates on your debt will fluctuate accordingly.

Centralized Management

Managing technical debt in a centralized way is an important factor in ensuring consistency.  If departments are left to their own devices to track, measure and remediate their technical debt it will become difficult to maintain a consistent enterprise level view of the balance sheet.  Organizations would be wise to consider a centralized registration database to track technical debt.  This database should also be managed by an objective independent party outside the line of business and technology departments.  Business and technology partners will likely have conflicting perspectives that will have to be reconciled.  In many cases technology partners will tend to sharpen the saw too much and business partners sometimes won’t want to sharpen it enough.

There are methods to help reconcile differing perspectives on the amount of resources that should be allocated to paying back technical debt.  One approach might be to assign a value to each line of inadequate code and establish a credit limit for an application that is agreed to by the stakeholders in advance.  When the application exceeds its credit limit, new features get put on hold while refactoring takes place.  If an Agile methodology is being leveraged, it could be mandated that every Xth sprint be dedicated to refactoring.

Conclusion

Unfortunately, there are no silver bullets in the war against technical debt.  As we’ve seen from this series on technical debt, however, there are strategies for tackling the problem.  The key to formulating an effective strategy on managing the technical debt lifecycle can be summarized by the these key points.

  • Define, measure and manage technical debt consistently
  • Not all technical debt is bad
  • Know what warning signs look like
  • New debt is unavoidable
  • Create a culture of transparency
  • Be proactive in managing technical debt

If your organization needs help getting a handle on technical debt, feel free to reach out to us for assistance.  Thanks for taking the time to read my thoughts on the subject.  I look forward to your feedback.

 

References

Weill, Peter, and Jeanne W. Ross. IT Governance on One Page. Working paper no. 349. Cambridge, MA: Massachusetts Institute of Technology, 2004. Print.

Covey, Stephen R. The Seven Habits of Highly Effective People: Restoring the Character Ethic. New York: Free, 2005. Print.

Grant, Kirkpatrick. "Corporate Governance Lessons from the Financial Crisis." Financial Market Trends 2 (2009): 1-30. Print.

 

From http://blog.acrowire.com/technical-debt/technical-debt-part-5-governance/

Published at DZone with permission of its author, Ted Theodoropoulos.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: