If the maxim "what gets measured, gets managed" should be used to judge the use of social media in companies, then clearly the topic is moving beyond mere casual interest. Cutter Consortium's recent survey on the topic makes that abundantly clear. However, until I analyzed the results of the survey, I felt that many in industry were thinking somewhat schizophrenically. Most CIOs and business leaders I talk to are -- themselves singly or speaking for their organizations -- of two minds regarding social media.

If the maxim "what gets measured, gets managed" should be used to judge the use of social media in companies, then clearly the topic is moving beyond mere casual interest. Cutter Consortium's recent survey on the topic makes that abundantly clear. However, until I analyzed the results of the survey, I felt that many in industry were thinking somewhat schizophrenically. Most CIOs and business leaders I talk to are -- themselves singly or speaking for their organizations -- of two minds regarding social media.

This issue of CBR was quite interesting and a lot of fun to write about. It centers on a very timely and increasingly pervasive topic: social media, focusing our attention on the monitoring of the social media landscape by organizations. As the saying goes, and which Vince alluded to in his contribution, you can't manage what you don't measure. While the old saying may or may not be true, what is sure is that measuring is costly, in terms of time and the expense associated with the right tools.

This issue of CBR was quite interesting and a lot of fun to write about. It centers on a very timely and increasingly pervasive topic: social media, focusing our attention on the monitoring of the social media landscape by organizations. As the saying goes, and which Vince alluded to in his contribution, you can't manage what you don't measure. While the old saying may or may not be true, what is sure is that measuring is costly, in terms of time and the expense associated with the right tools.

This survey investigated the extent to which and how organizations are monitoring social media. The 54 respondents are primarily from North America (52%), with 22% from Europe, 15% from Asia/Australia/Pacific, 7% from South America, and 4% from Africa.

This survey investigated the extent to which and how organizations are monitoring social media. The 54 respondents are primarily from North America (52%), with 22% from Europe, 15% from Asia/Australia/Pacific, 7% from South America, and 4% from Africa.

Every development manager has faced the choices: Ship sooner? Squeeze in an extra feature? Test a little less to cut cost? Invest in infrastructure? Rewrite that problematic code? Virtually every development cycle goes through a similar set of tradeoffs multiple times in the course of getting code out the door. Every time a decision is made, the overall quality, maintainability, complexity, and stability of a software system goes up or down.

Technical debt is about doing the system right, not about doing the right system. It is essentially a quantifiable measure of how good the quality of your code is. It does not address functional completeness, nor can it predict success in the market. However, functional completeness might not amount to much if your technical debt is high. Likewise, market success is likely to elude you if you do not pay back your technical debt in a timely manner.

The DeLorean system is the long-time production system one of my clients relies on to expose its entire business via the Web. The client had successfully developed, evolved, and sustained this system, and its successful business, for more than a handful of years. A few years past that point, it started becoming evident that the system was growing increasingly inflexible and brittle.

Every development manager has faced the choices: Ship sooner? Squeeze in an extra feature? Test a little less to cut cost? Invest in infrastructure? Rewrite that problematic code? Virtually every development cycle goes through a similar set of tradeoffs multiple times in the course of getting code out the door. Every time a decision is made, the overall quality, maintainability, complexity, and stability of a software system goes up or down.

I've been familiar with the term "technical debt" for nearly a decade now, and I remember how it first resonated with me as a way to describe the insidious complexity and entropy that slowly creeps into software systems. I've taught many teams about the notion of a technical credit card that can eventually become maxed out, such that you can no longer add features to a system without significant effort.

When talking about debt in software, there tends to be a focus on the code itself. This type of software debt is described as technical debt. Although this is an important type of debt to manage in software development, there are other aspects that must be tended to as well. Software debt includes the following:

Technical debt -- issues found in the code that will affect future development, but not those involving feature completeness

Acceptance tests are performed by an end user or system owner to verify that delivered software functions correctly and meets requirements.1 Acceptance test debt is the nonexistence or nonautomation of acceptance tests. Developing product features is more risky when an organization has acceptance test debt. The debt corresponds inversely to the proportion of requirements that are covered by automated acceptance tests. To reduce the risk, you need to decrease the debt.

Much has been written about the mechanical aspects of technical debt. Cutter Senior Consultant Kent Beck and Martin Fowler first cataloged what we call code "smells" in 1999. The book in which this catalog of smells appeared is commonly known as "the Refactoring book,"1 and it is a well-known source on the subject of technical debt. But Fowler's book and other writings like it don't address the causes of technical debt. Rather they point out what it is and how to fix it.

Our understanding of what constitutes technical debt changes as our experience and technology advance. Today's best practice inevitably becomes tomorrow's legacy system. The metaphor of technical debt originated before the client-server model became the dominant computing paradigm and hasn't been as widely applied and analyzed in systems. We now have the lessons of nearly two decades of experience managing Web architectures to reflect on.

In this Executive Report by Robert K. Wysocki, we explore in detail the 12 basic tenets that characterize complex project management (CPM).

In the complex project world (aka agile and extreme), there are some basic tenets that seem to buck traditional project management (TPM) thinking about how to manage complex projects or at least offer a fresh approach to successfully managing and completing such projects.

In recent years, both the enterprise risk environment and enterprise security measures have evolved considerably. In this Executive Report by Brian J.

In recent years, both the enterprise risk environment and enterprise security measures have evolved considerably. In this Executive Report by Brian J.

In recent years, both the enterprise risk environment and enterprise security measures have evolved considerably. Risk is now being brought into the fold of a unifying concept -- enterprise risk management (ERM), which attempts to consolidate heretofore siloed risk management efforts within a single, centralized structure.

In recent years, both the enterprise risk environment and enterprise security measures have evolved considerably. Risk is now being brought into the fold of a unifying concept -- enterprise risk management (ERM), which attempts to consolidate heretofore siloed risk management efforts within a single, centralized structure.

It's amazing how organizations spend vast sums in the interest of discovering the newest, latest, and most advanced business practices and technologies. They throw their energies behind radical change, while ignoring the improvements that can be made through effective implementation of existing practice.

It's amazing how organizations spend vast sums in the interest of discovering the newest, latest, and most advanced business practices and technologies. They throw their energies behind radical change, while ignoring the improvements that can be made through effective implementation of existing practice.

It's time we stopped this debate over the roles and responsibilities between the project manager (PM) and the business analyst (BA) and focused our efforts on realizing the benefits of the PM and BA partnering to deliver maximum business value to their clients.

Whenever we deal with challenges of gargantuan proportions, we break them down. This decomposition enables us to understand, manage, and ameliorate the challenges.