Cross - A Field Guide for Applying Technical Financial Statements, Part I

By Brad Cross - 25 March 2009

So far, we have discussed a number of ways of applying financial models to software projects. We explored liabilities as an estimate of a project's technical debt. We explored assets as an estimate of the business value of software components. We explored techniques for computing equity as a function of assets and liabilities. We explored cost of carry and cost of switching as proxies for cash flows. We concluded by exploring techniques for framing tradeoff decisions based on equity and cash flow analysis.

The purpose of weighing assets against liabilities and cost of carry against cost of switching is to manage components of software projects like financial portfolios - assessing each component on its risk vs. return. The objective is to have a functional model for framing technical and business decisions about software. These models are not prescriptive. The purpose of the series so far has been to introduce the technical, financial, and process concepts.

Now that we understand these concepts, how do we put this into practice?

First of all, if your project is a complete mess, then collecting a bunch of metrics and rigorously applying financial concepts may not be appropriate at all. If you have only a handful of tests, then there really isn't much point in a careful analysis of test coverage and the distinction between unit test coverage and system test coverage. If your system is in really bad shape, your problems are often painfully obvious. That said, when it seems difficult to know where to start, the balance sheet model can help you pinpoint the worst problems and target the components that need the most attention.

I have applied this balance sheet approach in a number of different ways on my projects. I’ve used it to decide whether I should rewrite, refactor or replace un-maintainable components that carried too much technical debt. I’ve used it to inform estimates of effort: if an enhancement required modifying a component with high technical liabilities, I knew it was probably going to take longer. I’ve used it to prioritize work to maximize owner's equity by increasing priority of work in high-asset components and de-prioritizing or seeking open-source replacements for low-asset components.

I'm sure there are other ways to apply this model to software projects. For instance, if you have many different projects, programs, or business areas, you could apply this approach at different levels of granularity in the business. You could also use this way of thinking to frame decisions about green-field projects; even at startups. In fact a classic startup mistake is to pile on too much technical debt in an effort to go faster, which results in going slower, and ultimately leads to hitting a brick wall.

Step 1: Choose your metrics that define your debt

I recommend sticking to a pragmatic, lightweight spirit with this technical balance sheet approach. Use what you can get on the cheap - without much time investment. On one project, we already had access to clover, so we were able to mine its metrics "for free". We used these metrics to build the initial prototype of our balance sheet in an hour.

On my last project, we built a mind map (see below) of what we considered to be interesting metrics. We assembled the entire team to discuss what we thought were the most important aspects of the technical quality of the system (i.e. the most costly liabilities) and then identified which liabilities were measurable with current open source tools. It is interesting to note here that some aspects I typically evaluate are missing - such as code duplication. The team never mentioned this as one of the top concerns during this session.

Whatever metrics you choose, it is critical that they are actionable. A lot of tools will show you fancy charts, tables and diagrams, but few of these visual representations are actionable. You need to be able to identify prioritized lists of actions. For example, Simian or CPD will sort the list of code duplication by worst offenders; your obvious first action is to tackle the worst offenders. If you see that your highest bug counts and lowest test coverage is in one of your most valuable components, then working on the robustness of that component is a clear action item. Often you can find a few monolithic classes where many of the issues occur; refactoring these while bringing them under test can be a simple way to achieve a radical change in your equity for that component.

Step 2: Compute your financials by functional area

Here's a recap of our journey through the examples used in our discussions:

In the article on measuring technical liabilities, we constructed a table using a few simple and common metrics as indicators of technical indebtedness.

Functional Area	FX Cop	Coverage	Lines	Duplication	% Duplication
Brokers	139	1%	2984	234	8%
Data	52	31%	1450	297	20%
DataProviders	59	1%	1210	78	6%
DataServer	27	48%	1489	40	3%
Execution	7	48%	618	0	0%
FIX	27	1%	48484	39337	81%
Instruments	133	55%	12896	714	6%
Mathematics	77	56%	2551	205	8%
Optimization	25	60%	305	26	9%
Performance	2	73%	134	0	0%
Providers	36	47%	707	42	6%
Simulation	20	77%	241	0	0%
Trading	54	50%	2955	472	16%
TradingLibrary	66	29%	7035	1674	24%

Next, in the article on measuring assets and intangibles, we talked about using substitutability as a proxy for asset valuation in order to consolidate a basket of concrete metrics into an abstract relative metric.

	Module	Substitutibility				Module	Substitutibility
	Brokers	2				Mathematics	3
	Data	2				Optimization	3
	DataProviders	2				Performance	3
	DataServer	2				Providers	1
	Execution	3				Simulation	3
	FIX	1				Trading	3
	Instruments	3				TradingLogic	4

In the piece on technical equity, we show to transform our table of metrics for technical liabilities into a number that can be reasonably compared with the asset value of each component in order to derive a rough number representing technical equity and how leveraged each component is.

Component	Assets	Liabilities	Equity	Leverage
Brokers	2	3	-1	Infinity
Data	2	3	-1	Infinity
DataProviders	2	3	-1	Infinity
DataServer	2	2	0	Infinity
Execution	3	2	1	3
FIX	1	4	-3	Infinity
Instruments	3	3	0	Infinity
Mathematics	3	1	2	3/2
Optimization	3	1	2	3/2
Performance	3	1	2	3/2
Providers	1	1	0	Infinity
Simulation	3	1	2	3/2
Trading	3	3	0	Infinity
TradingLogic	4	3	1	4

Finally, in the article on cost of carry vs. cost of switching, we discussed thinking about tradeoff decisions in terms of cash flows when considering paying down more or less principal.

• When you take on technical liabilities, you incur cash flow penalties in the form of ongoing interest payments, i.e. going slow.
• When you pay down principal on your technical liabilities, you incur cash flow penalties in the form of payments against principal. However, these cash flow penalties are of a different nature: they come in the form of paying down principal in the short term (going slower right now) in exchange for paying less interest (going faster as the principal is paid down).
• The notion of going faster or slower shows the connection between cash flows and time. The cost of ongoing interest payments is an incremental reduction in speed, whereas the cost of payments against principal is an investment of time in exchange for an increase in speed. Restated, there is a trade off between cash flow penalties now (paying the cost of switching) for decreased cash flow penalties in the future (reducing the cost of carry).

Based on my experience building software, I do not think that the relationship between cash flows, time, and speed is well understood. Much of the problem stems from confusion between the short and long term impact on cash flows that result from making certain tradeoffs. People cut corners under the auspices of short term speed. Often, this corner-cutting actually has the reverse of the intended effect, and can even destroy the chances of delivering. I have seen this thinking lead to the destruction of entire projects within 1 to 2 quarters.

Almost everyone will agree that a decade is long term and that taking on a lot of technical debt can be a significant risk to longevity. Fewer will agree that a year or more is long term. Very few will agree that a quarter is long term. Nevertheless, the more projects I work on, the shorter my definition of "long term" becomes with respect to technical debt. If you really look at the cash flow trade-offs that result in the relationship between time, speed, and technical debt, and you consider the compounding effect of negative cash flows that result from the debt, it becomes much less attractive to mindlessly acquire technical debt in the name of speed. It often results in going slower, even across the time horizon of a quarter or less.

So now we have some crude numbers, and we understand how to think about cash flow trade-offs. In part II, we'll present how we formulate and execute a plan to increase technical equity.

---

About Brad Cross: Brad is a programmer.

Kehoe - Smug Post-Modernisms and Other Notions We Get Wrong

By John Kehoe - 10 March 2009

I was watching Gremlins 2 with my daughter this weekend (yes, I’m a bad dad, but don’t hold the sequel against me, just the fictional violence). What strikes me about the movie is how cheesy it is. Not the plot but the technology. The video conferencing system, the voice based building controls. I particularly like the talking fire alarm system giving a history of fire, but I digress. It is a great period piece for late 80’s business and technology (Did you know that you could smoke in an office in 1990?). Yes, post modern sophistication relegated to a period piece. Such is father time.

It got me thinking in a broader context. What are we getting wrong today that will be revealed with the passage of time? We can look at the history of scientific progress. Examples abound in astronomy, biology and physics. The same can be said in social sciences, economics and politics. Up until the 1950's, the universe was thought to be quite small. Up until last year, bundled mortgages looked as a good way to diversify risk.

How do we know which horse to back? The first place to look is the ecosystem (yeah, sounds touchy feely, but it isn’t) of the technology. Diamond created the first MP3 player, a 64MB job. They did this years before Apple. Apple won the race, but why? They created a fully contained ecosystem. It consisted of a closed DRM format, content, exclusivity of content, blessing of RIAA and a logo program. It didn’t hurt that they hyped the heck out of it. Microsoft tried the same with Zune, but hasn’t had anywhere near the success. Microsoft was too late to the market and didn’t have the best marketing or industrial design (people like polished plastics and nickel alloy). The same is true with the other media players.

The ecosystem became pivotal. As a consumer, do I go with another ecosystem or do I go with iPod? My best mate abhors all things Apple (except his trusty Newton) and argues against the iPod. iTunes and iPod are closed DRM systems, the music isn’t portable to other systems, Apple locks in content providers. The arguments are similar to the Linux, Apple, Microsoft or [fill in the blank with a comperable technology] proponents or opponents. The fact remains that most people choose the iPod because it has the most mature ecosystem.

So what if there is no ecosystem? How do I pick the winner? I resort to need and simplicity. What do I need to accomplish? For instance, suppose I have a customer facing application that brings in $100 per minute. When the transaction rate slows, I lose money. I can quantify "normal," define a cost of abnormal activity and prove what additional revenue I can create with further capacity. I can determine my cost for that performance delta. It is a simple model and readily understood. It guides what the impact is, what is my need and what can I afford. It’s a good way to avoid the technology weeds.

Time makes fools of us all. We can use that to our advantage. If you don’t need technology XYZ, can’t afford it or can’t absorb it, then don’t buy it. The new classic example is BluRay v. HD-DVD. Both were expensive technologies that consumers would not absorb. The end result of a hard press by Sony lead to the capitulation of HD-DVD within a two week period in 2007. This made winners of the people who bought BluRay and the consumers that waited. Don’t mistake the initial BluRay owners as brilliant strategists: HD-DVD could have won as well. At any rate, the first adopters of BluRay paid $900 for bulky players. Better to wait for Wal*Mart to sell them for $99.95. The real winners are the consumers that sat out the battle.

So we use need and time to our advantage as best we can. We can use a contrarian perspective to the technology cycle. Think of this as the Devil’s Advocate (and yes there is a Devil’s Advocate in the Vatican). This would be considered the "B.S. detector" (a characteristic well honed by Mrs. Kehoe and applied to the auto dealer or to me asking for a 52” big screen). This leads to a skeptical mindset, a healthy maladjustment of the trusting mind.

Consider the evolution of broadband. Fifteen years ago technologists thought it essential, but prohibitive in cost (think ISDN a.k.a. “I Still Don’t Need”). We knew (or at least strongly suspected) what we could do with broadband communications: distribute information, telecommute (the real reason IT guys pushed broadband), new forms of communication, WebEx (which didn’t exist fifteen years ago), shopping, expansion of markets, outsourcing, offshoring, distributive teams, etc. The wheels come off the bus when we start standing up 100 Mbps internet, free municipal Wi-Fi and universal broadband. Why are they needed? Is to keep up with Elbonia? Why should there be a government run Wi-Fi network? If people don’t want broadband why force the build out that capacity? The sixty-four-million-dollar question is: when does a technology become valuable? Fibre to the house was goofy 20 years ago. If you have ask The Creator why he needs a starship.

Despite our best efforts, time will still embarrass us (really, the K car was brilliant idea). What has been the long term impact of Michael Jackson? He went from being King of Pop to Regent of Ridicule in short order. Will Miley Cryus be the Max Headroom of today? (I do have to claim that my daughter is not a Miley fan, I can’t be that bad of a father.) So foolishness can rule the day, but I doubt that Sir Mix-A-Lot’s ‘Baby Got Back’ will be considered "classical music" in two hundred years. We don’t see the Sun Microsystem's ‘We puts the dot in dot com’ commercials (’99-’00) as being seen as the launch pad of corporate success, but an apex of hubris signaling the impending internet bust of ’00.

Looking at the merits of the solution in the context of its ecosystem, need, simplicity, time and our return models, we minimize our risks and bring a skeptical mindset to the hype cycle. Let's not be the next "dot" in "dot bomb."

---

About John Kehoe: John is a performance technologist plying his dark craft since the early nineties. John has a penchant for parenthetical editorializing, puns and mixed metaphors (sorry). You can reach John at exoticproblems@gmail.com.

Pettit - Restructuring IT: Making In-Flight Change

By Ross Pettit - 24 Febuary 2009

All businesses are undergoing unprecedented changes. Revenue forecasts aren’t materializing, capital structures are proving unsustainable, and operations are being scrutinized for inefficiencies. This, in turn, means that businesses are being completely restructured in how they are capitalized, organized, managed and governed. As businesses restructure, so will IT.

As we face restructure, we have to look critically at our IT lifestyle. We know that if we eat a poor diet and don’t exercise, we run a greater risk of health problems than if we eat a healthy diet and exercise regularly. The same applies to IT: if our work habits lack discipline, we’re going to have health problems that, in turn, put business operations at risk equivalent to heart disease or diabetes.

Agile and Lean offer IT a healthy lifestyle choice: disciplined execution of a set of best practices give greater focus, consistency and transparency to operations than we get from traditional approaches to IT. Experience in a variety of business domains tells us that we can expect significant impact by taking on Agile practices: we will reduce the probability of a catastrophic failure, defects will decline substantially, delivery times will accelerate, and the business value of what we deliver will increase.

But restructuring to be an Agile / Lean IT organization is not something that happens by management fiat. Agile IT requires that each person embrace fundamental principles that value the business problem at hand as opposed to the technical problems we concoct. This requires behavioral changes that run counter to decades of training, messaging and mentoring embedded in the IT profession. In fact, it goes to the heart of the oft-cited gap between business and IT: day-to-day IT activity is often fundamentally misguided, as people are busy solving the wrong problems. Indeed, it is not uncommon for people in IT to subserviate a very real business need to go in pursuit of speculative technological “future-proofing.”

Given the urgent need to restructure, this behavioural gap presents IT leaders with a significant challenge.

First, restructuring takes a lot of effort. If restructuring IT requires changes to fundamental work habits, we must not underestimate the amount of effort that will be needed to bring this change about. Bridging the gap between “how we work today” and “the results we must achieve given the reality we face” is not simply an exercise in tools and training. It requires a concerted effort to change the behaviours that underlie how work is done: how requirements are defined, solutions are developed, teams are organized and managed and IT is governed. This comes about through experience. Change happens within each team and department as people gain proficiency with new work habits while delivering, supporting, and maintaining solutions.

Second, IT can't shut-down while it restructures; it must be restructured while delivery work is in full flight. That means the restructuring effort itself will be subjected to change and adaptation. This makes restructuring a moving target, which both blurs the vision of the target state and wears down people’s patience and energy for the change.

Significant organizational effort spent in pursuit of a moving target will put the change leader in a constant state of conflict. On the one hand, he or she risks managing to a compromise, where long-term sustainability is sacrificed for short-term "results" (often, ironically, in the name of pragmatism). For example, a project team may elect not to introduce unit testing because the effort is believed to be too great and the business need too urgent. The team may write code faster initially, but it will prove to be a false efficiency as defects rise and time spent refactoring obliterate any gains. On the other hand, the change leader must not be dogmatic. An IT organization doesn’t exist so that it can be Lean, it exists so it can deliver business results. Too great of emphasis on process – insisting on 100% unit test coverage, for example, just for sake of having high unit test coverage – risks prioritizing process in favor of results.

Most of the challenges the change leader will face during in-flight restructuring come down to a simple, if not always obvious, test: are we reconciling the reorganization to the business demands or reconciling the reorganization to old work habits? The prior part of the test helps us be sure that dogma doesn’t trump results. The latter tells us that we must not compromise in the name of making everybody happy.

To make this decision consistently, even when the goalposts are moving, change leaders must have a clear understanding of both the business need and the goals of the restructuring. By keeping the business outcomes such as reduction of defects or accelerated time to delivery the clear priority, we bring unambiguous focus to the change effort. And that focus is critical. Every day, change will be challenged by all kinds of things: distracting and counter-productive technical objectives (e.g., “we need to solve every possible problem we may have in this and any future application that requires session management”), irrelevant, non-value-added IT practices (e.g., "we've always required effort-remaining project status reports"), and individual motivations that run counter to change (such as job preservation or people's "stationary inertia" at work). In-flight operations restructuring requires intense, unrelenting effort to swim against the tide of “how things have always been done here.” The change leader must have a clear vision for operations that is flexible to business demand but uncompromising to IT convenience if there is to be a real, durable restructuring.

The change leader must always be clear that the goal of restructuring is to have the organization executing in such a way that it sustainably yields better performance. To be sustainable, we don't just need solutions to report improved technical measures, we need to work in such a way that day-to-day project decisions do no harm, much like decisions we take in our personal lifestyles. For example, we can send code to the "technical clinic" for IT liposuction, where we invest time into remediating tight coupling, dependencies and complexity so that a team has a clean code base, free of technical debt. However, just as the stomach-stapled person may resume bad dietary habits and regain weight, so will the IT team with the remediated code base resume bad habits. This means that IT leaders must insist on a constant, independent validation that restructuring has taken root. One way to do this is to regularly scorecard team performance to scrutinize execution. Another is to make sure that organizational structures – incentives and rewards, recruiting and promotion, governance and oversight – reinforce the Agile value system. If these things are done, old habits are unlikely to return.

The pressure has never been greater on IT. Business is asking, “what are you doing for me this quarter” with increasing anticipation and scrutiny. The best guarantee that IT operations can adequately and professionally answer this question is to execute in a transparent, consistent and disciplined manner. In an uncertain business world, that’s the best form of “futureproofing” IT can pursue.

---

About Ross Pettit: Ross has over 15 years' experience as a developer, project manager, and program manager working on enterprise applications. A former COO, Managing Director, and CTO, he also brings extensive experience managing distributed development operations and global consulting companies. His industry background includes investment and retail banking, insurance, manufacturing, distribution, media, utilities, market research and government. He has most recently consulted to global financial services and media companies on transformation programs, with an emphasis on metrics and measurement. Ross is a frequent speaker and active blogger on topics of IT management, governance and innovation. He is also the editor of alphaITjournal.com.

Reiser - Getting the Most out of Offshore Development

By Greg Reiser 11 February 2009

Many businesses avoid using offshore resources to implement high-value, high complexity software projects and many who try are frequently dissatisfied. In a recent survey Forrester Consulting found that nearly half (46%) of businesses were unhappy with their offshore provider for development of mission-critical applications.

This begs the question, “Is offshore development incompatible with high-value high-complexity projects?”

My experience suggests otherwise. I have worked with many talented teams that have successfully delivered high-value high-complexity solutions using a distributed development model that takes advantage of talent located in multiple locations around the world.

In this article I will briefly describe how specific practices, some associated with agile development, will help you get maximum value out of your distributed development efforts.

(Please note that I prefer to use the term “distributed development” instead of “offshore development”. This describes projects where work occurs in multiple locations. It is my experience that there are no “offshore” projects. Rather, there are distributed projects where a good bit of the work is performed offshore.)

Involve the whole team in the planning – This is counter-intuitive to those organizations that rely on up-front analysis and planning and then engage a development team (possibly a vendor) for the implementation work. This presents two problems.

First, the development team will insist on doing its own analysis in order to fully understand the business requirements document, use cases, RFP, etc. Hence, some of your up-front effort will be redundant.

Second, and more importantly, it’s during the up-front analysis and planning that the business sponsors and subject-matter-experts establish a shared understanding of the project vision, business objectives and priorities. If the development team (or vendor) is not involved in this process they will be less effective in adapting when the inevitable surprises occur.

Sorry folks, documentation just doesn’t cut it. To paraphrase General Dwight D. Eisenhower, “The plan is nothing, but planning is everything.”

Monitor the product, not the process – Many agilists criticize earned value analysis (“EVA”). Although the EVA technique has shortcomings, the basic idea of assessing project progress by the value delivered is sound. It is much better to assess progress based on functionality delivered rather than interim deliverables such as the System Design Specification (“SDS”) or worse, budget or schedule consumed.

Whether the project team is distributed or not, in-flight metrics based on implemented functionality and user feedback are significantly more reliable barometers than traditional “percent complete” metrics. How many projects have you seen that are 90% complete for half their actual schedule?

Although the SDS may be a very important and valuable artifact (I’m not one of those people who demonize all documentation), its veracity is suspect until an implementation validates it.

Admit that you have a (communication) problem – It doesn’t matter if your project methodology is agile, waterfall or something else. Communication and efficiency suffer when team members are separated by miles. It gets worse when they are separated by time zones as well. In addition to the obvious investments in communications infrastructure and practices (high-quality speakerphones, high-bandwidth networks, overlapping workday schedules, etc.), consider some not so obvious practices.

One of my favorites is the “exchange program”. Have people from each work location spend time working (not just visiting) in the other work location. I’m talking about at least two weeks at a time, working side by side with peers in the other geography. This is both an effective knowledge-sharing and team-building technique.

Don’t give in to the argument that “money saved on travel can be more effectively applied to real work”. The improvements in efficiency far outweigh the additional travel costs. On one large complex program we experienced a 200% increase in throughput after we implemented an exchange program.

I don’t necessarily advocate expensive video-conferencing equipment and services. Although it is a blessing to have access to such, the cost-benefit is not as favorable as it is for less technically sexy investments.

The bottom line is that your project plan must address the communication challenges inherent in distribution. If the necessary investments exceed the benefits of doing the project in a distributed way then don’t do it that way.

Redundant roles – A typical pattern for distributed projects is to have the project manager, subject-matter-experts (“SME”) and business analysts at the customer site and the developers and testers at an offshore facility. This works quite well for small, short-term projects, but it is sub-optimal for large, complex programs.

Concentration of expertise and/or decision-making in one location slows the project down, as the development team often has to wait a full day (best case) when certain types of impediments arise.

Having business analysts and/or SMEs close to the developers and testers improves throughput as questions are answered much more quickly. Having project managers in each location improves throughput as many decisions can be made much more quickly. Having developers at the client site improves throughput as critical defects can be resolved immediately and integration challenges can be addressed in a timely manner.

From a lean perspective, redundant roles are actually a best practice because the apparent waste in redundant roles is significantly less than the waste generated by the wait times in the more typical staffing model.

Monitor technical integrity – “Technical debt” is a metaphor developed by Ward Cunningham that describes the long-term terms costs associated with “quick and dirty” development. The “interest” on this debt is realized in the form of increasing development costs due to inflexible and/or overly complex design, excess dependencies, duplication, defects, etc.

Technical debt management is important for any project. Distributed development makes technical debt management more difficult because some, if not most of the code is developed by the offshore part of the team. Hence there is a greater risk that by the time the symptoms of too much technical debt become obvious, the cost to correct will be high.

You might replace your offshore team due to poor performance and you might even recover some of your costs. But if this really is a mission-critical project, your business will still suffer. Although you can and should apply manual techniques for monitoring the technical integrity of the software under construction, I have found that the use of automated tools to monitor indicators such as automated test coverage, adherence to coding standards, design quality and design complexity can serve as early warning signals for technical debt growth.

Using these types of tools within an automated build process that sounds an alarm when metrics fall outside specified thresholds accomplishes two things. One, they trigger investigation and potential remediation when it is still possible to do so at low cost. Two, they automatically encourage design discipline. No one wants to be singled out for violating coding standards, for not following the agreed upon testing discipline, or writing unnecessarily complex code.

Once again, a modest investment can reduce risk and saves significant costs within a relatively short period of time.

These are but a few techniques, some obvious and some not so obvious, that help make it possible to execute high-value high-complexity projects and programs via a distributed model. Look for future articles for more practical learnings from the trenches.

---

About Greg Reiser: Greg is a software development professional with 20+ years of experience as a developer, project manager and a consultant. He has experience in a wide range of industries including banking, insurance, publishing, logistics, healthcare and telecommunications. Greg has helped numerous enterprises deliver mission-critical solutions using advanced software development practices. He is currently focused on helping organizations get the most out of global development capabilities.

Ververs - IT's Leadership Opportunity

By Carl Ververs - 4 February 2009

In his latest alphaIT article, Ross Pettit writes about how true leadership is urgently needed in IT, now that business restructuring is becoming a means of survival for many companies.

An August 2008 study by InformationWeek revealed that executives outside of IT value leadership more than any other characteristic in CIOs. Having experience running a business unit outside of IT is considered very valuable as well. These two factors combined leave no room for interpretation: IT needs to stop thinking that just “managing the shop” suffices and realize that providing true leadership is critical if it has any aspirations of retaining relevance.

I posit that in many cases IT has been lacking true leadership for a very long time. For some strange reason, people who do one thing very well rise to the top of management ranks: somebody who was the first technologist in a firm, somebody who ran a certain project well, somebody who has technical knowledge and skills that were pertinent at some point. What is neglected is the individual’s ability to lead, adapt to changing business contexts and inspire others to do the same. It is assumed that success in one context – as a manager or developer in a specific project team – automatically translates into success in another.

It is hard to resist promoting people who are like us and who work like us, but in so doing we create a self-sustaining pattern of like traits to be promoted, warts and all. In evolution, this is a guaranteed path to extinction. Weak leaders promote other weak leaders. We may be surrounded by competent technologist or technology managers but we’ve shut out true leaders who have the courage and determination to not just shake the apple cart, but make something other than apple pie. Arguably, the people we need the most – the innovators – are completely blocked out.

The Financial Times recently ran an article about the animators at Disney. After Walt died, the remaining veterans who had worked directly with him, the so-called “nine old men” were promoted to run the studio. They were not exactly top-shelf animators, and it showed. The outstanding talent Disney had attracted over the years – among others an obscure guy named Tim Burton – walked out within a few years because they were managed badly.

In his blog, John Soat touches on the topic of hiring IT executives and quite a few people comment how it is only fair to promote from within. Luckily, several commentators have a level head and state that firm should hire and promote people who can effectively bring change.

Here is how this cycle can be broken. IT managers very often have a contentious relationship with the business. The business should seek out people who are not in senior management roles but who are very vocal and active in the company’s technology. Invite these individuals to partner with the business on pursuing the action items Pettit lists in aforementioned article and watch what unfolds.

To illustrate how effective this can be, let’s examine the case of a Chicago options trading firm. The business side was very unhappy with the technology leadership but could not find a way to improve on that. They hired a CIO who talked a good game, but did not have the mettle to change anything, either by motivation, coercion or force. Then the traders partnered with a few “vigilante technologists” who had been actively chipping away at the established IT order by introducing new technologies and innovative solutions and funded an innovation group. In short order, this group started to produce real revenue-generating solutions, introduced new ways of working and quickly overshadowed IT management in providing true leadership. Those who tried to interfere with this group’s progress were swiftly isolated and rendered harmless. This set the precedent that business-as-usual was over and IT as a whole was going to be held to a new, higher standard.

Yes, change is scary, especially if that change violates our core beliefs and assumptions. But with the current economic situation, companies don’t have a choice but to take decisive action. As Pettit’s, and related articles state, now is the time for companies to shake their IT department's apple cart a good bit, and shake the rotten apples out while they’re at it.

It’s hot in the kitchen. Time for the faint of heart to stand back.

---

About Carl Ververs:  Carl has been a business transformer through technology since the start of his career two decades ago. Always at the vanguard of new thinking and creative application of systems, he built CRM systems, used SOA and applied Agile techniques well before they were named.

Carl's technical expertise lies mainly in high-performance computing for derivatives trading and business process management. His background spans a wide spectrum, including business application specialist, hierarchical storage system architect, customer management systems designer, trading operations manager, Agile project Management coach, SOA practice lead, PMO/QA director and deputy CIO. Carl is an avid musician and composer, computer graphics artist and geopolitical pundit. He lives in Chicago with his wife and son.

Kehoe - A DEC VMS Cluster, a Funky Chair and a Toaster Oven Walk Into a Bar...

By John Kehoe - 28 January 2009

I do not like change forced by ‘the Man’, change out of my control or change that doesn’t help. I do like change that I push, change that makes my life easy and change that puts money in my pocket. As IT professionals, we push change. We often do so without appreciating what our users require, what the users are doing or the historical context of our solutions.

What are we doing wrong? Let’s look at a manufacturing example. I once owned a nice little under-the-cabinet toaster oven, circa 1991, that worked reliably for almost two decades. When it hiccupped I simply fixed it. Alas, it eventually started belching smoke and so I replaced it.

In the IT world, this belching represents the old, unsupported application that we are afraid to touch, lest it combust. It has exceeded its carrying cost and the time has come to replace it. My quest to find a new toaster oven took a while as the new models had been redesigned to meet current codes (think the manufacturing equivalent of SOX, HIPAA and whatever the politicians are about to do to the financial sector). My Elbonian made Char-Nobyl 8000 toaster oven, finally arrived (long past due, as often happens in software system replacement). We had to measure and mount the heat shield as well as mate the oven to the mount (application infrastructure). The instructions turned out to be wrong. I could not reuse the existing mounting equipment. Matching up the supplied components was problematic. Poor design, poor build, poor execution and dodgy installer.

Now we get to use the oven. My first thought: why is my toaster oven plastered with English, Spanish and French instruction and warnings? I bought it in Chicago, not Paris or Buenos Aires. This is the small electronics world equivalent to the user interface. It’s annoying (sure I’m ethnocentric, but a Frenchman and Argentinian would say the same: they didn’t buy a toaster in Chicago).

Now I want to toast a bagel. Simple task: insert bagel; set darkness; start the job; repeat as desired (or ‘insérer bagel; set obscurité; démarrer le poste de répétition comme souhaité’). It’s not that simple with this toaster oven. This baby comes with a plethora of dials. First you set the darkness level. Then you rotate a knob clockwise, then counterclockwise. The third step is to wait for the light to turn green (which, for some reason, turns blue instead). Finally I push the button to ‘launch my bagel into orbit’. Success! I toast another and it’s burnt. Turns out I need to recalibrate my darkness level with each toasting to avoid burning. At least it doesn’t belch smoke.

This is a good metaphor for the weakness of IT applications: we toss in every conceivable feature, the UI is unnatural, the instructions are off, the business rules are mercurial… you get the idea.

How do we make a better toaster oven? Consider the past and the trade-offs. Do we need to replace the heat shield and mounting locations? Can we at least use the same bolt layout? Do we need the languages? Do I need this degree of globalization? What about the UI, why have the extra dial? Why can’t the oven maintain a regulated temperature? In IT we tend to design what we think we need, not what our customer needs.

Asking the customer is no guarantee of success. We’re still likely to end up with dozens of ideas, many of them contradictory or just plain bad. A few gems may exist among amongst the cruft, but they are sometimes difficult to distinguish. We may even avoid considering customers or users who have a propensity to complain.

So where does that leave us? We must look to the past. Just because an idea is old doesn’t mean it’s stale. Consider this story in the context of today’s web 2.0. In the late nineties, I worked with Digital Equipment Corp (DEC) systems. I once chatted up a DEC field SE about the reliability of their hardware. He proudly told the story of a 911 emergency system that had been running on a VMS (a real operating system) cluster (DEC invented the technology) for 16 years with zero downtime. The design was thoughtfully centered on what the user required and what the technologist could do. Yes, they periodically refreshed the software and the operating system. All this was done without bringing the application down. Try that with today’s technology mix and applications. Would you want a 911 system running on a cloud or web 2.0?

Here’s another example. Remember the really cool chairs in the 1960’s sci-fi movies. In all our sophistication, we mocked the strange designs. Surely they had to joke (OK, they were being serious, but the design did not age well) that anyone would use such a contrivance. Well forty years later, I’m at a state of the art (opened three days earlier) corporate video conference center for a $34b company. What’s the first thing I noticed, after the three HD armed cameramen and thirty foot projector setup that put IMAX to shame? I see these wild-looking chairs that could have come from 2001: A Space Odyssey or Logan’s Run.

So what can we glean from my tales? First, the problems we see today have analogues in the past. A lack of historical perspective in our current crop of technologists hampers good problem solving (Action item: crack open a VMS manual to steal some ideas). Two, our solutions are too often divorced from the use case. Our users are not forthcoming in what they want nor do they fully appreciate what they need. We must crawl into their heads to understand what is required and build from those use cases. I say use cases deliberately: we don’t need pretty interface ideas. We do need to value the UI, but we can't simply put out something shiny and think that's the end of it. Form must follow function, which means we must first understand the function. We need to know how they do their jobs today and how the tool we are building will help them do it. Three, we are making software that is too difficult to use. Consider the toaster oven. Why the abrupt disconnect from the past? If your users are coming from 3270 terminal land or fat client world, our objective is to make lives easier with technology, not to simply require users to change from one technology to another. Finally, consider the plumbing. Are we proposing a more reliable solution than the customer has or are we opening ourselves to reliability and performance grief?

So crack open those old manuals, play with some assembly code and enjoy some classic sci-fi movies this weekend. On Monday you can start looking at use cases. By Friday you might be able to deliver some ‘change’ that doesn’t ‘look’ like change and make change resistant users think they came up with it.

---

About John Kehoe: John is a performance technologist plying his dark craft since the early nineties. John has a penchant for parenthetical editorializing, puns and mixed metaphors (sorry). You can reach John at exoticproblems@gmail.com.

Pettit - Come the Hour, Come the Leaders

By Ross Pettit - 21 January 2009

It’s pretty obvious by now that we’re not in an ordinary downturn. The US Federal Reserve and the Bank of England have invested well over $1 trillion propping up their respective financial services sectors, and every indication is that there is more yet to be spent on asset purchases and guarantees. For all intents and purposes, the domestic US auto industry has failed (with, as of this writing, the notable exception of Ford Motor). The Baltic Dry index has fallen 96% from its peak and there are indications that global container shipping is effectively free. Deflationary forces – with which few of us have any first hand experience – are evident in everything including volumes, prices, salaries, staffing levels and asset values. Add to the landscape completely unexpected large-scale incidents of fraud such as Satyam and Madoff and there is no denying that we live in very challenging times, with few precedents or patterns.

The headlines today are dominated by bailouts. Before long, they’ll be about bankruptcies. This will create a new business landscape, the shape of which none of us can fully predict. One thing we do know is that before the dust settles, businesses both healthy and unhealthy will have to go about the task of restructuring.

Restructuring will extend to IT. IT can keep pace and perhaps even get slightly ahead of the trend. But that requires leadership, and leaders are in short supply in all areas of business. This is obvious from the predominance of two common attitudes: complacency and elective ignorance.

First is complacency, often bordering on denial. There are quite a few people taking a “wait and see” attitude, believing that the economic situation isn’t as bad as is being reported (lots of business is still being transacted), governments are stepping in (weren’t we taught in history class there could never be another “great depression?”), there’s been a change in US leadership, and so forth. The prevailing attitude in this camp is that the economy will work itself out and that businesses are not at wholesale risk.

There are also a fair few willing to ignore what's happening, electing to focus exclusively on execution. Since none of us control the economy, the thinking goes, better that we just get on with the things we do control, such as day-to-day execution. We need to step up our efforts and fight the good fight. Times will be tough, but putting our nose to the grindstone will see us through. Cut costs. Sacrifice. Be positive and optimistic.

In the current economic context, both of these attitudes are acts of capitulation. They substitute “hope” and “aggressiveness” for genuine leadership.

As leaders of IT organizations, we’re several steps removed from the line-of-business of our partners, making it difficult for us to be true business leaders. It also places us in a vulnerable situation: if IT is perceived as a utility (and not a strategic partner) we’re seen as a draw on revenues rather than a core competency in long-term success. The CEO and the board won’t look to us for strategic contribution as much as they’ll look for a budget request consistent with the deflationary times.

This is a frustrating environment in which to try to lead as traditional market and operational moves are acts of blind faith or wild ambition. What we can do today to provide leadership for our business partners and our teams?

• Have a firm but malleable business vision founded in facts.
• Pick a timeframe that can be monitored and adjusted.
• Restructure operations for responsiveness.

Here are six practical things we can do to execute a leadership agenda.

1. Vision: We must forecast a bottom for our business / industry. Relax: any forecast we make is going to be wrong. The point isn’t to be precicely accurate, but to define a floor against which we can reconcile and explain all of the business decisions we will face in the coming months. That floor must be something we arrive at independently, by analyzing the data (macro and micro) at our disposal. It is important that we process every bit of economic data and filter signal from noise, fact from emotion. We cannot selectively pick facts nor emotionally align with an outcome that we would like to be true. If we preface any replay of our analysis with “I believe..." we have failed this test.
2. Timeframe: We must choose the indicators that we’ll use to monitor and adjust the timing (and the details!) of our forecast. Not only is it important that we forecast a bottom, we must get our fignernails dirty with the data. This will allow us to ascertain whether reality is evolving toward or away from our predicted future state, and give a reasonable time horizon to adjust our execution. To do this, we need data. Headliners such as the S&P 500 and FTSE 500 are interesting, but can bake in stale data such as last quarter’s sales or dividend forecast. Look to leading indicators of economic activity. For example, if we’re heavily exposed to consumer spending, we can look to the Baltic Dry index to see when global trade starts to show sustainable signs of life. Or if we're close to construction or financial services, we can look to see when the Case-Shiller index shows that house values are again consistent with rates of income growth as they were prior to 2003. Better yet, we can create our own composite index out of key indicators specific to our situation, such as the enterprise value or the percentage of toxic-to-tangible assets of our customers.
3. Vision: We must be specific and direct with everybody – from the board, to the CEO and CFO, to our business peers, to everybody in our teams – about what the data is telling us. Does it appear that our business is shaping up to be a predator, a buyout target, or in a different business entirely? Figure out the business needs that IT must satisfy to support the company that will emerge on the other side, and make sure we are in full agreement with our busienss partners. We must articulate a decoupled vision so that we can explain and focus efforts on the right problem at the right time. We can encourage people to take the initiative in acquiring new skills in alignment with that vision. The data may be negative and it may not make people very happy, but how we act and prepare, and how we explain our actions and preparations, inspires confidence more than all the rah-rah optimism in the world will ever achieve.
4. Restructuring: We must change the way we work to maximise responsiveness. We cannot predict when recovery will happen or what form that recovery will take. Cutting costs to withstand a downturn in the hope that recovery is around the corner (and with it a return to business as usual) is not leadership. Being sustainably responsive to whatever the economy, the market, governments and the competition deals us is leadership. We can act very boldly to eliminate situational complexity, unaligned gatekeepers, and any other obstacles that make it difficult to get things done. We can also look very closely at Lean principles to not only eliminate waste but to make sure effort is directed toward results.
5. Restructuring: We must take a long, hard look at the portfolio for any self-targeted missiles. The one thing that will undermine our leadership in the eyes of our business partners is if we are blindsided by something that is in our control. Especially in difficult times, people will do things to contain bad news in the fear of losing their jobs, so we must be vigilent: do we have any projects that could surprise us with a spectacular collapse? Is Bernie Madoff one of our project managers (or worse, our project portfolio manager?) We need to find out now. Right now. We can do this by bringing unrestricted transparency to our projects.
6. Restructuring: We must identify the top 3 capabilities that will be the most valuable in our future and patiently pursue them. Perhaps our organization has a deficiency in project management, or we envison changing from a custom appdev shop into an integration shop. We can take some long but lightweight positions in these different capabilities. For one thing, we can look internally and identify the people in whom we want to invest for skill development. We can look externally as well: labor supply outweighs demand, so this is an opportune time to advertise for new hires. We can also partner for capability: plenty of firms are coming to grips with the same set of challenges, so there's no need to go it alone. Above all else, we must take our time and make sure we get the right people under the right circumstances. And we mustn't assume that we'll recognize the right people or the right circumstnace especially if we've no experience or a poor track record of acquiring it. We must invest in developing interviewing techniques, and be aggressive but fair in defining terms and opportunities for partners.

This isn't easy to execute. A lot of people in IT lack business fundamentals and may struggle to understand our goals and objectives. We will make mistakes and suffer setbacks. And it can be difficult to explain to people engaged in daily firefighting why this demands attention. But going off in a fit of blind execution is economic "trench warfare," a tactic that has a history of unpleasant consequences. Survival may be at the front of our minds, but as leaders we must be able to articulate a future that is more than just survival. Many IT organizations "survived" the downturn of 2001-3 but never fully "recovered," underperforming for their business partners in the years that followed. We can't ignore threats to survival, but we must restructure and reorganize with informed preparedness, leading toward some vision - even if a bit inconclusive on the details just yet - of a transformed destination. To realize that vision, we're going to need every oar in the water, so it is best that we treat our people with respect and give them full disclosure of our vision and expectation, and the opportunity to take the initiative in sharing in its fulfillment.

At a time when a lot of businesses are on fire, this sounds like a lot of etherial work. And there is no denying that we’re in for a lot of long days and long nights, sacrifices and hard decisions just to stay on top of operations. But this isn’t the time to be tactical. Playing the hand we're dealt and hoping for the best, or simply executing pell-mell in the expectation that something good will come of it, abdicates leadership at the time it is needed the most. Businesses don’t need administrators doubling down on the same techniques, they need leaders ready to invent and innovate in a different and as of yet unknown commercial landscape. Making the effort to shape our situation relative to an informed, forward-looking business context will give us that much more of an opportunity to determine our futures.

---

About Ross Pettit: Ross has over 15 years' experience as a developer, project manager, and program manager working on enterprise applications. A former COO, Managing Director, and CTO, he also brings extensive experience managing distributed development operations and global consulting companies. His industry background includes investment and retail banking, insurance, manufacturing, distribution, media, utilities, market research and government. He has most recently consulted to global financial services and media companies on transformation programs, with an emphasis on metrics and measurement. Ross is a frequent speaker and active blogger on topics of IT management, governance and innovation. He is also the editor of alphaITjournal.com.