archive.Joe Lamantia.com

The culture, structure, and workings of an organization often pose greater challenges for User Experience practitioners than any technical or design questions at hand. If you’d like to know more about the factors behind these situations, be sure to check out We Tried To Warn You: The Organizational Architecture of Failure, by Peter Jones, just published by Boxes and Arrows.

Peter is an independent consultant with deep expertise in research, product design, and strategy. His talk for the panel on failure at the 2007 IA Summit was insightful and in-depth, and this two-part series offers quite a bit more very useful material on the roots and warning signs of organizational failure (by comparison, consider the very brief post I put up on the same subject a few years ago.)

Peter’s is the second written feature to come out of the failure panel (my missive on the parallels between entrepreneurial and societal failure was the first). I’m looking forward to part two of We Tried To Warn You, as well as additional features from the remaining two panelists, Christian Crumlish and Lorelei Brown!

Here’s a snippet, to whet your appetite:

How do we even know when an organization fails? What are the differences between a major product failure (involving function or adoption) and a business failure that threatens the organization? An organizational-level failure is a recognizable event, one which typically follows a series of antecedent events or decisions that led to the large-scale breakdown. My working definition: When significant initiatives critical to business strategy fail to meet their highest-priority stated goals.”

Boxes and Arrows has published part 3 of the Building Blocks series, describing the Container blocks in detail. Next in the series is part 4, which describes the Connectors in the building block system in detail.

If you’re working on a portal, dashboard, or tile based design effort of any kind, the building blocks readily serve as a common language and structural reference point that allows effective project communication across traditional discipline boundaries. These two articles in tandem (parts 3 and 4) provide details on how the Building Blocks can provide a strong, flexible, and scalable usr experience and information architecture framework for the long term.

My current plan is to release a toolkit at approximately the same time as part 4 of the series. Part 4 is in the editing stage now, so this a good time to ask readers for suggestions on what should be part of the toolkit, and what form it should take. Suggestions?

Boxes and Arrows just published part two of the Portal Building Blocks series – Introduction to the Building Blocks. This second installment covers the design concepts behind the portal building blocks system, and guidelines on how to flexibly combine the blocks into a well-structured user experience.

If you are working on a portal, dashboard, widget, social media platform, web-based desktop, or any tile-based design, this series should help clarify the growth and usability challenges you will encounter, as well as provide a possible solution, in the form of a simple design framework that is platform and vendor neutral.

Stay tuned for the third installment in the series, due out shortly!

For those in the enterprise IA / UX space, The next frontier in IT strategy: A McKinsey Survey centered on the idea that “…IT strategy is maturing from a reactive to a proactive stance”is worth a look.

This nicely parallels a point made about the reactive mindset common to IT in many large organizations, in discussion on the IAI mailing list last month. Lou Rosenfeld’s post Information architects on communicating to IT managers, summarizes the original discussion in the IAI thread, and is worth reading as a companion piece.

Lou’s summary of information architecture and user experience voices in the enterprise arena is noteworthy for including many examples of strong correspondence between McKinsey’s understanding of how IT strategy will mature (a traditional management consulting view), and the collected IA / UX viewpoints on addressing IT leadership – typical buyers for enterprise anything – and innovation.

Dialogs that show convergence of understanding like this serve as positive signs for the future. At present, a large set of deeply rooted cultural assumptions (at their best inaccurate, usually reductive, sometimes even damaging) about the roles of IT, business, and design combine with the historical legacies of corporate structures to needlessly limit what’s possible for User Experience and IA in the enterprise landscape. In practical terms, I’m thinking of those limitations as barriers to the strategy table; constraining who can talk to who, and about which important topics, such as how to spend money, and where the business should go.
Considering the gulf that separated UX and IT viewpoints ten – or even five – years ago, this kind of emerging common understanding is a good sign that the cultural obstacles to a holistic view of the modern enterprise are waning. We know that a holistic view will rely on deep understanding of the user experience aspects of business at all levels to support innovation in products and services. I’m hoping the rest of the players come to understand this soon.

Another good sign is that CIO’s have won a seat at the strategy table, after consistent effort:

Further evidence of IT’s collaborative role in shaping business strategy is the fact that so many CIOs now have a seat at the table with senior management. They report to the CEO in 44 percent of all cases; an additional 42 percent report to either the chief operating officer or the chief financial officer.

Looking ahead, information architecture and user experience viewpoints and practitioners should work toward a similar growth path. We fill a critical and missing strategic role that other traditional viewpoints are not as well positioned to supply.

Quoting McKinsey again:

IT strategy in most companies has not yet reached its full potential, which in our experience involves exploiting innovation to drive constant improvement in the operations of a business and to give it a real advantage over competitors with new products and capabilities. Fewer than two-thirds of the survey respondents say that technological innovation shapes their strategy. Only 43 percent say they are either very or extremely effective at identifying areas where IT can add the most value.

User Experience can and should have a leading voice in setting the agenda for innovation, and shaping understandings of where IT and other groups can add the most value in the enterprise. To this end, I’ll quote Peter Merholz (with apologies for not asking in advance):

“…we’ve reached a point where we’ve maximized efficiency until we can’t maximize no more, and that in order to realize new top-line value, we need to innovate… And right now, innovations are coming from engaging with the experiences people want to have and satisfying *that*.”

McKinsey isn’t making the connection between strategic user experience perspectives and innovation – at least not yet. That’s most likely a consequence of the fact that management consulting firms base their own ways of thinking, organizational models, and product offerings (services, intellectual property, etc.) on addressing buyers who are themselves deeply entrenched in traditional corporate structures and worldviews. And in those worlds, everything is far from miscellaneous, as a glance at the category options available demonstrates; your menu here includes Corporate Finance, Information Technology, Marketing, Operations, Strategy…

BTW: if you weren’t convinced already, this should demonstrate the value of the $40 IAI annual membership fee, or of simply reading Bloug, which is free, over paying for subscriptions to management journals

Mark Blumenthal, of Pollster.com, recently posted a set of text clouds showing the words used by each candidate in the Democratic presidential debate Thursday night. The clouds were generated from transcripts of the debate, using Daniel Steinbock’s Tag Crowd tool.

Candidates’ Text Clouds

In the screenshot of Mark’s posting, it’s easy to see this is a great example of a collection of text clouds used for comparative visualization and interpretation. The goal is to enhance understanding of the meaning and content of the candidate’s overall conversations during the debate, an idea I explored briefly last year.

Just a month ago, in a post that identified text clouds as a new and distinct tag cloud variant, I suggested:

text clouds may become a generally applied tool for managing growing information overload by using automated synthesis and summarization. In the information saturated future (or the information saturated present), text clouds are the common executive summary on steroids

Supporting the comparison and interpretation of political speeches is an inventive, timely, and resourceful application that could make text clouds a regular part of the new personal and professional toolkit for effectively handling the torrents of information overwhelming people in important situations like vetting political candidates.

I especially like the way this use of text clouds helps neatly sidestep the disheartening ubiquity of the soundbite, by aggregating, distilling, and summarizing all the things the candidates said. I suspect few – if any – of the campaigns realize the potential for text clouds, but they definitely know the detrimental power of soundbites:

“It’s a mess,” said an exasperated-sounding Mr. Prince, Mr. Edwards’s deputy campaign manager. “Debates are important, but in these big multicandidate races they end up not being an exchange of ideas, but just an exchange of sound bites. They have become a distraction.”

From Debates Losing a Bit of Luster in a Big Field

The value of a collection of soundbites over an insightful dialog is – apologies for the pun – debatable. But even if a simple exchange of soundbites is what the new shortened formats of many debates yields us, text clouds may help derive some value and insight from the results. The combined deconstructive and reconstructive approach that text clouds employ should make it possible to balance the weight of single remarks of candidates by placing them in a larger and more useful context.

History Repeats Itself

In the longer term view of the history of our responses to the problems of information overload, the appearance of text clouds may mark the emergence of a new general puprose tool for visualizing ever greater quantities of information to support some qualitatively beneficial end (like picking a good candidate for President, which we sorely need).

The underlying pattern – a consistent oscillation between managing effectively and ineffectively coping, depending on the balance between information quantity and tool quality – remains the same. Yet there is also value in knowing the cycles that shape our experience of handling the information crucial to making decisions, especially decisions as important as who leads the country.

The NY Times transcript of the debate is available here.

Con­tent man­age­ment efforts are justly infa­mous for exceed­ing bud­gets and time­lines, despite mak­ing con­sid­er­able accom­plish­ments. Exag­ger­ated expec­ta­tions for tool capa­bil­i­ties (ven­dors promise a world of automagic sim­plic­ity, but don’t believe the hype) and the poten­tial value of cost and effi­ciency improve­ments from man­ag­ing con­tent cre­ation and dis­tri­b­u­tion play a sub­stan­tial part in this. But unre­al­is­tic esti­mates of the scope of the con­tent to be man­aged make a more impor­tant con­tri­bu­tion to most cost and time over­runs.

Scope in this sense is a com­bi­na­tion of the quan­tity and the qual­ity of con­tent; smaller amounts of very com­plex con­tent sub­stan­tially increase the over­all scope of needs a CM solu­tion must man­age effec­tively. By anal­ogy, imag­ine build­ing an assem­bly line for toy cars, then decid­ing it has to han­dle the assem­bly of just a few full size auto­mo­biles at the same time.

Early and inac­cu­rate esti­mates of con­tent scope have a cas­cad­ing effect, decreas­ing the accu­racy of bud­gets, time­lines, and resource fore­casts for all the activ­i­ties that fol­low.

In a typ­i­cal con­tent man­age­ment engage­ment, the activ­i­ties affected include:

• tak­ing a con­tent inventory
• defin­ing con­tent models
• choos­ing a new con­tent man­age­ment system
• design­ing con­tent struc­tures, work­flows, and metadata
• migrat­ing con­tent from one sys­tem to another
• refresh­ing and updat­ing content
• estab­lish­ing sound gov­er­nance mechanisms

The Root of the Prob­lem
Two mis­con­cep­tions — and two com­mon but unhealthy prac­tices, dis­cussed below — drive most con­tent scope esti­mates. First: the scope of con­tent is know­able in advance. Sec­ond, and more mis­lead­ing, scope remains fixed once defined. Nei­ther of these assump­tions is valid: iden­ti­fy­ing the scope of con­tent with accu­racy is unlikely with­out a com­pre­hen­sive audit, and con­tent scope (ini­tial, revised, actual) changes con­sid­er­ably over the course of the CM effort.

Together, these assump­tions make it very dif­fi­cult for pro­gram direc­tors, project man­agers, and busi­ness spon­sors to set accu­rate and detailed bud­get and time­line expec­ta­tions. The uncer­tain or shift­ing scope of most CM efforts con­flicts directly with busi­ness imper­a­tives to care­fully man­age of IT cap­i­tal invest­ment and spend­ing, a neces­sity in most fund­ing processes, and espe­cially at the enter­prise level. Instead of esti­mat­ing spe­cific num­bers long in advance of real­ity (as with the Iraq war bud­get), a bet­ter approach is to embrace flu­id­ity, and plan to refine scope esti­mates at punc­tu­ated inter­vals, accord­ing to the nat­ural cycle of con­tent scope change.

Under­stand­ing the Con­tent Scope Cycle
Con­tent scope changes accord­ing to a pre­dictable cycle that is largely inde­pen­dent of the specifics of a project, sys­tem, orga­ni­za­tional set­ting, and scale. This cycle seems con­sis­tent at the level of local CM efforts for a sin­gle busi­ness unit or iso­lated process, and at the level of enter­prise scale con­tent man­age­ment efforts. Under­stand­ing the cycle makes it pos­si­ble to pre­pare for shifts in a qual­i­ta­tive sense, account­ing for the kind of vari­a­tion to expect while plan­ning and set­ting expec­ta­tions with stake­hold­ers, solu­tion users, spon­sors, and con­sumers of the man­aged con­tent.

The Con­tent Scope Cycle

The high peak and ele­vated moun­tain val­ley shape in this illus­tra­tion tell the story of scope changes through the course of most con­tent man­age­ment efforts. From the ini­tial inac­cu­rate esti­mate, scope climbs con­sis­tently and steeply dur­ing the dis­cov­ery phase, peak­ing in poten­tial after all dis­cov­ery activ­i­ties con­clude. Scope then declines quickly, but not to the orig­i­nal level, as assess­ments cull unneeded con­tent. Scope lev­els out dur­ing sys­tem / solu­tion / infra­struc­ture cre­ation, and climbs mod­estly dur­ing revi­sion and replace­ment activ­i­ties. At this point, the actual scope is known. Mea­sured increases dri­ven by the incor­po­ra­tion of sup­ple­men­tal mate­r­ial then increase scope in stages.

Local and Enter­prise Cycles

Apply­ing the context-independent view of the cycle to a local level reveals a close match with the activ­i­ties and mile­stones for a con­tent man­age­ment effort for a small body of con­tent, a sin­gle busi­ness unit of a larger orga­ni­za­tion, or a self-contained busi­ness process.

Local Con­tent Man­age­ment Scope Cycle

At the enter­prise level, the cycle is the same. This illus­tra­tion shows activ­i­ties and mile­stones for a con­tent man­age­ment effort for a large and diverse body of con­tent, mul­ti­ple busi­ness units of a larger orga­ni­za­tion, or mul­ti­ple and inter­con­nected busi­ness process.

Enter­prise Con­tent Man­age­ment Scope Cycle

Scope Cycle Changes

This graph shows the amount of scope change at each mile­stone, ver­sus its pre­de­ces­sor. Look­ing at the changes for any pat­terns of clus­ter­ing and fre­quency, it’s easy to see the cycle breaks down into three major phases: an ini­tial period of dynamic insta­bil­ity, a sta­tic and sta­ble phase, and a con­clud­ing (and ongo­ing, if the effort is suc­cess­ful) phase of dynamic sta­bil­ity.

Scope Cycle Phases

Where does the extra scope come from? In other words, what’s the source of the unex­pected quan­tity and com­plex­ity of con­tent behind the spikes and drops in expected scope in the first two phases? And why dri­ves the shifts from one phase to another?

Bad CM Habits

Two com­mon approaches account for a major­ity of the dra­matic shifts in con­tent scope. Most sig­nif­i­cantly, those peo­ple with imme­di­ate knowl­edge of the con­tent quan­tity and com­plex­ity rarely have direct voice in set­ting the scope and time­line expec­ta­tions.

Too often, stake hold­ers with exper­tise in other areas (IT, enter­prise archi­tec­ture, appli­ca­tion devel­op­ment) frame the prob­lem and the solu­tion far in advance. The con­tent cre­ators, pub­lish­ers, dis­trib­u­tors, and con­sumers are not involved early enough.
Sec­ondly, those who frame the prob­lem make assump­tions about quan­tity and com­plex­ity that trend low. (This is in com­pan­ion to the exag­ger­a­tion of tool capa­bil­i­ties.) Each new busi­ness unit, con­tent owner, and sys­tem administrator’s items included in the effort will increase the scope of the con­tent in quan­tity, com­plex­ity, or both. Ongo­ing iden­ti­fi­ca­tion of new or unknown types of con­tent, work flows, busi­ness rules, usage con­texts, stor­age modes, appli­ca­tions, for­mats, syn­di­ca­tion instances, sys­tems, and repos­i­to­ries will con­tinue to increase the scope until all rel­e­vant par­ties (cre­ators, con­sumers, admin­is­tra­tors, etc.) are engaged, and their needs and con­tent col­lec­tions fully under­stood.
The result is clear: a series of sub­stan­tial scope errors of both under and over-estimatio, in com­par­i­son to the actual scope, con­cen­trated in the first phase of the scope cycle.
Scope Errors

Smart Scop­ing
The scope cycle seems to be a fun­da­men­tal pat­tern; likely an emer­gent aspect of the envi­ron­ments and sys­tems under­ly­ing it, but that’s another dis­cus­sion entirely. Fail­ing to allow for the nat­ural changes in scope over the course of a con­tent man­age­ment effort ties your suc­cess to inac­cu­rate esti­mates, and this false expec­ta­tions.
Smart scop­ing means allow­ing for and antic­i­pat­ing the inher­ent mar­gins of error when set­ting expec­ta­tions and mak­ing esti­mates. The most straight­for­ward way to put this into prac­tice and account for the likely mar­gins of error is to adjust the tim­ing of a scope esti­mate to the nec­es­sary level of accu­racy.

Rel­a­tive Scope Esti­mate Accu­racy

Scop­ing and Bud­get­ing
Esti­ma­tion prac­tices that respond to the con­tent scope cycle can still sat­isfy busi­ness needs. At the enter­prise CM level, IT spend­ing plans and invest­ment frame­works (often part of enter­prise archi­tec­ture plan­ning processes) should allow for nat­ural cycles by defin­ing classes or kinds of esti­mates based on com­par­a­tive degree of accu­racy, and the estimator’s lee­way for meet­ing or exceed­ing implied com­mit­ments. Enter­prise frame­works will iden­tify when more or less accu­rate esti­mates are needed to move through fund­ing and approval gate­ways, based on each organization’s invest­ment prac­tices.

And at the local CM level, project plan­ning and resource fore­cast­ing meth­ods should allow for incre­men­tal allo­ca­tion of resources to meet task and activ­ity needs. Tak­ing a con­tent inven­tory is a sub­stan­tial labor on its own, for exam­ple. The same is true of migrat­ing a body of con­tent from one or more sources to a new CM solu­tion that incor­po­rates changed con­tent struc­tures such as work flows and infor­ma­tion archi­tec­tures. The archi­tec­tural, tech­ni­cal, and orga­ni­za­tional capa­bil­i­ties and staff needed for inven­to­ry­ing and migrat­ing con­tent can often be met by rely­ing on con­tent own­ers and stake hold­ers, or hir­ing con­trac­tors for short and medium-term assis­tance.

Par­al­lels To CM Spend­ing Pat­terns
The con­tent scope cycle strongly par­al­lels the spend­ing pat­terns dur­ing CMS imple­men­ta­tion James Robert­son iden­ti­fied in June of 2005. I think the scope cycle cor­re­lates with the spend­ing pat­tern James found, and it may even be a dri­ving fac­tor.
Scop­ing and Matu­rity

Unre­al­is­tic scope esti­ma­tion that does not take the con­tent scope cycle into account is typ­i­cal of orga­ni­za­tions under­tak­ing a first con­tent man­age­ment effort. It is also com­mon in orga­ni­za­tions with con­tent man­age­ment expe­ri­ence, but low lev­els of con­tent man­age­ment matu­rity.

Two (infor­mal) sur­veys of CMS prac­ti­tion­ers span­ning the past three years show the preva­lence of scop­ing prob­lems. In 2004, Vic­tor Lom­bardi reported: “Of all tasks in a con­tent man­age­ment project, the cre­ation, edit­ing, and migra­tion of con­tent are prob­a­bly the most fre­quently under­es­ti­mated on the project plan.” [in Man­ag­ing the Com­plex­ity of Con­tent Man­age­ment].

And two weeks ago, Rita War­ren of CMSWire shared the results of a recent sur­vey on chal­lenges in con­tent man­age­ment (Things That Go Bump In Your CMS).

The top 5 chal­lenges (most often ranked #1) were:

1. Clar­i­fy­ing busi­ness goals
2. Gain­ing and main­tain­ing exec­u­tive support
3. Redesigning/optimizing busi­ness processes
4. Gain­ing con­sen­sus among stakeholders
5. Prop­erly scop­ing the project

…“Prop­erly scop­ing the project” was actu­ally the most pop­u­lar answer, show­ing up in the top 5 most often.

Accu­rate scop­ing is much eas­ier for orga­ni­za­tions with high lev­els of con­tent man­age­ment matu­rity. As the error mar­gins inher­ent in early and inac­cu­rate scope esti­mates demon­strate, there is con­sid­er­able ben­e­fit in cre­at­ing mech­a­nisms and tools for effec­tively under­stand­ing the quan­tity and qual­ity of con­tent requir­ing man­age­ment, as well as the larger busi­ness con­text, solu­tion gov­er­nance, and orga­ni­za­tional cul­ture concerns.

Mergers and acquisitions activity in 2006 reached record levels, and it’s likely that the pace will increase in 2007.
In the midst of the epic deal-making, companies should look beyond immediate benefits for shareholders and executives, and pay very close attention to the impact of mergers (and other major organizational shifts) on customer experiences. Why? Because acquired customers are easily lost.

Mergers and acquisitions create transition points, moments when avoidable customer experience mistakes sour once strong relationships with loyal customers of an acquired company, and they depart permanently. This is doubly unfortunate: the right customer experience can bridge old and new for acquired customers, and provide reassuring continuity during times of substantial flux in areas such as brands and identities, corporate cultures, organizational structures, supporting enterprise architectures and systems , even customer service procedures.

Well-managed customer experiences offer two kinds of specific benefits. The first benefit is an unexpected (and thus more powerful) refutation of established wisdom from across industries that defines post-merger service expectations as bad. Consider these two examples:

From If more US airlines merge, who would benefit?:
Aviation analysts like Kevin Mitchell of the Business Travel Coalition in Radnor, Pa. … argues that a flurry of mergers right now would raise prices, overcrowd already-packed planes, and create chaos for customer service for years to come precisely because it is so difficult to merge aviation corporate cultures.”

Of course, Wall Street is going to push it,” he says. “What’s good for investors, shareholders, and management may not be good for others: Lots of employees will be laid off, and customers can look forward to 20 to 30 percent price hikes and several years of customer-service [misery].”

And this from FCC clears AT&T merger:

Natalie Billingsley, a supervisor with the California Public Utilities Commission’s Division of Ratepayer Advocates, which advocates for consumer interests, said the new concessions improved the outlook for AT&T and BellSouth customers. But she said consumers would have been better off if the merger had not been approved and expressed skepticism that customer service would improve.
“You hope that service will improve, but it hasn’t been seen with prior mergers,” she said.

The second benefit is balancing the service disruptions common to post-merger integration (sometimes collision is the better word) efforts with a positive experience oriented toward the longer term. This is especially important for acquired customers, who lack examples of how the acquiring company handles customer relationships, and need surety regarding it’s intentions.

Enterprise business process, information architecture, and technology integrations (your SAP or mine…) are notably prone to conflicts that can disrupt customer experiences in dramatic and unexpected ways. Much of the disruption is easily managed in advance by communicating upcoming changes to customers. The rest is best handled by the customer experience equivalent of the detour. While the details may prove complex behind the scenes, the basic idea is very simple: tell acquired customers that things used to work one way, explain that they now work another, then show them how, and support them through the required changes.

Because the idea is so simple, organizations that fail to anticipate and respond to customer experience disruptions during integration efforts neglect the basics of building sound relationships with acquired customers. Neglecting acquired customers from the beginning is a good indicator that the new organization places low value on customer relationships in general. With bad experiences during botched transitions, customer satisfaction declines, relationships sour, and loyal customers leave.

Snapshot of a Disrupted Experience
AmericanBank recently acquired MegaBank, and integrated the two companies’ on-line banking tools. These tools served credit card customers, in addition to banking customers. But since neither MegaBank nor AmericanBank communicated information or plans about the merger (no detour…) to MegaBank credit card customers, the stream of personally addressed emails issued from mysterious sources inside AmericanBank looked exactly like a credit card fraud spam broadcast designed to snare the unwary.
Following the email broadcasts, AmericanBank abruptly redirected traffic from the MegaBank account portal to the AmericanBank website, without notifying MegaBank customers of the switch, thereby mimicking another common tactic in fraud efforts – the decoy log-in screen intended to extract user IDs and passwords from unsuspecting visitors, who do not recognize the difference between the legitimate and fake log-in gateways.

More disruptive for MegaBank customers was AmericanBank’s decision to erase their log-in names and then create new user names in those cases where MegaBank log-ins happened to duplicate those of existing Bank of America customers, effectively displacing them. This particular change would have been troublesome with adequate communication, since user names and passwords present extensive usability and memory challenges, but again AmericanBank failed to notify MegaBank customers of the changes.
As icing on the cake, AmericanBank created new passwords for MegaBank credit card customers as well, again without notification. The combination of new log-ins and new passwords made it impossible for MegaBank credit card customers to access any of AmericanBank’s on-line account management functions.

MegaBank customers trying to use their normal on-line account management tools experienced this series of integration steps as spam broadcasts, hijacked navigation, recognition failure, displacement, and a password recovery loop leading to account lock-out. The only way to sort it out and regain access was a laborious staged phone call that revealed the regular to customer service channels couldn’t handle on-line access problems.

In the end, MegaBank customers incurred direct costs in the form of service charges to make payments by phone while locked out of the on-line system, late fees for missing payments while sorting out the account access issues, and punitive interest rate raises based on automated application of contract rules triggered by late payments. The complete reckoning includes additional indirect costs in the form of frustration, confusion, wasted time, and the effort required to find a substitute credit card servicer.

All in all, the customer experience of the AmericanBank and MegaBank integration provided clear signs of:

• misaligned business structures
• mismanaged integration
• an unbalanced short term outlook
• poor relationship management
• punishing customers for bad business decisions

From the perspective of an acquired customer, it’s easy to recognize these as symptoms of internal ill health, manifest as indifference or ill will toward customers. Which equates to strong incentive to leave in 2006, and not return in 2007.

I’ve created a suggested (and highly original) tag for bookmarking items related to the building blocks:

ia_building_blocks

I’ve tagged a few items on del.icio.us – my default bookmarking service – and will monitor tag streams from some of the other bookmarking services.
http://del.icio.us/tag/ia_building_blocks

I’m presenting for the Taxonomy Community of Practice web seminar today. I’ll be talking about a long-term, enterprise-level strategy and design engagement for a financial services client, sharing work that combines information architecture and taxonomy efforts over the past year.

The agenda for the call includes several other speakers; it should be a strong showcase of information architecture and taxonomy work from different settings.

If you’d like to listen, some details are below. Registration and more information is available from www.earley.com/events.htm

Date and time: Friday, December 1st, 2006 – 2:00 to 3:30 PM EDT

Duration: 90 minutes

Format: Teleconference

Cost: $50 per attendee

Register for the session (you will receive dial-in instructions and slides the day before the call)

Description:
User Experience design is often thought of as distinct or different from taxonomy design. What are good IA practices and how do they influence taxonomy design? In this session you’ll hear from three experienced IA’s who will share specific examples from their organizations and consulting projects that will illustrate principles that you can apply in your taxonomy projects.

In this session, hear about:

• a user experience design effort that combines information architecture and taxonomy approaches for a major financial services client
• specific experiences applying IA with Compaq and HP and “business taxonomies” – taxonomies that live within strict business limitations

Presenters:
Seth Earley, Earley & Associates

Joe Lamantia

Bob Goodman

Andrew Gent, Hewlitt Packard

IBM recently announced the next version of Lotus Notes will support OpenDocument Format as a native file format (as reported in IBM Bets Big On Open Source In Next Release Of Lotus Notes). This shift to an open file format is – as the majority of the coverage of IBM’s announcement correctly interprets it to be – a direct challenge to the dominance of the Office suite of productivity applications, a class of products in which Microsoft has long relied on proprietary file formats as a cornerstone of it’s market control strategy. Making the challenge explicit, the next version of Lotus Notes will also include “…built-in word processing, spreadsheet, and presentation graphics software”.

Since Microsoft relies on the integration of SharePoint and the Office suite as a pillar of it’s collaboration plans (in Gates outlines SharePoint strategy, hammers IBM, John Fontana of Network World quotes Bill Gates as saying, “The key point is that SharePoint is becoming the key platform for collaboration of all types… When people look back on what we are doing with Office [2007] here, the most revolutionary element will be what we are doing with SharePoint.”), IBM’s shift to OpenDocument Format is also a strategic move in the larger category of enterprise collaboration, itself a subset of the emerging comprehensive information working environments Forrester Research calls the information workplace.

An End to Imperialism
I’ve suggested already that the conceptual construct labeled ‘collaboration’ is at heart another instance of enterprise software and solution vendor marketing rhetoric designed to mask reality – it’s simply not possible to change established cultural, organizational, perceptual, or philosophical understandings of what work is and how it should be done with an approach centered on technology – in a quasi-utopian haze.

IBM’s adoption of OpenDocument doesn’t change this picture of the collaboration landscape. Instead, it indicates a larger shift; dawning recognition and acknowledgment that monocultures are no longer viable, or valid, or broadly acceptable in the enterprise arena.

The creation and preservation of monocultures (recently in the news associated with Microsoft thanks to Dan Greer and others’ prescience) is one of the salient characteristics of the old approach to enterprise software solutions. It is especially visible in those enterprise solutions whose intended role within a portfolio of product and service offerings is to serve as a consistent revenue source, strategic bulwark against competition, and cost shifting mechanism whereby clients paid for the development of new products and services, often under the guise of maintenance, patches, upgrades, etc.

Broadly, the old approach to enterprise solutions was an imperial model, with aspects of colonialism, that pursued a military style take and hold growth pattern.

Wikipedia offers the following introduction to imperialism:
“Imperialism is a policy of extending control or authority over foreign entities as a means of acquisition and/or maintenance of empires. This is either through direct territorial conquest or settlement, or through indirect methods of exerting control on the politics and/or economy of other countries. The term is often used to describe the policy of a country’s dominance over distant lands, regardless of whether the country considers itself part of the empire.”

In the realm of software imperialism, the customer organization buying and installing an enterprise software package was seen as a form of territory to be occupied or controlled by one or more hostile, rivalrous software and services vendors seeking to extract continuing revenues from their occupied possessions; revenues in the form of maintenance, support, customization, administration, or other sorts of solution upkeep and extension expenses.

Empires exerted control formally through a variety of political and economic mechanisms, and informally through influence over political, economic and cultural spheres. Wikipedia’s entry for “empire” offers some instructive parallels to the enterprise solution model:

“First, in an empire there must be a Core and a Periphery. The empire’s structure relates the core elite to the peripheral elite in a mutually beneficial fashion. Such as relationship can be established through any number of means, be they aggressive, coercise, or consensual. And while there is a vertical relationship between the core and periphery, there is a lack of substantive relations between periphery and periphery. This relationship he describes as an incomplete wheel: there are hubs and spokes, but no rim.”
The relationship of interconnected elites is easy to see in the pattern of incented sales and buying decisions; “Need tickets to that exclusive event? No problem, we’ll get them for you right away…”

But it’s the idea of disconnected hubs and spokes that is key to understanding the correspondence between the old enterprise model and imperialism. How often do individual client solutions (perhaps for different departments or business units) interact with each other? How often do instances of the same solution for different clients allow effective interaction between different clients of the same vendor? How often do different products nominally part of ‘integrated’ solution sets that were in actuality assembled by aggregating the offerings of acquired companies successfully interact?
Again, without overloading the analogy, there are clear parallels between the degrees of empire and the lifecycle of enterprise solutions and vendors.

“Motyl also posits varying degrees of empire: Formal, Informal, and Hegemonic. In a formal imperial relationship, the core can appoint and dismiss peripheral elites, obviate any external agenda or policies, and directly control the internal agenda and policies.”

As a consultant, I’ve seen aggressive software and services vendors directly drive business direction, strategy, investment, and process change decisions all too often. Organizations lacking vision, effective leadership, or those entering complacency or suffering decline look to vendors for leadership by proxy, allowing or asking vendors to apply their own inappropriate frames of reference and perspectives to understand and choose courses of action in situations outside the vendor’s proper domain.

“In an informal imperial relationship, the core has influence but not control over appointing and dismissing peripheral elites, direct control over the external agenda and policies, and influence over the internal agenda and policies.”

This informal relationship is the position of the entrenched vendor that provides ‘perspective’ on many situations outside their proper domain. Vendors seeking to increase their territory within client organizations often pursue growth via this method. Alternatively, vendors will control the environment in which customers and other service providers make decisions, as in the “open API” approach wherein the enterprise exposes a portion of it’s architecture, code base, or other platform, but maintains exclusive control over the API without any binding commitments.

Wikipedia continues:

“Finally, in a hegemonic relationship, the core has no control over appointing or dismissing peripheral elites, control over the external agenda, influence over external policies, and no control over the internal agenda or policies.”
This is the stage that the existing collaboration solutions seem to be entering, as witnessed by IBM’s announcement, and Microsoft’s failure to date to advance the OpenXML standard to full legitimacy.

The Passing of Imperium
In essence, the old enterprise approach exemplified the closed system, one that was sustained by the authority and credibility of the originating vendor in the face of other competing closed systems. Fundamentally, software empires and imperialism are predicated on the validity of closed systems. What happens when open systems become the preferred model?

“Empire ends when significant peripheral interaction begins, not necessarily when the core ceases its domination of the peripheries. The core-periphery relationship can be as strong or weak as possible and remain an empire as long as there is only insignificant interaction between periphery and periphery.”

OpenDocument is designed to allow exactly the sort of periphery to periphery interaction that closed architectures prohibited. IBM’s shift to OpenDocument shows awareness that old style closed imperial enterprise systems are no longer viable. In this, they are following the changing rhetoric of those such as Larry Cannell from collaborationloop.com, who offers a strongly pro-open system view in A Vision For Collaborative Technologies:

“I believe openness breeds innovation, and there are many parts of the collaborative technology market that need a big injection of innovation. While vendors continue pushing integration as their primary value proposition for closed systems, the astute competitor will embrace openness and provide innovation within an ecosystem of collaborative technologies based on open standards. Today we have a plethora of email systems which nearly everyone connected to the Internet is capable of using. We need comparable open and simple choices for other collaborative technologies; whether it is collaborative workspaces or online communities. It will not be until we have simple open standards that foster familiarity and easy interconnectivity that will we see widespread use and explosive innovation.”

Cannell is careful here to take a positive and forward-looking line regarding collaboration, but his view of closed systems is clearly negative. And the implied consequence of a closed system is lack of innovation, one of the key signs of organizations in decline.
Didn’t I start out by saying that we should be wary of the marketing rhetoric surrounding collaboration? Yes, precisely because the majority of the rhetoric coming from enterprise vendors still exemplifies the closed system, imperialist enterprise ethos.

However, in the case of IBM, it’s clear that they’ve anticipated the consequences of ignoring the environmental shift to open systems that is at hand, and reacted accordingly, at least as regards the core document standard underlying Lotus Notes (which is still awful, BTW, just in case anyone misinterprets this article to mean I think otherwise…). The relationship of Notes to Workplace seems largely unknown at this point, and still subject to bitter infighting, in another great parallel to the imperial model. Microsoft, as the other major collaboration vendor, may be able to stem the tide against open systems in the short term, but will eventually have to respond.

My thoughts on the current form of enterprise solutions as a class / industry / way of solving business problems remain unaltered – in fact I think that IBM’s move supports many of the predictions I made earlier this year, following earlier treatments by others writing on the same subjects.