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.
Labels: Change Management, IT Governance, Restructuring IT, Strategic IT
¶ 11:37 PM
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.
Labels: Agile Management, IT Governance, Leadership, PMO, Strategic IT
¶ 8:00 AM
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 LeverageDetroit 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.
- 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.)
- 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.
- 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.
Labels: Change Management, IT Governance, Restructuring IT, Strategic IT
¶ 8:26 PM
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.
Labels: IT Governance, Restructuring IT, Strategic IT
¶ 8:00 AM
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?”
Labels: IT Governance, Restructuring IT, Strategic IT
¶ 2:00 PM
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).1 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.
1 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.
Labels: Leadership, Restructuring IT, Strategic IT
¶ 10:17 AM
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.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.
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.
Labels: Agile Management, Change Management, IT Governance, Restructuring IT
¶ 12:26 PM
