Mitigating Corporate Financial Risks of Lean IT

It's pretty well established that Agile and Lean IT are more operationally efficient than traditional IT. Agile teams tend to commit fewer unforced errors, and don't defer work. This results in fewer surprises - and with it, fewer surprise costs - in the final stages of delivery. Agile practices unwind the “requirements arms race” between business and IT, while Lean practices reduce waste throughout the delivery cycle. And Agile teams are organized around results as opposed to effort, which enables more prudent business-IT decisions throughout delivery.

This operational efficiency generally translates into significant bottom line benefits. From a financial perspective, Agile IT:

• Can capitalize a greater proportion of development costs
• Consumes less cash and manages cash expenditure more effectively
• Has higher yields and offers better yield protection on IT investments
• Is less likely to experience a catastrophic correction that takes everybody by surprise (e.g., appear to be a Black Swan event)

While all this sounds good, there’s no such thing as a free lunch. No surprise, then, that fully agile IT brings a new set of risks. A leaned-out IT organization capitalizing a significant proportion of its discretionary spend is highly susceptible to a perfect storm of (a) SG&A contraction, (b) IT project write-off, and (c) suspended IT investments.

The "Perfect Storm" of a Lean-IT Financial Crisis

The meteorology of this perfect storm happens more often than you might think. Consider the following scenario. Suppose at the end of the first half of a fiscal year (H1), we face the following:

• SG&A spend on data center operations runs higher than forecast because more mainetnance work is done than forecast, and contractor costs rise unexpectedly
• Effort has to be written off a capital project because the project team didn't achieve anything meaningful (and therefore there's no asset to capitalize)
• An early stage investment is suspended pending a re-examination of business benefits

Then the CEO pops by to say that H1 results are disappointing, and asks us to cut the IT SG&A budget significantly for H2.

We now have a lot of things competing for our reduced SG&A budget in H2. Meanwhile, our capital investment portfolio is underperforming.

Our Lean IT organization faces a two-phase exposure similar to the credit crisis that struck Wall Street in 2007. Initially, we face a liquidity crisis. This quickly gives rise to a solvency crisis.

Phase 1: Liquidity Crisis

A liquidity crisis is triggered by the contraction of SG&A (also known as Operating Expense, or OpEx). Whether our business is govered by GAAP or IAS, the rules that govern capitalization of intangible assets such as software require us to define our investment intention. That is, we need to be able to explain that we're making a capital investment in software because we expect to achieve this return or business benefit. In IT, investment intention is defined by a project inception phase of some kind. Accounting rules dictate that inception has to be funded out of SG&A. What this means is that before we can spend out of a capital budget, we must spend some SG&A money first. It's also important to bear in mind that the same is true at the other end of the delivery cycle: last mile tasks such as data migration can't be capitalized; they also must be funded out of SG&A.

In effect, our SG&A budget (also known as operating expense, or OpEx) is leveraged with capital expense (CapEx). A contraction of OpEx proportionally reduces the CapEx accessible to us. This puts IT capital investments at risk. If we have less OpEx to spend, we may not be able to start new projects because ramp-up activities like project inception must be funded out of OpEx. We also may not be able to get capital investments into production because the things we need to do to get them across the finish line must be funded out of OpEx. Depending on how highly we're leveraged, even a small loss of OpEx may create liquidity seizure of our IT portfolio. This will force us to make difficult investment decisions to defend our portfolio returns.

Phase 2: Solvency Crisis

Just as happened on Wall Street, a liquidity crisis soon becomes a solvency crisis. In IT, “solvency” is capability. IT departments invest in people to learn how to get stuff done both in the business context (what are the critical business drivers?) and the IT context (how do all these systems actually work together?) IT people master the situational complexity necessary to keep the systems that run the business humming. They know not only which bit to twiddle, but why.

With this in mind, think back to our two funding sources: OpEx and CapEx. Capitalizing development of IT assets is an exercise in funding salaries and contractor costs out of CapEx budgets. As described above, an IT department that experiences a liquidity seizure loses access to its capital budgets. With capital funds inaccessible for payroll, an IT department faces very uncomfortable staff retention decisions. The people who know how to get stuff done may have to be released. If that happens, the very solvency – that is, the ability of the IT department to meet business demands – is in jeopardy.

While transferring from one budget to another may appear to be a simple way to protect IT solvency, it’s an option of last resort. Capitalization distributes the cost of an investment over many years, because the asset is depreciated. Depreciation increases corporate profitability for the year in which an IT investment is made because costs are deferred. Conversely, expensing recognizes the cost of an investment as it occurs, which decreases profitability for the year in which an investment is made. Moving money from CapEx to OpEx, then, will have a negative impact on current FY profitability. “IT Impairs Earnings” is not the sort of headline most CIOs aspire to see in the annual report. In fact, going hat in hand to the CFO is a career limiting move for the CIO.

Mitigation

This “perfect storm” is more common than you might think. Mitigating exposure is done through a variety of different mechanisms.

One is to hedge the project portfolio by bringing several investments into the early stages of delivery and then putting them into operational suspense. This creates a deliberate OpEx expenditure at the beginning of a fiscal cycle (before risks of OpEx impairment are realized over the course of a year) to multiple project inceptions, and then rendering some of those investments dormant. This diversifies the IT project portfolio, allowing IT capability to shift among different projects should one or more of those projects be cancelled.

Another is to align the project financing window with the Agile delivery window. A lot of this risk results from the incongruity of a long budgeting cycle that is matched with short Agile delivery windows. Following the lead of the sustainable business community, businesses should move to adopt micro-finance for IT projects. This is very difficult to achieve. Among other things, it requires an active investment authority (e.g., an investment committee actively involved in portfolio reviews) as well as a hyper-efficient inception process.

Yet another is to encourage people to think like “active traders” as opposed to “passive investors”. Each person must look for “trades” that will improve a team position overall. This can be anything from the priority of specific requirements or the people in the team (e.g., aggressively rooting out net negative contributors).

Finally, and most importantly, we’ve learned that Agile IT requires Agile governance. We may have all the data in the world, but optimal investment decisions don’t happen of their own volition. Just as Agile delivery teams require tremendous discipline, so, too, does the Agile executive. Liquidity and solvency crises are averted not through mechanical processes, but through meta-awareness of the state and performance trajectory of each investment in the portfolio.

Supplying IT Mercenaries

Last month we took a look at the different types of staffing in IT, using Machievelli’s book The Prince as a guide.

Buyers of forces, be they military or IT, have long been advised against employing mercenaries. Strangely enough, nobody has paid this counsel much mind. The buy side still buys mercenaries, more than ever. Just have a look at your own sales lead list. Lots of demand for short-term specialists.

So what’s an IT supplier to do?

Let’s look at this from the perspective of a “supplier of forces” that wishes to be sustainable business, one that aspires to do business for many years. In the parlance of Machiavelli, we want to look at this from the perspective of a firm that wishes to be an independent “state.”

Supplying Mercenary Forces

For IT firms, there are always mercenary opportunities, because there are always buyers looking to fill highly specialized roles for some period of time: an Oracle financials expert, an iPhone app developer, an interim project manager, a Sharepoint specialist.

To the supplier of forces, a mercenary opportunity might look attractive because it appears to offer short-term placement, outsized income, and few strings attached. This is almost always illusory. In fact, mercenary work can cause more harm to the supplier than it’s worth.

Mercenary work is income, not wealth.

When a supplier firm is in need of income, mercenary work can appear to be especially attractive. But income is not wealth.

Income pays the bills, but most income streams are not sustainable. Wealth sustains a business. The sell-side firm accumulates wealth in many ways, including intellectual property, a well-honed social system for delivery, people who are highly capable or have deep industry knowledge, and referenceable, long-term clients. Mercenary jobs do not contribute to the development of any of these. This stands to reason, as the mercenary buyer is looking to exploit expertise, not contribute to its development. As a result, mercenary opportunities don’t contribute to wealth. They are income, and little else.

Income can be useful depending on the needs that the supplier has. However, it must be recognized for what it is, and not confused with wealth.

The cost of mercenary income is very high.

Buyers of mercenaries rent knowledge and expertise in pursuit of their own agenda. In so doing, they exploit, but do not build, the wealth of suppliers.

Let’s think back to Machiavelli for a moment. Machiavelli wrote in terms of princes and the states they govern. In Machiavellian “sovereign state” terms, if a state dispatches too many of its best forces on mercenary missions, it will be unable to defend its home and advance its agenda. The same applies to the would-be sustainable IT supplier.

Suppose a sell-side firm chooses to retain its best and supply untrained or unskilled forces into a mercenary mission. The buyer of mercenaries will recognize the skill level of the forces supplied and conclude they are not getting value for money. The buyer will complain and even threaten the supplier (seeking damages, seeking not to pay, etc.). This means mercenary work draws down senior staff almost exclusively.

Being forced to dispatch senior staff is costly as it stunts the development of the sell-side business. Mercenary engagements rarely offer opportunities for the supplier to incubate new capability as can be done when deploying on “one’s own” missions. By extension, because they’re on mercenary missions, senior staff are unavailable to the sell side firm for the “one’s own” missions – developing deep customer relationships, industry knowledge or intellectual property – that build a business. This makes the sell-side business vulnerable and weak.

Sacrificing business development to accept jobs on offer is to trade wealth for income. That, by definition, makes it expensive income. It is dangerous for the supplier to get caught up in the attractiveness of income, especially if they lose sight of wealth-producing activities.

The worst mercenary engagements are destroyers of wealth.

The people you send into a mercenary mission may not return from the mission. For example, they may elect to quit and work for somebody else. Re-acquiring that capability is not inexpensive as you can’t just hire senior staff off the street: it takes time to recruit and train, build experiences, and mature somebody considered to be among the most senior staff.

But losing somebody in a mercenary mission is not just a loss of capability, it’s an erosion of wealth. Losing senior staff in which you’ve invested undermines the fabric of the supplying firm, especially if that person was a cultural icon, a strong leader, had many years of accumulated experiences, or was woven into the synaptic social processes of the organization itself. This form of wealth destruction in mercenary missions is particularly damaging because it results not from the pursuit of the supplier’s agenda, but in somebody else's agenda. That is, it’s not lost in pursuit of wealth, it’s lost in pursuit of income. Income doesn’t compensate for a destruction of wealth.

If you are going to put capability at risk (e.g., put people in a situation where they may be pushed beyond their limits), it is far better to have wealth to show for it.

Mercenary engagements encourage defection among the ranks.

Mercenary engagements favour the independent contractor more than they favour a firm that supplies mercenaries.

Suppose a member of your forces recognizes a mercenary situation for what it is, and furthermore that it’s likely to be a long-term mission. Since the situation is not likely to change, he or she might as well make the best of it for themselves. By becoming an independent contractor, they can negotiate more favourable terms with the buyer. This is usually nothing more complex than availing themselves at a lower cost to the buyer than their current host firm - that is, your firm - bills them out for. As an independent contractor, they’ll be well positioned to strike this bargain, especially once the mission is well under way and they’re already part of it.

The individual has the upper hand over the supplier firm because realpolitik trumps principles. Even with contractual covenants designed to deny a person going independent and taking a customer with them, the supplying firm will typically not impose them in mercenary circumstances. The sell-side firm already sacrificed pursuit of its agenda in pursuit of income. Also, the sell-side firm won't value mercenary work as highly as it will "one's own" or "auxiliary" work. Subsequently, the sell side firm won't risk future income from the buyer by playing the "principles of conduct" card with the would-be independent contractor. And both the independent contractor and the buyer know this.

Mercenary engagements can quickly become high maintenance.

If you send inferior or inexperienced forces, the buyer is likely to reject them and demand replacements and possibly seek damages. This can be as little as the refusal to pay for those initially fielded to expenses related to any transition work undertaken.

You may staff experienced forces, but they run into factors that curtail their effectiveness, things such as work environment, tools they must use, and the aptitude of those with whom they must work. The buyer of mercenaries is usually not inclined to respond to the demands of the mercenary, so they are ignored. The mercenary, unhappy and restless, may cause all kinds of disruption directly to you, or to the buyer (which will find its way to you). The mercenary may also resign themselves to the situation and mentally check-out. This will undermine the sense of value the buyer believes they are acquiring ("I expected more leadership from your people...") In either case, you will be spending a lot of time with the people deployed in a mercenary situation. On top of it, the buyer will be reluctant to pay, which will delay cash flow.

Alternatively, you may staff an experienced person, but one with the wrong personality. Personality conflicts are often not recognized for what they are, and personality problems completely obfuscate the landscape. So whether suitable to task or not, the buyer will claim he or she is not receiving value for money. In this case, the buyer may ask the supplier to intervene in integrating the mercenary, and will often communicate barbs or jabs stated by his or her "own" forces to undermine the credibility of the mercenary. The buyer may seek to renegotiate terms.

All of these increase the supplier’s cost of doing business, which erodes the margin on the mercenary income.

Mercenary engagements are very rarely closed-ended as promised.

Rarely does a patient tell a doctor the prognosis, what procedures to perform, what staff to have, what medications and treatments to prescribe, and so forth. In fact, in medicine, we do the opposite: doctors provide independent assessments, and proceed accordingly with the patient.

Yet mercenary engagements are defined by the buyer, not by the supplier. Mercenaries are rarely granted an opportunity to assess the battlefield, because they’re simply signing up to fight in somebody else’s battle.

Successful, clean extraction from the mercenary mission requires that the mercenary perform relative to the buyer expectation of the mission, and that the mercenary can explain how he or she has fulfilled consistent with buyer expectation. This requires the buyer to accurately articulate the problem space and how the mercenary will contribute to resolution. It also requires the buyer to completely articulate the problem space and how the mercenary will fit into that solution. Given the intrinsic optimism and selective amnesia that buyers of mercenaries typically have, it’s a stretch to assume that the buyer’s definition of the mission will have any bearing on the reality of what can, let alone what should, be done. The buyer has self-prescribed treatment, and most often, the prescription is well wide of the mark. This will obfuscate the definition of “success” of the mercenary mission, and make it difficult for the sell-side firm to conclude and collect.

The buy side may also wish to retain a mercenary for indefinite periods. People often buy mercenaries because their own forces are not performing well. The buyer can become unusually attached to a mercenary because this is the one person who speaks with clarity and authority and gets things done. The buyer may be unwilling to let the mercenary go, offering both extension and increased income. They may drag their feet on extracation procedures such as hand-off of mercenary work to their own, even if this comes at a cost to their own business. This positive vibe with a buyer may make the “income” more palatable, but it remains income just the same. And that vibe can just as quickly turn toxic due to some change in the buyer's situation.

Regardless the circumstance, a clean extraction from a mercenary mission is the exception rather than the rule.

Very few IT firms succeed as purely suppliers of mercenary forces.

Gaining a reputation as a “good mercenary” is not necessarily wealth building. It may create more mercenary opportunities. It may allow you to increase your fees. But it will not create wealth generating opportunities.

Mercenary skills tend to be highly specialized. The mercenary must be very fluent with a specific technology, a specific technique, or the specific nuances of how a particular company works. But as technology goes through cycles of obsolescence, as management fads come and go, and as companies are bought and sold, mercenary skills are high value for relatively short periods of time. The mercenary must therefore keep skills current and up to date and be in a position to influence technology cycles and management fads.

Conversely, there are few opportunities for generalist mercenaries. There may be people who can figure out a technology or collection of systems given time, but the buyer of mercenaries isn’t looking for generalist skills. They’re generally looking to have a very specific problem (e.g., involving a very specific collection of technologies) solved.

As mentioned above, mercenary work lacks characteristics of sustainability. Mercenaries are brought in to perform closed-ended jobs. While a job may command a high income, it is temporary by definition. The mercenary is removed from the situation at the first opportunity. Using the parlance of Machiavelli, once the battle is over, the mercenary will not be invited to be a “colonist.” The mercenary must therefore have a secure home to which to return and the opportunity to ply his or her trade elsewhere.

This means that a mercenary must always be on the lookout for the next opportunity, which usually means a different buyer. Because mercenary work tends to be very challenging and consuming, the mercenary can usually only go looking for new opportunities once the job at hand is completed. A mercenary is truly fortunate if he or she has a strong enough network that opportunities seek them out. On top of it, a mercenary must constantly evolve his or her skills to remain current, something difficult to do when deployed as a mercenary as opposed to an “auxiliary” or “one’s own” force.

Didn't the Swiss make it work?

What of Switzerland? Famous throughout the centuries as suppliers of mercenary forces (it wasn’t uncommon for Swiss forces to be engaged on opposite sides of the same battlefield), the Swiss were notoriously good mercenaries and converted mercenary income to wealth. Do they not offer a model for the would-be supplier of mercenaries? The Confederatio Helvetica benefits from a natural defensive geography. It is difficult for an invading force to mount an offensive as it’s tough to win an uphill battle, and then have sufficient forces remaining to sustain the victory. Switzerland has abundant natural resources, notably water, meaning an opposing force isn't going to win a war of attrition. A victor would have the unenviable challenge of administrating a government over the fiercely independent Swiss. All in all, the Swiss could avail a greater percentage of their population to mercenary pursuits without putting their own agenda (rather, the agenda set by each Canton) at great risk. Arguably, this was how the Swiss did advance their agenda.

While this model worked, it was also highly situational. There weren't a lot of other regions of Europe that had so many factors creating a natural invulnerability, let alone a population that sought principally to form a sustainable and symbiotic relationship with it. While it's not out of the realm of the possible, there aren't too many businesses today benefiting from market forces that make them similarly sustainable.

The sell-side has to know what it’s buying in a mercenary opportunity.

Clearly, the sell side buys into a mercenary situation, just as the buyer is buying mercenary forces.

The buyer of forces will often try to represent a mercenary opportunity as something other than “mercenary” to the supplier of forces. This can be innocuous: perhaps they don’t understand the distinction themselves, or this is how procurement has taught them services are contracted. It can also be malicious: a buyer can willfully deceive a supplier, perhaps because they’re engaged in a political battle with other people in their business and simply wish to deceive.

Mercenary work is still the most prevalent form of demand on the landscape. There is internal pressure to enter into these engagements as many people in the sell-side business will champion them for reasons ranging from hitting quarterly numbers to the brand association of doing business with those firms. Just ask yourself going in: where's the line between getting a “foot in the door” to build a business relationship and simply opening a short-term income spigot?

Throughout time, the sage advice to those on the buy side wishing to press forward an agenda as an independent "nation state" has been to avoid mercenaries. This advice is just as applicable to those on the sell side who aspire to be sustainable businesses pursuing an agenda of their own.

Mercenaries, Auxiliaries, and how we Staff IT

I've spent a lot of time reflecting on Brad Cross' blog post on Wages. It got me thinking specifically about Machiavelli's book, The Prince.

Niccolò Machiavelli made some important observations regarding the conduct of a prince, making specific recommendations for what a prince must do to maintain the integrity of a state. Among other things, he wrote about the composition of forces necessary to both defend and advance the interests of a principality.

While military metaphors are in many ways inappropriate for business (business situations are nowhere near as serious as armed conflict), they are among the oldest of human endeavours and provide a rich history of organization and social dynamic. Just as there have been business books that derive lessons from such diverse personalities as Sun Tzu and Attila the Hun, we can similarly draw some interesting lessons from Signore Machiavelli.

Machiavelli observed there are four compositions of troops:

1. One's own forces (i.e., drawn from the population of the principality)
2. Mercenaries
3. Auxiliaries
4. Mixed from any combination of the above.

This provides an apt metaphor that describes a how technology “campaigns” are commonly staffed.

On the buy side, most businesses aspire to staff with “one’s own forces.” This provides a perception of control, specifically with regard to compensation, promotion, and even daily work activity. Many firms believe they have "one's own" because they staff with direct hires. But there's more to having “one’s own forces” than putting people on the payroll. The interests of the employees (or in military terms, the conscripts) must be fully aligned with the unit. A unit (e.g., a project team or an army) is victorious and with it the sponsoring organization (business or state) and the individual, or the unit is not victorious and with it both sponsoring organization and individual lose out.

If an individual is pursuing a path of personal success that is not aligned with the success of their unit, they are not, from the perspective of the principality, “one’s own forces.” In fact, they fall into one of the next two categories, that of mercenary or auxiliary. In technology, we see this all the time. For example, freshly minted university graduates are typically looking first to acquire skill and experience in a specific technology, expecting to change employer many times in the pursuit of that skill, as opposed to being motivated to fulfill a business mission enabled by the project they’re working on.

By the same token, most businesses engage mercenaries. Mercenaries are often independent contractors, loyal to no leader, and loyal only to themselves. While there can be exceptions, according to Machiavelli they're not good troops in the end because they are not dependable in battle. Specifically, they're the first to desert since they have little on the line. Also, their interests are not aligned once the battle is over. According to Machiavelli, the risk here is "dastardy," or maliciousness. Mercenaries draw income from battle, not wealth from victory. It is in their interest to seek - or to create - conflict. And this is common in the IT industry. How often have we seen an important business initiative beholden to a technology component that is laden with technical debt, the delivery of which is in the hands of mercenaries who are motivated neither by the business impact of the solution nor its reliability and affordability of maintenance? By contrast, how often do we see people develop career "annuities" for themselves, drawing an income for an extended period of time as caretakers of a business critical application that is heavily laden in situational complexity?

Auxiliaries, according to Machiavelli, are particularly dangerous. In military terms, the independent auxiliary unit seeks its own opportunities precisely because it is in a position to create attractive circumstances. In business, if a host company gives a contract firm autonomous leadership on an initiative, the host firm will find a significant portion of its forces are loyal to another. According to Machiavelli, the risk with auxiliaries is "valour". Auxiliaries are motivated by the opportunity to drive wealth from adventurism. If a buy side firm contracts with a sell side firm for an independently-functioning team, it is not out of the question that under competent leadership that sell-side firm will look to strike its own bargain with the market. It may develop expertise, capability, intellectual property or domain knowledge that it can monetize elsewhere. Alternatively, it may hold a customer firm hostage for better terms for some of these things.

The last category of forces - mixed - is in fact the most common in technology. Most firms don’t have a homogenous staffing model. They rely on contractors and outside firms for significant portions of their staff. Also, as mentioned above, there will be inconsistencies in the motivations of their FTEs. “One’s own” forces must be motivated by the wealth of the business (however “wealth” in the situation is defined) as opposed to personal income, to have it at risk, and to have a direct influence on the outcome. Very often, that isn’t the case among badged employees, which means a fair number will be mercenaries. They'll be motivated by individual interests that are not fully aligned, and may even come at the cost of their paymasters. There are also cases where there are auxiliary units lurking about in a business, especially technology: people who have worked together for many years for several different organizations, who form a shadow unit and eventually move to strike their own bargain.

People on the buy side and sell side of technology generally don’t recognize these distinctions. Generally speaking, people on the buy side (a) don’t recognize that their staff are mixed and not "one's own" especially in the absence of contractors; (b) don’t understand the consequences of their staffing mix (e.g., what does it mean from a retention perspective that people aren't first-and-foremost die-hard employees committed to the success of the business imperative?); (c) fail to understand the nuances of how to deal with each group specifically (e.g., in project crises, we tend to see a lot of rah-rah managerial fluff spewed forth from buy-side leadership to sell-side people who are completely disconnected from the business situation at hand); and (d) have no idea the risks and opportunities of each group.

By the same token, the sell side doesn't appropriately approach the market. Sell-side firms that aspire to be "auxiliary forces" talk as if they can be "one's own" (the ubiquitous word "partners” is usually invoked), yet they usually sell themselves as mercenaries to the classic formula of people x time x rate. In this effort based formula the risk is borne by the buyer, but the impact of mercenary pricing cuts both ways. Sell-side firms very often end up in mercenary situations yet fail to price and structure it to reflect the “income” that it really is, mistakenly believing they're developing a vehicle for “wealth” (i.e., a sustainable business opportunity.) Finally, sell-side firms typically fail to understand the full terms and conditions required of both parties for the supplier-vendor relationship to be fully aligned to perform as “one’s own” for the business mission at hand. Very often, they export the problems they have as a sell side business (such as hitting revenue targets or maintaining margin) into the value proposition offered by the sell side. It comes as no surprise that in the end, they default into a cost or "mercenary" engagement model.

The nature of forces – and the consequences – haven’t changed all that much since the dawn of time. The lessons of Machiavelli for the state apply to both technology buyer and seller alike.

The buy side sources staff from a market overwhelmed with sell-side firms offering technology specialists, vertical market expertise and bodies in bulk. The buy side needs to have the right expectation for the right type of firm. The large-scale staff-aug firm has some of the characteristics of an auxiliary, but when it comes right down to it aren't they really just a large mercenary outfit? And does a firm with deep vertical "practices" have aspirations to monetize (possibly to our disadvantage) the expertise derived from the solution we're engaging them for? Alternatively, are we trying to engage a genuine partner firm in a mercenary model? For that matter, do we do things on the buy side to create the circumstances that allow us to engage "one's own" forces? Perhaps most importantly, do we recognize the fundamental characteristics that make a person or a firm suitable for that kind of engagement?

The buy side also needs to consider the project mission. Perhaps the organizational politics have compelled us to go in pursuit of some boondoggle but we know that sooner or later, people will come to their senses and cancel the project. Or perhaps we have a situation where we need to prop up a project deliverable only until we complete negotiations for an alternative solution. In such cases, the buy side firm would be foolish to allocate "one's own" forces, and would be better off to engage mercenaries or auxiliaries.

Curiously enough, a lot of business press has covered this from the perspective of the buy side. It’s worth reflecting on this in greater detail from the perspective of the sell side, or the supplier of “forces.” That will allow sell-side firms to recognize the right characteristics, opportunities, and circumstances for deploying capability across their customer portfolio.

Firms on the buy and sell sides – from established to start-up – experience this phenomenon. Many buy side firms wish to engage, and many sell side firms wish to be engaged, as "one's own." To do that requires trust, which doesn't come easy and must be earned every day. It also requires some form of a shared opportunity model, and very, very few examples of this exist today. This isn’t to say that true partnerships can’t be forged, but instances of this are the exceptions and not the rule in technology. Auxiliary and mercenary buying patterns – transacting for specialized knowledge or bulk capacity (people x time x rate) – are the rule in IT.

A fully aligned partnership - that is, sourcing for "one's own" in Machiavelli's model - is possible only with like minded people who form deep relationships built on a firm foundation of trust and fundamentally aligned interests in achieving a business goal. Those like minded people on whom you can build that trust relationship are hard to find, and they're few and far between, but seek them out and you'll build mutually sustainable businesses.

Sustainability versus Efficiency

My friend Bradford Cross posted an interesting blog on wages last week. It’s a great piece, particularly his comments on Henry Ford's approach to business profitability.

To a great extent, the Ford model Brad refers to is dependent on the combination of volume and productivity. That aspect of the model came to a screeching halt for Ford in the 1920s when the Model T simply passed its "sell by" date. Once the product outlived its market, sales volume dropped. They not only discontinued production in response to growing inventories, they didn’t have their next product, the Model A, out of the design phase. They were forced to shut down the line for months. That put quite a dent in accumulated profitability. They also lost their lead in market share.

The focus on volume and productivity drives businesses to aggressively remove cost and increase productivity from repeatable processes to maximize profitability. In so doing, they're not focused on sustainability, they're focused on efficiency.

Sustainability requires constant change. We have to constantly think about the surrounding business conditions: labor patterns, competitive threats, customer needs and so forth. Sustainability requires us to be primarily concerned with where the business is going to be tomorrow. Efficiency requires everything to stay the same. We luxuriate in the simplicity of holding everything else constant when we focus solely on efficiency. When we pursue efficiency, we're focused on where the business is right now.

In the extreme, we optimize relative to the circumstances of this moment in the hope - the hope - that time will stand still long enough for us to draw an income, have 2-point-something kids, take a decent vacation every year, and accumulate sufficient wealth to retire.

Hope may be audacious, but it's a lousy strategy.

In efficiency-centric businesses, it’s not uncommon to find people doing substantially the same things that people were doing 10 years earlier. Because the definition of work is consistent, it’s repeatable, and that makes everybody's job that much simpler. That's true for everybody in the business: people on the line do the same tasks, people in HR recruit for the same positions, people in finance forecast costs in the same business model, and so forth. When things don't change all that much - markets, supply chains, etc. – a business can make a lot of money, and individual wage earners draw a steady income. But in an age when things change a lot, you can't make a lot of money this way for very long. A business optimized relative to a set of circumstances that are artificially held constant is a business in a bubble. Production of any sort can't operate in a bubble. At least, it can't operate in one for long. The longer it does, the bigger the mess when the bubble bursts.¹

Brad mentions that Ford's model was more complete than volume and productivity. There's another dimension that, if executed, makes a business sustainable and less prone to seismic interruption: constant innovation in response to external factors. With that must also come invention, which is of course not the same as innovation. This is also not the same as internally-driven innovation. To wit: while shaving a few seconds off the time it takes to tighten a bolt might make bolt-tightening more efficient, it's useless if the market has switched to rivets in place of bolts.

If we aggressively evolve both what we make and how we make it, nobody in production will be doing what people were doing 10 years ago, because those jobs didn't exist 10 years ago. They won't exist 10 years from now, either. In fact, we don’t want entire categories of jobs that exist today to exist a decade from now. This means we have to be less focused on the known (what we’re doing) and more focused on the unknown (what should we be doing?) This makes work a lot harder.

Well, as it turns out, building a sustainable business is hard work.

In innovation-centric firms, production isn't in a bubble. In fact, it's very much integrated with its surroundings. That's where Brad's reference to “worker skill” comes into play. In technology, it’s more than just a question of skills: it’s a question of both capability and the passion to acquire more knowledge.

This may seem to be blatantly obvious: of course those are the workers we want. How hard can it be to hire them? It’s just a recruiting problem, right? Brad specifically makes the point that there’s a (wildly mistaken) school of thought that assumes we can get the best people by spraying a lot of money around.

If only it were so simple, as Brad points out. It's very difficult to succeed at this, not only because it requires a change in recruiting behaviours, but because it means significantly disrupting an internal business process. That's harder than you might think: the efficiency-centric mindset is firmly entrenched in business, government, and the universities that educate the management that run them both.

Efficiency-centric firms are process heavy. The people in these firms - badged, independent contractor and supplier alike - are very heavily invested in that firm's processes. Subsequently they resist change to the processes and practices that they have worked so hard at mastering and making “efficient.” This creates organizational headwinds so resistant to change they can bend solid steel. Any "change initiative" that isn’t blown away by these headwinds is corrupted by it. So, the boss says knowledge is power, and he's told us we’ve got to have the most knowledgeable people in the business? No problem: we’ll show how knowledge-hungry our people are. HR will set up some computer-based training and tie a portion of management bonuses to the number of training hours their people “volunteer” for. Managers will then measure their supervisors on training hours their people receive. Supervisors will set a quota for laborers. Laborers will fill out the necessary form to show they’ve hit their training quota, and circulate answer keys if there’s a test at the end so that nobody fails to meet their quota. The efficiency-centric system returns to balance with no net impact: laborers aren’t inconvenienced, management receives its bonus, and the organization can now measure how much they "value knowledge." Everybody plays, everybody... well, it's complicated. Those who lead the initiative "win" because they can report that a measured improvement took place on their watch. Those who sponsored the initiative are "reaffirmed" because the firm can now prove they have knowledge-hungry people. The rest don't necessarily win, but they certainly "don't lose." And isn't that the point these days, to make sure everybody is a winner?

We see this pattern repeated with all kinds of well-intended initiatives, whether it be a mission for zero defects or a drive to be Agile. People will do everything they can to sustain that which they have already mastered, even to a point - misguidedly or maliciously - of giving the appearance of innovating and changing. Efficiency-centric organizations have stationary inertia that is extremely resilient to internally-initiated change. Only when an external event trumps every other priority - and most often it has to be a seismic event at that, such as the complete evaporation of revenue - will a bubble burst.

This kind of industrial thinking has made its way into IT. We assume our external environment (labor market changes, technology changes and so forth) are static, so we stand up a big up-front design, put together a deterministic project plan, and staff at large scale to deliver. We also see it more subtly when people look to code "annuities" for themselves: systems that are business-critical that they can caretake for many years. This creates an expectation of job security and therefore recurring income. This isn’t just a behavior of employees or contractors looking for stable employment: there are consulting businesses built around this model.

Going back to Brad's blog post, this creates a wage discrepancy and with it, a bubble. People who accept the annuity make the erroneous assumption that the rising tide of inflation will sustain their income levels. It’s actually just the opposite: the minute somebody is working in one of those annuities, their skills are deflating because they're not learning and accumulating new knowledge. So is the asset value of the thing they're caretaking. The people who do this misread the market (e.g., assume an outsized value of the asset to the host firm) and subsequently have a misunderstanding of their wage sustainability. The resultant wage bubble lasts until the "market" catches up: either the host firm takes costs out of maintenance (e.g., by labor replacement) or retires the asset. The person who was earning what amounted to an outsized income by being in this bubble faces that same seizmic correction as Ford did in the 1920s if they're not prepared with their own "Model A" of what they're going to do next.

The mis-fit of the industrial model in technology is that industrialization makes no provision for capability: each person is the same, the only difference being they're either more or less productive than the average, and indexed accordingly. That completely ignores the impact of destabilizing change that people make in what they do and how they do it. Disruptive, externally-driven innovation should be the rule, not the exception. Of all lines of business, this should be the case with technology. And with the right group of people, it is.

Disruptive innovation pops a bubble. A popped bubble threatens entrenched interests (e.g., those who have mastered life inside the bubble). But disruptive innovation is what makes a company sustainable.

¹ I am indebted to my colleague Chereesca Bejasa for using the term "bubble" to describe a team operating to a different set of processes and behaviours within such an environment. Just as a team can be in a bubble relative to the host organization, the host itself can be in a bubble relative to its market.

Is Google to IBM as Apple is to Apple?

In the late 1970s, the microcomputer industry was still in its emergent stages. Microcomputers weren’t nearly as powerful as mainframe and minicomputers. There also wasn’t clearly a “killer app” for them. But at the time, it was obvious that microcomputers were going to have a significant impact on our lives. People bought computers for home and used them for work. They even brought them from home and used them at work. While the software was primitive, you could solve many different kinds of problems and perform sophisticated analyses more efficiently than ever (e.g., the simple "what if" forecasting that we can perform in an open-source spreadsheet today was a major breakthrough in productivity 30 years ago). Having a microcomputer in the office was something of a status symbol, if a geeky one. And they made work fun.

The microcomputer industry had some other interesting characteristics.

Most corporate technology people (working in a department known as "Information Systems" as opposed to "Information Technology") didn’t take microcomputers all that seriously. They were seen as primitive devices with little computing power. Toys, really. From the perspective of the technology establishment, “micros” were only really useful if they had terminal emulation software (such as VT100, 3270, 5250) so they could connect to a more “serious” computer.

It was a highly fragmented market. There were lots of different combinations of architectures, operating systems and CPUs. There were also lots of different manufacturers, each offering their own standard and going in pursuit of business users, including firms such as Osborne, Sinclair, Commodore, Tandy and a rather unique firm called Apple Computer.

No one microcomputer platform was dominant. Each sought to develop and sponsor a library of applications and add-ons so they could sell hardware. For the most part, each relied on value-added resellers as their primary channel.

IBM took a different tact when they entered the microcomputer market,. IBM didn’t compete against the rest of the microcomputer market. They created a new market for something they called a Personal Computer. Using off-the-shelf components they built an open platform that anybody could replicate. Through the combination of brand, applications and reach, IBM was the standard in the personal computer space. The prevailing wisdom at the time was that “nobody got fired for buying IBM.” This made personal computers a safe corporate investment, and made IBM the standard.

For a few years, Apple and IBM waged a pitched battle. IBM, or perhaps more accurately, the "personal computer" standard as defined by IBM, was victorious and for all intents and purposes remains the dominant platform today. And while they lost control of that which they had created, IBM had strong hardware sales, while Apple was for many years relegated to being a provider in niche markets such as education and desktop publishing.

Fast forward 30 years.

A handheld computer / smartphone industry has emerged in recent years, and it shares many of the same characteristics of the early stages of the microcomputer business.

Smartphones have been underpowered for much of the past decade, but it’s pretty obvious that they'll soon become very powerful and will have significant impact on our lives. The current "killer app" - e-mail - is really a utility function. The equivalent to the microcomputer's “’what if’ scenario” capability hasn't yet been identified for the smartphone. But it will, and these devices will change how we live and work. As with the early microcomputers, a lot of people have bought a personal smartphones, and it’s not uncommon for people to use their personal handheld for work (e.g., using an iPhone for maps/navigation). The smartphone a person carries is something of a status symbol, if a bit of a geeky one. And they’re fun.

Until recently, we’ve been force-feeding big-screen (1440 x 900 pixel) form factors into small handheld devices. That is, until the current generation of smartphone arrived, mobile devices were primarily made useful as “internet terminals” more than application processors, no different from the terminal emulation of a previous generation.

It is a highly fragmented market, with competing CPUs and operating systems. There are also lots of different vendors with proprietary products, such as Nokia, Blackberry, Palm and another called Apple Computer.

No one platform is dominant. Each is seeking to create and sponsor a library of applications as a means by which to gain market share. Most sell through value added resellers.

Google recently entered this market. In many ways they’re taking the same approach as IBM. By offering an open platform, anybody can build a Droid-compatible phone. They’ve built out a sizable applications catalogue in a short amount of time. They also have brand and reach, although it can't be confirmed whether somebody has been fired for buying Google.

It's interesting to see not only the same market phenomenon happening on a different technology, but that Apple Computer (and specifically Steve Jobs) is at the epicenter of it.

Perhaps it will turn out differently this time. Apple has been through this same dynamic once before. They can also learn from Microsoft’s unsuccessful attempts to make Windows Mobile an ubiquitous platform . And Google has entered the hardware business on the Droid platform, but they're not a hardware company. However, none of this may matter. In the 1980s, the value was in the hardware, but the lion's share of revenue in the Android market won't be in hardware sales. This means Google is following a similar pattern, but changing the attributes. They're not pursuing a 30 year old strategy as much as they're updating a strategy to be the dominant provider in a current market.

No matter how this plays out, it's shaping up to be an epic battle for platform supremacy, just as we experienced 30 years ago. The microcomputer industry was highly innovative in the 1980s. It was an exciting business to be in. No doubt the same will be true of the smartphone / handheld computer business in the 2010s.

It was Mark Twain who wrote, “History doesn’t repeat itself, but it does rhyme.” We’re witnessing this now. Best of all, we have a front row seat.

Restructuring IT: Anticipatory Responsiveness

Michael Milken, the former junk bond king, has a charitable foundation. His foundation did some research a few years ago that determined that 70% of 7 chronic illnesses - things like diabetes, heart disease, lung cancer and so forth - are preventable through lifestyle change. They concluded that if people took better lifestyle decisions, doctors could focus their energies on enhancing and improving the quality and duration of life. But they can’t, because people create so much “remediation work” for them to do through poor lifestyle choices.

This is an apt metaphor for IT. We do a lot of things, such as introduce situational complexity and technical debt, that pile on the work we have to do.

This is at the heart of what we have to pay attention to in our restructure from industry to profession: if we know that we are not doing things that make more work to be done, and if we also know that we are doing things that consistently result in quality outcomes, we’re much less likely to self-inflict more work.

Restructuring IT requires us have a different set of expectations. When we follow traditional restructuring led with org charts and budgets, we take behaviours for granted. We simply can’t. Like US policy on nuclear disarmament in the 1980’s, we must trust, but verify.

The good news is, behaviours are actionable. There are things we can do to bring about the right behaviours in an organization. The bad news is, this is vastly different from everything we’ve been taught about reorganization.

The purpose of this restructure isn't to assign people into roles, but to build an IT organization that is durably, anticipatorily responsive. That’s a mouthful. “Durable anticipatory responsiveness” is the extent to which we’re consistently able to do things that allow us to get things done – complete things, useful things, not just bit twiddling. But it isn’t enough to just “get things done.” We have to avoid launching any self targeted missiles, like creating high-maintenance code and therefore high cost assets. So being responsive means doing useful things, and it means not making work for ourselves.

The “anticipatory” bit means that we’re doing things that allow us to look ahead to figure quickly out where we’re at risk, or where we have an opportunity. Anticipation is important. We’re not simply waiting around for things to happen. That was how IT applied Rapid Application Development. We tried it in the 1980s, and it let us be better, faster, cheaper… pick any two. We need to anticipate. We need to get in front of things. So, dealing with whatever comes through the door isn’t enough; we also influence the business agenda in a meaningful fashion. That means positioning IT as a peer with the business, not in a power struggle with it or subservient to it.

To restructure this way, we have a model . We look at 10 practices, each decomposed into 6 stages, that allows us to assess a team, department or organization. Each practice is explained in sufficient detail to allow us to identify how a team gets things done today, how people behave. We recognize there are behaviours that inhibit responsiveness (“regressive” behaviours), and there are increasingly aligned behaviours. Especially in the early stages of restructure, we want to establish basic collaborative behaviours, because we’re creating new work patterns among people in a team. We're building “muscle memory” of how people in a cross-functional team must work together.

Fundamental collaborative behaviours cannot be taken for granted. I was working with a program team last year that had hundreds of people working in different technology silos, delivering a solution that impacted 4 distinct lines of business. Originally, they were spread out across the building. The only physical organization they had was by area of technology (client-side devs sat together, server-side devs sat together, QA sat on a completely different floor, etc.) So we organized people into line-of-business teams and co-located them in the same physical space. But changing physical layout wasn’t enough to change behaviours, because somewhere along the way people ended up working on missions divergent from that of "develop a software asset."

One example of this was that teams were in the "defect tracking" business more than they were in the "defect fixing" business. Following the relocation, QA analysts were sitting next to developers in the same team, but rather than talk to each other, developers and QA continued to work independently and communicate exclusively via the defect tracking tool. Defect reports, questions, "non-replicatable" and "ready for retest" and so forth we're all communicated via tracking tool. Not surprisingly, this led to re-opens, failed retests, questions, requests for additional documentation, and all kinds of other hand-offs. That not only made the remediation process inefficient, it created very long histories of defect tracking activity that were more noise than signal as a lot of the data captured was irrelevant to the actual problem.

Because it was more important to show effort as opposed to results, they weren't behaving as a team delivering a software asset, they were behaving as a team that needed to track details about defects. By asking people to collaborate on solving defects at time of discovery, we were able to make defect repairs available sooner. In fact, it wasn't unusual for a repair to be available in a build in less time than it took to submit an initial defect report. Getting into a state where this was the de facto behavior did not happen simply because people were physically co-located and had some collaboration tools. It required active intervention by management working directly with developers and QA solving specific problems in a collaborative manner.

Behaviour change is not a one-time action. Team circumstances change: people come and go, technology is upgraded, business needs change, etc. That means we must constantly pay attention to behaviours if they are to be durable. To do that, we can apply the model as often as we need - annually, quarterly or monthly - to ascertain whether people are making good "lifestyle" decisions." This allows us to assess the extent to which we are restructuring the fundamental organizational behaviours to focus on results as opposed to effort.

However, we must be careful. Competent assessment is a capability, not a task. Assessment is not done by questionnaire or checklist, and "objective self-assessment" - asking teams to critically analyze their own behavioural restructure - is most often wishful thinking. It requires an experienced touch to apply a combination of archeology and sociology to separate the opinion of how people aspire to work from the fact of how they are actually working. Creating a competent assessment capability requires investment, but it is critical to success as the assessments provide the telemetry of restructure.

We now know that to be a results-based organization, we must reorganize around behaviours. We have a good idea of what those behaviours are from an established model. We can use this model as both guide to and instrumentation of our restructure. But before we go off in pursuit of restructure, we must first internalize some guiding principles. We'll cover in the next installment of this series.

Restructuring IT: Organizing for Results

Up to this point in this series on Restructuring IT, we’ve looked at how IT has adopted an industrial model. IT has achieved scale, but at the cost of results, as is clear from the low rate of success of IT investments. We'll now take a look at how we can organize IT for results.

Professional versus Industrial

IT needs to reorganize for results, not scale. Organizing for results requires professionalism as opposed to industrialism.

People in industrial and professional situations each use drills, but you wouldn’t staff an assembly line worker in an operating room to get "capacity" on a surgical team.

To get professionalism, we need to organize less to try to be predictable (which will always escape us) and more to be responsive and accountable.

Let’s think about the things that would professionalize IT.

• Instead of scrambling just before a deployment, what if every solution build acted as an internal gatekeeper of quality, continuously executing to validate technical, functional and non-functional completeness of everything we do?


• Instead of trying to “inspect quality” into IT, what if testing were a team responsibility, automated and integrated into what we do daily?


• Instead of watching big-up-front designs morph from whiteboard masterpiece to over-engineered Frankentecture, what if teams had the flexibility to take design decisions in near-JIT fashion, with a minimum of duplication and the fewest moving parts possible?


• Instead of a “requirements arms race” between business and IT, what if we were able to accommodate continuous business involvement, facilitated to enable continuous change management and adaptive project management?


• Instead of standing up volumes of impenetrable and unactionable requirements, what if we had short, business oriented requirements that could be quickly steered through development and QA and into production?


• Instead of sending round reams of paperwork for PMs to fill out in little more than CYA exercises, what if we were able to govern IT non-invasively, ascertaining from our delivery teams whether they’re delivering value for money, and working in accordance with expectations?

We have the means by which to do all of these things. Today. Right now. But we can’t simply will them into place. To get these things, we need to restructure IT.

What does it really mean to “restructure”?

Before we discuss what restructuring IT is, let’s first understand what it isn’t.

Restructuring IT isn’t a question of org charts. All too often, new reporting lines just rearrange the deck chairs on the Titanic. It also isn’t about budgets, either: we can’t do more with less, because there isn’t that much less with which we can get any more done with.

How about the management cheerleading of recent years, things like “be close to your customer” and “have fewer hand-offs in your work processes.” When folks like Tom Peters started putting those messages forward in the 1980s they were a wake-up call that business had gone adrift. And yes, we need to restructure with this in mind. But we can’t have reorganization by platitude. We need something actionable.

Restructuring IT is about behaviours. Changing behaviours away from industrial thinking to professional thinking is a pretty big shift. Among other things, it means each person is responsible not just for doing the tasks they’ve been assigned, but doing what is necessary for the project to succeed.

Think back to the surgical team metaphor. As my colleague Greg Reiser points out, the surgical team collaborates toward a shared objective, improving the quality of life of the patient. Their primary goal may be to graft blood vessels that bypass a coronary artery blockage, but their objective is to prolong the life of the patient. What does the team do when they discover, as they almost always do, that the condition of the heart and surrounding tissue is not exactly as they expected? They apply their professional expertise and work as a team to adapt in order to achieve the primary objective. This is how professionals behave.

It doesn’t help, of course, that there are so many headwinds to getting things done in IT, ranging from a constant cycle of upgrades that change points of integration to an abundant supply of people without the complete gene in their DNA. Results are hard. Finishing stuff is hard.

This begs a critical behavioural question: why take the risk of getting “results”? Why put yourself on the line, underwriting success with your personal guarantee, especially if you have a built-in scapegoat? I met with a team last year where the PM, BA and dev lead knew a project was going to fail, because the development team simply didn’t have the capability. The project leadership didn’t make any effort to change staff, because the decision of who to staff was somebody else’s: people were supplied to them by procurement. The project was conspicuous because it was late starting as it was, so their priority was to get started. Never mind that they knew it wouldn’t finish. In the end, they could say they simply played the hand they were dealt by the organizational structures – in this case, an industrial-inspired procurement function – that existed to make IT effort “cost effective.”

So rather than work to success, rather than pressing the button and stopping the line and saying “this project is going to fail and we need to do something about it before we make a commitment of capital and time” they simply got on with the work knowing they were going to fail.

This is all too common. There is structural disincentive to achieve results in a lot of IT organizations. This disincentive is supplemented with soft scrutiny. Most measures of “complete” amount to little more than people working to a state where nobody can tell them they’re not done, instead of working to a state where somebody can conclusively tell them they are done.

So what makes us think people will make the effort to get things done?

It also makes you wonder: how much of this is going on in your IT organization today?

In our next installment, we'll take a look at how, specifically, we restructure for results.

Join Your Peers at an Agile Governance or Budgeting Event In October

October is normally a heads-down month. In addition to being in the home stretch of meeting our yearly objectives, we must dedicate cycles to shaping, communicating and justifying our plans for next year.

October is also a busy month for information sharing. The thoughts and ideas that have percolated through the year reach their maturity about this time, and we want to share them before everybody goes on their winter holidays. ThoughtWorks has no shortage of events coming up, and I am privileged to be a part of many of them.

If you’re in Chicago on Tuesday October 20, ThoughtWorks is hosting a panel discussion on the Budgeting and Financial Implications of Agile. On the panel are experienced IT leaders who head strategy, portfolio management and application development for their respective businesses. They've come to terms with balancing short-term operational flexibility with long-range budget forecasting. Stop by the Aon Center at noon if you can, but please register before you do.

Our first webinar in the Agile PMO series, Real Time Metrics, was very well received. We’re pleased to present Real Time Governance, a follow-on webinar that extends the concepts to their next stage of evolution. I’ve had the opportunity to present the Governance material with my ThoughtWorks colleagues Jane Robarts and David Leigh-Fellows in Calgary, Toronto (which was recorded and is available on InfoQ) and San Francisco. We’re broadcasting this next as a webinar with a full Q&A session on Thursday, October 22nd. The response has again been very enthusiastic, but with virtual seating at a webinar there are unlimited spaces, so please feel free to register and attend.

Members of the Project Portfolio Management Professionals association attended our Real Time Governance presentation in San Francisco last month and invited us to present it to their membership. I’ll be presenting to the PPMP via webinar on Friday, 23 October. If you are an IT leader with project portfolio management responsibility today, I strongly encourage you to look into this association. Take a look at their website or reach out directly to them for an invitation.

If you’re in Dallas on the 27th, I’m hosting an executive roundtable on Financing and Budgeting Agile projects. ThoughtWorks hosted a similar event in Chicago back in August. The people who attended that event have self-organized a micro-community. We’ve had a follow-on event and lots of peer-to-peer conversations as we mutually educate and collaborate on the unique funding and forecasting challenges and opportunities presented by Agile. Reach out to me directly if you're interested in attending the Dallas roundtable.

Finally, ThoughtWorks is sponsoring Agile East at the end of October in Philadelphia on the 29th and New York on the 30th. We have a powerhouse lineup of experienced, thoughtful practitioners, including Martin Fowler, Graham Brooks, Premanand Chandrasekharan, Carl Ververs, Joe Zenevitch, Shyam Mohan, Greg Reiser, Andy Slocum, Tiffany Lentz, Manu Tandon and Alla Zollers. This is an outstanding group of people and I’m humbled to be a presenter among them. I’ll be giving the noon keynote on Budgeting and Financial implications of Agile. Specifically, I'll be looking at how Lean and Agile allow us to maximize capex but require us to be extraordinarily diligent to prevent the perfect storm that can create an IT liquidity - and potentially IT solvency - crisis. I can’t stress enough what a stacked lineup of people this is. Make plans to be in Philadelphia or New York at the end of the month, just be sure to register.

Restructuring IT: The Detroitification of IT

In previous installments of this series on restructuring IT, we looked at how IT has adopted industrial practices as it has gone in pursuit of scale. As a result, IT bears striking resemblance to Detroit automakers. Let's look at some common characteristics.

Sub-Optimal Quality

Detroit suffers its periodic crises of quality. There was a joke that made the rounds during the 1970s that you know you have an American car when you get the factory recall notice in the mail. In much the same way, industrial IT is notorious for low technical quality of what it produces.

Long Time-to-Market

Detroit has excessively long product development times. It takes years to go from idea to availability. Former Chrysler CEO Lee Iacocca famously went on a tirade when he wanted to see what the LeBaron would look like as a convertible. His design manager told him something to the effect that they first needed to do a scale model, then a wind tunnel, then the prototype, so they’d have it for him in about 6 months. Iacocca’s reply? “Just take a chain saw to the roof!” How many CEOs look at their IT department and ask, “why is it so hard to get anything done in IT?”

Too Much Leverage

Detroit got by for so long because it could “pull demand forward.” Very few people pay cash for their cars. Instead, they finance their purchases. They're buying a car based on future earnings, not on their accumulated savings. Think about what happens in industrial IT, in terms of capability. There’s far less supply of “bankable capability” than there is demand. Instead, the industrial IT model looks for capacity. It puts people new to the IT industry in a position to put code on the line, learning as they go along. In effect, the industrial IT model borrows against future capability development. There’s even a few firms that have bet their entire business on this model.

As my colleague Greg Reiser pointed out recently in a webinar we produced for cio.com:

The extreme case of this are the large IT outsourcers that have rapidly grown over the past 20 or so years. Many firms that have actually bragged about their ability to add over 1,000 new professionals per month! Now while I can comprehend the ability of the US Marine Corps to add new soldiers at that rate, I personally cannot comprehend how a professional services organization can effectively add, develop and assimilate knowledge workers at such a pace. So I am not surprised when clients of these firms complain about the shallow depth of talent assigned to their projects. Remember, although the Marines put all recruits through a rigorous 12-week training program, every single one of those recruits is still just an entry-level soldier at its conclusion. It can take years to train and groom people for more challenging roles. Why should you expect different for software engineers?

Producing Solutions People Don't Want, but Have No Choice But To Use

Finally – and this one is arguably a bit of a stretch – Detroit has suffered eroding market share for many years. In many cases, they’re turning out cars people don’t want to buy, year after year. Increasingly, the people who do buy the cars are the people who have to buy the cars. E.g., they’re people who are in the automotive ecosystem. Sound familiar? IT stands up solutions that business users don’t want but have no choice but to use because they're in the corporate ecosystem.

A Troika of Trouble

There are three factors accelerating the rate of Detroitification of the IT industry.

1. We have a capability shortage. For one thing, we’re not developing “heroes” in sufficient numbers to prop up this system, the folks who can jump among silos to do the unperformed tasks lost in the handoffs that happen in specialization. For another, IT isn’t the destination employer for people that it once was. (And by the way, neither are automakers.)
2. We’re overloading on “situational complexity.” To get something done in most IT shops a developer has to be fluent in an esoteric landscape of existing systems, policies and procedures. Somebody might be the smartest developer in the world, but they'll make no impact unless they invest time in mastering the esoterics. That’s not attractive knowledge for somebody to acquire, because it’s not portable. There's not much value in having “I learned all the weird stuff necessary to get things done in this specific functional area of company x” on a resume. It’s also a frustrating experience, as very often the people alleged to have the right information aren’t really authorities themselves.
3. Quality is assumed. Solutions delivered today are laden with technical debt, but very rarely is anybody looking for it. Apply metrics over just about any codebase in just about any company, and the odds are that you'll find at least one of the following: excessive complexity, excessive duplication, poor encapsulation or excessively long methods.

An increase in situational complexity, plus an increase in technical debt, combined with a decrease in total capability gives us exponential growth of people expending effort but showing little in the way of business results.

We should obsess about results, not scale. Scale is useless if we can’t get stuff done.

We’ve had a look at the problems with industrialization. Next, we'll look at how we can reorganize IT for results.

Restructuring IT: "Too Big to Fail" Doesn't Equal Success

By going in pursuit of scale, we’ve created an IT function that is “too big to fail” in many businesses. Companies depend on IT – many can’t operate without it – yet they don’t really understand it.

The result is moral hazard. Moral hazard is the proverbial “heads I win, tails you lose” scenario: a person takes boneheaded risks knowing that if they turn sour, somebody will come to their financial rescue. There is tremendous concern that we're witnessing this in financial markets today: banks bought high-risk collateralized debt obligations with borrowed capital to juice returns, only to need the US taxpayer to intervene to rescue them when the value of those assets collapsed and the market for them dried up. The moral hazard of the situation is the disincentive for the banks to be prudent risk-takers in the future: if a person knows somebody will bail them out, there's no reason not to take boneheaded risks again.

This describes IT. We stand up massive projects that fail more often than not. When they fail – 6 out of 10 times mind you – the business sponsoring the initiative bails it out. And there’s no downside risk: those people who were bailed-out continue to hold down their jobs because “they’re the only ones who know the system.” They might even get promoted. This creates moral hazard in IT, as it builds in the expectation that success of the project is optional.

This is the result of industrial thinking. IT defines highly specialized roles that assume people perform repetitive tasks. This allows IT to scale by hiring armies of people, each into a very narrow position, making people expert at one very specific piece of the solution chain. Unfortunately, it also makes the success of a project an abstract goal for each person, and success of each person a relative goal. Restated, in the industrial model each person is less responsible for success of the project, and solely responsible to show that they did exactly as they were told.

Think about an IT project a long-jump team, staffed not with one person who can jump nine feet, but nine people who can jump one foot. Clearly, the results aren't going to be the same.

This is why we’ve hit the limit with industrialization. Industrial IT assumes people are automatons performing specialist tasks in a repetitive fashion. That assumption is diametrically opposed to our business partners' perceptions of IT as a source of innovation. An industrial approach that values specialization and repetitiveness implicitly stifles innovation, invention, initiative and leadership. It bleeds out creativity. I had a colleague tell me the other day that two people on a team he was working with would sit and stare at the wall until told exactly what to do. Once done, they'd go back to staring at the wall. That’s industrial IT in action, and it's devoid of innovation.

We've seen this same industrial phenomenon in other professions. For example, when professional sports leagues expand, the quality of play goes down. Consider baseball. When Major League Baseball expanded a little over a decade ago, players posted outrageous offensive statistics. The reason? There were a lot of pitchers in the major leagues who weren't really "major league." They were just people hired to fill the roster, to hold a spot in the rotation. On the days those people would pitch, the team managers would hope only that they wouldn't hurt them, more than they had any hope that they would actually help.

We have this in IT. They’re called “net negative” people. These are people who create more work for people to do than actually solve the problems we need them to solve. Analysts who write requirements that need to be substantially re-analyzed before they can be turned into code, developers who write code that is of such poor quality that it needs to be rewritten before it can be released to QA, or testers who execute test scripts without being able to pass or fail them because they don't really understand what it is they're testing in the first place all create more work for people to do than they contribute. Overall, they're "net negative" to the project.

Businesses will be restructuring for quite some time. That amplifies the risk of a late-stage project failure to IT, because project bailouts are less likely in this business climate. To come to terms with this new environment, IT needs to be less concerned with industrial scale, and more concerned with bottom-line results.

Before we get into the details of how we need to restructure IT, we'll first take a look at the similarities between the state of mature industrials and the characteristcs IT is showing today. We'll also look at the factors that are accelerating IT toward the same fate as the US automakers.

Restructuring IT: A Different Look at the Business-IT Relationship

The relationship between IT and its business partners is notoriously bad. Year after year, surveys by different research organizations report that improving that relationship is a top-10 priority for CIOs. But despite being a high priority for many years running, it hasn’t improved all that much.

Before we can make any headway improving that relationship, we must first understand how IT's pursuit of scale is responsible for a lot of the dysfunction.

Let’s take a look at what the business and what IT each want from the relationship.

First, what does the business want from IT? To put that question in perspective, we need to externalize a bit. Let’s think about what we want from the relationships we have with our key suppliers, such as the place where we go to get our coffee in the morning.

• We want results from our suppliers. In our example, we want our coffee in whatever configuration we ordered (hot or iced, cow/soy/no milk, etc.) within a reasonable amount of time after we order it.
• We want to work with professionals: we don’t want to see people scratching their heads wondering how to grind beans or froth milk. We also don’t want to hear somebody tell us that pouring drip coffee into an insulated cup “isn’t their job.”
• We want a relationship. A couple of months ago, the WSJ ran a story that people are less likely to cut back spending at places where they have a relationship with the firm, even if their household income statement tells them they need to make severe cuts. This certainly rings true in our coffee shop example: we like it when people recognize us, and have our drink ready for us before we order.
• We want innovation. If somebody offered us a cappo-moca-latte we’d probably give it a try. We want to know people are thinking about our needs and our experience as a customer.
• We want to trust the people with whom we do business. Certainly, we want to know that we get a full cup of coffee, with ingredients that aren't spoiled.
• We want value for money. We may very well pay $2.75 for a cup of coffee, but we have to feel that the coffee we're getting is worth that $2.75.

This doesn’t really describe how IT has approached its relationship with its business partners. Historically, it's had a different set of priorities.

• IT has been in pursuit of “big” as opposed to results. To get “big,” we’ve created specialist roles so we can train and staff armies of people.
• IT keeps business partners at arm’s-length: it’s been “you do the business, we’ll do the technology.”
• IT prefers predictability over innovation. In technology, Java is the new Cobol. Also, IT project management is most often an excessively detailed project plan that tries to define every action that people will take far into the future.
• IT doesn’t look to establish trust, as much as we want people to have faith that we'll overcome whatever problems we may encounter.
• People in IT are generally more interested in solving interesting technology problems than they are providing value for money.

What we end up with is a pretty big relationship gap. IT is opaque. IT solutions are laden with technical debt. There aren’t enough cross-trained heroes to bridge the gaps that exist among all those specialists. Each partner in this relationship has an unhealthy dependency on the other: business can't function without IT, and IT reacts more than it leads critical business decisions. The bottom line? IT still has a success rate no better than 4 in 10.

So it really shouldn't be a surprise when we hear a CEO, CFO, COO or even a CIO ask, “why is it so difficult to get anything done in IT?”

The Case for Restructuring IT

Business is tough right now, and it’s going to be so for a while. In tough times, you want to be very good at what you do. The more “fighting fit” you are, the more likely you are to survive a challenge.

Unfortunately, IT isn’t all that good at what it does. In fact, on the whole, it’s pretty bad. That means that IT isn’t very well prepared for this downturn.

How bad is it? The research organizations have historically reported a pretty high failure rate of IT projects: about 30% of all IT projects fail outright, while another 30% disappoint their business sponsor (e.g., excessive cost, wrong functionality).¹ On the whole, an IT investment has, at best, a 4 in 10 chance of success.

Companies are already reticent to invest in this climate. IT doesn't offer scared capital a safe haven.

It also suggests that IT is on a trajectory of self-destruction. If we want to look ahead to where IT is headed, we need look no further than present day Detroit.

Photo credit: Ben Wojdyla, The Ruins of Detroit Industry

How did this happen? Consider some of the forces that have shaped the current IT landscape in the past 20 years. The steady growth of IT that was accelerating slightly with the advent of client/server gave rise to explosive growth driven by the combination of internet and Y2K. By the mid-1990's, demand for IT was dramatically outstripping supply. To satiate this demand, IT went in pursuit of scale. To get scale, IT took professional jobs and codified them into industrial tasks, because it’s easier to staff vast numbers of people in highly specialized roles than it is to develop professional capability to solve business problems using technology.

Today, businesses buy, recruit, staff, govern, gatekeep, develop, analyze and test following a model that puts a priority on “big.”

Unfortunately, all the time we’ve been in pursuit of scale, we’ve not been in pursuit of results. Results are assumed. We assume armies of specialists will follow an explicitly defined project plan to produce a solution that is technically sound, functionally complete, and financially satisfactory, all with minimal risk of impairment.

With a 4 in 10 batting average, results cannot be assumed.

By placing a priority to scale, IT mistakes effort for results. We often see success expressed as a function of hours to be invested. It isn’t that simple. Successfully delivering an IT solution is a function of a lot of factors, such as clear communication, effective collaboration and capability; well-informed decision making about technology, functionality and commercial viability throughout the life of a project; flexibility and responsiveness; and ultimately, producing meaningful things for our business partners. These can’t be captured in task orders and forecasts of work effort. They’re lifestyle decisions of how IT goes about its business.

It is time to restructure IT, to move away from an effort-centric industrial model, towards result-centric professional one.

¹ As an example, the 2009 CHAOS report from The Standish Group shows that things haven't changed all that much, reporting 44% of IT projects were challenged (late, over budget, and / or with less than required features and functions) while another 24% failed.

Are You Ready to Restructure?

Global business faces unprecedented changes. Earlier this year, I wrote in an article for alphaITjournal.com:

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.

The need to restructure will be with us for a while. The financial economy isn't functioning normally, as capital markets remain on life support. The real economy isn't functioning normally either. We're still in the midst of business bailouts. Bailouts will give rise to bankruptcies, which will give way to restructuring. "Restructuring," says Gilles Moec, economist with Bank of America, "is very much the story of 2009." And business leaders seem to expect to face restructuring for some time: in a recent survey, IBM found that 91% of CEOs believe they need to restructure their businesses.

IT won't escape this phemonenon, and it must also restructure. Procurement, management and execution of IT have traditionally been focused on effort. IT has the opportunity to restructure for results, to be a transparent, efficient, responsive and collaborative participant in the business. There is tremendous upside for doing this, as it will make IT less a captive supplier of technical services, and of more an engaged business partner.

ThoughtWorks recently released a webinar I recorded on restructuring IT. I've also posted articles specific to restructuring IT on alphaITjournal.com. One covers challenge of change management during restructure, the other governing restructure. In the coming months, I'll be posting a blog series on IT restructuring that covers the deficiencies in the "industrial IT" mindset, defines a better future state for IT, and ways to go about remaking an IT organization to achieve that.

IT faces unprecedented challenge today. We have our work cut out for us, but we already have many of the solutions at hand that will allow us to meet those challenges. The opportunity is there for IT to get in front of this, and be at the forefront of corporate leadership. In turbulent times, better to be in a leadership role than relegated to a supporting position.