Design Thinking and Emerging IT Roles


designthinking

This is the third and final part in a multi-part post inspired by Robert Pirsig’s masterwork, Zen and the Art of Motorcycle Maintenance.  In Part 1 (titled “Reflections on ‘Zen and the Art of Motorcycle Maintenance’ 38 Years Later “) I discussed the implications for IT professionals of Pirsig’s musings on ‘classic’ versus ‘romantic’ worldviews, and his struggle to resolve these.

In Part 2, (titled “Zen, Motorcycle Maintenance, Design Thinking and Information Technology”) I teed up my observation that this classic-romantic balanced approach is embodied in the “design thinking” movement, popularized by Tim Brown and Ideo and exemplified by companies as diverse as Apple, Proctor & Gamble, Herman Miller and GE.  I discussed why Design Thinking is becoming increasingly important to the IT profession.  Among the reasons for the rising importance of Design Thinking in IT:

  1. Thanks to the likes of SAP, Oracle, et al, and the growing base of cloud-based ‘applications as a service,’ most of the opportunities to improve or automate transactional business processes have been exploited.  Today, businesses are increasingly searching for product, service and business model innovation.
  2. As we accelerate the move from custom development to personal apps, reuse, and “mash-ups,” much more emphasis is placed on synthesis rather than analysis – leveraging widgets and components rather than coding solutions from scratch.

I will pick up in this final part where I closed Part 2, with a discussion of three roles that are key to instilling Design Thinking in an IT organization.

Key Roles for Design Thinking in IT

Achieving the classic-romantic balance in discovery and solutioning involves many IT roles, but there are three roles that I believe are key:

Roles – Not Necessarily Jobs!

Before we examine these roles and how they work together, I want to emphasize I am talking about roles, as opposed to jobs.   The distinction is important in that the notion of organizing around roles imparts flexibility and variety for a workforce, whereas jobs tend to constrain people in boundaries defined in job descriptions.  An individual typically will hold only one job, but may fill multiple roles.  For example, my job is Principal in a consulting firm.  In some engagements, I am the Engagement Lead.  In others, I might be a Subject Matter Expert.  In still others, I am the Client Relationship Officer.  Beyond engagements, I might be a Research Program Leader or a Research Associate.

Also, these roles are typically instantiated with all sorts of labels – rarely the label I’m using here.  For example, I’ve worked with Business Relationship Managers (BRM’s) who were called Business Partner Director, Account Manager, Client Relationship Manager, IT Business Partner, Business IT Partner, IT Demand and Account Manager, Client Engagement Director, and so on!  And the specific missions, visions and implementations of the BRM role has been as varied as their titles!

Nevertheless, let’s drill into these roles and how they relate to each other and to moving IT to more of a Design Thinking philosophy.

Business Relationship Manager

I’ve posted extensively on this role in the past – it’s the role that sits between the IT organization and its business clients.  As such, it both represents the business clients to IT, and IT to the business clients.  This role has surfaced over the last 10 years or so.  I don’t know what percentage of IT organizations have this role today, but as an indication, LinkedIn hosts 2 groups dedicated to the role.  One group – IT Business Relationship Management - currently boasts over 1,800 members.  The other group, Professional Business Relationship Managers currently has over 2,600 members!  (In the interests of full disclosure, I co-manage the latter group.)

As the bridge between the business and the IT organization(s), the BRM plays a key role in moving above and beyond the traditional “requirements analysis” to an approach to discovery and solutioning that is more:

  • collaborative
  • abductive
  • experimental
  • integrative
  • outside-in
  • human-centric
  • innovation-biased approach

As such, the BRM has to understand Design Thinking, and ensure that the qualities listed above are brought to the table and play together effectively and efficiently.  The BRM herself does not have to be expert in these qualities, but must be an effective “broker” ensuring that people with the needed competencies and incentives are at the table.  These competencies will often be found in the other two emerging roles – those of Enterprise Architect and Product Manager.

Enterprise Architect

As with BRM’s, Enterprise Architects (EA’s) come in all sorts of flavors with a variety of titles.  The major distinction I would make is with what are generally called IT Architects.  Enterprise Architects are clearly focused on the business, business models, major business processes, business-IT platforms and the ecosystem within which the business operates.  IT Architects, by contrast, are focused on the technologies, their standards and how they inter-operate.

Wikipedia defines Enterprise architecture (EA) as:

… the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future state and enable its evolution.

Practitioners of EA call themselves enterprise architects. An enterprise architect is a person responsible for performing this complex analysis of business structure and processes and is often called upon to draw conclusions from the information collected. By producing this understanding, architects are attempting to address the goals of Enterprise Architecture: Effectiveness, Efficiency, Agility, and Durability.

As with BRM’s, the EA role has been growing in prominence over the last 10 years or so.  Typically, it is complementary to the more technical roles of IT Architect, Information Architect, and so on.  Also, as with BRM’s there is little that is ‘standardized’ about the EA role, and by many measures it is something of a stretch to use the term “profession” when talking about EA’s, in spite of the efforts of bodies such as The Open Group Architecture Framework (TOGAF®), and my old friend, John Zachman and his Zachman Framework for Enterprise Architectures.

Again, as with BRM’s, LinkedIn is home to an Enterprise Architecture Network, with an astounding 85,000+ members!  As an example of the passion exhibited by this group, a recent comment that stated, “EA is often left in IT because it can only handle tame problems” garnered 572 comments!

At its best, the EA helps bring to the business-IT discovery and solutioning table some of the competencies from my bulleted list above.

Product Manager

The third role in the triad that can help IT organizations introduce more Design Thinking into their activities is that of Product Manager.  This role is far more scarce in IT organizations than either BRM or EA.  It is, however, universal in product companies, including information technology product companies.  Wikipedia defines Product Management as:

…an organizational lifecycle function within a company dealing with the planning, forecasting, or marketing of a product or products at all stages of the product lifecycle.

The role consists of product development and product marketing, which are different (yet complementary) efforts, with the objective of maximizing sales revenues, market share, and profit margins. The product manager is often responsible for analyzing market conditions and defining features or functions of a product. The role of product management spans many activities from strategic to tactical and varies based on the organizational structure of the company.

While involved with the entire product lifecycle, the product management’s main focus is on driving new product development. According to the Product Development and Management Association (PDMA), superior and differentiated new products — ones that deliver unique benefits and superior value to the customer — is the number one driver of success and product profitability.

Of particular note, Wikipedia goes on to note that:

Product management often serves an inter-disciplinary role, bridging gaps within the company between teams of different expertise, most notably between engineering-oriented teams and commercially oriented teams. For example, product managers often translate business objectives set for a product by Marketing or Sales into engineering requirements. Conversely they may work to explain the capabilities and limitations of the finished product back to Marketing and Sales. (Emphasis added.)

The Design Thinking Triumvirate

So, the keys to getting more Design Thinking into Business-IT solutions lies in the triumvirate of Business Relationship Manager, Enterprise Architect and Product Manager, with the BRM as the broker and orchestrator of these roles.  There are, of course, other roles played – e.g., business analyst, project manager, program manager, and so on, but I wanted here to focus on those roles which are less common but in the ascendancy.

Graphic courtesy of Green Hat Group

Enhanced by Zemanta
About these ads

Do You Approach Strategy Formulation as an Event or a Continuous Process?


I find that most strategy efforts aren’t very strategic.  Nor do they have much real impact, or lead to significant change.

The Problems with Traditional Strategy Formulation Approaches

I think the supporting evidence for my findings lies in the fact that most companies either:

  1. Don’t undertake strategy formulation initiatives unless they feel they have to (e.g., 5 or more years have passed since they last conducted a strategy session, or the current strategy is clearly not working!)
  2. Do undertake strategy formulation regularly and rigorously (typically annual), with a detailed process spanning many weeks and taking lots of time.  When they are through the effort, everyone breaths a big sigh of relief, and gets back to work – and to executing against the original strategy!

Those in camp 1 above often engage strategy consulting firms.  Nothing inherently wrong in that, except that it can be a high cost route that ends in a good strategy that either:

  • Does not fit the firm’s capabilities particularly well, or…
  • Does not get sufficient engagement with those in the firm who must understand, buy into and execute against the new strategy.

Those in camp 2 above usually have a full time strategy organization – a small, but expensive group of bright folk who need to justify their existence.  Nothing inherently wrong in that, either, except that:

  • The results are often less than inspiring.  They do a good job going through the motions, but the thinking isn’t really very strategic, nor the goals very ambitious.
  • The results typically do not get sufficient engagement with those in the firm who must understand, buy into and execute against the new strategy.

Strategy Formulation as a Continuous Process

I believe much better results can be achieved if strategy formulation becomes:

  1. A continuous process.
  2. A firmwide capability – a strength, even!
  3. A collaborative process.

We are living in unprecedented times.  Uncertainty and change are everywhere.  Market conditions can change overnight.  The globally interconnectedness of everything creates a complex environment that behaves in unpredictable ways.

New Possibilities Enable Continuous Strategy

At the same time complexity has increased and predictability decreased, information technologies create new possibilities for a very different approach to strategy formulation:

  • From an event to a continuous process enabled by the Internet
  • From a “canned” exercise for the select few to a “social” exercise for the many – employees, customers, suppliers, partners
  • From lengthy “big bets” with high uncertainty to rapid “business experiments” with low risk
  • From a dearth of data to help evaluate strategic options to a plethora of powerful business analytics, predictive modeling and simulation tools to help bring strategy formulation and execution together into a rapid learning model

Some of today’s fastest growing companies have figured this out and are quietly, but aggressively honing their continuous strategic capabilities.  Meanwhile, the large majority of companies are stuck in the old paradigm – afraid to open up the strategy process – just when the need for a shot of innovation and fresh thinking are matters of survival!

What do you think?  Are you in a company that is successfully moving to a more continuous approach to strategy?  Should your company be doing more to make strategy continuous?  How can you help achieve this?

Enhanced by Zemanta

Innovation and Web 2.0 – A Compelling Relationship?



I had a very interesting and exciting week!  I was a speaker at an nGenera Senior Executive Summit, which drew about 60 top executives from mostly large companies – CEO’s, CIO’s, CFO’s, HR and shared service heads, and even a couple of Lawyers and Platform/Brand managers.  It was an auspicious group – both in terms of participants and presenters/session leaders, which included Jim Collins, Michael Treacy, Don Tapscott, Tammy Erickson and Dartmouth’s Tuck School Professor, Chris Trimble.

I introduced my ideas about leveraging Web 2.0 (broadly defined) to significantly drive up the value of business innovation – specifically by following the principles and processes of Design Thinking.  I’ve been getting to this point in my last series of posts (Part 1, Part 2 and Part 3.)  In fact, those posts were largely written as I was developing my session materials.

Does ‘Design Thinking’ Have Legs?

Part of my thesis built upon the success of the Design Thinking movement that has gelled over the last 5 years.  I have found the success stories compelling, and the underlying principles resonate with my own experiences and values over the last 30 years in trying to leverage IT for increased innovation.  However, I was troubled by the recognition and acceptability of the term ‘Design Thinking’ – especially in the US.  The text of a 2007 speech by BusinessWeek‘s Bruce Nussbaum given in London tipped me off that there might be a problem here.

Nussbaum’s Banana…

In his 2007 speech to the Royal College of Art, Nussbaum noted:

In the US, CEOs and top managers hate the word “design.” Just believe me. No matter what they tell you, they believe that “design” only has something to do with curtains, wallpaper and maybe their suits. These guys, and they’re still mostly guys, prefer the term “innovation” because it has a masculine, military, engineering, tone to it. Think Six Sigma and you want to salute, right? I’ve tried and tried to explain that design goes way beyond aesthetics. It can have process, metrics all the good hard stuff managers love. But no, I can’t budge this bunch. So I have given up. Innovation, design, technology—I just call it all a banana. Peel that banana back and you find great design. Yummy design. . The kind of design that can change business culture and all of our civil society as well.”

One of the first to make the Web 2.0 connection, Nussbaum went on to say:

Innovation is no longer just about new technology per se. It is about new models of organization. Design is no longer just about form anymore but is a method of thinking that can let you to see around corners. And the high tech breakthroughs that do count today are not about speed and performance but about collaboration, conversation and co-creation. That’s what Web 2.0 is all about.”

I tested the waters of my Summit attendees, first by asking how many in the room had some familiarity with the term ‘Design Thinking’?   Three hands shot up, and a couple sort of hovered around shoulder level (presumably meaning, “I’ve heard of it, but please don’t call on me to talk about it!”).  Of the three hands, two were from companies for whom I had Design Thinking case studies about and who were listed in my very first slide (I had not at this point turned on the projector.)  The third hand was from a senior executive at a major Industrial Supply company that I had not expected to be particularly Design Thinking literate.  So, test 1 indicated that the term is not widely known.  Of course, this does not necessarily mean that Design Thinking is not widely practiced – perhaps all 60 companies in the room do in fact excel at Design Thinking, but refer to what they do as some variation of Nussbaum’s ‘banana’?  However, I truly doubt this.  In fact, the many one-on-one conversations that I had with the executives at this summit during the reception and dinner following my presentation supported my sense that explicit efforts to drive up the value of business innovation are relatively few and far between.

Are Design Thinkers Web 2.0 Enabled?

To the larger part of my thesis, there was little evidence at this Summit that any form of Web 2.0 was being explicitly leverage to support Design Thinking (or innovation, or the banana!)  There were a few ‘accidental experiments’ and emergent social networks – both internal and external – but nothing claimed as part of a deliberate, holistic effort to increase innovation through Web 2.0 technologies.  This for me was the big surprise.  The Senior Vice President of Strategy from one of the Design Thinking literate companies told me at the reception, “When you first connected Design Thinking and Web 2.0 in your presentation, I thought you’d completely lost it!  But as you gave examples, the light bulbs began to turn on – I think you are onto something!”  This was gratifying indeed – well worth the price of admission!

Graphic courtesy of RI Nexus

Reblog this post [with Zemanta]

Design Thinking 2.0: Enabling Innovation with Web 2.0 – Part 2


In my first post in this series, “Design Thinking 2.0: How Web 2.0 Might Foster and Enable an Innovation Revolution” I summarized the concepts of Design Thinking and raised the question of how Web 2.0 might enable increased innovation.  (For an interesting perspective on Design Thinking by Business Week’s Bruce Nussbaum, see his excellent essay based on his 2007 speech to the Royal College of Art in London.)

In my next post I will  drill down and suggest ways to use Web 2.0 technologies and approaches to increase innovativeness and business success, but for now I want to examine the Core/Edge distinction in order to focus us clearly on Edge capabilities, where innovation tends to surface – without being encumbered by the Core.

“Core” and “Edge” Capabilities

Identifying the best ways to leverage collaborative technologies for innovation require an appreciation of the distinction between “Core” and “Edge” business capabilities.  The notions of “Core” and “Edge” I think were first articulated in June 2005 by John Hagel III, a former McKinsey consultant, and John Seely Brown, former chief scientist of Xerox in a Wharton Summary interview titled “Can Your Firm Develop a Sustainable Edge?”  In that interview, Hagel noted:

The… edge… has to do with the notion of competitive advantage, but it also has to do with the view that the ability to develop capabilities involves operating at the edge. Of course, “edge” has multiple meanings as well. It means the edge of the enterprise, the edge of business processes, geographic edges in terms of emerging economies, demographic edges in terms of younger generations coming in with different mindsets – it’s a whole set of edges that create the opportunity for accelerating capability building.”

Seely Brown noted in the same interview:

… being able to listen deeply and participate on the edge, you can pick up things before anybody else picks them up, and you can use that to accelerate your own capability building… This puts a new spin on why distributed collaboration around the world might be critical in creating this sustainable edge.”

My colleagues and I picked up this theme in our multi-company research at nGenera and I covered it in some depth starting in March 2008 with my “Surfing and IT Innovation” post, followed in July 2008 with my “Edginess and IT Innovation” post.

The reason this Core/Edge distinction is so important for IT professionals in the corporate environment is that the Core exerts enormous gravitational pull – innovation activities such as business experiments at the edge tend to get pulled into the core where standards and rigid processes rule.  The Core typically consumes 70% to 90% of IT resources, starving edge activities of the resources and focus they need to flourish.

Requirements of Core Capabilities

Core Capabilities exist to support exploitation of existing business opportunities.  As such they tend to be ‘locked down’, complex and hard to change – in fact, they are designed to prevent ‘bad change.’  Core processes are intended to be highly stable and predictable, typically built on proprietary and relatively fixed architectures.

Requirements of Edge Capabilities

By contrast, Edge Capabilities exist to stimulate and support the exploration of new business opportunities. As such they must be open, agile, transparent and adaptive.  While Core capabilities must ‘prevent bad change’, Edge capabilities are designed to stimulate ‘good change.’  They leverage open, emergent architecture and open sourcing. This, of course, is the realm of Web 2.0 – social media, open source, open innovation, cloud computing, etc.

Balancing Core and Edge Capabilities

The table below further highlights the differences between Core and Edge capabilities and shows example of each type.  My point here is that most IT organizations have many years of experience in perfecting Core capabilities but have relatively little experience with Edge capabilities.  The IT leaders’ natural preference is to control rather than facilitate, to direct rather than stimulate.


In Part 3 of this series, we will look at a generic Design Thinking process and see how each step can be enabled by Web 2.0 “Edge” capabilities.

Image courtesy of Larval Subjects

Reblog this post [with Zemanta]

Exploring an IT Operating Model for Enterprise 2.0 – Part 4: IT Governance


In Part 1 of this series, I suggested that the implications of Enterprise 2.0 for the IT organization are dramatic.  I also suggested that the ways of designing and executing an IT Operating Model in a Web 2.0 context are quite different from traditional approaches.  In Part 2, I outlined the major elements of an IT Operating Model as being:

  • Processes – how we perform activities that deliver predictable and repeatable business results through competent people using the right tools.
  • Governance – how we make and sustain important decisions about IT.
  • Sourcing – how we select and manage the sourcing of our IT products and services.
  • Services – our portfolio of IT products and services.
  • Measurement – how we measure and monitor our performance.
  • Organization – how we structure and organize our IT capabilities.

In Part 3 we looked at how Web 2.0 approaches could transform the way IT processes are defined and managed.  I now want to look at IT governance, and the implications of Web 2.0 for this ever important aspect of IT operating models.  Due to the depth of this topic, I will discuss the facets and domains of IT governance in this post, then deal with the Web 2.0 implications in a subsequent post.

Facets of IT Governance

There are many definitions and descriptions of IT Governance, and frameworks such as COBIT that attempt to bring ‘best practices and processes’ to the domain.   The two definitions I have landed on in my years of research and consulting in this space, are:

  1. A framework of decision rights and accountabilities to encourage desired behavior to realize maximum value from information technology.
  2. Aligning IT decision-making with enterprise governance and business unit objectives through an interrelated set of processes, policies and decision-making structures with clear goals, roles and functions, sponsored by the CEO, with clear consequences for compliance or lack thereof.

I like the first definition for its simplicity, getting to the heart of both ‘decision rights’ and ‘accountabilities’ through the lens of ‘behaviors’ all focused on maximizing the value realized through IT.  This is pragmatic – you can define the types of behaviors you would like to see (e.g., business takes ownership for the business outcomes to be enabled by IT initiatives), or behaviors you are seeing but would like to eliminate (e.g., people see IT as a ‘free’ resource, and therefore use it with little or no regard as to its cost or value.)

I like the second definition in contrast for its recognition that IT governance is an extension of enterprise governance, and for its reference to ‘processes’, ‘policies’, and ‘decision-making structures.’  I also like the emphasis on CEO sponsorship and consequence management – i.e., governance with ‘teeth’.

I’ve come to view IT governance as a means to achieve balance between the competing forces of innovation versus standardization and business unit autonomy versus collaboration.  I also see IT governance as a way to manage IT investments and assets as a  resource that is shared by the enterprise.  Finally, good IT governance provides a “transmission chain” for the highest level enterprise strategy, from senior executives on down through the organization. As such, IT governance is a critical alignment mechanism.

IT Governance Domains

Peter Weill and Jeanne W. Ross, in their excellent book, IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, call out five decision domains of IT governance:

  • IT Principles (strategic choices between competing perspectives.  For example, ‘We will optimize IT investments for the enterprise rather than for individual business units.’)
  • IT Architecture (“the organizing logic for data, applications, and infrastructure captured in a set of policies, relationships and technical choices.”)
  • IT Infrastructure (“Centrally coordinated, shared IT services that provide the foundation for the enterprise’s IT capability.”)
  • IT Investments and Prioritization (“How much and where to invest in IT, including project approvals and justification techniques.”)
  • Business Application Needs (“Specifying the business need for purchased or internally developed IT applications.”)

While these domains may each be handled by different processes, policies and decision-making structures, all of these domains must be covered in ways that support a coherent strategy and set of beliefs about IT.

IT Governance, In Other Words…

IT governance deals with how the business makes decisions about the deployment and delivery of IT.  When sound IT Governance is in place, senior executives not only know their organization’s IT plans and policies, they also know how they are made.  IT governance is about the specification of decision rights and responsibilities required to ensure effective and efficient use of IT.  As such, it deals with organizational power and influence, and therefore  must be approached with care!

IT Governance 2.0

The implications of Web 2.0 on IT Governance are dramatic and far reaching!  On the one hand, with ‘transparency’ a watchword of good governance, 2.0 capabilities offer several important mechanisms to bring transparency both to the design of effective IT governance processes and structures, and to their ongoing execution and management.  On the other hand, dealing with decision rights and accountabilities in the types of highly diverse, distributed and fluid information environment enabled by social networking tools can become quite complex.  We will dig deeper into the implications of Web 2.0 for IT governance in a subsequent post.

Image courtesy of The ERM Current

Reblog this post [with Zemanta]

I Must Have my Head in the Clouds!


Streaky Freaky CloudsI’ve been posting on and off about Cloud Computing since I began this blog a couple of years ago.  But, as one who spends most of his time with IT leaders of large global enterprises, sometimes the promise of the Cloud seems more like a mirage!

I’ve Looked At Clouds From Both Sides Now

Back in August 2008, not being able to resist the title to the wonderful Joni Mitchell and her reference to “cloud illusions I recall”, I posted on the denial I was witnessing among my client base.   I likened it to the denial that was common among CIO’s back in the early 1980’s.  To quote from that post:

(CIO’s) were mostly in denial, even as executive offices just down the corridor from the CIO’s office were beginning to become home to a variety of rogue PC’s – machines such as Apple II’s and Radio Shack TRS 80’s.

Fast forward 25 years or so. Now the press is full of predictions and prognostications about Cloud Computing, several key players are investing heavily in this space (pun intended) but many CIO’s and CTO’s either just don’t believe it, see it as warmed over service bureau computing from the 60’s and 70’s, or believe it’s the greatest threat to enterprise computing sanity since computer viruses first appeared.

Now, nearly 1 year later, I’m still seeing the same denial – Cloud Computing, for the most part, is on the back burner – a technology to watch!  Clearly, there are significant risks with the untried, standards are still evolving, and there’s something intimidating about such a simple concept being able to replace so much enterprise technology and expertise – the “heart and soul” of the typical IT organization.  In fact, for many IT shops, this “heart and soul” is where they’ve invested many of their improvement efforts over the last few years, implementing ITIL and process improvement approaches.  That’s been a hard-won fight, and CIO’s are loathe to admit that there might now be an easier and better way!

In another post earlier this year on The Dangers of Cloudy Thinking, I wrote:

I’m fascinated and bemused by this Cloud Computing phenomenon. Never before have I had such a strong feeling that something really, really important is happening – a fundamental discontinuity, if you will, in the way we leverage IT – and yet most of my clients and those I am interacting with in a couple of multi-company research projects are essentially standing on the sidelines.

Hincliffe’s “8 Ways That Cloud Computing Will Change Business”

Dion hits the nail on the head once more with his excellent June 5 post in which He says:

(Cloud computing offers) benefits that can potentially change the game for many firms that are willing to be very proactive in managing potential downside. These include access to completely different levels of scale and economics… Easier change management of infrastructure including maintenance and upgrades (cloud vendors extensively virtualize and commoditize the underlying components to make them non-disruptive to replace and improve) … Cloud computing also offers an onramp to new computing advances such as non-relational databases, new languages, and frameworks that are designed to encourage scalability and take advantage of new innovations such as modern Web identity, open supply chains, and other advances.

He goes on to show the major pros and cons, and then to cite 8 compelling ways that cloud computing can change business.

Cloud Computing – Ideal for the “Edgy” Opportunities?

Dion refers to the use of cloud computing beyond “edge” computing (which he describes as minor applications and non-critical business systems).  This is the only place where I take issue – I think “edge” computing is where the exciting action is, where the high value and innovative opportunities lie.

Back in July 2008, I posted on “Edginess and Innovation.”  In that post, I differentiated between “core” and “edge”:

Many IT leaders when talking about the “core” are referring to the “legacy” systems…  built over the years and have to maintain.  But in reality, the core goes much deeper than the systems and technologies. Business processes – especially when you include the unautomated practices and workflows that interact with the automated ones, are hard to change. The mindsets that dominate “core” thinking and “edge” thinking are radically different. I’ve noted before that quality guru Joseph Juran distinguished between “preventing bad change” (keeping processes under statistical control” and “creating good change” (innovating processes and products, or creating “breakthrough” performance as Juran put it) and the different management approaches and structures each requires. Most IT leaders have focused for years on management approaches more consistent with preventing bad change than creating good change. This has created a mindset that abhors risk taking.

I believe most of the “core” opportunities have been addressed in the typical global enterprise.  Sure, there’s always more to do (and the trap of saying “yes” to all the business requests to continually tweak and bolt onto core systems) but I believe you can move the business value needle significantly to the right by tackling more of the “edge” opportunities, and that is where, to Dion’s point, the Cloud (and its related technologies) offers real promise – now!

Reblog this post [with Zemanta]

Supposing You Funded IT Like a Charitable Donation?


charity_box1I’ve had this IT funding fantasy for years (I know, it’s really sad that my more exciting fantasies are to do with IT funding scenarios!) Supposing the CIO had to do a fund drive every year or every six months the way our local National Public Radio stations had to operate in order to fund certain IT activities?

I actually hate the NPR fund drives, but I love what privately funded radio brings compared to all other forms of news and quality radio programming  in the USA, and I realize that the funding model is necessary and ultimately important to the NPR mission.

Listening to my local radio station’s NPR funding appeal for a couple of weeks twice a year always gets me thinking about IT funding and my “IT Charitable Donation Fantasy.”  I’m not suggesting this is the way to fund all IT activities – far from it.  I believe that funding, for good or bad, drives behavior, so if we want responsible business behavior around IT assets and activities, we need to think through the desired behaviors and how funding models promote or detract from those behaviors.

Three Distinct IT Funding Pools

It is useful to carve IT spending into 3 broad categories:

  1. IT infrastructure.  This should be defined very broadly to include all shared IT capability.  To borrow from Prof. Peter Weill’s definition, IT infrastructure is the base foundation of IT capability budgeted for, centrally coordinated and shared across the enterprise.  I don’t see this being funded through a charity-like, voluntary basis.  Like all infrastructures, nobody really wants to fund it, and few understand the technology details, risk management, capacity planning and other implications that render IT infrastructure either reliable and supportive of the business mission on the one hand,  or unstable and get in the way of the business mission on the other.  I think IT infrastructure is best funded as a kind of tax – in a way that fairly represents the proportional value to the organization that uses it.  Depending upon the nature of the business, this might be a function of headcount, divisional revenue, or some other factor.  And, as an aside, the CIO should be looking to continuously improve the cost per unit of infrastructure over time.
  2. Business Solutions.  These should essentially be funded by the business units that require them and will benefit  from them.  If more than one business unit, then the combination of business units will fund the solution in proportion to the degree of benefit or value each derives.  This will never be pure science and will typically involve some kind of negotiation between the parties.  By the way, this type of activity should have a robust value realization approach to go along with the funding.  (I’ve posted on value realization quite a bit in the past – if you are not familiar with this material, please either search my blog for “value realization” or drop me a line, and I’ll send you the links.)
  3. Innovation/Research and Development.  This is the part of the IT budget that I think lends itself best to a voluntary funding model.  The most common funding practice I come across for this category of activity is “stealth funding” – i.e., the CIO squirrels away funds from other activities, and runs them below the radar – some unspent training dollars here; some savings from a renegotiated vendor contract there; some money left over from a project that came in under budgets, and so on.  The problem with stealth funding is that it is unpredictable, and it hides from the customer base the fact that money for innovation and R&D is actually necessary, and a sign of a healthy IT organization.

Fund Raising for IT R&D

So, how might this work?  First, the CIO needs to decide a funding target for IT Innovation and R&D.  This might be something between 1% and 5%.  Then build a business case – how will the funds be used?  Why should the business care – how might they benefit?  Typically, these funds will be invested in a mini-portfolio of activities, from low-risk to high-risk, and from short-term to long-term.  Will there be an expected payback on the whole portfolio?

For those business heads that chose to participate, will they get any special treatment compared with those who chose not to participate?  (This is a thorny question!  NPR does not threaten to cut me off listening to the wonderful Morning Edition or All Things Considered, or any of their great weekend shows should I not ante up each year for “membership.”)  For the CIO, I’m not sure how best to play this out.  I think some special treatment might be the ability to participate in business experiments that are associated with the R&D activities, but there may be other quid pro quos for those who pony up to the R&D fund.

Comments?  Questions?

So, what do you think?  How “fantastic” is my IT funding fantasy?  Are any of you doing anything like this?  How is it working?  Could it work?  Answers on a postcard, please!

You’ve Got Information Technology Questions? We Have Answers…


athinaAs an IT professional or IT leader, do you find yourself with questions or issues you’d like to get opinions about?  Of course you do.  As a consultant, researcher, educator and author, I get questions all the time.  For me they are my oxygen.  If the questions ever stopped, well, I frankly don’t know what I’d do!

At the risk of coming across as arrogant, after 15 months of blogging and 166 posts, I sometimes find myself opening up my blog and entering a search term in which I’m interested in the search box in the banner, and using my own blog to remind myself what I’ve written about, or that others have commented on regarding that topic.  Often, the search comes up with some useful information – sometimes with some helpful link or insight.

So, here’s a suggestion – next time you have a question, or a topic of interest related to IT organization, governance, value realization, architecture, ITIL, CMMI, or emerging leading practices, give my blog a chance.  See how it holds up as a repository of useful nuggets.  Let me know – if it works for you, or if it let’s you down.  Let me know how to make this blog a more useful resource for you.

“Edginess” and IT Innovation


In preparing for our upcoming Executive Perspective in Chicago on September 18/19, my team has been exploring what is meant by “edginess?”  What does edginess look like in its various forms?  When and how is edginess good, productive, appropriate?  When is it bad, counterproductive, inappropriate?

John Hagel and John Seely Brown in their landmark paper, “From Push to Pull- Emerging Models for Mobilizing Resources” contend “The edge is where the action is – in terms of innovation and value creation. Companies, workgroups and individuals that master the edge will build a more sustainable core.”   This analogy of “core” and “edge” has influenced the recently completed (though still in the final stages of documentation) research on Reaching Level 3 Business-IT Maturity.

Many IT leaders when talking about the “core” are referring to the “legacy” systems and their drag on resources and forward motion.  They are typically referring mostly to the computer systems and infrastructures they have built over the years and have to maintain.  But in reality, the core goes much deeper than the systems and technologies.  Business processes – especially when you include the unautomated practices and workflows that interact with the automated ones, are hard to change.  The mindsets that dominate “core” thinking and “edge” thinking are radically different.  I’ve noted before that quality guru Joseph Juran distinguished between “preventing bad change” (keeping processes under statistical control” and “creating good change” (innovating processes and products, or creating “breakthrough” performance as Juran put it) and the different management approaches and structures each requires.  Most IT leaders have focused for years on management approaches more consistent with preventing bad change than creating good change.  This has created a mindset that abhors risk taking. 

So, back to edginess.  People can be edgy – those with strong opinions that often feel at first like they come out of left field.  I worked for a boss once that included in our evaluation criteria, “uses appropriate edge!”  This led to a great deal of dialog (all enlightening) and sometimes, real-time coaching when a consultant used appropriate versus inappropriate edge.  In that context, edge was taking a strong point of view that we believed in, even if it felt at the time that client did not share that point of view.  This, of course, is fundamental to good consulting.  Clients don’t hire consultants to blindly agree with all their positions and plans!  There is often invaluable information in edgy people – be they employees, consultants, customers or business partners.  Sometimes, of course, they are wrong, or their timing is off – but there’s still useful information in “hearing” them.  I had a CIO client once that had one of these “edgy” people (let’s call him Fred), and he just did not know how best to leverage him.  We were trying to help his organization become more innovative at the time.  Everyone I spoke to suggested we talk to Fred, and bring him into a workshop we were planning.  When I suggested this to the CIO, he said, “No – Fred’s too disruptive!”  The funny thing is, the CIO really wanted to increase the innovativeness of his organization – and yet his own instincts resisted the some of the very same attributes he wanted to see.  He had risen to CIO by being a great manager, running a very disciplined and effective shop.  He had the vision to know he needed to moved the shop beyond that (beyond Level 2 to Level 3, in the nomenclature of our Business-IT Maturity Model) but was inhibited by his own instincts.  It’s a case of, “I’ve found the enemy – and it’s me,” or “Be careful what you wish for!”  I think Fred left the organization soon after that – and I believe it was an unfortunate loss.

Technology can be edgy – by which we mostly mean “on the leading edge.”  Many IT shops have a well-worn principle that states, “We will be a fast follower of emerging technologies, but chose not to be at the cutting edge.”  I won’t comment here on the pros and cons, and even validity of such a principle, but clearly such shops have made an explicit decision (at least, in principle) not to be edgy in terms of technologies.  What will it mean to such an organization when they want to move to Level 3 – to become more innovative?

Humor can be edgy.  The late George Carlin was certainly edgy!  And therein lies the rub.  When are you “at the edge” and when are you “over the edge?”  The answer of course is relative to the observing party, but being edgy, with anything, introduces risk.  Risk that must be balanced against trust, and much has been written about the nature of trust and its role in the move towards Enterprise 2.0. This issue of the edginess of humor and how and where to draw the line came up in our collaboration with Second City (comedy and improv) who are working with us on the Chicago Executive Perspective event in September.  How should we define the boundaries?

I will continue with this “edgy” theme in upcoming posts.

BTW, sometimes I get questions about the photos or illustrations I select for a post.  For those not in the know, the photo here is of the guitarist/backup singer from the successful Irish band U2.  He goes by the name of The Edge.

Goodby, Shadow IT – Hello, Shadow IT


shadow_opportunity_big.jpg

In our multi-company research WebEx call earlier this week a participant reflected on the changing attitudes to “Shadow IT” – that term IT professionals give to non-IT professionals when they ‘step into their IT professional turf’ and do stuff that should have been ‘better left to the professionals.’

The Shadow IT phenomenon is a great example of what I’ve referred to in the past as ‘sticking points’ – things you need to do to drive Business-IT Maturity from Level 1 to 2, but that if you keep doing, will stick you at Level 2 – in fact, you almost literally have to ‘undo’ them to get to Level 3.  Let me explain.

At lower Business-IT Maturity Levels, Shadow IT is by and large, bad news.  First, it’s typically a business response to a need that the IT organization is not fulfilling – i.e., it’s symptomatic of a problem.  Second, because it is typically IT activity that happens ‘in the shadows’, it often does not have the integrity or recoverability characteristics that a ‘professionally built’ solution would have (at least, in theory!)  Third, given this, after a time, the ‘one-off’ solution created by Shadow IT evolves into a mission critical system, and gets handed to the IT organization with a plea for, “Can you please sort this out and maintain it from now on?”  This sometimes creates a problem because the solution was developed by a non-supported or non-standard technology.

So, typically in late level 1, the CIO goes Stalinist and demands that all IT budget and resources be centralized under his or her control.  This allows rationalization and consolidation, and generally helps elevate maturity into the Level 2 space.  In parallel with this, the architecture group gets empowered, principles and standards are declared, technology roadmaps produced, and IT architectures created.  Welcome to Level 2.

The paradox, however, is that to get to Level 3, the power of ‘end user computing’, for want of a better term, is critical.  That’s where most of the business knowledge lies, where the business problems are felt most intimately, and where most of the ‘arms and legs’ are.  And, given that Level 2 created all that fine IT and Enterprise Architecture with supporting infrastructure, it is now possible to safely unleash the Shadow IT monster!  Rather than see Shadow IT as an evil to be tempered, it must now be seen as a force to be harnessed and directed.

You can see the challenge – in a relatively short period, perhaps 18 months or 2 years, something that was treated as a pariah must now be cherished and nurtured.  This creates a kind of mental whiplash that most people can’t easily absorb.  But I believe that you have to manage through this see-saw to get to Level 3 and the business value that is unleashed at Level 3.  Recognizing this phenomenon, and being able to dialog about it is half way to solving it.