/Tag: Visual Story

The Story behind “Stories That Move Mountains”

By |2012-11-04T18:31:33+00:00November 4th, 2012|Enterprise Architecture|

There is a new book available that I’d like to let everyone know about.  It is called “Stories That Move Mountains.”  I wrote this book with two fantastic professionals Martin Sykes and Mark D. West.  In this post, I’m going to talk about how this book came to be, and why I felt so strongly about it that I invested two years of my life in bringing it to market.

First off, if you are interested in buying the book, and we think you will be, you can click on the image of the cover to take you straight to our “buy the book” page on the book’s sister site, StoriesThatMoveMountains.com

book_cover_image_sm

Edward Tufte and Me

My journey into “rich information” began, as it did many others, when I heard about a book called “Visual Explanations” written by Edward Tufte.  It was 1997, and the dot-coms were booming.  I had left Microsoft to stake a claim in the modern gold rush.  I was working as a development manager in a quickly growing web development company in downtown Seattle called Fine.com International. (see note

On my team was a talented young web developer named Brian Poel who told me about a seminar he attended hosted by Tufte.  In the seminar, Tufte taught about creating visual designs that inform, not just impress.  Brian showed me the materials and I ended up reading Tufte’s book myself  (Another bit of evidence to support the old saying: a manager is only as good as the smart people that surround him).

Visual Explanations: Images and Quantities, Evidence and NarrativeAt fine.com, we used the techniques described by Tufte in every way we could.  His guidance led to design ideas that fed into the Nasdaq.com web site, the Marriott hotels web site, and many more.  I learned the power of structuring information in a way that makes it easy to consume, elegant to perceive, and compelling to read. 

It would  be many years before I needed these techniques myself.  That didn’t really start until I became a management consultant.  The year was 2001, and the dot-com that I co-founded after leaving fine, Acadio, had failed along with tens of thousands of other young start-ups.  I had moved to a consulting company called Sierra Systems Group (headquartered out of Vancouver British Columbia) to make ends meet.  For the most part, I focused on technology activities, but I had to ramp up my communication skills.  So I started using some of the rich information techniques that I learned from Tufte in our marketing and sales materials.  I cannot say that I was particularly good at it.

I Can’t Draw… Seriously

I really can’t.  Not even stick figures.  Which is odd, because both of my parents, my eldest brother, and my daughter, are all gifted artists.  Not that I can’t create useful diagrams… I had trained in high school as a draftsman.  Give me a T-square, two triangles, a nice drawing board, and couple of sheets of vellum and I can draw a complete set of floor plans for your house (well… I could in 1980… maybe not so much now).  But freehand, I am hopeless. 

Beyond Bullet Points: Using Microsoft PowerPoint to Create Presentations that Inform, Motivate, and Inspire (Business Skills) (English and English Edition)So when I tried to create a nice visual representation, and failed, I thought it was because of my lack of skill as an artist. I couldn’t have been more wrong.  Regardless, the best I could do, at the time, was to follow the guidance in “Beyond Bullet Points” and create PowerPoint presentations that were compelling using emotive photographs.  They were nice, but they weren’t the things I wanted to create.

 

Meanwhile on the other side of the Atlantic

Turns out, I was part of movement of sorts.  A growing number of people had taken up the challenge of creating interesting visual representations of complex information.  The “infographic” movement had started, and companies were springing up here and there to provide clear, simple, and compelling explanations of complex information.  On the other side of the world, in the UK, an enterprise architect named Martin Sykes had begun his own journey, around the same time as I had.  Big difference: he didn’t give up.

If you ever get a chance to meet Martin, you will enjoy his company immensely, just as I do.  Martin is clever, thoughtful, easy-going, and funny.  He’s a systems-thinker and an excellent speaker.  Martin was also influenced by Tufte, but he continued on to find many other authors and designers who were publishing and writing about this new way of doing things.  Martin started creating his own single page explanations of otherwise complex information, building up his skills and collecting techniques along the way.  And, Martin took the time to learn how to draw.  That didn’t hurt.

I met Martin Sykes through a mutual friend, Gabriel Morgan.  Gabriel had joined the Enterprise Architecture team in Microsoft IT just a few months after I did, but he came to the practice from his work as a consultant using Microsoft Motion (later renamed Microsoft Services Business Architecture or MSBA).  Gabriel had met Martin a few times, and had seen some of the visualizations that Martin used to explain business architecture.   Gabriel worked with Martin to set up a workshop, for our team, to learn some of these skills.  And in late October of 2007, Martin flew to Redmond and spent a week teaching us how to “tell stories” using a series of visual metaphors.  At the time, he called them “Big Pictures” but that thinking evolved and we now refer to these creations as “visual stories”.

Can we do this again?

imageDuring Martin’s workshop, each of us created a visual representation of some idea or story we wanted to tell.  Martin had distilled his own personal techniques into a FIVE DAY COURSE on creating visual stories.  He walked us through ample examples, storytelling exercises, and a fairly simple process that he used to create visual stories.  I created two visual stories in that class, one of which Martin still uses today… as an example of what NOT to do in a visual story!

The five day class happened once. Over the next few years Martin did four one day classes at different companies where he had been asked specifically to do more following a series of 90-minute presentations he had done at internal and external conferences. But the ideas were not “catching fire”, in large part because Martin was just happy to use what he was learning and focus on his day job of making change happen.

 

Meanwhile, I kept using his materials, and referred often to the binder full of PowerPoint slides that he provided.  I practiced a few times more, and then stumbled into success.  I created a visual story to explain an enterprise architecture roadmap to the Vice President of Operations.  I presented the one page visual, and the meeting went fairly well.  We got the sponsorship we needed.  What I didn’t discover until later: that same Vice President took my one-page presentation and gave it to Steve Ballmer, CEO of Microsoft and one of the most powerful businessmen in the world, to explain how Microsoft’s Operations Division was attacking a key problem within the company.

That single page told a story.  It was not a bunch of data.  It was not a bunch of clever graphics.  There was no hand-drawn art.  It was a careful construction created using Martin’s techniques, and it changed my career.  I was promoted and over time, I was leading a team.  I wanted to bring Martin back to our group to do another one of these fantastic workshops, so that more of us could learn his techniques.  I was willing to teach it myself if I had to.

A book is born

My goal was to put on a workshop for the entire Enterprise Architecture team within Microsoft IT.  I reached out to Martin and asked if he had ever updated those PowerPoint slides.  Thus began a series of meetings that morphed into a book proposal.  We planned to create something visually interesting, to use our own ideas to tell the story of how use these ideas.  Martin reached out to a friend of his, Mark West, a talented artist and designer that had worked with Martin on creating some of his training materials.  Mark was familiar with the process because Mark had lived it.  And he can draw.   (I’m understating rather wildly.  Mark has spent time as an art instructor at a college in Seattle, in addition to running his own design firm.  Mark is a change agent who masquerades as a very cool designer.)

During those early days, we simplified and clarified the process of creating a visual story, and we called it “CAST.”  CAST is an acronym for “Content, Audience, Story, Tell” which are the four stages of the process.  We created a simple “canvas” that anyone can use.  During this past year, Martin has put together a couple of workshops in other parts of the company and has used them to work out the bugs.  We call this canvas  the “CAST model” and I have completely adopted it.  It’s like a simple visual checklist that helps you remember and iterate through the steps to creating a visual story.

We still haven’t done that workshop for Microsoft IT.  We decided to create a book that we could both use to teach anyone we wanted.  We decided to focus on using these skills to simplify the process itself, and to make it easy for folks who, like me, are not artists.  Note: in a professional setting, on projects that are funded to create compelling information, I strongly recommend enlisting the help of a visual designer… but for your own use, to explain your own information, you can follow the CAST process to do the trick.  Just like I did.

The long slog

Anyone who walks the road from idea to a complete book knows that it can be a difficult and time-consuming effort.  We had our moments when each of us thought that this whole thing was nuts.  After all, there were so many good books already on business storytelling and good design principles.  Couldn’t someone just read those books? 

They could, but what I got from Martin, in that workshop in 2007, was not in any of those books.  Martin didn’t change my career with a collection of art tricks and bits from a dozen books.  What Martin gave me, and what we wanted to give our readers, is a simple step-by-step process that a non-designer could follow to create a USEFUL and COMPELLING single-page visualization.  Not high art.  High value.

We knew we had something unique… something that none of the other books and authors and workshops had built.  We had something that the non-artists among us could use to be compelling and useful.  We had a book about change, and making change happen.  We had a book about stories, and using those stories to drive big changes, huge changes… using those stories to MOVE MOUNTAINS.

Most of the text was written between November of 2011 and May of 2012.  Most of the artwork that infuses this book, on every single page, was created in the spring and summer of 2012.  The book is compelling and visually beautiful.  We treated every single pair of pages as a two-page layout, and each was hand constructed by Mark West.  Our publisher, Wiley and Sons, created a new team, with about twice the normal book staff, just to assemble it.  Wiley knew we had something unique, and they were willing to take a real risk on it.  Our team at Wiley did a fantastic job.  I’ve been a co-author before, but never had an experience anything like this one.  The level of communication, collaboration, and shared iterative design was simply unprecedented.  The Wiley team moved a mountain as well. 

image

Sample of a two-page spread used in the book Stories That Move Mountains

What you will get out of this book

In case it’s not clear already, we want this book to be practical and useful.  This is NOT an art book, even though there is one chapter that focuses on detailed visual elements like fonts, colors and layouts.  This is not a typical business book either.  There are no long expositions on financials or sales strategy or performance measurement.  This is a
book about change, and it is for ANYONE that wants to influence another person to lead a change. 

What you will get out of this book is a step-by-step process to follow that results in a visual story.  We walk you through numerous examples, showing how we use the CAST stages to create visual stories and there is a final chapter that literally goes end-to-end in creating another visual story.  We provide advice, and hugely valuable nuggets from a dozen other books that fill out shelves in mine and Martin’s and Mark’s libraries. 

imageOur references chapter is also a simple, clear, layout that focuses on a small and manageable list of excellent books for you to use if you want to “go deep” on any part of the process (you won’t have to, but just in case you want to).  We are also committed to continuing the conversation on the book sister-site http://StoriesThatMoveMountains.com where all three of us blog and upload resources (including a downloadable CAST model template, like the one on the right).  You can also find us on Facebook for a more socially-oriented conversation (www.facebook.com/storiesthatmovemountains) as well.

It should come as no surprise that both Martin and I are Enterprise Architects.  The biggest value we offer our clients is helping them to build the case for change.  But change can be anything.  You could be changing a business, or a team, or a family, or even yourself.  You can create a visual story for nearly any situation where you want people to remember, and connect, with your case for change.

Yep, it still works

I’ll give you an interesting example.  I am currently volunteering my time to a professional organization called the “Center for the Advancement of the Enterprise Architecture Profession” (or CAEAP, pronounced “seep”).  Through that organization, I have been assigned, by CAEAP, to work with another professional organization that they partner with: the “Federation of Enterprise Architecture Professional Organizations” (or FEAPO, pronounced “FEE-poe”).  I’m working on creating an industry-wide perspective on Enterprise Architecture.  I went to a FEAPO meeting just last weekend where I was working with people, in person, that I’ve only met one time before.  They were all aware of my project, of course, but it was not, and is not, their primary focus.  I couldn’t be sure that they remembered anything from the last time we’d met, in February.  I decided to use a visual story to frame what would have otherwise been a boring status update. 

imageOn the plane flight from Seattle to Fort Lauderdale (five hours in coach, on a red-eye overnight flight), I filled out the CAST model and created the entire presentation.  (I had no internet access on the plane, so the graphic images I used were all on my PC hard drive).  The moment I landed, I drove to FedEx Kinkos, printed the visual story on nice, sturdy, 11×17 paper, and drove straight to the 8:30am meeting.  When it came time to present, I handed out the sheets and we turned away from our screens and spoke to each other instead.

Later that evening, as we sat eating dinner at an upscale Surf-and-Turf restaurant, they were reciting back to me the humorous bits of the story that I told.  The story stuck.  It was memorable.  As a result, everyone has a good idea of what I need from them, and what they need from me, because we had a simple compelling visual story to work from.  (I’ll see if I can get a link to that document made available so that you, gentle reader, can see it.  A thumbnail is on the right).

So yes, I think you should buy this book.  I’d say that even if I didn’t help write it, but I did.  This is our way of saying: it’s time to change the world.  This is our mountain to move.  Join us.  The world needs change agents to be effective.  You are a change agent.  If we help you become just 5% more effective, what hurdles will you overcome?  What innovations will you introduce?  What problems will you solve? 

These are interesting times. 

On the Hunt for the One-Page View of an Enterprise

By |2011-06-03T10:55:52+00:00June 3rd, 2011|Enterprise Architecture|

I am currently noodling the idea of a one-page view of my employer (Microsoft) for the purpose of rationalizing the sharing of services across business units and business models.  (If you understood the previous sentence, you are probably an enterprise architect, even if that is Not your title).

As a result, I’m on a hunt for the various one-page views that other companies have produced.  The excellent book “Enterprise Architecture As Strategy” (Ross and Weill) provides three tangible examples (Delta Airlines, ING-Direct, and MetLife).  A fourth I found entirely by accident this morning… a very old one drawn by a Disney cartoonist in 1957, and made available here: (http://taotwit.posterous.com/the-visualisation-of-business-models-did-disn).

1957 one page view of Disney

This is an interesting view in that it illustrates the relationships between the business units and how they functionally support one another.  It doesn’t allocate responsibility, but rather demonstrates responsibilities through the relationships.  In effect, it is a somewhat “contractual” view, indicating the accountabilities between business units.  Fascinating for many things, one of which is the date.

The synchronicity of this find is resonating for me because yesterday, a friend and fellow Enterprise Architect within Microsoft named Krishna Srinivasan, shared a very similar view that demonstrated how the functional units of Microsoft could be viewed.  I’m sharing it here because, honestly, the view was so generic that it is difficult to view it as “revealing” anything that someone couldn’t guess.  That said, it is a fascinating, modern depiction of many of the same key concerns that the 1957 view of The Disney Company was trying to illustrate.  One key distinction: in stead of communicating relationships in terms of accountabilities, it demonstrates process relationships (inputs and outputs). 

One bit of brilliance to consider is that you can track the various processes in the company by following the arrows from box to box to box.  It doesn’t quite meet the needs I’m looking for in shared service rationalization, but it does say a lot about how organizations can be represented visually. 

 

clip_image002

How (not) to convince an architect

By |2010-12-09T11:12:10+00:00December 9th, 2010|Enterprise Architecture|

I’ve been watching, with a mixture of dismay and mirth, a LinkedIn discussion between Adrian Grigoriu and a group of Enterprise Architects as he attempts to promote his new business architecture approach.  Now, to be fair, Adrian has already written and published his book, so it is a little late to take constructive criticism from his peers.  Poorly timed discussions are a dangerous thing.

One thing that is clear: the architects on LinkedIn are not convinced that his diagram is actually an architectural model.  To be fair, Adrian has dug a hole for himself by (a) insisting that his diagram is actually an architectural model, and (b) stating that it compliant with emerging standards.  The folks on the forum have rather convincingly demonstrated that both these statements are untrue.  The odd thing is: those statements don’t need to be true.  The diagram doesn’t have to be an architectural model to be a useful diagram.

Not everything that an architect produces must be an architectural model.  I think it is good when we use models because we can defend the view with data, but the imperative of an EA is to be useful first and foremost.  It is entirely possible that, in some situations, Adrian’s diagram would be “useful” without being a model.  Unfortunately, he never describes those cases, so we are left to marvel at his diagram and say “good job” without being sure that we can use it.  Personally, I don’t find it useful.  Alas.

So, what does it take to get other architects to see value in the work you do?  What mistakes did Adrian make when he started the conversation?

  • First and foremost, we all have a certain amount of self confidence in the “goodness of our stuff.”  That can lead to a little bit of self delusion, and every author is susceptible to it.  The key, in a semi-scientific community like EA, is to counterbalance that natural tendency with opinions from peers in a private and trusted conversation, before you go live to the marketplace with your final product.  Scientists discovered a long time ago: peer review matters.  Get your peers to review your work before you publish it, so that you can make statements that are credible, accurate, and compelling without getting involved in pedantic discussions.
     
  • Secondly, Use some of that business savvy that makes a business architect successful and consider your “idea” to be a product.  How would you market that product?  What name would you call it that would be appealing to the people who need to “buy” it?  What would they find credible, surprising, useful, compelling, and easy to share?  Perhaps if Adrian had taken a “marketing” approach to his ideas, he would not have named his framework “GODS,” presented it only from the business process perspective, or ignored the fact that he has represented two (out of dozens) of high level business models as though it were an archetype for all commercial businesses.
     
  • Third, when you want others to believe you, tell a compelling story about how the product came to be, what inputs you used, what experts you relied on, how it has already proven useful in three or more places, how others can use it, and why it is important for your readers to adopt it NOW.  If you cannot weave together all of the elements of a good story, your customers won’t care and you will spend all your time talking to critics who really have no motivation to support you, but plenty of reasons to oppose you.  Not a good place to be.
     
  • Lastly, know when you are selling and when you are collaborating.  His question to LinkedIn was phrased to invite collaboration, but that is not what he wanted to occur.  As a result, his purpose (advertising the book) is defeated, but more importantly, he is unable to collaborate with people who would love to help him, but cannot because he did not ask for help at the time when it would have been useful: before the book was out the door.

I wish Adrian good luck with his efforts, but more importantly, I hope to learn from his mistakes.

Creating a compelling visual story

By |2010-12-03T17:14:00+00:00December 3rd, 2010|Enterprise Architecture|

One thing that I’ve become fascinated with over the past few years is the difference between people who have good ideas, and people who use good ideas to bring about change.

I’m not alone to notice that the folks who originate a concept are usually NOT the ones who get the credit for it… it is the person most associated with sharing that idea with the widest number of people in the most consumable manner.  We see this in all fields: technology, industry, science, math, politics, etc.  No matter what field you are in, the ability to create an original idea is not the most important thing: the ability to make that idea understandable, compelling, and consumable is.  In fact, the idea does not have to be new to be made new through a compelling and interesting presentation.

For Enterprise Architects, this is a huge concern.  Most EA folks rise through the ranks of technology or business, in fields that traditionally value accurate and specialized outputs.  For a technologist, this could be source code, a BPMN business process model, an excellent project plan, or a UML architectural diagram with very specific semantics.  For a business person, this could be a financial analysis, a process dashboard, or a quality control performance review.  Specific technical outputs like this are rewarded and people rise through the ranks, many landing in business management, planning, or enterprise architecture positions. 

But now, a new skill is required: the ability to influence your peers.  Business and Enterprise Architects frequently find that their transition into this role is a rocky one, because they go from a world of detailed, well-defined, well ordered artifacts that people use to perform their jobs, to a near-cacophony of variable deliverables that are useful because they motivate leaders and SMEs to change things.  Technical architecture roles are usually design roles.  EA and BA are change-agents.  Talented architects can stop their forward progress at this point, and many will.  Using your considerable technical skills to convince people is not appealing to everyone, and many folks prefer to stay in the world of specific, accurate, and measurable artifacts that well-motivated people are simply expected to use. 

We need to go from presenting data to telling stories.

For this post, and many to follow, I will attempt to highlight an example of a visual story that I found interesting, compelling, or thought provoking.  In each one, I will ask you, the reader, to consider the core elements of the story: What is the central theme?  What action are we hoping to compel?  What element of the story did a good job of catching your attention.  What questions does it raise?

First post is a video that has made it’s rounds on Twitter of late.  This is a visualization of information collected by noted statistician Hans Rosling, presented in a unique and fascinating manner.  First the video:

 

Now, for the questions to consider:

  • What was Roslings’ purpose in sharing this information with us today?  To inform, to inspire, to motivate, to delay, or to convince? 
  • What makes the presentation credible?  Do we believe him?  Do we trust him?  Why or why not?
  • What makes the presentation enjoyable?  Do we want to hear more about this topic?  Do we want to hear more from this presenter?
  • What makes this presentation memorable?  Is it unexpected?  Concrete?  Simple? 
  • Did the presenter use the information to tell a story?  Are there characters, plot, conflict, and resolution?  Do we identify with it?
  • Could this kind of presentation be used to inspire change?  What would need to be added?

 

Visual Story Review

Each time I present a visual story, I will also provide my opinion of it using questions like the ones above

I found the presentation very engaging.  The speaker has presented this material before, making references and manipulating the presentation in ways that illustrate a deep understanding of the information underneath it.  He slows down, for example, to illustrate the effects of specific world events.  He draws grand conclusions and illustrates trends.  That builds credibility.  I come away feeling that he is not only a good presenter, but that he is a thought leader that I could trust when I want to use that data.

The presenter makes moderately good use of the technology.  The graphs are interesting and accurate, but the cinematography is not particularly good.  Why film in a loft?  The choice of location (apparently an empty warehouse) detracted from the presentation and made it a little tougher to read.  Plus, with all the technology at his disposal, why use such flat chart graphics?  Three-dimensional objects, especially ones with images of specific country flags, would be been much more compelling than flat mono-color circles.

What he doesn’t do is motivate specific action.  I don’t identify with the data, nor do I use it to affect the choices I make in my daily life.  I don’t know if Roslings is hoping that I will change my behavior, spend more (or less) money, buy (or avoid) certain products, support specific causes, or vote for candidates that share specific ideas.  (It appears that his decision to take an impartial viewpoint was intentional on his part, and I laud him for it).  On the other hand, the presentation DOES inspire me.  His presentation gives me ideas that I can use when I want to tell a story: thoughts about how to visualize information, make it compelling, or boil down a mountain of data to create knowledge.  I can mimic his techniques in my own work, and for that reason, I find the presentation both informative and valuable.

If you have suggestions for specific visual stories that you’d like to share, please send me a link from the blog.  I’ll look into it and if I agree that the presentation is interesting for a discussion on “how to change things,” then I will post it.

Drawing Effective Technical Diagrams

By |2010-04-29T09:41:00+00:00April 29th, 2010|Enterprise Architecture|

As architects, we spend a good bit of time trying to get a very complicated set of ideas communicated in a clear, consistent, and understandable manner.  A simple diagram with a clear story can be very compelling.  A poor diagram can actively sink your efforts. 

A great example of a poor diagram appeared on the front page of the New York Times a few days ago.  This horrible diagram attempts to describe the complexity of the US Afghanistan Policy in the war we are fighting there.  The diagram didn’t have a clear message, metaphor, or organizational method that allowed key observations to be drawn from it.  (copied below)

About the only decision that this diagram supports is “simplify this.”  But there is no clear way recommendation on how to do that, the areas that need the focus first, or even the rationale for the complexity that has emerged. 

091203-engel-big-9a

So what can we do?  We live in a complex space.  We’ve all delivered complex diagrams before.

I got a note from another architect this morning pointing to a masters thesis produced in 2006 by Noah Iliinsky at the University of Washington.  This masters thesis, titled Generation of Complex Diagrams: How to Make Lasagna Instead of Spaghetti , provides a great deal of good information on how to tell if your diagram is any good, and how to develop a better diagram for the audience at hand.

Direct link to PDF: https://digital.lib.washington.edu/xmlui/bitstream/handle/1773/3100/iliinsky_complex_diagrams.pdf?sequence=1

Reference: https://digital.lib.washington.edu/xmlui/handle/1773/3100

It’s a good paper, and worth a look for any architect wanting to learn to improve the kinds of diagrams that they produce, and best guide the decisions that need to be made.