Exploring an IT Operating Model for Enterprise 2.0 – Part 3: Process Management

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 the next series of posts we will consider how these elements can be dramatically improved with Web 2.0 capabilities.

Web 2.0 and Process Management

Process Management, including all phases of process design, deployment, automation, including work flow and continuous improvement, are well-served by collaborative approaches and Web 2.0 tools.  With minor add-ons, SharePoint plus some creative use of Wikis works well for most aspects of process management.  Furthermore, once you are in a browser and on the web, you have access to a plethora of collaborative tools that are helpful when performing process management work, including project management, mind mapping, polling, voting, training and communicating, financial modeling, drawing, 3-D modeling, and so on.  Cheap, and in many cases free, these tools let you create a productive environment, or even a “process management toolkit” for reengineering your IT operating model.

Microsoft, in their “People-Ready Process” approach to Business Process Management argue (appropriately, in my opinion) that you don’t need to standardize on a single tool – the needs and preferences of analysts, process owners, architects, and so on, as well as the tools with which each may be familiar, will vary.  Also, most of these Web 2.0 tools are evolving rapidly, so focus more on the techniques and building the skills, while being prepared to switch or upgrade tools as the market allows.  (Obviously, you need to work closely with your collaboration managers and enterprise architects to ensure they are well informed about what you are doing, and that you don’t create any ‘unpleasant surprises’ for them or the IT operations environment!)

Graphic courtesy of Microsoft People-Ready Process: Collaborative Process Design

Not Just About IT Processes!

Note that while my primary intent and focus for this series of posts is using Web 2.0 approaches in the design and deployment of IT Operating Models for an Enterprise 2.0 world, the same approaches apply to Enterprise 2.0 business process management.  However, I generally feel that the IT organization is well served “doing unto themselves” before they go too far “doing unto others”!  This is a matter of both need (i.e., IT organizations need a healthy dose of collaborative process management!) and experience (i.e., IT organizations should gain some first hand experience in the approaches before they plunge into business process management 2.0!).

Not Just About Web 2.o Tools

As IT professionals, we inevitably gravitate towards the tools, but collaborative approaches bring so much more than useful tools.  I find that with collaboration, it is so much easier to follow agile methods – thereby delivering value sooner.  It also brings the issues of organizational and cultural change to the foreground.  It is an old cliche that “people don’t resist change – it’s being changed that they abhor!”  By bringing a broader swath of stakeholders into end-to-end process management, the challenges of process deployment, adoption and ongoing refinement are significantly reduced.  People are far more engaged in their processes, including their design, use and improvement.  Furthermore, the rapid, iterative methods afforded by such collaborative approaches also facilitate a “design for implementation” approach – helping eliminate design flaws up front, and to iron out kinks faster than traditional methods allow.

Tell us about your experiences with collaborative business process management.  What’s worked well for you?  What not so well?  What have been the benefits?  What have some of the impediments been?

Cartoon courtesy of Doug Savage, Savage Chickens

Reblog this post [with Zemanta]

Exploring an IT Operating Model for Enterprise 2.0 – Part 2

Elements of an IT Operating Model

This is the second part of my series on IT Operating Models for Enterprise 2.0 (for the introduction, please see here.)  In Part 1, I explored the question, “Why Does Enterprise 2.0 Demand a New IT Operating Model?”  I posited three key answers:

  1. The types of IT products and services the IT organization must deliver in an Enterprise 2.0 world are quite different from those in a 1.0 world.  Enablement of enterprise collaboration, for example.
  2. The ways that IT products and services can be delivered in an Enterprise 2.0 world are also quite different.  Through “the cloud”, for example.
  3. The ways of designing and executing an IT Operating Model in a Web 2.0 context are also quite different.  Collaboratively, and through “the cloud”, for example.

I mentioned my current interest and excitement about the 3rd point as something I’ve been exploring, both through multi-company research and through actual consulting engagements, and that is where I want to focus this post.

What Are the Primary Elements of an IT Operating Model

My last post described an IT Operating Model as “the basic framework your IT organization follows to get your products and services into the hands of its consumers and customers.”  Let’s consider what might be the primary elements of such a framework:

  • Processes – how we perform activities that deliver predictable and repeatable business results through competent people using the right tools.  For example, how to we shape demand?  How do we surface and clarify demand?  How do we turn demand into solutions that deliver the intended (or better) business results?  How do we continuously improve the way we do IT work?
  • Governance – how we make and sustain important decisions about IT.  For example, how do business needs and initiatives get prioritized?  How do we manage the tensions between local and global optimization?  How are “standards” chosen and what are the consequences for deviations?  How do we govern major business programs?
  • Sourcing – how we select and manage the sourcing of our IT products and services.  For example, how do we leverage our scale?  What do we offshore, near shore, onshore, in house, in source, contract?  How do we manage key vendors?
  • Services – our portfolio of IT products and services.  For example, what is in our service catalog?  How do we define and manage service levels?  Do we offer differentiated services by customer segment (e.g., concierge service for executives or key customers?)
  • Measurement – how  we measure and monitor our performance.  For example, what are the shared goals of the IT organization?  How does the business determine value realized and delivered through IT investments?  How are we improving over time?  What are our leading indicators of performance and trends, what are they telling us and how do we know what to do about it? What customer experience are we creating for users of our products and services?
  • Organization – how  we structure and organize our IT capabilities.  For example, what capabilities should be located within the IT organization and what can be within the business?  How do we organize around major projects and programs?  How do we organize around major products and platforms?

Note, I deliberately put Organization Structure last in the list.  For years, when I’ve been consulting on IT operating model design, clients invariably want to start with the organization design.  I call that “moving the deckchairs on the Titanic.”  It rarely solves anything.  On the other hand, if you work around the other elements – services, processes, governance, etc., the organizational decisions fall out relatively easily, and far more coherently.

For the last 50 years or so, IT Operating Model Design was mostly an oxymoron – they weren’t designed as much as evolved.  When deliberate design was attempted it was typically though workshops, using flip charts, post-its, PowerPoint slides, Visio, and so on.  At the end of the day, you had an organization chart to follow, organizational charters, templates, process descriptions and such, usually as MS Word and PowerPoint documents that got emailed to and fro, edited, re-edited and eventually “filed,” never to be seen again until the next CIO and the next attempt to “better align IT to the business!”

So, How Can Web 2.0 Change the Way to Design an IT Operating Model?

Given collaborative tools, wiki’s, social networks, prediction markets, et al, how can IT Operating Model design be performed in a more collaborative, impactful way?  How can it be done so that the traditional artifacts of the design – the PowerPoints, flip charts and Visio diagrams become “the way work gets done”?

I will pick up this question in the next post in this series.

Reblog this post [with Zemanta]

Exploring an IT Operating Model for Enterprise 2.0

First, in the interests of full disclosure, the title for this blog was inspired the excellent blog, Wierarchy, and its latest post on Exploring the HR Management Framework for Enterprise 2.0. Note, I have changed the title from “an” to “the”  as I feel there are multiple possible management frameworks for IT, and from “Management Framework” to “Operating Model” as I believe that the concept of an “operating model” is more tangible and actionable for IT folk – especially through Web 2.0 tools, as I shall show in subsequent posts.

So, What’s an IT Operating Model?

eHow, in their very simplified discussion on how to develop a business operating model state that an operating model is:

the basic framework that your company follows to get your products into the hands of consumers”

If we translate this to the IT space, we could say that “an IT operating model is the basic framework your IT organization follows to get your products and services into the hands of its consumers and customers.”

Why Does Enterprise 2.0 Demand a New IT Operating Model?

This is a question I get from time to time, and I think there are at least three key answers:

  1. The types of IT products and services the IT organization must deliver in an Enterprise 2.0 world are quite different from those in a 1.0 world.  Enablement of enterprise collaboration, for example.
  2. The ways that IT products and services can be delivered in an Enterprise 2.0 world are also quite different.  Through “the cloud”, for example.
  3. The ways of designing and executing an IT Operating Model in a Web 2.0 context are also quite different.  Collaboratively, and through “the cloud”, for example.

I’m actually most excited about point 3. above.  It’s something I’ve been exploring, both through multi-company research and through actual consulting engagements, and can now state unequivocally that Web 2.0 provides an incredibly powerful context through which to design and actualize an IT Operating Model.  But in the next few posts, I’m going to explore each of the three questions.  And, in the interests of collaboration, let me ask a question…

How are you using Web 2.0 approaches to change your IT Operating Model?

Image courtesy of FredCavazza.net

Reblog this post [with Zemanta]

Are You Falling Into the Customer Satisfaction Trap?

Customer Satisfaction is a slippery and potentially dangerously misleading concept!  I was reminded of this when reading an article entitled “Satisfaction vs. Loyalty” by William J. Cusick in the excellent publication, The Conference Board Review.  Cusick argues that customers who complete satisfaction surveys typically respond “satisfied” or “mostly satisfied” regardless of how they really feel.  He goes on to cite a study of people who had recently changed their banks.  In this study, 80% said they had been “satisfied” with their former institution, and yet they still chose to leave!

Why Do We Provide Misleading Customer Feedback?

According to Cusick, “because it’s easier!” How many times, in a restaurant, for example, when the server asks, “Was everything alright?” we respond in the affirmative when, in reality it was not ok, and we intend to never return?  Of course, there is a threshold of service below which we will complain – for some this threshold is lower than for others – but the reality is that we often don’t have the energy or motivation to provide honest feedback.

Poor Instrument Design

How many times have you chosen to fill in a customer feedback form only to abandon it in mid-flight because it’s design does not permit you to give the feedback you’d like to give?  I know that happens to me from time to time – the instrument design is totally inadequate and sometimes actually exacerbates my negative feelings towards the organization.

Lack of Follow-up

I think it is a well-worn and proven fact that a proper response to a customer complaint can help not only recover from a service or product problem, but can actually help build loyalty.  And yet so many companies and organizations fail to acknowledge, let alone respond to customer feedback.  (I will post in a couple of days on my experience with Get Satisfaction and a complaint I made about Bose Quiet Comfort headphones a couple of years ago – a very sad but fascinating story!)

Our Options – Exit, Voice and Loyalty

Providing feedback is subject to an interesting set of dynamics.  Many years ago I read a fascinating book on this called Exit, Voice and Loyalty, by Albert O. Hirschman.  In this book, Hirschman argues that members of an organization have two possible responses when they perceive that the organization is not performing – they can exit (withdraw from the relationship); or, they can voice (attempt to improve the relationship through communication, grievance or proposal for change).  Exit is associated with Adam Smith’s invisible hand of the market. Voice, on the other hand, is political and can be confrontational.  Hirschman explores the dynamics and characteristics of “exit” and “voice,” and the interplay of these choices with “loyalty.”

The book has helped me recognize my responsibility in “voicing” any concerns I have with an organization.  It also reminds me when and why to “exit” a relationship, taking into account my concern for loyalty to that organization.  In the case of flawed customer feedback, the loyalty factor is so low that people can’t be bothered to provide real and useful feedback.  They may, in fact, deliberately withhold feedback feeling that the organization doesn’t even deserve it!

Customer Satisfaction vs. Customer Experience?

Another problem with Customer Satisfaction is that even if feedback is provided, it may not tell you what you really need to know.   A couple of years back I had to make a service call to a software provider.  They used remote access to figure out what was wrong and correct it.  I was asked to complete a follow-up survey that wanted to know if the call had resolved the problem.  It had, but my “Customer Experience” was far less than positive, but they could not have known that from my response to their survey.  The reasons were:

  1. I never should have had the problem with their software in the first place.
  2. In finding and fixing the problem, they made no attempt to help me become self-sufficient in fixing the problem in the future.  I knew this was likely to be a recurring problem (as it subsequently proved to be!) and did not relish the pain and wait times associated with reaching their customer support desk!

I’m sure they recorded me as a satisfied customer, and rewarded their support desk for a job well done.  But in reality, I had a poor customer experience, and would never do business with them again, nor recommend them to my friends.

What Experience Are Your Customer Receiving?

How well are you really surfacing your customer’s satisfaction with your product or service?  How do they feel about their customer experience?

Reblog this post [with Zemanta]

Apple Gets It Right – Again!

I’ve been a long term Windows PC user, from time to time using Macs for various reasons.  I bought my wife an iMac a couple of years ago, and “borrow” her machine when I want to do video editing or any of the music work I need to do as part of my hobby – it just seems so much easier to use and more effective on the Mac.  In my recent semi-retirement state, I felt I had earned to right to a more capable and enjoyable desktop machine than I’d had in a while, so after a relatively short evaluation I bought the latest iMac.  What a great machine, and, as importantly, what a fabulous shopping experience!

The Apple Store  – An Exceptional Customer Experience!

I’ve taken advantage of Apple Stores before (I’ve also taken advantage of Apple’s online store.)  Both channels are clearly superior to those offered by competitors.  I decided to take advantage of Apple’s Personal Shopping service – you book an appointment with an Apple expert for an hour of time in the store.  Booking the appointment was a breeze, handled over the web.

My personal shopper greeted me at the designated time and was knowledgeable, courteous and pretty much everything I had hoped for and expected.  No selling pressure – this was more about determining my needs, and helping me understand what was available.  Given the crowds that typically gather in Apple stores, this is definitely my recommended way to go!  Within the hour I was ready to make my purchase, and 10 minutes later was headed to my car with a very large box!

27 Inch iMac – Be Still, My Heart!

Compared with what I’m used to (16 inch Lenovo laptop), this is one, big mother!  The screen is spectacular!  The machine set up and everything associated with it is exceptional.  The way the pieces are packed and protected, the ease of getting the packing open, the simplicity of getting things set up is superb!  I LOVE the new wireless Magic Mouse – no scroll bar or wheel – it has a multi-touch surface so that you can scroll, swipe and click (yes, both left and right click!) with ease!

Just for chuckles (and to pass some time on a very cold Atlanta Sunday afternoon) I went to my Netflix account and chose a movie for “instant viewing.”  (The 35th Anniversary concert DVD by the progressive rock band Yes.  As an aside, if you are a prog rock fan, this is a superb disk – filmed in Boston, MA in 2004.)

In full screen mode, this proved to be a highly viable way of watching (and renting) a movie.  (In the interests of full disclosure, I do have a relatively high end sound system hooked up, so I did not put the internal speakers to the test.)

Anyway, apart from proving to myself that I can take advantage of Netflix Instant Movies, I’m loving the speed, screen size and quality and all the characteristics of the iMac.  Any I think just about any business can learn from Apple’s approach to design and retailing.  I paid a huge premium for going Apple – and I don’t resent one cent of it!

Reblog this post [with Zemanta]

The Challenge of Sustainable Software

Just about everyone has become attuned over the last few years to the concept of sustainability.  Except, it seems, when it comes to software practices.  In most IT environments, by far the largest chunk of costs associated with a given piece of software, surface after it is initially delivered.  That is true of purchased packages, as well as for custom code.  And yet most organizations don’t properly budget for the total lifecycle costs for a piece of software.  More importantly, neither do they plan and build software for sustainability.  And very few actually plan and budget for the costs of decommissioning a system that is no longer sustainable (either technically or economically) or is no longer needed – until that decommissioning is long overdue!

“We Support the Future!”

This is not a new problem.  Many years ago I was involved with an organization known as the Software Maintenance Association (SMA).  Prior to the so-called Y2k thing a decade ago, the SMA struggled to garner the respect it deserved.  As Y2k loomed, the SMA became a valuable focal point for software remediation practices and tools.  Post Y2k, I have not kept up with the fortunes of the SMA, but I will always remember their slogan – “We Support the Future!” That always struck me as a fresh and compelling way to think about the disciplines and activities associated with keeping software doing what it needs to do.  It also reminds me that much of today’s software practices are focused on the here and now, with relatively little regard for future sustainability.

How to Make Software Sustainable?

Given the complexity behind the issue and in an attempt to increase the value of this blog to its readers, I’m going to approach the topic of software sustainability as an experiment in collaboration.  I will create a series of posts over the next month or so, incorporating as much dialog and discussion as I can surface.  I welcome, as ever, any and all commentary on this blog.  But I will also leverage other means (e.g., social media, personal network) to discover the state of the art and surface leading or promising practices.

I am hopeful that we can generate useful commentary, experiences and shed some helpful light on the topic.  As a starting point, I propose three major categories or ‘lenses’ through which to explore sustainable software practices:

  1. Technical
  2. People
  3. Financial

To help get things kicked off, here’s my initial thinking on these issues.

Sustainable Technical Practices

There is no doubt in my mind that Enterprise Architecture is key here.   My colleague and friend Roy Youngman describes this appropriately as “a means to reduce the cost of change.”

There’s been some very good news here over the last few years.  Standards have emerged that while not being panaceas, can help in bringing a more ‘architected’ approach to software – more ‘plug and play’ as it were.  Service Oriented Architecture (SOA) and derivatives such as Web Oriented Architecture (WOA) have shown significant benefits.  Unfortunately, much of the evidence is anecdotal due to a lack of good software management practices – in particular, good metrics, uniform terminology, enlightened costing models (e.g., activity based costing) and good baseline data.

Ironically, the lack of good  data exacerbates the challenge of building a business case sufficiently robust to drive real change in software practices.  As such, in spite of their promise, these standards are still not commonplace, their adoption impeded by forces such as organizational inertia, lack of an architecture infrastructure with sufficient ‘teeth’ to shape behaviors, and by all the packaged software that organizations increasingly rely on.  These bring their own architectural idiosyncrasies (or lack of architecture!), leading many organizations to have effectively outsourced their architecture – often unwittingly, and almost always, unwisely!

There is other good news in contemporary development methods such as Agile and its Scrum derivative.  Being based on iterative refinement, these inherently create and, to a degree, enforce sustainability into their products – each iteration must, in some respects, ‘anticipate the next iteration.’  Furthermore, Scrum roles such as Product Owner, if well implemented and connected with broader Product Management roles (responsible for total lifecycle costs and value) can bring a great deal to sustainability.

Sustainable People Practices

The challenge here, especially with agile development models, is that the teams run at a relentless pace.  The question is, can people sustain this pace day in, day out?  Does Scrum become a euphemism for ‘heroic efforts’ that leave people sick or with broken families?

I believe the last couple of recessionary years have left IT staff’s depleted, less than fully engaged and with deteriorated organizational talent management practices.  While the pace of technological change continues to increase, most organizations have actually decreased their investment in training and competency development over the last couple of years.

Sustainable Funding

I’ve joked before that a consultant can often score a cheap point by telling a CIO, “Your IT funding model is broken!”  It always is!  Funding models typically evolve over many years, without sufficient consideration as to the desired behaviors they should lead towards.  On top of this built-in dysfunctionality, IT project teams, by way of either reducing “sticker shock” or simply because they’ve not done the analysis, don’t plan and manage in terms of full lifecycle costs.

Let the Sustainable Software Discussion Begin!

So, with those few initial thoughts:

  • How do you see the issues of sustainable software at your organization?
  • What priority does software sustainability have in your organization today?
  • What priority should it have?
  • What successes have you had addressing sustainability of software?

Please comment here, or Tweet me, email me, or whatever!  Let’s figure this out!

Image courtesy of BLDG Blog

Reblog this post [with Zemanta]

We Picked the Wrong Tool!

How many times have you heard, “We picked the wrong tool!” when referring to a project management or portfolio management or just about any other kind of tool for the IT organization?  I’ve heard that many, many times over my 30 year consulting career.  So, it’s time for a couple of uncomfortable truths – expressed as “Merlyn’s Rules of IT Tools”:

  • Merlyn’s Rule #1:  You will always pick the ‘wrong’ tool.
  • Merlyn’s Rule #2:  If you focus on the process being automated or supported, and the management of organizational change, you will probably find you actually have the ‘right’ tool.
  • Merlyn’s Rule #3:  If you focus on the process and management of organizational change and still want a different tool, then switching to a new tool will be trivial.

The Cobbler’s Children

All IT people know the three rules above.  You would never allow technology to be applied to a business process without reengineering the process first.  And yet, when the “customer” is the IT organization, all the conventional and hard-earned wisdom goes out of the window and into the shredder!  I’d like to explore why this is, but frankly, I don’t know.  I guess it is a syndrome that all professions are prone to – hence the ancient proverb.

Image courtesy of USDA Agricultural Research Solution

Reblog this post [with Zemanta]

Selling Enterprise Architecture Through Analogy

I use analogies a lot – in my teaching, consulting, and just about everywhere else!  By no means a panacea, a well chosen analogy can make things “click” for people who might otherwise not “get it.”

“Selling” Enterprise Architecture

I’ve blogged frequently about Enterprise Architecture (and its subset, IT Architecture) because I believe it is a fundamental, literally, foundational discipline for business enablement through IT, and yet is woefully under-served in most organizations.  One reason is – it is tough – balancing competing needs for standardization on the one hand, and innovation on the other.  The other reason is IT architects are often poor  business communicators, and are inept in “selling” the effort necessary to do things in an “architected” way.

Architecture and the New York Subway

My temporary relocation to Manhattan has allowed me to experience the New York subway (and bus) system more fully than ever before – and it makes a great analogy for Enterprise Architecture – or its lack thereof!

New York’s public transport is a gem!  No, it’s not world class (try Singapore’s or the Washington DC Metro system for examples of clean, quiet, fast systems) but it works.  However, I have quickly become aware of many idiosyncrasies of the New York subway.  Certain stations (e.g., 14 Street, 59th Street-Columbus Circle, Borough Hall) where you need to change lines, don’t seem to ‘line up’ properly – you have long underground walks, underground shuttles, or, in some case, have to surface to street level in order to go back down to the different line (these are aptly referred to as “station complexes” and complex they are!)  Some connections between lines that should be simple, aren’t!  It felt to me as if there wasn’t a coherent architecture to the subway system – so I did a little research to find out why.

Three Subway Architectures!

In 1898, the City of Greater New York was formed from several counties and their constituent cities, towns, villages and hamlets.  The City recognized the need for an underground subway system, but also realized that no private company would provide the significant capital required for such an infrastructure.  The City decided to issue rapid transit bonds and contracted with the Interborough Rapid Transit (IRT) to build and run the subways, sharing the profits with the City.  IRT opened the first NY subway in 1904.  Meanwhile, the Brooklyn-Manhattan Transit (BMT) was building and buying up the Brooklyn elevated rail lines.

In 1913, the city embarked on a “Dual Contracts” initiative, engaging the private IRT and BMT to expand their systems.  By the 1930’s, the City realized that the independent IRT and BMT were making handsome profits, so the City of New York created its own third system, the Independent Subway System (IND).  The IND introduced yet a third architecture, so that the IND, IRT and BMT were competing with each other.

The Challenge of Integration

This competition led to overlapping services and different standards (such as carriage width, carriage length, train stop safety mechanisms).  In 1940, the City took over the transportation assets of the BMT and IRT under a program called Unification.  However, to this day, due to different tunnel diameters, curves and clearances and the different rolling stock, asset utilization is sub-optimal, and for passengers, navigating the subway system can be challenging and inefficient.  To eliminate overlapping and redundant services, certain stations and even some tunnels had to be closed.  Also, costly “interfaces” had to be built between the three separate systems in the forms of tunnels, walkways and shuttles.

If New York City Were a Business?

Imagine the City of New York as a business, and the IRT, BMT and IND as separate divisions.  Imagine that each division wants to create its own IT organization and IT capabilities.  Imagine there is no overarching architecture or standards.  Now imagine, as a business you recognize the synergies between your three divisions, and want to integrate and leverage as many shared services as possible.  What do you find?

  1. It’s incredibly costly to achieve integration because your three IT infrastructures are incompatible.
  2. You discover you have excessive redundancy across the three IT infrastructures.
  3. The cost of keeping the IT infrastructures running is eating into your operating margin, and yet the capital cost of rationalizing the infrastructures is prohibitive.
  4. With eCommerce and Enterprise 2.0 possibilities, you need to collaborate more effectively across divisions than you do currently, but none of the three IT infrastructures will support that type of collaboration.
  5. You ask your CIO, “How could you let this happen?” as you look for a replacement!
  6. Your CIO points to the chief IT architect and blames him for doing an inadequate job of convincing the IRT, BMT and IND divisions of the need for an overarching architecture.
  7. Your chief architect commits suicide (by jumping in front of a subway train?)

The Value of Enterprise Architecture

So, what were the costs of the lack of a unifying architecture to the NY Subway system?  Had the IRT, BMT and IND followed an overall architecture and set of standards, how much time and money would have been saved compared with the “each go it alone” approach?  That is the value of architecture.

What analogies can you use that will resonate with your senior business executives to sell them on the value of Enterprise Architecture?

The Downside of Standardizing Too Soon

In all fairness, I must reference the fact that choosing standards too soon can and does stifle innovation.  The beginnings of the New York Subway occurred while there was a fierce competition between Nikola Tesla’s Alternating Current (AC) and Thomas Edison’s Direct Current (DC) systems.  DC won out (for good reasons at the time) but modern solid state technology and advances in electric motor and switching technology mean that AC would have led to a simpler, more flexible and less costly subway system construction.

Image courtesy of Blog Them Out Of The Stone Age

Reblog this post [with Zemanta]

Deming’s 14 Points Revisited: Part 10

This post picks up on Parts 1 to 9 and examines the ninth of Deming’s 14 Management Points, which urges:

Break down barriers between departments. People in research, design, sales, and production must work as a team, to foresee problems of production and in use that may be encountered with the product or service.

I’ve posted before on organizational silos (see Bustin’ Silos with the Role Bomb!), the inefficiencies they introduce and how silos tend to dampen the magic of innovation and collaboration.  “If only the left hand knew what the right hand was doing” is a familiar cry of woe!

The Promise of Business Process Reengineering

Deming’s 9th Point in many ways foreshadows the Business Process Reengineering (BPR) movement of the 1990’s with its end-to-end business processes (e.g., order-to-cash, hire-to-retire) and process management discipline cutting across traditional organizational boundaries.  BPR almost always leveraged information technology to gain efficiencies in terms of speed and resources – sometimes in innovative ways, often shifting work to the customer.

Unfortunately, in spite of the promise, there were quite a number of horrible BPR failures, especially in the early 1990’s.  Many early failures were associated with the so-called Enterprise Resource Planning (ERP) monster software packages that often accompanies BPR efforts.  But, there have also been some spectacular successes and ERP together with at least some form of process management are invariably at the heart of them.

Matrix Management

Process Management led organizations (that were not already there) towards the discipline of matrix management.  For some organizations, having more than two “bosses” (over-simplifying the situation enormously) represents too great a culture shift.  As such, the inertia associated with traditional hierarchies, silo behaviors and limited collaboration tends to overwhelm moves towards cross-departmental or cross-geographical boundaries.   Some companies (J&J comes to mind) seem to manage really well with complex operating company and market structures.  For them, matrix management, while never without its frustrations as with any management system, works well and is effective.  They have established the tools and disciplines to ensure clear lines of accountability together with a reasonably entrepreneurial spirit.

Is Collaboration a Tool to Break Down Departmental Barriers?

Web 2.0 promises to take collaboration to new levels – both within the organization and across its ecosystem. The conundrum, however, is:

  • Web 2.0 tools and technologies can help break down organizational boundaries
  • Organizational silos inhibit the institutionalization of collaborative behaviors

In other words, organizations that are already collaborating well across organizational boundaries are better positioned to exploit Web 2.0 than those with strong organizational silos.  I believe some proficiency with matrix management is necessary for success with cross-enterprise collaboration.  Given that, and with a thoughtful deployment of Web 2.0 tools with clarity of the strategic intents for the collaboration initiative, I believe Dr. Deming would be delighted to see the possibilities inherent in the world of Web 2.0, and its potential for “breaking down barriers.”

Reblog this post [with Zemanta]

Deming’s 14 Points Revisited: Part 9

This post picks up on Parts 1 to 8 and examines the eighth  of Deming’s 14 Management Points, which urges:

Drive out fear, so that everyone may work effectively for the company.

Fear and Social Networking

From my consulting experience (and, I regret to say, from some of my experience as an employee) fear can be a very real issue in organizations – inhibiting people’s willingness to try new things, to speak out when they see inefficient practices or broken processes, to challenge dumb decisions by management, and so on.  Fear also limits people’s engagement in their work (their willingness to give their discretionary effort).  And, in an age of emerging Enterprise 2.0 – with its dependence upon internal and external social networking, fear can be a major impediment to progress in learning and developing new ways of working, innovating products and services, and better connecting stakeholders.

Today’s climate of high unemployment and the threat of “downsizing” on the horizon, fear in many organizations is on the uptick.  Fear mobilizes the body’s “fight or flight” mechanism, leading to either defensive behavior (hiding, submissive, low engagement) or aggressive (even destructive) behavior.  I sometimes see the variant of passive-aggressive behavior, where, for example, people agree to a decision, then work the back channels to sabotage it!

So, to what degree is fear inhibiting your organization’s efficiency and effectiveness?  What is the source of that fear?  What can be done to eliminate or at least, reduce fear in the workplace?

Fear and Trust

Fear is the opposite of trust. Trust is important for high performing organizations because it leads to synergy and performance. As organizations begin to enter the Enterprise 2.0 realm, fear and trust become even more important.

Author and management consultant Charles Handy, notes that, “If we are to enjoy the efficiencies and other benefits of the virtual organization, we will have to rediscover how to run organizations based more on trust than on control. Virtuality requires trust to make it work: Technology on its own is not enough”.

Driving Out Fear

Corporate coach Jan Austin in her excellent blog post FEAR IN THE WORKPLACE: SYMPTOMS, SOURCES, SOLUTIONS, suggests that:

Eliminating fear begins with leaders acknowledging their own responsibility for creating and/or participating in a fear-driven organizational culture. By examining their assumptions and behaviors which have either triggered or perpetuated defensive, fearful responses in others, and consciously choosing to communicate in a more positive, proactive manner, they can interrupt the patterns of fear and the associated defensive routines in the organization. Leaders can take a number of steps to engage organizational constituents in more open, collaborative conversations and encourage greater positive participation in the work of the organization. Leaders can do this by employing simple but powerful facilitation skills.

Jan goes on to suggest techniques four key strategies for leaders, comprising:

  1. Establishing Rapport
  2. Improving Listening Skills
  3. Asking Questions Which Increase Trust and Reduce Fear
  4. Promoting Dialogue

Check out Jan’s post.  How many of these strategies and the techniques she suggests might help your organization become a less fearful and more collaborative place?

 

Image courtesy of The Vancouver Sun

Reblog this post [with Zemanta]