Good Management Can Work Miracles

Pharmaceutical companies do not successfully deliver drugs just because they hire a lot of highly skilled researchers in lab coats. They deliver drugs because they have people to secure funding for research of some drugs over others, to take them through lab and clinical trial, to steer them through regulatory approval, to manufacture, to make doctors aware of them, to distribute them to hospitals and pharmacies, and to follow-up on results. When it all comes together, the overall benefit of the resulting system can be incredible, such as an increase in life expectancy. As Thomas Teal wrote succinctly, “Good management works miracles.”¹

The same applies to an Information Technology organisation that is core to achieving alpha returns: it needs the management practices to match high-capability people. Consider Xerox PARC. In the 1970s it spawned tremendous innovation in personal computing technology. From those innovations came products, solutions, and even categories that didn’t previously exist. Billions of dollars of revenue and profitability were generated – for everybody but Xerox. Why? Bright people were inventing and innovating, but nobody was there to monetise their work.²

In general, IT has structural and social deficiencies that conspire against development of a management capability. Technical IT jobs offer individual satisfaction on a daily basis, with frequent feedback and acknowledgement of success at solving a very specific problem or challenge. IT reward systems are also often based on individual performance tied to granular and highly focused statements of accomplishment. This is contrary to IT management positions where the results of decisions made may not be realised for weeks or months, measures of success are often less tangible, and rewards based on the performance of a large collection of individuals. It is also not uncommon for a company to belittle the value of management by defining it as a collection of supervisory or hygienic tasks e.g., to ensure everybody on a team has taken requisite compliance training each quarter and submits their timesheet each week. In other instances, line management may simply have all decision-making denied it, relegated to polling subordinates to find what’s going on to summarise and report upwards, while also being given messages from higher up to deliver to the rank and file. These aren’t management practices, they’re tasks of administrative convenience masquerading as management.

These deficiencies are supplemented by an IT industry that, on the whole, doesn’t place much value on management. Technical people promoted into management positions will very often resist management responsibilities (e.g., electing to continue to perform technical tasks), and also be highly unleveraged in a team (one manager to dozens of direct reports.) There is more precise definition and greater mobility of technical jobs than of management jobs. The same is true for skill acquisition: there are a wealth of IT oriented books, magazines, journals and publications on very specific technologies or applications of technologies, but not nearly the depth on matters of management. And all too often, what passes for management guidance in books and publications are lightweight abstractions of lessons learnt wrapped in layers of cheerleading and self-esteem building directed at the reader, not principles of sound management science. No surprise, then, that it can be far more attractive for an IT professional to prefer a career path of “individual contributor” over “manager.” Collectively, this doesn’t help increase in number the ranks of capable managers.

One of the root causes is that IT is considered a technology-centric business, as opposed to a people-centric one. ³ By definition, IT solutions – what the business is paying for – are not delivered by technology, but by people. The misplaced orientation toward technology as opposed to people means that management tends to focus not on what it should – “getting things done through people” – but on what it should not – the “shiny new toys” of technology assets. This misplaced focus creates a deficiency in management practices, and widens the capability gulf relative to the demands being placed on IT today. It is a structural inhibitor to success in delivering solutions.

Top-down, high-control management techniques have proven to be orthogonal to the IT industry. Amongst other things, this is because of a high concentration of highly-skilled and creative (e.g., clever at design, at problem solving, and so forth) people who don’t respond to that style of management. It is also because top-down practices assume an unchanging problem space, and thus an unchanging solution space. Unfortunately, this is not a characteristic of much of what happens in technology: IT solutions are produced in a dynamic, creative solutions space. For one thing, most projects are in a constant state of flux. The goal, the defined solution, the people, and the technologies constantly change. This means day to day decisions will not move in lock step with initial assumptions. For another, in most projects there is not a shared and fully harmonised understanding of the problem: if anybody on the team has a different understanding of the problem, if there is latency in communicating change to each member of the team, or if somebody simply wants to solve an interesting technical problem that may or may not be of urgent need to the business problem at hand, decisions on the ground will be out of alignment with overall business needs.

Each IT professional takes dozens of decisions each day. The principal objective in managing a highly-capable organisation is not to take decisions for each person, but to keep in alignment decisions people take. Management of a professional capability is thus an exercise in making lots of adjustments, not pushing blindly ahead toward a solution. But facilitating lots of adjustments isn’t a simple problem because management doesn’t just happen by itself in a team. As Dr. George Lopez found out, changing to self-managed work teams isn’t a turnkey solution:

• With no leaders, and no rules, "nothing was getting done, except people were spending a lot of time talking." After about a year and a half, he decided teams should elect leaders.⁴

But that, too, isn’t enough. The basic management tools and structures must be present or this simply doesn’t work. Consider this description of Super Aguri’s F1 pre-race meetings:

• "The process is very formal," says Super Aguri sporting director Graham Taylor. "I chair our meetings and ask the individuals present to talk in turn. Anyone late gets a bollocking, only one person is allowed to talk at a time, and it absolutely is not a discussion. It … is absolutely the best way to share a lot of information in a short passage of time. … If you don’t need to be there, you’re not."



• … While the briefing process has always been with F1, the structure has evolved to absorb the increasing complexity of cars and the concomitant increase in team size. "When I started in F1 there were 50 people in the team, now there are 500," says [Sam] Michael, […Williams technical director]. "If you don’t have a firm hold, not everyone gets all the information. You need to have structure.”⁵

Consider how many layers a team, or even an individual developer, may be removed from a large IT programme. The lack of upward transparency from the individual and downward visibility from the programme management makes it nearly impossible to keep decisions aligned. This is where good management delivers tremendous value: the basic, focused structures of Agile project management – the daily stand-up, the iteration planning meeting, the retrospective, the iteration tracking report, the release plan – provide focus, structure, and discipline that facilitate maintaining alignment of individual and group goals. A salient point in the example from Super Aguri is that greater team capability makes the need to do these things that much more acute: the higher the degree of professional capability in the team, the more adjustments there can be to make, if for no other reason than the rapidity with which the highly capable will work a problem space.

“We are not a family,” Robert Lane, the CEO of Deere & Co, recently said.⁶ “What we are is a high performance team.” If IT is to deliver high-performance results – to be an alpha capability that contributes to alpha business results – it requires not only high-capability people but the management practices to match.

¹ Teal, Thomas. "The Human Side of Management." Harvard Busines Review. April, 1996. I highly recommend reading this article. He deftly summarises the gap between the impact management has relative to the investment made into developing talent completely. It has arguably become more pronounced in the 11 years since this article first appeared.
² Gross, Daniel. “How Xerox Failed to copy Its Success.” Audacity. Fall, 1995. Audacity, the business journal, has long since ceased publication which is a shame: it provided excellent snippets on business decisions, both successful and unsuccessful, in the broader context of their market conditions.
³ The change in moniker from “Information Systems” to “Information Technology” was, arguably, a step in the wrong direction. The word “systems” is expansive, and extends to solutions with partial technology component to them - or none whatsoever. “Technology” narrows the remit, and thus the business impact, of what we now call “IT.”
⁴ White, Erin. “How a Company Made Everyone a Team Player” The Wall Street Journal, Monday 13 August 2007.
⁵ Grand Prix Tune-Ups” F1 Racing Magazine. August 2007. As perhaps the first among high-performance industries, it’s interesting to see what sounds very much like a stand-up meeting being core to race day execution - and how it has allowed them to scale.
⁶ Brat, Ilan and Aeppel, Timothy. “Why Deere is Weeding Out Dealers Even as Farms Boom” The Wall Street Journal, Tuesday, 14 August 2007.

Alpha Returns Require an Alpha IT Capability

Demand for IT in business continues to rise. Looking backward, over the last 10 years the IT market has absorbed the new capacity in Asia and South America, yet still we find global and national/regional IT employment is up since 2000.¹ Looking forward, all indications are that demand will continue to rise. More importantly, there are very strong indicators that IT will increasingly be a strategic capability: the forecasted increase in worldwide investable assets is creating demand for new sell-side financial products;² fact-based management is increasingly being applied to sweat assets or improve competitiveness of operations, which in turn demands increasing amounts of data about specific businesses and processes;³ and the re-emergence of high-risk capital (the recent downturn in credit markets notwithstanding) is funding start-up companies suggest that demand for IT will continue to rise.

This presents both a dilemma and a competitive opportunity for companies today.

IT is, fundamentally, a people business. While the systems and solutions it produces might automate tasks of the business, not to mention allow for complex tasks not otherwise practical to be manually executed, the production of those systems is a people-centric process. It stands to reason also that the more complex the solution, the more skilled the people behind the solution. The challenge facing an increasingly strategic IT isn’t a capacity question, but a capability question. Skills and capabilities are not commodities. It takes a great deal of individual skill to solve business problems through IT systems, specifically to model, code and construct solutions that scale, are secure, and are reliable. The highly-capable IT professional, one who has the ability to perform technical tasks as well as understand the business context, is already rare. But as IT becomes a driver of strategic imperative, these professionals will be in that much greater demand. The problem facing IT, then, is that the increase in demand for strategic business solutions that have a significant IT component will outpace the arrival rate of new highly-capable IT professionals, making the highly-capable IT professional that much more scarce.

This is obvious through the example verticals posited above: an increase in development of sell-side products, or an increase in the demand for greater and more accurate data on the business (and business processes) are clear examples of companies trying to achieve returns that beat the market by making use of a significant IT component. The trick to yielding higher ROI through such strategic IT solutions is not to reduce the “investment” on the IT component. Such strategic solutions can’t be sourced based on cost-of-capacity; they need to be sourced specifically on the capability of those delivering the solution. Capacity - the time available to work on developing these solutions - will not alone deliver the solution as emergent products and greater business insight are arrived at iteratively, and through business-IT collaboration. Looking simply at IT capacity to do such tasks is to hold skills as a constant. In a people-centric business, skills are not constant. The trick to yielding higher ROI through strategic IT solutions is to achieve “alpha” IT capability relative to the market – that is, to have an IT capability that beats the average, or “beta,” market IT capability. Specifically, sourcing an IT capability and allowing it to improve at the same rate of the overall market (beta) isn’t going to be sufficient if IT is to be a driver of above-average returns (alpha.) To drive above-average market returns, that IT capability must itself be above average.

Being “above average” or “below average" is difficult to assess because there is no “IT capability index” and thus no baseline for IT in general, let alone within an industry. Subsequently, any assessment of IT capability is likely to be laden with assertion. Worse, we have often allowed “results” to act as a surrogate for an assessment of IT effectiveness, but looking exclusively at results is often incomplete, and there is a high degree of latency between results data – the quality of delivered IT systems – and capability development. It is possible, though, to take an objective assessment of IT capability. We can look to a wealth of indicators – development excellence measures such as code quality and delivery transparency, staff peer reviews, customer satisfaction, and business value delivered – to create a composite of IT effectiveness. In some cases, we may need to have relative baselines: e.g., we measure over time against an initially assessed state of something like customer satisfaction. In other cases, we can identify strong industry baselines, such as code quality metrics we can run against the source behind such open source projects such as CruiseControl, JBoss, Waffle, PicoContainer and many, many others to provide an indicator of achievable code quality.

Gaining a sense of relative strength is important because it provides context for what it means to be high-capability, but it doesn't define what to do. Clearly, there must be things a strategic IT organisation must do to become high-capability, and remain so over time. And this isn’t just a money question: while compensation is a factor, in an increasingly competitive market you quickly end up with a dozen positions chasing the same person, all the time.⁴ The high-capability IT organisation must offer more than comp if it is to be durable. It must be a “destination employer” offering both skill and domain knowledge acquisition as well as thought leadership opportunities. This requires investing in capability development: skills, specialisation, innovation, and so forth. Going back to our examples, the development of cutting-edge sell side products (e.g., structured credit products) will require business domain fluency as well as a high degree of technology skill. Similarly, if companies are to “sweat the assets” of a business to their limits requires a very low noise-to-signal ratio of their business intelligence; that requires IT to be highly fluent in business process and business needs. Companies seeking alpha through IT cannot be obtain this capability through beta activities such as the acquisition of new technology skills through natural turnover and changes in the overall market capability, or the introduction to the business domain through immersion in an existing codebase. Indeed, companies relying on beta mechanisms may find themselves underperforming dramatically in an increasingly competitive market for capability. Instead, to be drivers of strategic solutions and thus alpha results, capability must rise from strategic investments.

The successful development of this capability turns IT into a competitive weapon in multiple ways. The business context is obvious: e.g., new sell-side products will clearly allow a trading firm to attract investment capital. But it goes beyond this. In a market with a scarce volume of high-performance people, being the destination employer for IT professionals in that industry segment can deprive the competition of those people. Hindering a competitor from developing an alpha IT capability will undermine their ability to achieve alpha returns. This makes IT both a driver of its host firms returns as well as an agent that disrupts the competition. This clearly demarks the difference between beta reactions, such as anticipating IT demographic changes in anticipation of recruiting efforts, and alpha reactions that create those shifts through recruiting and retention activities that force competitors to react.

This does not apply to all IT organisations. Those that are strictly back-office processing are simply utilities, and can, with minimum risk, trail the market in capability development. But businesses with significant portions of alpha returns dependent on IT systems development require a similarly alpha IT capability. If they follow the utility model, firms dependent on strategic IT are going to post sub-optimal returns that will not endear them to Wall Street. If instead they do the things to build a high capability captive IT or by partnering with a firm that can provide that high capability IT for them, and by building out the governance capability to oversight it, they’ll not just satisfy Wall Street, they’ll be market leaders with sustainable advantage.

¹The Department of Computing Sciences at Villanova University has published some interesting facts and links.
²"Get Global. Get Specialized. Or Get Out." IBM Institute for Business Value, July 2007.
³"Now, It's Business By Data, but Numbers Still Can't Tell Future." Thurm, Scott. The Wall Street Journal, 23 July 2007.
⁴The Battle for Brainpower" The Economist, 5 October 2006.

Strategic IT Does More than Assume Technology Risk, it Mitigates Business Risk

Risk management, particularly in IT, is still a nascent discipline. Perhaps this is because there are an overwhelming number of cultural norms that equate “risk management” to “defeatism.” To wit: “Damn the torpedoes, full speed ahead!” is intuitively appealing, offering a forward-looking focus without the encumbrance of consideration for that which might go wrong. This notion of charging ahead without regard to possible (and indeed likely) outcomes all too often passes for a leadership model. And poor leadership it is: sustainable business success is achieved when we weigh the odds, not ignore them entirely. Thus leadership and its derivative characteristics - notably innovation and responsiveness - are the result of calculated, not wanton, risk taking.

How risk is managed offers a compelling way to frame the competitiveness of different business models. A recent report by the IBM Institute for Business Value¹ forecasts that Capital Markets firms engaged in risk mitigation have better growth and profit potential than firms engaged in risk assumption. According to this report, risk assumers (such as principle traders or alternative asset managers) may do a greater volume of business, but it is the risk mitigators (notably structured product providers and passive asset managers) who will have greater margins. Since Capital Markets firms are leading consumers of IT, and as IT tends to reflect its business environment, this has clear implications for IT.

Traditionally, IT has been a risk assumer. It provides guarantees for availability, performance and completeness for delivery of identified, regimented services or functionality. This might be a data centre where hardware uptime is guaranteed to process transactions, a timesheeting capability that is available on-demand, or development of a custom application to analyse asset backed securities. Being asked to do nothing more than assume risk for something such as availability or performance of technology is appealing from an IT perspective because it’s a space we know, or at least we think we know. It plays directly to that which IT professionals want to do (e.g., play with shiny new toys) without taking us out of our comfort zone (the technology space versus the business space). Worrying with the technology is familiar territory; worrying about the underlying business need driving the technology is not.

IT can only provide business risk mitigation if it is partnering with the business for the delivery of an end-to-end business solution. If it is not – if IT maintains the arms-length “you do the business, we do the technology” relationship - IT assumes and underwrites technology risk, nothing more. The trouble is, this doesn’t provide that much business value. Technology itself doesn’t solve business problems, so the notion of managing technology – be it to optimise cost, availability, performance or completeness – is no different from optimising, say, the company's power consumption.

This defines IT's business relevance. Being a provider of utilities is not a strategic role. Energy offers a compelling parallel: while it is important for a business to have electricity, most businesses don’t think of the power company as a strategic partner, they think of the power company as just “being there.” The concern is far more utilitarian (e.g., are we turning off the lights at night) than it is strategic (e.g., nobody measures whether we're maxmising equity trades per kilowatt hour.) Worse still, businesses don’t think of their utilities whatsoever. They're aware of them only when they're not there. Awareness is negative, at best escalation, at worst a disruption to the utility’s cash flow.

In any industry, risk assumption is the purview of utility providers. Software development capacity, IT infrastructure, and software as a service are all examples of risk assumption. They are useful services to be sure, but of low business value. They compete on cost (through, for example, labour arbitrage or volume discounts) as opposed to differentiation on value (that is, as drivers of innovation or invention.) For IT as a whole to have business value it must not be viewed as a technology risk assumer but a mitigator of business risk.

The latter role has been historically de facto granted because business systems are substantially technology systems, hence IT has had a direct (if unforseen and unofficial) hand in business process re-engineering, partner management, and compliance certification. In the future, defaulting into this role is not a given: while business solutions have a significant technology component they are not solved entirely by technology. The actual business solution is likely to involve increased regulatory compliance, complex process changes, constant training, ongoing supplier and customer management and integration, and so forth, all of which are increasingly complex due to multiplicity of parties, tighter value chain coupling, and geographic distribution, amongst other factors. Clearly, the technology component is but one piece part of an overall business solution.

Here lies the point-of-pivot that defines IT as strategic or tactical. If IT subserviates itself to a role of technology sourcer abdicating responsibility for success of the end-to-end business solution, so shall the business cast IT as nothing more than an interchangable component to the solution to the business problem. Conversely, when the business and IT both recognise that the technology piece is the make-or-break component of the overall business solution (that is, the technology bit is recognised as the greatest single controllable factor in determining success), IT has strategic footing. It achieves this footing because it mitigates risk of the business solution in business terms, not because it assumes risk for services that the business can competitively source from any number of providers.

Being a mitigator of business risk does in fact require that IT has robust risk management of its own capabilities. That is, internally, IT effectively and competently insures delivery. Here, we run directly into the fact that risk management is not a particularly strong suit of IT, and for the most part is primitively practiced in the IT space. Certainly, it is not simple: executive IT management must be able to analyse risk factors of individuals and teams (e.g., staff turnover, knowledge continuity, individual skill, interpersonal factors.) It must do so across a broad spectrum of roles (quality engineer, developer, DBA, network engineer) with regard to a wide variety of factors (e.g., are we a destination employer / destination account for our suppliers, are we giving people stretch roles with proper mentoring or simply tossing them in the deep end filling out an org chart?) These people factors are critical, but are but one source of risk: IT must be able to manage service availability, requirements accuracy, security and performance across software and infrastructure. Furthermore, this risk spectrum must be presented in a portfolio mannner that assesses risk factors on in-flight and potential fulfillment alternatives, both at this moment and forecast over time. A trivial task it is not.

Regardless of the complexity, technology risk assumption does not provide business value. In Hertzberg’s terms, keeping one’s house in order does not provide satisfaction to one’s partners, even if the absence of order creates genuine dissatisfaction with one’s partners. Successful assumption of risk – maintaining uptime within tolerance, or being “on time and on budget” - are nothing more than basic hygiene. We have allowed these to masquerade as providing “business value.” They don’t. The absence of hygiene – reliability, performance, continuity, completeness – relegates IT to a tactical role because it gives the appearance that IT is incapable of keeping its house in order. At the same time, the presence of hygiene – making deliveries on schedule, or meeting conditions of SLAs – does not entitle IT to a strategic role, it merely contains dissatisfaction.

To become a strategic capability, IT must offer motivators to the busisiness. To accomplish this, IT must focus specifically on activities that mitigate business risk. The core opportunity lies with people. IT is still very much a people-based business; that is, code doesn’t write itself, projects don’t manage themselves, network topographies don’t materialise, solution fitness dosesn't just happen, etc. A key differentiator in what makes IT strategic versus tactical is the extent to which people are leveraged to create business impact: the developer who creates a clever solution, the analyst who connects a complex series of support issues and expressed business requirements, the project manager who brings business solutions to fruition. This requires an outward view that includes domain knowledge and business intimacy on the part of IT professionals. A greater, outward looking context core to each person’s day-to-day is how IT is provides satisfaction to the business. The absence of this - reverting to the “you do the business we’ll do the technology” approach - relegates IT to a utility service, at best a department that doesn't let the business down, at worst something that does. Conversely, an outward-looking, business-engaged capability that is focused on the business problems at hand is what distinguishes a strategic as opposed to a tactical IT.

An efficient, risk-assuming IT capability is a superb utility that contains cost. It is well regarded by the business until a less expensive alternative presents itself, at which time that same IT capability becomes an under-achiever, even a nuisance.² By comparison, an effective, expansive and business-risk-mitigating IT is a superb driver of business value, in touch with the environment such that it anticipates change and adjusts accordingly. In so doing, IT is not in the minimising business – minimising downtime, minimising cost, minimising catastrophic failures – but in the maximisation business – specifically, maximising business returns. A risk-assuming IT defines tactical IT; a risk-mitigating IT defines strategic IT.

¹IBM's Institute for Business Value offers a number of interesting research papers. On the whole they have much more of a consumer-oriented view of IT and offer different market perspectives on the role of IT. Look for another Capital Markets paper in July 2007.
²Michael Porter made the case in Competitive Strategy that competition on price isn't sustainable; we should expect nothing different for an IT utility.

Just as Capital Has a Static Cost of Change, So Must IT

The global economy is awash in cash. We’ve experienced unprecedented profitability growth for the past 16+ quarters, the cost of capital is low, investment risk is more easily distributed, and companies find themselves with strong cash balances. Increasingly, though, we're seeing companies being taken private and their cash taken out by new ownership, or companies buying back their own stock.

This has implications for IT, as it competes for this same investment dollar on two fronts. First, if the executive decision is to concentrate equity or engage in M&A, it inherently means that these types of investments are expected to provide greater return than alternatives, notably investments in operations. IT projects, being operations-centric, are losing out. Second, when companies are taken private, it’s often with the expectation that they’ll be flipped in a short period of time; to maximise return, operations will be streamlined before the company is taken public again. This means private capital will scrutinise the business impact of not only new projects, but existing spend.

To win out, IT has to change the way it communicates. It must think and report more in terms common to capital, less in terms common to operations.

This means that IT has to show its business impact in a portfolio manner. For every project, there must be some indication of business impact, be it reduction of risk, reduction of cost of operations, revenue generation, and so forth. This is not a natural activity for IT because, for the most part, IT solutions don’t themselves provide business return; they do only as part of larger business initiatives. As a result, IT often abdicates this responsibility to a project’s business sponsor. As stewards of spend and benefactors of budgeting, IT cannot afford to be ignorant of or arrogant to the larger context in which its solutions exist.

ITs effectiveness depends on its ability to maximise use of people and resources. This means taking decisions across multiple initiatives, which can bring IT into conflict with the rest of the business, especially with sponsors of those initiatives that are deprioritised. Business issues are not universally understood by IT's business partners. For example, Accounting and Finance people may recognise the need for systems that reduce restatement risk, whereas operations people may see systems and processes designed to reduce restatement risk as contributing only to operational inefficiency. Communicating business imperative, and then people and resource decisions in a business-priority context, make IT decisions less contentious. It also makes IT more of a partner, and less of a tool.

This is not to say that business-impact and return offers ubiquitous language for business projects. Not every dollar of business value is the same: an hour of a person’s work reduced is not the same as reduced energy consumption of fewer servers is not the same as a reduction in restatement risk is not the same as new revenue. However, always framing the project in its business context makes both needs and decisions unambiguous, and gives us the ability to maximise return on technology investment.

Because the business environment changes, so do returns. As a result, assessing business impact is an ongoing activity, not a one-off done at the beginning of a project. Over the life of any project it must be able to show incremental returns. The further out that returns are projected, the more speculative they are, if for no other reason than the changes in the business environment. Capital is impatient, and can find faster returns that provide greater liquidity than long-term programmes. If the business itself is providing quarterly returns, so must any IT project.

Operating and measuring an IT project in the context of its business impact is a fundamental shift for IT. The purpose of continuing to spend on a project is to achieve a business return; we don't continue to spend simply because we think we’ll continue to be “on-time and on budget.” This latter point is irrelevant if what doing - on-time or otherwise - has zero or even negative business impact. Measuring to business impact also allows us to move away from a focus on sunk costs. Sunk costs are irrelevant to capital, but all too often are front-and-centre for operations-centric decision-making: e.g., the criteria to keep a project going is often “we’re $x into it already.” This inertia is, of course, the classic “throwing good money after bad.” We forget that it’s only worth taking the next steps if the benefits outweigh remaining costs.

Managing to business impact requires perspective and visibility outside the IT realm. The actual business impact made must be followed-up and assessed, and all stakeholders – especially business sponsors – must be invested in the outcome. That might mean a budget reduction with the successful delivery of a solution, or bonus for greater revenue achieved. Whatever the case these expected returns must factor into the budgets and W2s of the people involved. This makes everybody oriented to the business goals, not focused on micro-optimisation of their particular area of focus (which may be orthogonal to the business goal.)

To execute on this, the quality of IT estimating must also be very high. When the business does a buy-back or engages in M&A, it has a clear understanding of the cost of that investment, an expectation of returns, and the risks to the investment. IT projects must be able to express, to the greatest extent possible, not only expected costs but the risks to those costs. Over time, as with any business, it must also be able to explain changes in the project’s operating plan – e.g., changing requirements and how those requirements will meet the business goal, missed estimates and the impact on the business return model. This creates accountability for estimating and allows a project’s business case to be assessed given historical estimate risk. It also improves the degree of confidence that the next steps to be taken on a project will cost as expected, which, in turn, improves our portfolio management capability.

Estimation must also go hand-in-hand with different sourcing models. Very often, projects assume the best operating model for the next round of tasks was the operating model taken to date. We often end up with the business truism: “when the only tool you have is a hammer every job looks like a nail.” Estimates that do not consider alternative sourcing models – different providers, COTS solutions, open source components, etc. – can entrap the business and undermine IT effectiveness. Continuous sourcing is an IT governance capability that exists at all levels of IT activity: organisational (self-sourcing, vendor/suppliers), solutions (COTS, custom), and components (open-source, licensed technologies, internally developed IP.) The capability to take sourcing decisions in a fluid and granular manner maximises return on technology investment.

In this approach, we can also add a dimension to our portfolio management capability to attract high-risk capital of the business. Every business has any number of potential breakaway solutions in front of it, not all of which can be pursued due to limited time and capital, not to mention the need to do the things that run the business. In addition to offering potential windfall benefits to the business, they are most often the things that provide the most interesting opportunities and outlets for IT people, necessary if an IT organisation is to be competitive for talent as a “destination employer” for best and brightest. These are impossible to charter and action in an IT department managing expectations to maintain business as usual. It becomes easier to start-up, re-invest and unwind positions in breakaway investment opportunities – and the underlying IT capability that delivers them – if they’re framed in a balanced technology portfolio.

By doing these things, we are better able to communicate in a language more relevant to the business: that of Capital. The behaviour of IT itself is also more consistent with Capital, with a static, as opposed to an exponential, cost of change. Such an IT department is one that can compete for business investment.

Patterns and Anti-Patterns in Project Portfolio Management

A critical component of IT governance is Project Portfolio Management (PPM). Effective portfolio management involves more than just collecting status reports of different projects at specific dates; it also involves projecting the delivery date, scope and cost that each project is trending towards and the impact of that projected outcome on the overall business. Without this latter capability, we may have project reporting, but we are not able to take true portfolio decisions – such as reallocating investment from one project to another, or cancelling underperforming projects – to maximise return on technology investment.

As with IT governance as a whole, many PPM efforts belie the fact that the discipline is still very much in its infancy. We see around us a number of practcies executed in the name of PPM that are in effect PPM anti-patterns.

Anti-Pattern: Managing by the Fuel Gauge

Traditional or Waterfall project planning defines a definitive path by which milestones of vastly different nature (requirements documentation, technical frameworks, user interface design, core functionality, testing activity and so forth) can be completed in an environment (team composition, team capability and requirements) projected to be static over the life of a project. This definitive path, defined to the granular “task” level in traditional project planning, creates a phase, task and subtask definition within the GL account code(s) that track spend against the project budget. When wed to the IT department’s time tracking system – which tracks effort to the subtask level – it is not uncommon for people to draw the mistaken conclusion that the total cost expended against the budgeted amount is representative of the percent complete we are to the overall project.

This is akin to “navigating the car by the fuel gauge” – the amount of time spent in each task is assumed to be an indicator of delivery progress because the plan itself is held out to be fact. Unfortunately, the environment is not static, and the different nature of project milestones makes the project prediction highly suspect. The car could be heading toward a completely different destination than originally envisioned, and in fact could be going in circles. This granular level of data does not translate into meaningful PPM information.

Anti-Pattern: Navigating through the Rear or Passenger Windows

Another approach to portfolio management is to survey every project at regular intervals to ascertain where it’s at relative to its original, deterministic plan, and for those “off course” reporting what will be necessary to restore project back to plan.

In its simplest form, this is akin to “navigating the car out the rear window.” Surveying projects to ascertain their overall percent complete is a backward looking approach that is easily – and not infrequently – gamed (e.g., how many projects quickly report “90% complete” and stay there for many weeks on end?) In its slightly more complex form – communicating the gap of current status to projected status and reporting a detailed set of deliveries a team is hoping to make by a particular date – is akin to “navigating the car out the passenger window.” It assumes that the original project plan itself is the sole determinant of business value, and is the basis of control of projects.

These are anti-patterns because they miss the point of PPM. The objective of portfolio management is to maximise return for the business, not maintain projects in a state of “on time and on budget.” Those time, scope and budget objectives, which might have been set months or even years ago, lose relevance with changing business conditions: market entrants and substitutes come and go, regulation changes frequently, and the sponsoring business itself changes constantly through M&A. These factors – not “on time and on budget” to an internally defined set of objectives – are what determine a maximum return on technology investment. In addition, this approach substitutes “sunk costs” for “percent of value delivered.” Sunk costs are irrelevant to business decisions; it is the remaining cost of completion relative to value achieved that matters.

Anti-Pattern: Breaking Every Law to Reach our Destination

An unintended consequence of PPM is the distortion of organisational priority. A culture of results can quickly morph into a culture of “results at any cost.” This, in turn, may mean that in the process of traveling to a destination, we commit multiple moving violations, burn excess fuel, and pollute excessively simply so that we appear to have “met our numbers.”

This is not typically considered part of PPM as much as it’s really a question of our overall IT governance. Still, it’s relevant to PPM: knowing that our investments are performing as they purport to be performing is important protection for our returns. To wit: through the 1990s Parmalat and Enron may have been strong performers in an equity portfolio, but gains were obliterated once shown to have been misrepresented all along. It must be remembered that project portfolio management relies on good governance and, in fact, exists as a component of it. Reaching our destination might make an initial delivery appear to be successful, but any returns achieved for reaching the destination might be completely obliterated by the cost of remediating the brownfield we created. Maximising return on technology investment is concerned with the total asset life, not just achieving a goal at a specific point in time.

Characteristics of a Pattern

We don’t yet – and should not expect to have – “GPS-style” navigation systems for individual projects that can feed our PPM. Because we cannot predict the future, any “map” is a fallacy. But we do have the tools by which we can "navigate through the front windshield," and do so without leaving destruction in our wake. We can do this if:

• We have fact-based manner by which to assess if a project can achieve its business goals in a time and for a cost acceptable to its business objectives.


• We have detailed visibility into the fact that energies are being directed toward high priority work.


• We have current, meaningful indicators of the completeness of the work being done – that we are working in such a way that we are maximising objectives under the circumstances, and that work declared to be “complete” is a matter of fact, and not opinion.

Agile project management is uniquely capable of bringing this about. Inclusive, independent statements of scope allow the path of system delivery to adjust to changes in priority, changes in capacity, changes in the understanding of requirements, and the experience of the team. Instead of relying on a prescriptive path, we have unadulterated transparency that exposes to everybody whether the best decisions relative to the business objectives are being taken given current information at the moment of decision.

These constructs provide the foundation for a fact-based, forward-looking PPM capability, because they enable informed “what if” scenario building across a portfolio of projects. Using these practices, we can develop meaningful, time-sensitive models, founded in fact, that allow us to forecast the impact of changes to team capacity (e.g., through turnover or reassignment), priority (through changing business environment) or scope (through expansion or better understanding) on our total portfolio. This isn't “project tracking” masquerading as “portfolio management;” it is the foundation of true portfolio management that maximises return on technology investment.

Agile under Sarbanes-Oxley

The business cycle of most firms is cash-driven: work is performed, invoiced at completion, and collected on negotiated payment terms. Obviously, cash flow is important to the business as it affects our ability to do the things to run the business, like meet payroll and pay expenses. Cash flow isn’t revenue, however. To recognize work delivered as revenue, client work must be delivered and unambiguously accepted by the client.

This is a priority, particularly for publicly traded firms. As the stock price usually trades at a multiplier to income (or in the case of many Nasdaq companies, a multiplier to revenue in lieu of earnings), revenue recognition is critical to Wall Street. For engagements that span many months, this can mean that revenue recognition is deferred for many reporting quarters. We can end up in a situation where cash flow is consistent and healthy, but net income is variable and frequently weak.

Amongst other things, Sarbanes-Oxley (a.k.a. Sarbox, or SOX) establishes compliance guidelines for publicly traded companies so that revenue isn’t gamed. The intent is to define clear guidelines accounting the facts of what operations have delivered or not delivered. As simple as that may seem, the pressure in the executive offices to recognize revenue is quite real, and the software industry in particular is rife with examples of companies gaming revenue numbers with incomplete deliveries.

The rules under Sarbox governing revenue recognition are explicitly defined. The governance mechanism for this under Sarbox is a “proof of completion” certificate. This is a simple document that serves as the client’s acknowledgement that specific functionality was delivered to satisfaction by the supplying vendor. This document must be received in the reporting period in which the revenue is to be recognized; e.g., if we’re going to recognize revenue in Q3, the proof of completion must be received by the supplier in Q3.

The capability for operations to deliver what they forecast will go a long way to letting the air out of the results bag. Of course, it’s not so easy. The ability for ops to deliver isn’t purely an internal function. Factors outside the control of a company’s internal ops, such as customer staff turnover or change in a customer’s business direction, can impair execution of even the best laid plans. Thus no matter how strong the internal operational performance, external factors will significantly affect results. Still, the ability to forecast and respond to this change in a timely fashion will go a long way to meeting revenue targets and goals, and reduce the risk of change in the business environment.

Our traditional ways of working in these environments are often based in hope and unnecessarily produce a lot of uncertainty and inconsistency of our own making. We set our forecasts based on individual “quarterly completion commitments” and “business feel” based on what we see in the sales pipeline. As we approach quarter-end, we swarm disproportionate numbers of people on specific projects to drive to what amounts to an internal definition of “complete,” only to then plead with the customer to accept. The pursuit of a mythical number given at the beginning of a quarter in the vain hope of making it a reality through the fortunate combination of contracts, capacity and capability coming into alignment is a primitive practice. This ultimately results in a mad scramble at quarter-end to complete deliveries, introducing operational risk. For example, if a delivery proves to be more complex than originally thought, or if people are not available, or if some customer deliveries are prioritsed at the cost of others, quarterly ops revenue contribution is at the mercy of things substantially out of our control. Without mitigating this risk – or indeed providing visibility into it in the first place – we increase the probability of a disappointing quarter.

In fact, these practices stifle operational maturity. In this model, operations are at best a hero-based delivery group that relies on a few talented individuals making Herculean effort 4 times a year (that is, at quarter end. At worst, they’re an under-achieving function that requires a high degree of tactical supervision. In either scenario, operations are reactive, forever executing to a mythical, primitive tactical model, never rising to become strategic contributors to the business.

Because they bring operations into alignment with regulatory requirements in a non-burdensome manner, Agile management practices are especially valuable in Sarbox or similarly regulated business environments. There are several Agile practices we can bring to bear in this environment:

• Instead of defining large, monolithic packages of delivery, we can decompose client deliverables into independent, uniform statements of business functionality or Agile Stories. Each of these Stories will have an associated revenue amount, specifically the cost of delivering each to the customer. This gives us a granular unit of work with economic properties.


• Each of these requirements can have an associated Proof of Completion document. This provides tangible affirmation that client acceptance criteria have been met.


• We can define the fiscal quarter as an Agile “release” divided into 13 iterations of 1 week each. This gives us time-boxes around which we can construct a release plan.


• We can forward plan our capacity by taking a survey of known downtime (vacations, holidays, etc.).

By executing to these, we yield significant financial and operational benefits.

• We accelerate revenue recognition. Granular, federated expressions of business requirement can be developed, delivered and accepted incrementally by the customer. This will yield faster revenue recognition than highly-coupled requirements made in one delivery.


• We reduce the risk of not being able to recognize revenue. Incremental customer acceptance reduces the risk to revenue recognition inherent in a single large delivery. For example, suppose a sea change within a customer threatens revenue from projects. If we have granular delivery and acceptance we can recognize the revenue for deliveries made to date. If we don’t, we lose revenue from the entire project, making both the revenue and the efforts to-date are a business write-off.


• We have more accurate forecasts of revenue capacity and utilization. By planning capacity, and taking into account our load factor, we can assess with greater accuracy what our remaining quarterly capacity looks like. Expressing this in revenue terms gives us a realistic assessment of our maximum revenue capacity. From this we can take investment decisions – such as increasing capacity through hiring – with greater confidence.


• We have more accurate revenue reporting. Each POC received creates a revenue recognition event in that specific iteration. This gives us a “revenue burn-up chart” for the quarter. In tracking actuals, we can show our revenue recognition actual versus our burn-up. This means revenue forecasting and reporting is based more in fact than in hope.


• We have more accurate revenue forecasting. By forming a release plan that includes the complete cycle of fulfillment stages for each customer requirement – analysis, development, testing, delivery and POC/acceptance – we have a clear picture of when we expect revenue to be realized. As things change over the course of the quarter – as stories are added or removed, or as capacity changes – the release plan is modified, and with it the impact on our revenue projection is immediately reflected.


• We have transparency of operations that enables better operational decisions. Following these practices we have a clear picture of completed, scheduled, open and delayed tasks, an assessment of remaining capacity, and visibility into a uniform expression of our backlog (i.e., a collection of requirements expressed as stories). With this we have visibility into delayed or unactioned tasks. We can also take better scheduling and operating decisions that maximize revenue contribution for the quarter.


• We have transparency of operations that reduces surprises. The release plan tells us and our customers when we expect specific events to take place, allowing us to schedule around events that might disrupt delivery and acceptance. For example, we may expect to make a delivery in the last week of the quarter, but if the person with signature authority on the POC is unavailable, we’ll not recognize the revenue. Foreknowledge of this allows us to plan and adjust accordingly.


• Acceptance Criteria are part of everything we do. The Proof of Completion document builds acceptance criteria into everything that we do. We think of completion in terms of delivery, not development. This makes everybody a driver of revenue.

In sum, Agile practices professionalize operations management. By being complete in definition, being fact-based, providing operational transparency and exposing and mitigating risk consistently throughout a reporting period, they align execution with governance. This results in non-burdensome compliance that actually improves the discipline – and therefore the results – of business operations.

Corporate Mental Health

In the course of implementing Agile practices, an organisation is likely to come face to face with deficiencies in both IT and business operations. Shortcomings in specifications, in quality, in team capability, in technologies all quickly come to the fore. Agile practices allow us to not only identify these shortcomings, but to call them out in a fact-based manner.¹ Still, how people in an organisation respond when presented with these will determine how successfully it adopts Agile practices.

While in theory, decision-making in a business context is coldly rational, decisions made by people in business usually are not. Because they impact people, business decisions – especially where performance or results are concerned – can be highly emotional. With regard to adopting Agile practices, this creates an important consideration. While they lend themselves to tremendous transparency, that transparency can unintentionally create discomfort and embarrassment. One person's "liberation" is another person's "fear."

The reaction to this increased transparency is very much an organisational characteristic. In the November-December 2006 edition of World Business, James Bellini writes:

• Businesses behave like people… the nature of this behaviour gives us vital clues as to the condition of a company’s underlying psychological state and in so doing helps us identify those that will succeed and those doomed to fail. It also offers the means by which those confronting failure because of an ailing, dysfunctional psyche can be given a new direction, towards revival and profitability.²

Mr. Bellini makes the point that organisations can fail because they fool themselves into believing something to be true, no matter the facts. There is an important alert here for those wanting to inject Agile practices: organisational self-delusion can be an obstacle to injecting fact-based management. Clearly, we’ll struggle to inject facts if facts don’t have currency. More constructively, there is clearly a “healthy” approach to presenting facts, as opposed to an “unhealthy” approach of confronting with facts.

The business sponsor and implementers of an Agile “programme of change” must be able to honestly assess the following:

• How well do people understand and accept the problems the organisation faces today? Do they see, for example, a deficiency in scalability materially impacts bottom line profitability? Do they see long development cycle times as interfereing with customer responsiveness and, therefore, new business? Do they look for and recognize features in competitive products as disadvantage in the market? Or is the prevailing attitude that the company have its customers, and the competition have its customers, and it will just sort itself out in the end?
  
• To what extent do people tolerate and encourage risk, and to what extent can the organisation accept fast failures? The initial adoption of Agile involves a lot of experimentation, trial-and-error, learning-by-doing, and failure. Is the organisation risk-averse with a “shoot the messenger” culture when things don’t quite turn out as planned? Or is there a recognition of the benefit to continuous learning and “fast failures.”³ Specifically, is there an expectation that people are in "stretch roles" learning and honing their capabilities as individuals? Is there greater infrastructure - training, mentoring, coaching - to support this?
  
• Is there a culture of responsibility or a culture of blame? Exposing problems will make people react, one way or another. For example, many companies are burdened with highly manual processes. Staff changes through resignation or promotion disrupt these processes. Do people accept the natural turbulence of transition and look for constructive ways to create more durable solutions? Or do they simply pass around blame for work not done?
  
• Finally, with what discipline do we take project sponsorship decisions? That is, how disciplined is our project portfolio management? Can we accept a project’s actual cost, time and trajectory in the context of a business case, and take necessary action? Do we accept reporting the actual state of a project as an expression of mastery of our profession? Or are go/no-go decisions substantially rooted in non-business factors, the team's credibility intertwined wth a delivery commitment, and hope the fundamental strategy for a project to maintain course?

Further complicating matters, each of these are bi-directional. The manner in which we expose problems – confrontational or progressive – will contribute to the success of the programme of change. That is, there must be a constructive, as opposed to a destructive, language for change. The responsibility for creating this positive nomenclature lies with the instigator of change.

Collectively, this sounds "soft," and perhaps it is. But at the end of the day, management is still “getting things done through people.” Not money, not technology, but people. We understand intuitively that these things matter, whether we can measure them or not. “Soft” or otherwise, they are relevant to us as managers. And references abound.⁴

The first example comes from Ford Motor's recently initiated turnaround. A recent story in the Wall Street Journal pointed out that Alan Mullaley, CEO of Ford Motor, openly applauded a division head for owning up to poor performance in a senior staff meeting. Mr. Mullaly’s reasoning? You can’t solve problems if you don’t acknowledge them, and not enough people were acknowleding them when Mr. Mullaley arrived. Something to think about in this example, too: if this is what's happening at the most senior levels of the company, what makes us think it will be any different within a project team?

The second example is Scuderia Ferrari F1. In an interview with F1 Racing Magazine, Ross Brawn, the recently retired technical chief at Ferrari, described team decision-making as:

• "Every last detail is critical… You cannot be weak in the tangibles, like the design of the car, and you cannot be weak in the intangibles, like your … interpretation of the rules. Whatever you felt you could achieve you’ve then got ot go out and find another 10 per cent…. We all knew that we had to do it and we knew the other guys were doing it, so that if you were not doing it you would be letting the side down. It was great to be a part of that mind-set; a group where we were all giving absolutely everything."⁵

Albeit extreme, there is a lot to be gleaned from this as an instantiation of organisational psyche. The cultural norms, the expectations of the peer group, while soft, are unambiguous: push yourself to the limit to push the platform (e.g., the car) to the limit. Leaving the potential for competitive advantage on the table due to lack of effort was unacceptable.

Clearly, Scuderia Ferrari is an organisation that deals in facts, not excuses or justification. Somebody will ask as a matter of fact, and not accusation: did we perform every combination of performance and reliability test? Are we in compliance with the sporting rules of the FIA? You don’t want to be the person called out for not answering those questions to their fullest; the organisational psyche guides you to fully pursue these answers prior to facing the questions.

The bottom line: organsational “psyche” is a factor in our ability to change and respond. Ultimately, it impacts our fundamental ability to compete. Mr. Brawn: “'It’s very rare in modern F1 to come up with a dramatic new concept or idea that will give you a step change in performance. So you cannot give anything away.'”⁶ This is not accidental, but systematic, part of the landscape. It might initially read a defensive tactic, but it’s very much an offensive strategy. Thoroughness means we don’t leave anything on the table; aggressiveness means we find and maximize innovation. That makes an organisation able to accept the need for change, and implement that change. And that makes it more competitive.

¹I am indebted to David Pattinson on this point. In the course of an engagement some years ago, he very specifically made the point that we hadn’t established a basis of fact for an issue, and we risked escalating a problem to a client “as a matter of opinion and not as a matter of fact.”
²Bellini, James. “Disguises and denial” World Business, November-December 2006. There’s a lot of information in his article, it’s worth re-reading a few times to get the full extent of his messages.
³It’s worth mentioning that Gartner has called out “fast failures” as a principle for effective innovation: “Fail Fast for More Effecitve Innovation.” Gartner Research. 1 March 2006.
⁴Oddly, and hopefully coincidentally, both are automotive.
⁵Allen, James. “Ciao for Now, Ross.” F1 Racing, January 2007. There’s a full quote from Mr. Brawn that truly captures the essence of Ferrari’s F1 team. Go buy the magazine.
⁶Ibid.

An "Innovation Maturity Model?"

Our innovation model now has multiple practices within each of three dimensions. Collectively, it looks like this:

Agility
Requirements
Responsiveness
Collaboration
Delivery Assurance
Testing
Build
Source Code Management
Collective Code Ownership
Architecture

Community
Tools & Infrastructure
Community Management
Participation
Bar Lifting
Risk Tolerance

Governance
Continuous Sourcing
Metrics
Compliance
Investment
Commercials

We can make this model still more finely grained by identifying the ways in which each practice area is performed. For example, we can define different ways to fulfill the Governance practice of “commercials and contracts.” By sequencing in degree order the extent to which each method of execution enables innovation, we can create a simple innovation “maturity model.”

This is, clearly, going to be a bit involved, but it gives us useful information. The extent to which the different practices are performed will be a strong indicator of our organisation’s aptitude for innovation. In addition, having a “maturity flight” for each will highlight strengths and deficiencies in how we operate now. This, in turn, allows us to focus our efforts and investments specifically where it will make us more competitive.

In constructing progressions of practice in rank order by the extent to which they facilitate innovation, we start with a simple taxonomy of “innovation maturity.”

Level 3: Practices that are fully aligned with and engender innovation

Level 2: Practices that engender but do not maximize innovation

Level 1: Practices that are neutral or marginally enable innovation

Level -1: Practices that inhibit consistent innovation

Having a “Level -1” is useful from the point of view that there is value in calling out practices that inhibit innovation. A Level 3 might be thought of as a maximum degree of facilitation. Between are varying degrees to which things are done that engender innovation but are suboptimal in a purely “innovation” context. This is not to say that Level 3 should be the target: there may be economic or operational reality why an organization peaks at level 2 or 1. This is also not to say that there are not levels beyond 3, but for purposes of constructing an initial model, it is best to keep it simple. Bear in mind that this is simply a model that provides us a structured way to analyse what we’re doing now and suggest what we should be doing instead.

With a taxonomy, and a series of practices, we should be able to construct a “maturity flight” for each practice, sequencing activity in degree order to which each engenders innovation.

For example, the “maturity flight” of the Compliance dimension of Governance might look like this:

Level 3: Compliance rules are automated and implemented as gatekeeper events in daily activity (e.g., through build) and feed a compliance dashboard

Level 2: Key success factors for solution completeness (security, performance, reliability) implemented as a battery of repeatable test suites

Level 1: Multi-disciplinary compliance working group formed with delivery leaders to articulate “solution completeness” in plain terms

Level -1: After-the-fact audit and review intended to find errors as opposed to guide solutions; rules set by non-delivery staff; rules exist in documentation

Similarly, within Community, the Participation flight might look like this:

Level 3: Programmes established to recognize and enable participation (e.g., a 10% scheme, internally funded conferences)

Level 2: Communities fo Practices form; practice membership recognized by HR as a soft “matrix” organization; soft budget allocated

Level 1: Collaboration tools and space passively advertised; demand-based “at-will” participation

Level -1: Teams work in isolation; collaboration is a function of individual networking

And so on, for all practices.

By doing this for every practice area, it becomes possible for us to:

Identify specifically the deficiencies and obstacles to our ability to innovate,

Map the affinity that we have for innovation.

Track our progress as we improve our ability to innovate.

Of course, with as many as 19 practice areas identified, this is going to produce a lot of data.As we have an index and a categorization for each, we can consolidate our scores and get an overall assessment of our Agility, Community and Governance practices.

In so doing, we have a composite picture of where we’re at relative to where we’d like to be relative to an “ideal state.” Again, we have to use this judiciously: this is not intended as a certification or a mandate. It is an indicator that, properly applied, should allow us to better ask and answer: to what extent does our organisation really do the things that lend themselves to innovation? We cannot expect innovation from an environment that is not conducive to it. This degree of insight goes a long way to avoiding a futile “innovation mandate.”

Aligning for Innovation

It’s worth looking more closely at each of the factors that enable innovation within an organisation: Agility, Community and Governance. Each of these means something specific. If we identify practices within each that affect our aptitude for innovation, we have something more concrete than “IT Governance, Community and Agility contribute to our ability to innovate.”

By taking a structured approach to critically examine how work is performed, we get unvarnished insight into how we do things today.
In so doing, we are more likely to align organisational objectives – efficiency through re-use, creativity from collaboration – with day-to-day work. This gives us an indication of the extent to which we have an aptitude for innovation. As a result, a focus on innovation is less of a hope-based initiative, and more of a fact-based exercise.

That said, if we are to critically look at things we do to facilitate – or, for that matter, stifle – innovation, we first must understand in greater detail the elements of Agility, Community and Governance.

Practices that Create Community

An innovation culture requires a Community that extends beyond any individual's immediate team or department visibility. The dimensions of forming Community include the following:

1. Tools and infrastructure create an intuitive platform for robust exchange of rich content in structured ways


2. Participation and individual contribution to this community is recognized, facilitated and rewarded through HR and corporate policy


3. Community management links participants, bridges groups and manages content


4. Global resource management gives people across the organisation participation and therefore visibility into different projects and opportunities


5. The organisation develops a culture that values and rewards continuous learning and fast failures.

Practices that create a Static Cost of Change

We also recognise that the cost of change – that is, the extent to which we are able to accommodate change with minimum disruption – is a contributing factor to our ability to produce and consume ideas and code.
Traditional ways of working have an exponential cost of change: design decisions, taken in early stages of a project, have long horizons. It becomes increasingly expensive to change course as we get further into a project as code is highly coupled to this set of decisions.

Agile practices have been shown to yield a more static cost of change. Decision horizons are shorter because decisions – requirements, architecture, code – are much more independent. Agile practices include the following:

1. Requirements are decoupled, with needs captured as independent, complete and valuable statements of business functionality


2. Continuous planning, estimation and execution happen in fixed iterations of 1 to 3 weeks, with the measure of time serving as the project “currency”


3. There is a deployable, functional deliverable at the conclusion of each iteration; integrity of completion is stressed in favour of feature pile-on


4. Teams establish a cadence – daily, weekly, monthly, quarterly – of frequent, low-ceremony, highly-focused communication events


5. A continuous cycle of requirements analysis, development, integration and test prevents a team from mortgaging its future, borrowing blindly against a future time-box to accommodate change


6. The business partner is engaged in business terms, not IT terms, and is involved in day-to-day decisions and activities


7. Simplicity of design and well-defined services are preferred over big up-front design or coarsely- or finely- grained functions.


8. Robust testing – in the form of programmer-written unit tests and QA-written functional tests – in conjunction with continuous integration, makes “development complete” less a matter of opinion, and more a matter of fact.


9. Teams report status and forecast completion in unambiguous terms to all project stakeholders

For purposes of critically analysing our day-to-day practices we will look at these a bit differently, but for now this list allows us to understand in context how we deliver – and how we would like to deliver – IT solutions.

Practices of IT Governance

Finally, innovations must not be a matter of opinion, but a matter of fact: do they deliver value for money, and are they delivered to a complete set of expectations. To be able to ask and answer those questions in a context of innovations, we must look at the following:

1. There needs to be a continuous sourcing model so that teams can exploit and contribute to emergent and rapidly evolving code and ideas in the Community


2. The economic impact of the Innovation Network on individual projects and the organization is assessed and publicised with indicators, metrics and measures


3. There must be a discipline of compliance – legal, technical and economic – of all IP released to the Community; this discipline must be non-invasive


4. The development of solutions from raw, unfinished ideas in the Community is facilitated by an investment framework


5. Traditional ways of working to the letter of a contract and suffering under the weight of rigid change controls must give way to commercial contracts that facilitate constant assessment of project variables – quality, time, resources and scope – in pursuit of meeting evolving business.

This is not to say that these practices are mandatory for innovation and we don’t look to these as elements of compliance or certification of an “innovative enterprise.” We do, however, recognise that these are things that systematically and synergistically incite innovation: if we have strong Community, a high degree of responsiveness and mature Governance we will be more inclined to innovate than if we have a weak community, long-term decision lock-in, and limited means by which to oversight IT results and activity.

The Aptitude to Innovate

Growth is back in business; it is the business imperative. Growth is fueled by innovation. And business leadership is looking to IT for innovation.

That’s good for IT. Think about where we’ve come as an industry:

10 years ago, IT was part of the business.

8 years ago, IT was going to reinvent the business.

5 years ago, the business wanted to get rid of IT.

3 years ago, the business accepted IT as a tolerated nuisance, but it kept it on a tight leash.

To be asked to be providers of innovation is to be invited back to the top table as business leaders. That’s a good problem to have.

But it’s not an easy problem to solve. Because innovation is neither a managed business function nor an explicit programme of work, it defies traditional management solutions. You can’t manage innovation as you manage sales. A culture of innovation also requires new ways of working, as most organizational structures and norms simply stifle it. Unfortunately, there are also few models or patterns for introducing and inciting innovation. No surprise, then, that 3 out of 4 CEOs think they lack both organizational process and leadership to engender business innovation.¹

The open source phenomenon provides us with one reference model: global communities of people collaborating on common problems to create robust, useful and re-usable solutions to problems. But in a commercial context, the open source model is a point of reference, not a reference implementation: adopting network organization structures is disruptive and potentially disastrous, and these types of structures are orthogonal to corporate cultures and reward systems.

Innovation is not invention. It isn’t the “eureka” moment, or the creation of new products and services out of R&D. It’s the consistent, rapid and deliberate maturation of what we have and do today. It’s evolution, as opposed to revolution. Think Ferrari evolving the F1-2000 platform to win 5 consecutive driver and constructor championships as opposed to BMW.Williams revolutionizing the FW22/3/4/5/6 over the same period (remember the tusks?) only to win the odd Grands Prix.

To be creating and just as importantly consuming innovative solutions in our day to day requires more than simply standing-up a repository for ideas, code and artifacts, and e-mailing a URL soliciting contributions and use. Developing a penchant for innovation requires that we focus on three things: having a static cost of change, building Community, and having a mature IT Governance capability.

Each workgroup, each team, must have a static – as opposed to exponential – cost of change. Traditional ways of working create long decision horizons: decisions made during architecture and design become hard to reverse in coding, testing and deployment. Highly coupled requirements create highly coupled code. Development is opaque. Collectively, this creates a cost of change that grows exponentially. Because everything is so highly coupled, it is difficult to ferret out clever solutions or integrate new ideas without significant disruption. By comparison, Agile practices create short decision horizons. Requirements are independent statements of need, code is decoupled, tested and always in a state of build-readiness. We have transparency in development. This creates a static cost of change, and makes it easy for ideas to be harvested and consumed. Agile practices, then, allow for a consistent supply and demand of ideas and solutions.

Organization – particularly hierarchy – can obfuscate needs and opportunities. To drive out and consume innovation, people must also be part of a Community larger than their immediate work teams or departments. This isn’t endless committee meetings or matrix organization, this is a slow but deliberate process of grafting a network organization model into a company. This is supported by infrastructure and tools, and by aligning Community participation with individual (career) and team (delivery success) goals. This gives us the ability to communicate and collaborate as an organization, across boundaries.

Finally, we need to call out the value of innovation, and define the context and completeness of each. Solutions must be shown to deliver business value, otherwise they’re just interesting ideas that may not be worth investment at this time. They must also be complete in scope, lest the rush toward adopting an idea create a legal, performance or quality problem that creates more harm than good. There must also be an instilled behavior of consistent sourcing, looking outside an immediate team for ideas and contribution. A mature governance capability gives us the ability to oversight and leverage innovation.

Given the increasing rate of change in business, there is an urgency to harvest and capitalize on ideas and IP. Bringing it about is not a top-down exercise in "managing innovation" as much as it’s a corporate competency and cultural phenomenon. Bringing this about happens in stages, and forming an “innovation network” is itself a process of organizational maturation. By deliberately developing capability in Agile process discipline, developing Community and maturing IT Governance, we create an aptitude for innovation and the ecosystem to perpetuate it.

¹ Business Innovation is a Rising IT priority, but is Not Yet Matched by Action, Gartner Research, 10 December 2006.

It might make the car go faster, but does it make the car more competitive?

Frank Williams, the legendary principal of WilliamsF1Team, has a single question he asks of any proposed change or innovation: “Does it make the car go faster.” This is intuitively appealing, especially for Formula1 teams which are in the business of winning races. We can similarly define a “litmus test” for business decisions: does any given project, initiative or decision make more money for the business?

While it’s great to have an over-riding sense of priority, this isn’t sufficient. We can engineer a car that will sit on pole and lead the race, but if the engine melts or the suspension buckles or the wings fall off after 20 laps, being fast simply isn’t enough. In Formula 1, reliability is just as important as speed for winning races. And the results reflect this: in the November 2006 issue, F1 Racing magazine published an analysis of race results between 2000 and 2006.¹ They concluded that Kimi Räikkönen lost two F1 driver’s championships because of reliability problems of his Mclaren-Mercedes; all other things being equal, in 2003 and again in 2005, mechanical retirements cost Kimi a championship. Clearly, going fast is important, but going fast while meeting requirements for quality is another.

The “it makes the car go faster” question is the classic “they get results” statement in consuming business services or solutions. Simply making the car “go faster” at best assumes things are in compliance with expectations (regulatory, quality, security, etc.), at worst dismisses if not outright ignores the importance of these issues relative simply to achieving bottom-line results. In F1, it is important to say that teams are not in the business of “speed,” but of “winning races.” This latter definition is far more inclusive, providing more comprehensive consideration for what it takes to succeed given operating realities.

Just as the FIA is increasing regulation, businesses are subjected to both increasing regulation and expectation (e.g., “is consumer data is secure”). This will affect our business “litmus test:” we can do things that drive revenue or increase profitability, but at what cost to our competitiveness relative to the business environment in which we operate? For example, we can produce a new consumer website to drive revenue, but if there’s a 90% chance of identity theft resulting from its use, the solution is a failure. Similarly, we can cut salaries 10%, but if turnover jumps to 50%, we will have a long-term cost problem. To be competitive, then, in business, just as in F1, we must have a more complete definition of “competitiveness” than simply, “does it make us more money.”

Carrying on with the F1 example, suppose that the FIA changes regulations so that engines must be more “green,” or consume less energy. Should this happen, the question “does it make the car go faster” must be considered with not just reliability but emission constraints, giving us a multi-dimensional problem. Success in this environment is far more difficult than simply “going really fast.”

It is important that we use the word “constraints” as opposed to “considerations” to describe the environment. “Constraints” promotes the value of one dimension over others, in this case “speed” over “reliability” and “emissions.” Emissions and reliability can only lose the race for us (e.g., by being in clear violation of sporting regulations and being disqualified, or by retiring from the race due to insufficient tolerance to stress), whereas speed can win the race for us by putting us, and keeping us, at the front of the grid.

The business imperative, then, regardless of what it means to have a “complete solution” remains the same: we’re in business to make money, not to comply with regulations. However, we respect the fact that we must comply with the regulations, expectations and constraints of the business environment and we place value in our capability to manage in the complete definition of our environment. We therefore want simple yet consistent models through which we can expose, analyze, and improve that which we do such that we maximize results given constraints of our operating environment.

This is why IT governance is such an important capability: it gives us greater mastery over our selves, our environment and how we interact with our environment. To that end, the equivalent question we must ask is “does it make the car more competitive.” This is less appealing as it lacks the precision, exactness and simplicity of “does it make the car go faster.” It also makes our objective a bit more vague, with “regulation” and “expectation” soft qualifiers that introduce opinion into our assessments of “compliance with expectations.” But it is a more accurate definition of success.

And therein lies the governance gap. We’re not especially good at governance now. For one thing, our bias is toward the appearance of results (delivering something under budget, getting something in production, steering systems through transactional acceptance, etc.) over solution completeness. For another, day after day we deal with the self-inflicted wounds of security violations, spiraling maintenance costs, production failures, and so forth. The intensity of the competitive environment – both regulatory and expectation – is only going to increase. We need greater mastery over not just what but how we do such that we’re aware of and developing our capabilities, and actually delivering, complete solutions.

An improved governance capability has the following characteristics:

• We balance our results orientation with a genuine concern for the means by which those results are achieved.
  
• We embrace a governance model that gives a comprehensive definition of “complete solution” the peer status – but not disproportionate priority – relative to “bottom line results.”
  
• We have the capability to answer both “effectiveness” and “completeness” questions such that governance is far more a matter of fact than opinion.
  
• We do the things necessary so that the team can put itself and the car (e.g., the business) on the limit without self-inflicting failure in the form of disqualification or inadequacy.
  
• We recognize that our ability to govern, as well as our ability to execute, are each maturing aspects of our collective capability; we execute to both as means by which to continuously improve and, therefore, maximize profitability given a changing operating environment.

By so doing, we constantly improve our execution and awareness of our execution, and sharpen our focus in pursuit of what matters most: not running the fastest race we can, but winning the race.

And that’s why we’re in business.


¹ The race results analysis appears in the “Looking Back in Anger” column of the Pitpass section of the November 2006 edition of F1 Racing magazine. F1 Racing consistently presents as complete a picture of an industry as you’ll find anywhere, including driver, engineering, supplier, regulatory and management dimensions. They communicate in a matter-of-fact writing style supplemented with unbelievable photographic images. If you have even a passing interest in F1, read a few editions and abstract the lessons learned, you’ll find a take-away for your business or industry.

The Leading Indicator of IT Relevance

An article in the 16-22 edition of BRW magazine by David James entitled “Listen and Earn” reports on research by Mark Ritson, an associate professor at the Melbourne Business School. His research shows a high degree of correlation (70%+) between customer loyalty and revenue growth. Specifically, the more positive customers are about a company or product to would-be customers, the greater the growth; similarly, the more negative they are, the lower the growth. It is, according to Dr. Ritson, twice as accurate as the next best measure.¹

This is unambiguous guidance for business executives and managers, especially relevant at a time when growth is the business imperative.² We can apply the same rule and draw similarly powerful conclusions for IT.

Whilst businesses are growing, IT budgets aren’t keeping pace. Gartner Research reports that on average, IT budgets lag revenue growth by about 61%; it’s as high as 63% in financial services.² Just as the bottom line number lags, so do the satisfaction indicators: Gartner goes on to report that 60% of CEOs see IT as an inhibitor of business imperatives², and Forrester Research reports the same number of business sponsors of IT projects are dissatisfied with fitness or timeliness of solutions delivered.³

If we interpret IT budgets as IT's revenue, it comes as no surprise that they’re lagging: business dissatisfaction with IT will reduce the enthusiasm to spend. Budget size is not the goal of IT; it is, however, an indicator of how relevant IT is to the business. If it is to move away from being perceived as a “tolerated nuisance” of doing business in this day and age, IT must be a driver of breakaway solutions, the things that create substantial market advantage or process efficiency for the business. IT won’t drive these unless solution satisfaction comes into alignment, bringing with it an increase in confidence in the capability of IT.

To have this information, we need the data. Fortunately, collecting custsat data need not be invasive or high ceremony: an 8 to 10 question survey consistently proctored (e.g., quarterly) will provide sufficient, frequent data. And, experience shows that what gets measured is what gets managed, meaning there is quick impact: although making the data visible early on causes some heartache, the numbers tend to trend upward because of their visibility.

This, then, makes the case for having customer satisfaction as a component of IT governance, not only because it is integral to answering the second governance question, “are solutions being delivered in accordance with expectations,” but specifically because it is a forward-looking indicator of IT’s relevance to the business.



¹ I highly recommend reading the full article in the 16-22 November issue of BRW magazine, it’s worth the AU$3.30.
² Gartner has produced a number of research reports in this area, including “IT Spending Lags Behind Revenue Growth in Most Industries” in August 2006 and “What’s on the Minds of CEOs and the Implications for IT” on 17 January 2005
³ From Forrester’s 2005 United States Technology User Benchmark Study.

The Governance Gap

The demand (and need) for IT governance is increasing faster than the discipline is maturing. Core to the problem is that there is no concensus as to what is meant by "governance" in an IT context. If anything, there is outright confusion, evidenced by the polyglot of consulting and services and the number of project management products being positioned as governance "solutions." This, in turn, means there are few coherant approaches (let alone solutions) to satisfy the need.

In and of itself this isn't a problem: that governance needs to be highly tailored to an IT organisation is simply an indication of practice immaturity. But there is a significant downside: practice immaturity means an absence of best practices and a high rate of solution mis-fit. This can be seen in many current IT governance structures. Often little more than large, cumbersome reporting exercises grafted on top of operations, they relying on poorly-modeled data-gathering mechanisms that inadequately interrogate what's actually happening on the ground. Instead of providing "windows on operations," they're CYA exercises that create arms-length relationships between field decision-makers and directors. At their worst, they're inhibitors to productivity and sew seeds of mistrust.

For starters, IT governance needs a clear definition. Fundamentally, IT governance is a results-oriented exercise that can be summed up in one question: what is being achieved, given operating realities (commercial, regulatory, risk, etc.)?

This is a more active than passive definition. Governance is, in fact, an active, engaged, results-oriented discipline. Some would argue that governance is more accurately defined as providing "guidance" to people throughout an organization as to how decisions should be taken and work should be done, but this is an incomplete definition. If it were meant as "guidance" it would be called "guidance." With governance comes responsibility: if bad corporate stewardship can result in criminal penalty, it is, indeed, a results oriented practice. That the obligation of "good governance" carries with it the need to know "how work is being performed" is simply an expansion - but not replacement - of the definition of governance. To wit: SOX requires the CEO and CFO to certify that financial reports reflect reality; that is, the bottom line is what they assert it to be. That the "how" is important to this act of executive certification is an extension of that basic performance-oriented question. IT governance is no different.

The über-question - what has been achieved given operating realities - breaks down into two distinct dimensions:

1. Are we getting value for money? That is, are we maximizing return on our techcnology investment? This allows us to assess the effectiveness of our decisions.
2. Are solutions being delivered in accordance with expectations? That is, are execution and delivery in compliance with corporate policy, be it security, quality, design, etc. This allows us to assess the completeness of our decisions and results.

The first dimension is results-orientated. It's important to note that it's not concerned with the question "are we meeting plan" but "are we getting bang for the buck." IT has traditionally asked this question after-the-fact, measuring results of operations / projects / programmes post-flight, as in-flight reporting is often little more than reporting to plan (and laden with opinion). Post-flight, however, is no longer sufficient: while corporate revenues are rising, cost containment is embedded into corporate culture; a recent report showed IT budgets lagging revenue growth by more than 60%. There really is a need to do more with less, and to do so on a large, organization-wide basis. In addition, the operating environment changes quarterly, monthly, weekly, daily; as a result "meeting plan" can be more destructive than helpful. Finally, it is important to assess which IT investements will yield the greatest business impact going forward. This means the "results" question needs to be asked on an ongoing basis and framed in a portfolio context.

The second dimension is process-oriented, concerned with whether results achieved are consistent with organisational objectives and expectations (that is, are decisions being made with a full scope of consideration.) This dimension - so often the focus of "governance" and so often ignored or outright chided ("what difference does it make how it's done, just that it's done?") - carries equal status to the results question. The "how" question has been the source of the bureaucratic burden of little operational value, the breakdown in the governance programme requiring that monthly "compliance reports" are filled out by teams, rife with survey-borne opinions more than operational fact. The reality is, "how" stuff is done is just as important as "what" is done. If SOX is evidence that this can't be left to trust in accounting and finance, it is not a stretch to say that it can't be left to trust in IT operations, either. Clearly, IT solutions that are vulnerable to security violation or are long-term financial drags on the balance sheet due to architectural flaws are serious matters: jobs are on the line for this stuff. As the stakes are higher - e.g., as the threshold for internal investment into IT projects is increasingly high and under closer scrutiny, as the cost of failing to safeguard information is similarly high, etc. - this can't be ignored.

Formalized governance is coming to IT. If it is imposed from the outside, IT will suffer under the weight of measurement and collection mis-fit, relegating IT to the role of "passenger" in the organization for many years to come. IT has the opportunity to incubate and rapidly professionalize a governance capability, aligning governance with execution through fact-based management that communicates performance not in an IT context, but in a business context. If successful, it will transform IT from being passenger to driver of organizational objectives.