LavaCon Session: Edwina Lui on the Goldilocks Approach

Right-sized Tools for Right-sized Solutions

The Goldilocks Approach: Finding the Right Project and the Right Team at the Right Size

Presenter: Edwina Lui, Information Architect, Kaplan Publishing

Slideshare: http://www.slideshare.net/EdwinaLui1/elui-lavacon2014goldilocks

By all the rules they teach you, Edwina Lui’s presentation at LavaCon 2014 should not have worked: There was simply too much information, and Lui talked much too fast. But for a presenter with the right gifts, the rules are clearly wrong, because Lui pulled it off admirably. Sometimes, too big is just right.

It helped that Lui had a very clear structure to her presentation: Three projects, one that failed because it was too big. One that failed because it was too small. One that succeeded because it was just the right size.

It takes a good deal of courage and confidence to give a presentation in which you claim only a 1 in 3 success ratio. In fact, one of the problems with conference presentations generally is that we only hear about the things that worked, while there are often far more lessons learned in the projects that failed.

And it was the learning that Lui identified as the biggest outcome of the three projects that she presented; why she was able to speak with confidence about what they had learned from all three. Her final slide was lessons learned, presented as a table of DOs and DONTs. The first of these was, to me, the most telling:

The first project she described aimed to introduce an Enterprise Content Management System and an Unified Content Model across all of Kaplan Publishing’s divisions, with the aim of facilitating content reuse across all the business units. Phase one of the project involved tools acquisition and content modeling. Phase two was supposed to be the rollout across the business units. Only when it came time for the rollout, the business units found that the system did not actually solve their business problems, the authoring  and workflow system much too complicated for the occasional authors that contributed most of their content, and that there was not enough reuse potential to justify adoption. That project was too big.Far too often in the content space, we fall prey to aspirational goals — the heroic projects, the enterprise-spanning projects, the projects that look good on resumes and in conference speaking proposals. But not every project has to span the enterprise to be successful, as Lui illustrated.

The second project she described was the creation of interactive ibooks. As a small project it was supposed to be isolated from the complications that had afflicted the first project, but the process, using Apple’s proprietary tools, proved to be much too manual, and the the books produced did not show any benefit. This project was discontinued. It was too small.

The third project was based on collaborative authoring in HTML. It used semi-structured HTML to achieve multi channel publishing. The tools used had a very low barrier to entry for contributors, which was important because of the number of short term contractors Kaplan has. It provided them with an environment as close as possible to their current experience while still achieving their publishing goals. This project was the right size and was a success.

The right-sized project with the right-sized tools

As a dyed in the wool structured content guy, I suppose I should be tut-tutting over the abandonment of a universal content model in favor of HTML authoring. But I am an advocate of right-sized solutions first and foremost. (Indeed, I think it is a cardinal sin of many structured content projects that they are too big, too complex, too ambitious, and too driven by aspirational goals.) As Lui brilliantly demonstrated, we need to make sure our projects are just the right size: the right scale, the right level of complexity, and the right level of usability. Above all, we need to make sure they solve actual, concrete, and immediate business problems.