Joe Lamantia.com

I just posted slides from my talk at the recent Enter­prise Search Sum­mit in NY “Search Me: Design­ing Infor­ma­tion Retrieval Experience”

Here’s the abstract from the session:

This case study reviews the meth­ods and insights that emerged from an 18-month effort to coör­di­nate and enhance the scat­tered user expe­ri­ences of a suite of infor­ma­tion retrieval tools sold as ser­vices by a major invest­ment rat­ings agency. The ses­sion will share a method for under­stand­ing audi­ence needs in diverse infor­ma­tion access con­texts; review a col­lec­tion of infor­ma­tion retrieval pat­terns, look at con­cep­tual design meth­ods for user expe­ri­ences, and review a set of longer term pat­terns in cus­tomer behav­ior called life­cy­cles, and con­sider the impact of orga­ni­za­tional and cul­tural fac­tors on design decisions.

This ses­sion will presents reusable expe­ri­ence design tools and find­ings rel­e­vant for con­texts such as enter­prise search and infor­ma­tion access, ser­vice design, and prod­uct and plat­form management.

Thanks to every­one who came by!

Read­ers active in the enter­prise, intranet, por­tal, and syn­di­cated con­tent & func­tion­al­ity spaces might be inter­ested in The Build­ing Blocks of Effec­tive Por­tals that appears in the Novem­ber / Decem­ber issue of Intranets Today.

Intranets is one of the lead­ing pub­li­ca­tions focused on these top­ics, with reg­u­lar con­tri­bu­tions from the likes of Rachel Alexan­der, Jane McConnell, and James Rober­ston.
You will need a log-in to read the com­plete arti­cle on-line, but per­haps you were think­ing of sub­scrib­ing, and this will pull you in.

In case you couldn’t make it to Ams­ter­dam for EuroIA 2008, or if you were in town but pre­ferred to stay out­side in the warmth of a sunny Sep­tem­ber Sat­ur­day than ven­ture into the mar­velous Tsuchin­ski the­ater, I’ve posted the slides from my talk Frame­works are the Future of Design.
Enjoy!

Read­ing about the recent release of Social­Text 3 I was struck by the strong par­al­lels between the defin­ing char­ac­ter­is­tics of enter­prise envi­ron­ments in 2003/2004, and the emerg­ing pub­lic Web 2.0 land­scape. The essen­tial char­ac­ter­is­tics of many enter­prise envi­ron­ments are:

• Syn­di­ca­tion: streams of mod­u­lar con­tent and func­tion­al­ity broad­cast widely to sub­scribers within the fire­wall, such as enter­prise data feeds, ERP, BI capa­bil­i­ties, CRM, cus­tom capa­bil­i­ties shared via SOA
• Ser­vices (e.g. envi­ron­men­tal, like the bees we used to have for pol­li­na­tion): iden­tity, secu­rity, pub­li­ca­tion, data man­age­ment, cloud stor­age, imap email, etc.
• Social Struc­tures: tan­gi­ble net­works & com­mu­ni­ties of like-minded peo­ple, ori­ented around a com­mon prac­tice, pur­pose, process, or pain; think of all the matrixed, hor­i­zon­tal org struc­tures and ad-hoc net­works encoded via inter­nal email lists, IM, sprawl­ing intranets, cor­po­rate direc­to­ries, etc.

These same attrib­utes are emerg­ing as the hall­marks of the pub­lic Web 2.0 land­scape. This is how the three S’s man­i­fest for Web 2.0:

• Syn­di­ca­tion: A lit­eral and fig­u­ra­tive tor­rent of con­tent in the form of blogs, RSS, feeds, streams, APIs, for social objects of all types, as well as cat­a­logs of rentable content
• Ser­vices: This layer is grow­ing rapidly for the pub­lic inter­net, with OpenID / OAuth, map­ping, visu­al­iza­tion, backup, cal­en­dar­ing — the list is nearly infi­nite, and still expanding
• Social Struc­tures: The Web (and soon the mobile uni­verse) is pro­foundly social now, and will con­tinue to become ever more so.

I think you can eas­ily see the strong par­al­lels. It’s this sim­i­lar­ity between the older enter­prise envi­ron­ments and the emerg­ing Web 2.0 envi­ron­ment that user expe­ri­ence prac­ti­tion­ers, — and espe­cially any­one prac­tic­ing infor­ma­tion archi­tec­ture — should note.
Why? As I’ve writ­ten before, mod­u­lar­ity is every­where in this new envi­ron­ment, it’s appar­ent at all lay­ers of the infor­ma­tion world, from util­i­ties like pro­cess­ing power, to ser­vices, to the ele­ments that make up the user expe­ri­ence. The effects of mod­u­lar­ity in syn­di­ca­tion, ser­vices, and social struc­tures on devel­op­ers and IT have been pro­found; prac­tices, processes, orga­ni­za­tional struc­tures, and busi­ness mod­els have all shifted in response.
This wave of change first affected the devel­op­ers who build and work directly with code and sys­tems. But inevitably, dis­ci­plines fur­ther up the stack are feel­ing the impact of this shift, though many of us (and I’m putting user expe­ri­ence in this class) may not know it yet.
How will we feel that impact? One obvi­ous way is in the pres­sure to adopt agile and other mod­u­lar prod­uct con­struc­tion prac­tices cre­ated by and for devel­op­ers as the pre­ferred way to struc­ture user expe­ri­ence and design efforts. This is a mis­take that con­fuses the dif­fer­ent stages of soft­ware / dig­i­tal prod­uct cre­ation (as Alan Cooper explained well at Agile2008). Design is not con­struc­tion, and shouldn’t be treated as if it is. And one size fits all does not work when choos­ing the process and toolkit used for cre­at­ing com­plex dig­i­tal prod­ucts, ser­vices, or expe­ri­ences.
One result of this mod­u­lar­ity rules all approach to user expe­ri­ence is the ero­sion of bounded or well-structured design processes that bal­ance risk effec­tively for the var­i­ous stages of design, and were meant to ensure the qual­ity and rel­e­vance of the result­ing prod­ucts and expe­ri­ences. Ero­sion is vis­i­ble the trends toward com­pres­sion or elim­i­na­tion of rec­og­niz­able design con­cept explo­ration and usabil­ity ver­i­fi­ca­tion activ­i­ties in many design meth­ods.
More imme­di­ately — in fact star­ing us right in the face, though I haven’t seen men­tion of it yet in m/any user expe­ri­ence forums — is the grow­ing num­ber of sit­u­a­tions wherein there’s “No designer required”.
Exam­ples of this abound, but just con­sider this fea­ture list for the Social Text 3 Dash­board:

• You decide what matters
• Cre­ate your dash­board in minutes
• Include 3^rd party infor­ma­tion and applications
• Track & attend to what’s most impor­tant to you
• Sta­tus updates flow auto­mat­i­cally, as you work

If that’s not spe­cific enough, here’s what comes out of the box, in the form of pre-built widgets:

• My Con­ver­sa­tions — changes oth­ers have made to any Social­text work­space page you authored, edited, or com­mented on
• My Col­leagues — recent updates made by peo­ple you are sub­scribed to
• Work­spaces — work­spaces you have access to and their activ­ity metrics
• Work­space Page — any page from any of your Social­text workspaces
• RSS Viewer — results of an RSS feed you configure
• Work­space Tags — a tag cloud of all tags in a par­tic­u­lar workspace
• All Peo­ple Tags — a tag cloud of all tags on peo­ple in Social­text People

No archi­tect required for most peo­ple here… and this trend is every­where.
And then there’s the awe­some spec­tre ofcom­modi­ti­za­tion. Lis­ten­ing to a friend describe the con­fus­ing expe­ri­ence of try­ing to select a short list of design firms for inclu­sion in an RFP made the link­age clear to me. I’ll quote Weil’s def­i­n­i­tion of com­modi­ti­za­tion from the paper ref­er­enced above, to make the point explicit.
Please recall that com­modi­ti­za­tion denotes the devel­op­ment of a com­pet­i­tive envi­ron­ment where:

• Prod­uct dif­fer­en­ti­a­tion is very difficult;
• Cus­tomer loy­alty and brand val­ues are low;
• Com­pe­ti­tion is based pri­mar­ily on price; and
• Sus­tain­able advan­tage comes from cost (and some­times qual­ity) leadership.
• Com­modi­ti­za­tion is dri­ven by excess capacity.

Please note that I’m not imply­ing user expe­ri­ence prac­ti­tion­ers face overnight obso­le­tion.
But I am say­ing that I doubt our cur­rent dis­ci­pli­nary world­view and toolkit ade­quately pre­pare us for the real­i­ties of the new envi­ron­ment emerg­ing so rapidly. Code, by con­trast, is and always will be mod­u­lar. (After all, that is the defin­ing attribute of our alpha­bets.)
But user expe­ri­ence is holis­tic, and has to learn to build in its own way from these smaller pieces like a writer com­bin­ing words and phrases. Even­tu­ally, you can cre­ate works of tremen­dous depth, rich­ness, and sophis­ti­ca­tion; think of Ulysses by James Joyce, or the Mahab­harata. These are richly nuanced expe­ri­ences that are the result of work­ing with mod­u­lar ele­ments.
My sug­ges­tion for one response to the oncom­ing wave of mod­u­lar­ity and com­modi­ti­za­tion is to focus our value propo­si­tion in the cre­ation of tools that other peo­ple use to define their indi­vid­ual expe­ri­ences. In other words, shift our pro­fes­sional focus to higher lay­ers of abstrac­tion, and get into the busi­ness of defin­ing and design­ing frame­works, net­works, and sys­tems of expe­ri­ence com­po­nents. Prac­ti­cally, this will mean things like observ­ing and defin­ing the most valu­able pat­terns aris­ing in the use of sys­tems of mod­u­lar ele­ments we design, and then advis­ing on their use to solve prob­lems. This is the direc­tion com­mon within enter­prise envi­ron­ments, and in light of the appear­ance of pub­lic pat­tern libraries (Yahoo’s UI), I think I see it hap­pen­ing within parts of the user expe­ri­ence com­mu­nity. I’m not sure it’s hap­pen­ing fast enough, though.
I hoped to com­mu­ni­cate some of these ideas in my talk on why frame­works are the future (at least for any­one prac­tic­ing Expe­ri­ence Archi­tec­ture) for the 2008 EuroIA Sum­mit that just took place here in lovely Ams­ter­dam. I’ll post the slides shortly. In the mean­time, what do you think? Is user expe­ri­ence ready for the mod­u­lar­ized, enterprise-like envi­ron­ment of Web 2.0? How are you respond­ing to these changes? Is com­modi­ti­za­tion even on your radar?

I’ve just started a new ‘Orga­ni­za­tional Archi­tec­ture’ group on Slideshare, to explore links to user expe­ri­ence, and ques­tions like these:

• What is orga­ni­za­tional architecture?
• How does orga­ni­za­tional archi­tec­ture relate to user experience?
• What can user expe­ri­ence prac­ti­tion­ers bor­row from OA to become more effective?

Join now!

The cul­ture, struc­ture, and work­ings of an orga­ni­za­tion often pose greater chal­lenges for User Expe­ri­ence prac­ti­tion­ers than any tech­ni­cal or design ques­tions at hand. If you’d like to know more about the fac­tors behind these sit­u­a­tions, be sure to check out We Tried To Warn You: The Orga­ni­za­tional Archi­tec­ture of Fail­ure, by Peter Jones, just pub­lished by Boxes and Arrows.

Peter is an inde­pen­dent con­sul­tant with deep exper­tise in research, prod­uct design, and strat­egy. His talk for the panel on fail­ure at the 2007 IA Sum­mit was insight­ful and in-depth, and this two-part series offers quite a bit more very use­ful mate­r­ial on the roots and warn­ing signs of orga­ni­za­tional fail­ure (by com­par­i­son, con­sider the very brief post I put up on the same sub­ject a few years ago.)
Peter’s is the sec­ond writ­ten fea­ture to come out of the fail­ure panel (my mis­sive on the par­al­lels between entre­pre­neur­ial and soci­etal fail­ure was the first). I’m look­ing for­ward to part two of We Tried To Warn You, as well as addi­tional fea­tures from the remain­ing two pan­elists, Chris­t­ian Crum­lish and Lorelei Brown!
Here’s a snip­pet, to whet your appetite:
How do we even know when an orga­ni­za­tion fails? What are the dif­fer­ences between a major prod­uct fail­ure (involv­ing func­tion or adop­tion) and a busi­ness fail­ure that threat­ens the orga­ni­za­tion? An organizational-level fail­ure is a rec­og­niz­able event, one which typ­i­cally fol­lows a series of antecedent events or deci­sions that led to the large-scale break­down. My work­ing def­i­n­i­tion: When sig­nif­i­cant ini­tia­tives crit­i­cal to busi­ness strat­egy fail to meet their highest-priority stated goals.”

Boxes and Arrows has pub­lished part 3 of the Build­ing Blocks series, describ­ing the Con­tainer blocks in detail. Next in the series is part 4, which describes the Con­nec­tors in the build­ing block sys­tem in detail.

If you’re work­ing on a por­tal, dash­board, or tile based design effort of any kind, the build­ing blocks read­ily serve as a com­mon lan­guage and struc­tural ref­er­ence point that allows effec­tive project com­mu­ni­ca­tion across tra­di­tional dis­ci­pline bound­aries. These two arti­cles in tan­dem (parts 3 and 4) pro­vide details on how the Build­ing Blocks can pro­vide a strong, flex­i­ble, and scal­able usr expe­ri­ence and infor­ma­tion archi­tec­ture frame­work for the long term.
My cur­rent plan is to release a toolkit at approx­i­mately the same time as part 4 of the series. Part 4 is in the edit­ing stage now, so this a good time to ask read­ers for sug­ges­tions on what should be part of the toolkit, and what form it should take. Suggestions?

For those in the enter­prise IA / UX space, The next fron­tier in IT strat­egy: A McK­in­sey Sur­vey cen­tered on the idea that “…IT strat­egy is matur­ing from a reac­tive to a proac­tive stance“is worth a look.
This nicely par­al­lels a point made about the reac­tive mind­set com­mon to IT in many large orga­ni­za­tions, in dis­cus­sion on the IAI mail­ing list last month. Lou Rosenfeld’s post Infor­ma­tion archi­tects on com­mu­ni­cat­ing to IT man­agers, sum­ma­rizes the orig­i­nal dis­cus­sion in the IAI thread, and is worth read­ing as a com­pan­ion piece.
Lou’s sum­mary of infor­ma­tion archi­tec­ture and user expe­ri­ence voices in the enter­prise arena is note­wor­thy for includ­ing many exam­ples of strong cor­re­spon­dence between McKinsey’s under­stand­ing of how IT strat­egy will mature (a tra­di­tional man­age­ment con­sult­ing view), and the col­lected IA / UX view­points on address­ing IT lead­er­ship — typ­i­cal buy­ers for enter­prise any­thing — and inno­va­tion.
Dialogs that show con­ver­gence of under­stand­ing like this serve as pos­i­tive signs for the future. At present, a large set of deeply rooted cul­tural assump­tions (at their best inac­cu­rate, usu­ally reduc­tive, some­times even dam­ag­ing) about the roles of IT, busi­ness, and design com­bine with the his­tor­i­cal lega­cies of cor­po­rate struc­tures to need­lessly limit what’s pos­si­ble for User Expe­ri­ence and IA in the enter­prise land­scape. In prac­ti­cal terms, I’m think­ing of those lim­i­ta­tions as bar­ri­ers to the strat­egy table; con­strain­ing who can talk to who, and about which impor­tant top­ics, such as how to spend money, and where the busi­ness should go.
Con­sid­er­ing the gulf that sep­a­rated UX and IT view­points ten — or even five — years ago, this kind of emerg­ing com­mon under­stand­ing is a good sign that the cul­tural obsta­cles to a holis­tic view of the mod­ern enter­prise are wan­ing. We know that a holis­tic view will rely on deep under­stand­ing of the user expe­ri­ence aspects of busi­ness at all lev­els to sup­port inno­va­tion in prod­ucts and ser­vices. I’m hop­ing the rest of the play­ers come to under­stand this soon.
Another good sign is that CIO’s have won a seat at the strat­egy table, after con­sis­tent effort:
Fur­ther evi­dence of IT’s col­lab­o­ra­tive role in shap­ing busi­ness strat­egy is the fact that so many CIOs now have a seat at the table with senior man­age­ment. They report to the CEO in 44 per­cent of all cases; an addi­tional 42 per­cent report to either the chief oper­at­ing offi­cer or the chief finan­cial offi­cer.
Look­ing ahead, infor­ma­tion archi­tec­ture and user expe­ri­ence view­points and prac­ti­tion­ers should work toward a sim­i­lar growth path. We fill a crit­i­cal and miss­ing strate­gic role that other tra­di­tional view­points are not as well posi­tioned to sup­ply.
Quot­ing McK­in­sey again:
IT strat­egy in most com­pa­nies has not yet reached its full poten­tial, which in our expe­ri­ence involves exploit­ing inno­va­tion to drive con­stant improve­ment in the oper­a­tions of a busi­ness and to give it a real advan­tage over com­peti­tors with new prod­ucts and capa­bil­i­ties. Fewer than two-thirds of the sur­vey respon­dents say that tech­no­log­i­cal inno­va­tion shapes their strat­egy. Only 43 per­cent say they are either very or extremely effec­tive at iden­ti­fy­ing areas where IT can add the most value.
User Expe­ri­ence can and should have a lead­ing voice in set­ting the agenda for inno­va­tion, and shap­ing under­stand­ings of where IT and other groups can add the most value in the enter­prise. To this end, I’ll quote Peter Mer­holz (with apolo­gies for not ask­ing in advance)
”…we’ve reached a point where we’ve max­i­mized effi­ciency until we can’t max­i­mize no more, and that in order to real­ize new top-line value, we need to inno­vate… And right now, inno­va­tions are com­ing from engag­ing with the expe­ri­ences peo­ple want to have and sat­is­fy­ing *that*.“
McK­in­sey isn’t mak­ing the con­nec­tion between strate­gic user expe­ri­ence per­spec­tives and inno­va­tion — at least not yet. That’s most likely a con­se­quence of the fact that man­age­ment con­sult­ing firms base their own ways of think­ing, orga­ni­za­tional mod­els, and prod­uct offer­ings (ser­vices, intel­lec­tual prop­erty, etc.) on address­ing buy­ers who are them­selves deeply entrenched in trad­tional cor­po­rate struc­tures and world­views. And in those worlds, every­thing is far from mis­cel­la­neous, as a glance at the cat­e­gory options avail­able demon­strates; your menu here includes Cor­po­rate Finance, Infor­ma­tion Tech­nol­ogy, Mar­ket­ing, Oper­a­tions, Strat­egy…
BTW: if you weren’t con­vinced already, this should demon­strate the value of the $40 IAI annual mem­ber­ship fee, or of sim­ply read­ing Bloug, which is free, over pay­ing for sub­scrip­tions to man­age­ment jour­nals

Mark Blu­men­thal, of Pollster.com, recently posted a set of text clouds show­ing the words used by each can­di­date in the Demo­c­ra­tic pres­i­den­tial debate Thurs­day night. The clouds were gen­er­ated from tran­scripts of the debate, using Daniel Steinbock’s Tag Crowd tool.
Can­di­dates’ Text Clouds

In the screen­shot of Mark’s post­ing, it’s easy to see this is a great exam­ple of a col­lec­tion of text clouds used for com­par­a­tive visu­al­iza­tion and inter­pre­ta­tion. The goal is to enhance under­stand­ing of the mean­ing and con­tent of the candidate’s over­all con­ver­sa­tions dur­ing the debate, an idea I explored briefly last year.
Just a month ago, in a post that iden­ti­fied text clouds as a new and dis­tinct tag cloud vari­ant, I sug­gested:

text clouds may become a gen­er­ally applied tool for man­ag­ing grow­ing infor­ma­tion over­load by using auto­mated syn­the­sis and sum­ma­riza­tion. In the infor­ma­tion sat­u­rated future (or the infor­ma­tion sat­u­rated present), text clouds are the com­mon exec­u­tive sum­mary on steroids

Sup­port­ing the com­par­i­son and inter­pre­ta­tion of polit­i­cal speeches is an inven­tive, timely, and resource­ful appli­ca­tion that could make text clouds a reg­u­lar part of the new per­sonal and pro­fes­sional toolkit for effec­tively han­dling the tor­rents of infor­ma­tion over­whelm­ing peo­ple in impor­tant sit­u­a­tions like vet­ting polit­i­cal can­di­dates.
I espe­cially like the way this use of text clouds helps neatly side­step the dis­heart­en­ing ubiq­uity of the sound­bite, by aggre­gat­ing, dis­till­ing, and sum­ma­riz­ing all the things the can­di­dates said. I sus­pect few — if any — of the cam­paigns real­ize the poten­tial for text clouds, but they def­i­nitely know the detri­men­tal power of sound­bites:

“It’s a mess,” said an exasperated-sounding Mr. Prince, Mr. Edwards’s deputy cam­paign man­ager. “Debates are impor­tant, but in these big mul­ti­can­di­date races they end up not being an exchange of ideas, but just an exchange of sound bites. They have become a dis­trac­tion.“

From Debates Los­ing a Bit of Lus­ter in a Big Field

The value of a col­lec­tion of sound­bites over an insight­ful dia­log is — apolo­gies for the pun — debat­able. But even if a sim­ple exchange of sound­bites is what the new short­ened for­mats of many debates yields us, text clouds may help derive some value and insight from the results. The com­bined decon­struc­tive and recon­struc­tive approach that text clouds employ should make it pos­si­ble to bal­ance the weight of sin­gle remarks of can­di­dates by plac­ing them in a larger and more use­ful con­text.
His­tory Repeats Itself
In the longer term view of the his­tory of our responses to the prob­lems of infor­ma­tion over­load, the appear­ance of text clouds may mark the emer­gence of a new gen­eral puprose tool for visu­al­iz­ing ever greater quan­ti­ties of infor­ma­tion to sup­port some qual­i­ta­tively ben­e­fi­cial end (like pick­ing a good can­di­date for Pres­i­dent, which we sorely need).
The under­ly­ing pat­tern — a con­sis­tent oscil­la­tion between man­ag­ing effec­tively and inef­fec­tively cop­ing, depend­ing on the bal­ance between infor­ma­tion quan­tity and tool qual­ity — remains the same. Yet there is also value in know­ing the cycles that shape our expe­ri­ence of han­dling the infor­ma­tion cru­cial to mak­ing deci­sions, espe­cially deci­sions as impor­tant as who leads the coun­try.
The NY Times tran­script of the debate is avail­able 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.