“Game films” - Our latest knowledge management tool

Top Gun and knowledge management   © Paramount Pictures

Sometimes writing is just too slow.

A couple of weeks ago I was on a  GoToMeeting session with Bob Batcheler of Newforma. Batch and I were developing content for a webinar called “Transforming data into knowledge: PIM and knowledge management.”  Batch had prepared his thoughts on project information management and I had prepared my slides on knowledge management. Our GoToMeeting session was the first time we had combined our slides and we were working through the mechanics of stitching our complementary narratives together.

I presented first. I quickly found myself scribbling note after note after note in my journal. Every time I would get a bit of momentum going, Batch would interject and throw out a question or build on my ideas. Which in turn lead me to reframe or clarify my thinking in ways in which I wanted to remember for our live performance. Hence the mad scribbling.

The problem with the mad scribbling approach was that it was too slow. In the middle of a burst of new ideas I’d say, “Hang on Batch – slow down, I want to capture this.” 

After several minutes of me imposing a  “burst-capture, burst-capture” rhythm Batch suggested we just record the GoToMeeting session so that I could stop taking notes and focus on producing a stronger story. Because recording a GoToMeeting session captures both audio and video, I could “study the film” later to pick up any changes, notes, or techniques worth incorporating.

Record the GoToMeeting session. It was so obvious.

My first “game film.”

Not only did recording the joint-writing session capture the raw ideas I was trying to write down – I also captured the tone, pacing, and inflection of my new “talking points.”

At one point, Batch really liked how I opened a particular slide.  I said, “hit this point hard, right here and pause for effect” into my microphone knowing that I was leaving myself a trail of notes to pick up later. In effect, I was “pre-coaching” myself.

After our meeting was finished, Batch uploaded the video to me. I watched the film several times, harvesting the best parts and eliminating the filler bits.  Recording the collaborative session improved both the quality of our webinar and improved my ability to recall the essence of the ideas we co-authored. (I’m sure it will also be amusing to look back on it later.)

Best of all, I had learned a new technique for creating and capturing knowledge. I called it my “game film.”

Meanwhile, in the office next door…

I have previously written about our methodology for performing Deltek Vision – Newforma Project Center (DV-NPC) integrations to illustrate how Knowledge Architecture invests in knowledge management. In this blog post, I explain how Brian created a checklist to transfer his knowledge of performing integrations to Chad. I also pointed out the limitations of checklists for knowledge transfer:

But there is more to bringing Chad up to speed on DV-NPC integrations than handing over the the knowledge explicitly contained in the checklist.  Brian also has experience and intuition (tacit knowledge for the KM geeks out there) which are not so simple to codify in a document. Our tactic here is for Chad to shadow Brian on enough DV-NPC integration engagements so that Chad can take over primary responsibility for delivering them in the future.  And of course, Brian will always be available as a backstop for questions.

Back to the brainstorming example above. I told the KA team about the experience I had with Batch at our next weekly meeting. As I began to enumerate the benefits of recording GoToMeeting sessions Chad interjected,

“Yeah, that’s a cool idea. I recorded the GoToMeeting session of the last DV-NPC integration I did with Brian last week. Good tip though.”

Chad went on to explain how valuable recording the integration process (several hours in length) had been. Not only did he capture the step by step process of tying the two systems together, he also captured Brian’s perspective on why he did things the way he did as well as  his experience in handling exceptions that might come up in other customer environments.

Chad found his way to recording the GoToMeeting session for the same reason that I did. Instead of scribbling “one-dimensional” notes, Chad was able to capture the rich knowledge contained in the video and his conversation with Brian. 

After the integration was completed, Chad studied (and continues to study) the “game film” much like a professional football coach reviews the tapes from Sunday’s game on a Monday to improve the plan for the next week. Or a surgeon reviews her latest operation to improve her technique. Or a group of fighter pilots (see Top Gun above) have “rankless, nameless debriefs” to accelerate the learning process of the whole squadron by performing root cause analysis of the flight plan’s execution to transfer lessons learned. 

Another knowledge management tool for your toolbox

Storytelling. Interviewing. Cookbooks. Host a conference.

Over the past several months I have written about the knowledge management tools that we use at Knowledge Architecture. Add game films to that list.

While game films are new to us, we have lots of ideas about how we can use them — documenting complex procedures, facilitating group learning and knowledge transfer, training new staff, and collaborating on process improvement come to mind.

We’ll keep you posted on our progress in implementing this new tool.

Looking for a proven way to transfer knowledge? Write a “cookbook.”

Julia Child and Knowledge Management

I like to begin conversations about knowledge management by talking about Julia Child. Julia’s travels through France, her education at Le Courdon Blue cooking school, and time teaching at an informal cooking school for American women in Paris – her experiences acquired over time - all became part of her personal knowledge base.

Julia’s informal cooking school was in fact, a collaborative effort with two other women, Simone Beck and Louisette Bertholle. Simone and Luouisette had already been working on a French cookbook for Americans and invited Julia to join them in order to make the book appeal to Americans. According to our good friend Wikipedia, “over the next decade, the three researched and repeatedly tested recipes. Child translated the French in English, making the recipes detailed, interesting, and practical.”

Julia Child was able to transfer her tacit knowledge (experience she had acquired over time) of French cooking into explicit knowledge (knowledge that can be reduced to a set of instructions)  through writing cookbooks. Millions of American women (and men) have read Julia Child cookbooks and learned from her experiences in France in the 50s.  

The Swiss Chef and his Cookbooks

My first manager after graduating from college was a Swiss technologist named Hannes Rosskopf.  Hannes possessed the traits you would stereotypically associate with the Swiss. He was precise, detail-oriented, and demanding.  I appreciated Hannes’s rigor because I knew that he was helping to mold me into a stronger consultant.  (Well, I almost always appreciated it.)

However, I believe what made the most lasting impact on me was Hannes’s approach to teamwork and personal development.  The first e-mail I ever got from Hannes went something like this:

Chris,

Glad to have you as part of the team. You will be helping me to write cookbooks.

Hannes

It turned out Hannes had also recently joined the company. He had been tasked with developing a standard methodology for our practice group. It was the dot-com bubble and our company was growing.  Our previous team leader no longer had time to provide technical leadership to the group because he had moved into a marketing and sales role. Charged with arming a hungry but inexperienced group of recent college graduates with technical knowledge  – Hannes borrowed a page from Julia Child. He decided to start writing cookbooks.

Hannes’s objectives differed from Julia Child’s in one major aspect. Julia Child aimed to transfer her knowledge to a sea of home cooks, most of whom she would never meet. Hannes’s predicament was more analogous to an executive chef starting a restaurant. His aim was to transfer his experience to a team of sous, prep, and line cooks so that he could further leverage himself over multiple projects.  Julia Child aimed to help her audience build their personal knowledge.  Hannes’s goal was to help build organizational knowledge. 

And so, I found myself busily writing procedural documents for building new e-mail servers, checklists for installing backup and recovery systems, and documenting rollouts of new software applications. Hannes curated, edited, and published this massive  collection of Microsoft Word documents to the team. He called this collection of explicit knowledge his “cookbooks.”

Often times, Hannes would lay down the outline of a new cookbook and seed it with his own knowledge. However, Hannes was most interested in enlisting us to improve the cookbooks because he knew that the process of writing cookbooks would help us to learn our subject matter better than simply following his procedures. Knowledge management in our team meant the following:

Figure out a new way to shave 3 steps off of a checklist that he wrote? Update the cookbook. Learn the hard way that the way we had been installing a certain piece of software was introducing conflicts with another piece of software? Update the cookbook. Need to learn how to perform a process that you’ve never done before? Read the cookbook. The cookbook doesn’t  exist? Write a cookbook. Then tell the team about it.

Hannes was relentless and systematic in his approach to creating, capturing, and sharing knowledge. In doing so, he not only built a library of explicit knowledge (cookbooks) with clear monetary value, he also leveraged his experience to grow a  team of consultants with a shared methodology for doing quality work.     

Crafting the Knowledge Architecture Menu

I continue to be surprised at how many “cookbooks” it takes to run a consulting practice. Knowledge Architecture will be one year-old next month. One of the things I have repeatedly told people over the last year is that I have felt like we were constantly doing things for the first time. 

Proposals. Contracts. Invoicing. Bookkeeping. Filing incorporation papers.  Checklists for welcoming new customers. Checklists for hiring new employees. Templates for developing information system roadmaps. Templates for developing intranet roadmaps. Planning guides for employee databases. Planning guides for project databases.  Procedures for performing integrations. Procedures for installing SharePoint. The list goes on and on.

Each of these cookbooks not only required an initial version, but now require constant revision as we acquire new knowledge through our daily work. However, I can sense that we are turning the tide on the volume of initial knowledge capture as we enter our sophomore year. While there is theoretically an infinite amount of knowledge to capture in cookbooks, not all knowledge is created equal.

We are focused on writing cookbooks which help us to do at least one of the following three things: perform quality work, increase profitability, and/or enable us to leverage each other and grow as a team.

Bon Appétit

If you are an architect who specializes in residential design, you probably carry around a library of unit plans which you have built over time. If you are a job captain, you probably have a checklist (at least a mental one) for transferring BIM models between members of the design team. As an HR professional, you probably have a set of  guidelines for your technical staff which you tell them before they interview new staff.

You are all cooks. You have acquired a large body of tacit knowledge over time through your work experiences.

There are more tools than ever before to help you create, capture, and share knowledge. Intranets, blogs, wikis, podcasts, and cheap video cameras to name a few.

Harness your knowledge. Write your cookbook.  Share it with your team.

You’ll never cook alone again.

“Do Not Hurry; Do Not Rest” – On Acquiring New Knowledge

How it begins

A couple of weeks ago I interviewed Josh Lobel to speak at KA Connect. Josh is an architect with a deep interest in the impact that digital  tools have on architectural practice.  A mutual friend had introduced us and had mentioned to me that Josh was a big fan of “The Craftsman” by Richard Sennett. I checked “The Craftsman” out from the library and have been recommending  it to people to ever since.  Here’s what the New Yorker has to say about it:

“Sennett considers an array of artisans across different periods, from ancient Chinese chefs to contemporary mobile-phone designers, in this powerful meditation on the "skill of making things well." The template of craftsmanship, he finds, combines a "material consciousness" with a willingness to put in years of practice (a common estimate of the time required to master a craft is ten thousand hours) and a strategic acceptance of ambiguity, rather than an obsessive perfectionism.”

Sennett discusses the history of knowledge transfer throughout the book. Organizations have always wrestled with best practices for educating the next generation of craftsmen, whether they be the  guilds of medieval Europe or modern design firms. In addition to exploring the history of organizational learning, Sennett explores what humanity has gained (and lost) from introducing machines into our workshops. Sennett specifically focuses on the impacts of using CAD tools in architectural practice.

Josh and I started our conversation by discussing “The Craftsman.” Our conversation was energizing and fun. As we jumped from topic to topic – discovering that each of us had been thinking about history and process and tools  and practice from different perspectives – I kept thinking one thought to myself:

“Damn I wish I was recording this.”

Interviews as knowledge assets

I sent Josh an e-mail the next day to pitch him on the idea of conducting an audio interview for the KA Connect blog. He wrote me back to say that he was in. Awesome. We’d produce it as a podcast, perhaps the first in a series. The wheels were turning now. I thought of all the other people I could interview, the sponsorships, the glory.

As the days went by I kept thinking about great having a podcast series would be – I’ve advocated interviewing as a great knowledge management technique for years. A good interview helps to tell someone’s story. If you ask the right questions,  your interviewee will often share insights that they had not previously articulated, even to themselves. (The knowledge management intelligentsia calls this “Latent Knowledge.”)  Best of all, you can capture an interview and leverage it as a reusable asset – whether as a blog post, podcast, or video.

Perfect. I’d lined up the essential elements for a new knowledge management initiative  – create knowledge, capture it as a reusable asset, and then share it via multiple channels. There were only two problems with my plan:

1. I didn’t have any experiencing interviewing people.
2. I had never put together a podcast.

How I acquire new knowledge

Most of the writing I’ve done on this blog has focused on organizational learning, not personal learning. In addition, I’ve focused on leveraging existing knowledge, neglecting acquiring new knowledge.

My desire to create a series of interview podcasts got me thinking about how I learn new skills. Unlike the apprentices in “The Craftsman,” I’m not in a guild.  There is no master to pass down knowledge honed over generations. In addition, many of the skills I want to acquire (i.e., podcasting) were invented in the last few years.

Founding Knowledge Architecture has required me to develop the ability to rapidly acquire new skills. When I reflect back on jumping into sales and marketing, accounting and finance, product marketing and development and the countless other new things I have begun to learn over the last year – I can tease out three sources of knowledge which I repeatedly target :

People. Books. Blogs.

People – It turns out that I’m lucky. Josh’s sister Mia is an audio producer and journalist who specializes in podcasts. She and I talked last week and she gave me a wealth of advice and pointed me towards a long list of resources. (Talking to as many people who have knowledge on the topic in question is always my first step in learning a new skill.)

Books - I’m headed to the library this afternoon to pull a couple biographies of interviewers. I’ll probably also pick out a couple “best practices”-type books. (In general, I tend to prefer biographies to best practices books. The insights tend to stick with me better.)

Blogs – I’ve already started adding blogs about podcasting to my Google Reader. Blogs are a particularly good tool for learning modern skills such as social media and emerging technologies. However, blogs work equally well for learning “old-school” skills like marketing, business development, and writing. (The evidence of prior  knowledge acquisition sprees is clear in the image below.)

“Do not hurry; do not rest” - Goethe

Once I’ve gathered some interviewing and/or  podcasting experiences from other folks, books, and blogs, it will be time to to just try it. Record my first interview. Share it. I can refine and tweak from there. I’ll probably even write about podcasting and interviewing to help me crystallize my thoughts on the subject.

I like what Goethe says about pacing yourself in life - “Do not hurry; do not rest.”

I think his quote also applies to learning a new skill. Take a bit of time to do some research – but get on with it. The doing is where the real learning happens.

What about you? How do you acquire new skills? Feel free to share in the comments below.

KA Dialog #1 – Part 5: Leverage yourself, and each other

“Give me a place to stand on, and I will move the Earth.” Archimedes

This post is the fifth in an open dialog with Bob Batcheler of Newforma. Here are links to Part 1: Knowledge management is squishy, Part 2: PIM is like a bunch of boxes… , Part 3: Information Disasters vs. Knowledge Disasters and Part 4: Disaster Prevention and Recovery (PM and KM Style) for reference.

Batch,

Happy New Year! I apologize for the delay in responding to your last post. I spent December on the road talking to all kinds of folks about knowledge management on both a strategic and tactical level, including Newforma. My journal is full of anecdotes, techniques and lists of ideas – many of which I’m sure I’ll be sharing on this blog.

I have a New Year’s day ritual that I’d like to share with you. I have a personal journal and a Knowledge Architecture  journal. At the start of every New Year I brew some coffee (this year I went to Starbucks)  and read through the previous year’s journal entries chronologically. Beyond having a good laugh at false assumptions and worries that never came to pass - I look for patterns that emerge or phrases that repeat. This year, one cluster of phrases from my Knowledge Architecture journal stood out:

“Leverage yourself.” “Leverage yourself and your organization.” “Leverage technology to…” “At its core, knowledge management is about leverage…”

A scan over my blog posts, website, and workshop materials confirms that leverage was my word of 2009.

Knowledge management and leverage

I know what you are thinking. 

“Good for you Chris, after a year of writing you have discovered that the point of learning and using technology is to leverage yourself.  I’m sure that Archimedes would be proud to personally welcome you the last two millennia of human progress .”

Fair enough, but I think that there is more to it. You closed your last dialog post with the following questions:

So, Chris, the question to you is, as you build your business, how are you investing in building KA’s knowledge assets?  Or are the cobbler’s children running around without shoes?

Building a new business  in a recession (the DJIA was around 6,000 when we launched in March, 2009) has led us to deeply embed bootstrapping and leverage deeply into our culture.

As you know, we are a small company with limited resources. While it is true we are growing, the wisest investments we are making are into leveraging our people and their knowledge.

I am also seeing this approach from our customers. Many of them do not anticipate hiring in 2010. They have cut the fat from their budgets, and many have gone further. So what’s left? The prevailing cliché is “doing more with less.” Which is exactly right as long as you move beyond simply repeating the slogan and waiting for change to magically appear.

I believe that “doing more with less” means creating, capturing, and sharing knowledge assets to leverage yourself and your team so that you can work smarter, faster, and more profitably. 

The silver lining for 2010 is that now is a perfect time to invest in becoming a knowledge-driven firm. Let me nail that down with some specific examples on how Knowledge Architecture is leveraging knowledge assets both individually and as a team.

Everyone is their own knowledge manager

My wife, Denise,  serves as my own personal Peter Drucker – asking me Yoda-like questions when I am stuck. Here’s a question that she asks me on a regular basis which is an excellent jumping off point for discussing knowledge management at Knowledge Architecture (and beyond):

WIIFM – What’s in it for me? As in, “what’s the WIIFM for X person?”

For Brian Campbell, a Senior Consultant with Knowledge Architecture, the WIIFM for developing a checklist for performing Deltek Vision – Newforma Project Center (DV-NPC) integrations is to be able to nail every integration efficiently and right the first time.

Why? Beyond the obvious high level of pride that all of us take in our work – we have a couple of structural elements built into our business model which support a knowledge-driven culture. The first is that we run open-book financials and share profits based on firm performance. In addition, all of our integrations are supported for a year under our subscription plan. This means that Brian (and all of us) are personally invested in performing our fixed-fee engagements both efficiently (profit-sharing) and right the first time (preventing costly and embarrassing re-work.)

Leverage that asset

Let’s keep following the DV-NPC integration checklist asset through the organization to see how we can leverage it in marketing and sales.

My primary roles at Knowledge Architecture are marketing and sales, product management, and corporate operations. There’s a WIIFM here for me as well. I obviously need to be able to talk about features and benefits of our products and services when I’m meeting with a potential customer. However, the knowledge asset (checklist) created by Brian also allows me to speak confidently about the process and provide accurate estimates for our fixed-fee services. In addition, our standard proposals and contracts are derived from our methodology.

Furthermore, our debrief after every integration engagement (yes, we do closeout meetings) ensures that our methodology and our marketing materials stay in sync. I’m not selling something Brian can’t deliver and he’s able to update the team on the latest lessons learned and updates to our checklist.

Our continuous feedback loop ensures that I’m not selling something our consulting team can’t deliver and we’re all aware of the latest changes to our methodology.

I suppose this might be described as the WIIFU – What’s in it for us?

Growing the firm and sharing knowledge

As you know, we have recently hired my brother, Chad Parsons, to join us as our Director of Engineering. Chad’s primary responsibilities include overseeing delivery of our solutions, software development, and internal technology operations. Welcome Chad!

One of our top priorities is to transfer our DV-NPC integrations from Brian to Chad. We have a couple new initiatives in the first quarter which are more applicable to Brian’s background, experience, and skillset than Chad’s and we want to free him up.

In order to leverage Brian and Chad appropriately — our knowledge asset is on the move again.

But there is more to bringing Chad up to speed on DV-NPC integrations than handing over the the knowledge explicitly contained in the checklist.  Brian also has experience and intuition (tacit knowledge for the KM geeks out there) which are not so simple to codify in a document. Our tactic here is for Chad to shadow Brian on enough DV-NPC integration engagements so that Chad can take over primary responsibility for delivering them in the future.  And of course, Brian will always be available as a backstop for questions.

Is it inefficient and expensive for us to have both Brian and Chad work on integrations in January and February? The short-term answer is yes. But in the long run we are investing in creating assets and leveraging our people appropriately, ensuring that we are working smarter, faster, and more profitably.

Back to you

The most successful knowledge management examples I saw last year were almost always bottom-up, instead of top-down.  They all had a WIIFM and many times that benefit was the ability for an individual to magnify their personal impact or that of their team by creating, capturing and sharing knowledge.

Which leads me to my questions for your next post:

As a software company who has a five-year head start and thirty employees on us, I’m interested in learning how you are investing in building Newforma’s knowledge assets? How are the lessons learned from both of our companies applicable for our architecture and engineering clients?

Best,
Chris

Bob Batcheler is Newforma’s vice-president of industry marketing and product management. Bob’s career as a professional engineer includes time at Black & Veatch and Bechtel Power Corporation. His AEC technology background encompasses a variety of roles at Autodesk and Softdesk. Bob earned bachelor’s and master’s degrees in civil engineering from Lehigh University, and qualified as a registered professional engineer in Maryland.

What Field of Dreams gets right (and wrong) about knowledge management

                                                                                                    GORDON COMPANY

“If you build it, he (they) will come.”

We’ve all heard the voice at some point. Inspiring us to build something transformational. Once it is clear that ”it” must be built, nothing will stand in our way.

Like Ray Kinsella in the movie “Field of Dreams,” we are convinced that our “it,” in his case a baseball field, is so compelling that once the word gets out that “it” is finished – people will come from miles away (and even back from the dead) just to take part in it. The bleachers will be full. The players will relive their glory days. And best of all, we will recline on the sidelines, drinking a lemonade, basking in the sunshine and brilliance of our creation.

The End.

(Roll credits.)

“If you build a lessons learned database…”

Over the last two weeks I ran two more workshops on “Knowledge-Driven Architecture”. One was hosted by AEBL’s San Francisco Chapter. The other was hosted at a large architecture firm in Seattle.

At one point in my workshops I ask the participants to break out into small groups and create an inventory of their firm’s “structural knowledge assets.” Structural knowledge assets* are the databases, written procedures, practice manuals and other explicit materials that capture the experience you have acquired over time. I ask the small groups to brainstorm at least ten structural knowledge assets. At the end of the exercise I ask the small groups to pick the most important one.

Lessons learned databases are emerging as the top structural asset identified by workshop participants. It appears that most firms are building lessons learned databases. They heard the whisper to build “it.” Then they went out and built it.

“…will they come?”

Not so much.

At least that seems to be the feedback I’m hearing when I ask the follow-up question “are the lessons learned databases being used?” In many cases, one or two passionate individuals (like Ray Kinsella) take the time to create lessons learned - converting the experience they have acquired into an asset that can be leveraged by the rest of the firm.  This process is fundamentally a writing exercise, though the asset might additionally take the form of a video or presentation.

Once our writers have created their lessons learned, they put on their librarian hats and capture the knowledge assets in a database or post them to the intranet. Our librarians thoughtfully organize the lessons learned.  They develop keywording taxonomies and ensure that the lessons learned are searchable by everyone. Many times the lessons learned are organized by client, building type, CSI division or any number of familiar and convenient hierarchies.

And then they wait. Like Ray Kinsella.

But unlike “Field of Dreams,” “they” don’t come. Our writer/librarians are on the sidelines of the field. They’ve got their lemonade. But there are no players on the field and no fans in the bleachers.

Why aren’t people using lessons learned databases? And why is Hollywood misleading us?

The missing third act of “Field of Dreams” 

Act One

Our writers created knowledge assets.

Act Two

Our librarians captured knowledge assets.

Ending

The staff doesn’t leverage the lessons learned.

Knowledge Management is the process of leveraging yourself and your organization through the systematic creation, capture, and sharing of knowledge assets.

Act Three (Missing)

Our teachers shared knowledge assets.

Ending (Take two)

The staff leverages the lessons learned and our protagonists have helped to build a knowledge-driven firm.

“If you create, capture and share lessons learned, they will come.”

I’m sure that in practice, folks are notifying others that they have created and captured knowledge assets. But there is notification and then there is systematically sharing. Or in other words — teaching.

We have to continuously share our knowledge assets through teaching.  The work of knowledge management is never done. Knowledge management is a process, not a project. Most important, knowledge management is people-driven.

You’ll meet three types of people in a knowledge-driven firm – writers, librarians, and teachers. Writers create. Librarians capture. Teachers share.  The teaching part, the commitment to systematically sharing, is what’s missing. We are two-thirds of the way there. We just need to finish the job. “Go the distance.”

Here are five ideas for systematically sharing knowledge assets such as lessons learned that I have harvested out of the workshops and consulting work that we do at Knowledge Architecture:

1. Create a best practices manual from your lessons learned database.
2. Institutionalize the best practices as processes by using simple tools such as checklists.
3. Develop an ongoing program where members of your staff teach modules of the best practices manual. 
4. Tie bonuses and promotions to teaching.
5. Improve your best practices manual by continuously creating, capturing, and sharing.

What do you think? Does this resonate? Do you have more ideas for sharing knowledge assets? E-mail me or leave comments below.

Chris

I’ll be leading a knowledge management workshop with AEBL in Orange County on December 10th. Click here to register or learn more about the “Knowledge-driven Architecture”  management roundtable.

*Credit to Thomas K. Stewart’s “The Wealth of Knowledge” for the framework.

KA Dialog #1 - Part 3: Information Disasters vs. Knowledge Disasters

                                                                                                               TOHO CO. LTD.

This post is the third in an open dialog with Ian Howell and Bob Batcheler of Newforma. Here are links to Part 1: Knowledge management is squishy and Part 2: PIM is like a bunch of boxes… for reference.

Ian and Batch,

Batch’s last post about “information boxes” got me thinking about “knowledge boxes.” And since you brought up using the idea of an information disaster to illustrate the importance of project information management, I thought I’d pick up on the thread and extend it to knowledge disasters.

Let’s start with two exercises. (If you aren’t Ian or Batch – you should play along at home as well.)

Exercise # 1 – Information Disaster

Clear your mind. Think about the “boxes” that you referenced in your last post. Specifically, visualize the contents of projects on servers or in the “CDs/DVDs in filing cabinets and paper drawings in boxes stored offsite by services like Iron Mountain” that you mentioned.

Now, imagine that your building burns down. What types of information artifacts would you lose?

Task - Write down at least 10 information artifacts you would lose. (Humor me here, you’ll see why at the end.)

Exercise #2 – Knowledge Disaster

Let’s try this again. Only this time, imagine that a couple senior folks in your company have just told you that they are leaving. Not only are they leaving, but they are setting up shop across the street. Not only are they leaving and setting up shop across the street, but their first client is actually one of your best clients and oh…by the way…they are taking about ten of your best people with them.

Now I hope this does not happen to you. But it happens all the time. It is how most companies get started.

When companies are confronted with the question “What is your company’s greatest asset?” the answer is some variant of “our people.”

So let’s try a second exercise…

Think about the scenario I described above. When those twelve people walk out the door to start their new company what types of “knowledge assets” would you lose? In other words, we’ve established that our people are our greatest assets, so what exactly is the impact of the disaster?

Task - Write down at least 10 knowledge assets that you would lose.

We don’t prepare for Knowledge Disasters like we prepare for Information Disasters.

Here’s an excerpt from Batch’s post last week:

This leads to an interesting potential thought exercise in promoting the value of project information and knowledge management in an AEC organization. I suggest you go back to the CIO in your story to ask, “What would be the impact of your firm losing all of the information associated with any one of your major projects over the past three years?” I suspect he would characterize that as a disaster, right? Then ask a follow-up question – “What would be the impact of being unable to find a key piece of information required to avoid a claim?” or “What would be the impact of hundreds of hours of skilled labor, from a project manager and IT support, required to find the information required to respond to a claim?” If he is honest with you, he will admit that the scenarios depicted in each of the follow-up questions is nearly as dangerous as the obvious disaster of outright data loss.

I don’t have to go back to the CIO in my story and ask those questions. I already know the answers and so do both of you. Of course he would agree that your scenario was a disaster and that the inability to discover data is nearly as dangerous.

Back to Exercise #1. I bet your list (you did write it down didn’t you?) looks something like this.

Sample project directory from Knowledge Architecture.

I believe we have a strong understanding about what information loss looks like because information artifacts are so quantifiable. The extent of our familiarity with the risks of poor information management procedures is evidenced by a robust,  information-centric disaster recovery industry.  Those risks are underscored by the amount of time and effort first put into disaster recovery planning on an annual basis.

At the same time, my observation is that companies don’t have an inventory of  knowledge assets written down. They don’t have  strategies to prevent losing knowledge assets in knowledge disaster scenarios like the one I illustrated in  in Exercise #2, people walking out the door. I had never heard the phrase “knowledge disaster” until I started working on this post. (Looks like “the Google” hasn’t either.)

Why is this? Why are we prepared for information disasters and not knowledge disasters?

Knowledge management is not squishy, it is simply more difficult than information management.

Knowledge management is more difficult than information management because it requires people to do something. Knowledge management is unlike information management in that we have to intentionally create, capture and share knowledge assets whereas information artifacts are the by-products of our daily work.

Now, I’m not saying that information management is easy. I most certainly understand the challenges that come along with the unimaginable volume of information architects and engineers generate annually. I think that project information management (PIM) tools such as Newforma Project center have made information management far less daunting.

But to put it quite simply…

Managing information artifacts is a challenge of abundance. Managing knowledge assets is a challenge of scarcity.

I want to close by picking up on the last line in your post from last week.

“…our shared belief (is) that AEC organizations must manage their project information effectively in order to have any hope of transforming that information into knowledge.”

I like the idea that there is hope for transforming information into knowledge.  Your comment implies that perhaps technology can aid with our “scarcity of knowledge assets” problem by doing some of the heavy lifting for us. 

Can Newforma Project Center help firms to transform information artifacts into knowledge assets? Could Newforma help firms to prevent knowledge disasters?

Looking forward to your next post. And happy unpacking.

Chris

Ian Howell is Newforma’s chief executive officer. He’s an architect by training, with practice experience in Australia and the United Kingdom. His AEC software industry experience includes positions with Autodesk, Citadon, Alias Research and Rucaps Australia. Among his contributions to the AEC software industry, Ian is a founder of the International Alliance for Interoperability, and currently serves on the board of direction for the buildingSMART Alliance.

Bob Batcheler is Newforma’s vice-president of industry marketing and product management. Bob’s career as a professional engineer includes time at Black & Veatch and Bechtel Power Corporation. His AEC technology background encompasses a variety of roles at Autodesk and Softdesk. Bob earned bachelor’s and master’s degrees in civil engineering from Lehigh University, and qualified as a registered professional engineer in Maryland.

3 things I learned about knowledge management from Seattle firms

Maximus / Minimus  serves spicy pork sandwiches on Pike street. (Photo credit: Denise Parsons)

Two weeks ago I facilitated the first “Knowledge-Driven Architecture” workshop in Seattle.  (Thanks to LMN Architects and Tim Rice for hosting us and AEBL for providing the forum.)

The structure of the workshop was simple — I introduced a framework for knowledge management and then we explored it through a series of interactive exercises. You can review the raw output from the exercises here.

As expected, most firms are using some combination of practice experts, lunch and learns, <insert firm name> universities, intranets and other proven methods to share knowledge. However, three items really jumped out at me during the workshop:

1. Patents on designs are great assets that can be leveraged long beyond their “expiration date.” Furthermore, the firm I’m referencing openly publishes the design, but clients continue to come to them for their implementation expertise instead of using a competitor.
2. Architecture and engineering firms can sell “subscription-based services.”  In fact, the firm I’m describing  refers to these long-term clients as “annuity clients.” Intimate customer knowledge combined with proprietary software designed to enable their client to manage their facilities portfolio…what a killer example of  knowledge management driving the top and bottom lines.
3. More firms are using open-book management to promote financial literacy than I thought. A couple weeks ago I wrote that “… opening the books and teaching basic business literacy might be one of the most powerful, untapped ideas for sharing knowledge that I’ve ever seen.“  Several of the firms in the Seattle workshop have been doing this for years.  Well, it looks like I need to get out more.

All of us have knowledge assets. Market-sector expertise.  Project management procedures. Technical details. A personal collection of space-planning diagrams. We create these knowledge assets through our daily project work. Yet the key to becoming a knowledge-driven firm is capturing your assets and sharing them with your organization. We should always be asking ourselves, “What are my assets and how well am I leveraging myself?”

In our final exercise, “leveraging your assets,” I asked the participants two questions. “What is the number one asset you are sitting on that you are committed to sharing?” “Which leverage technique are you going to use to share it?” I then agreed to follow up with them in a month to check on their progress. Here are three examples:

Participant A

Asset: Relationships with two major public clients in the region who won’t “let go” of me.

Leverage: Communicate the importance and value of others in the firm who know more than me to the client. 

Participant B

Asset: Information from conferences and presentations. (like this one.)

Leverage: Create a subscription-based model to alert people to new assets, recorded presentations being available.

Participant C

Asset: Firm financial management.

 Leverage: Hold sessions for employees to understand the basics of financially managing a firm.

The good news about knowledge management is that you are the key to making it happen. You don’t have to wait for a knowledge management committee, a corporate knowledge-sharing initiative, or a new intranet to get started.

Make a list of your assets and then start leveraging them.

Best,
Chris

I’ll be leading knowledge management workshops with AEBL in San Francisco on November 4th and Orange County on December 10th. Click here to register or learn more about the “Knowledge-driven Architecture”  management roundtable.

KA Dialog #1: Knowledge management is squishy

Ian and Batch,

Thanks for agreeing to participate in the first KA Dialog. I’ll get us started with a story.

I had a wide-ranging discussion with a CIO of a large architectural firm several months ago. Near the end of the conversation, I asked him for his opinion of my plan to build a knowledge management consulting practice focused on the AE industry. He kind of danced around what he really thought for a bit, and then came out with the truth:

CIO: “The problem with knowledge management is that it is squishy.”

Me: “What do you mean squishy?”

CIO: “I mean it can’t be measured. Going to my board to ask for money for knowledge management initiatives is always a struggle. Everyone gets that we need to do BIM. Same for buying servers or upgrading bandwidth. Easy sale. Knowledge management? Not so much.”

Me: “I’m sure the ROI…”

CIO: “My board doesn’t care about ROI because it is invisible. They can SEE us moving forward with BIM. They can SEE us upgrading to iPhones and 3D-printing our models. They can’t see us managing knowledge, and even if they could, it isn’t clear what the benefits are.”

I’m sure you two have have conversations like this before. I don’t know about you, my initial response to hearing something so diametrically opposed to what I believe is often to get defensive. I thought that perhaps my CIO friend wasn’t effectively selling the value of his initiatives. Or that he was pitching the wrong projects. Or any other number of reasons why he was wrong.

Eventually I moved from being defensive to becoming curious. So I started asking around…

I asked dozens of individuals ranging from CIOs to CEOs, architects to engineers, software companies to other consultants about knowledge management. I asked for definitions, strategic plans, measurement frameworks, and proven tactics. And what I found was that my CIO friend from the story above was correct. Knowledge management in our industry IS squishy. We don’t have a good sense of what knowledge management is, how to manage knowledge, what knowledge to manage, and who should be doing knowledge management.

I realized that if I wanted to build a practice around knowledge management, I’d better start putting together a pretty persuasive case to combat this perception. More to the point, I’d need to be able to hand folks a blueprint for knowledge management, a “knowledge architecture” if you will.

Enter the dialog that the three of us began a few months ago.

Ian, you gave me some advice that has become foundational to my approach. You suggested borrowing a lesson from Psychology and focusing on applied knowledge management, rather than on knowledge management theory.

Batch, you suggested that we un-muddy the knowledge management waters for ourselves and our customers by becoming more precise with language. There are tons of information systems in architecture and engineering firms — project information management (PIM) systems, digital asset management (DAM) systems, customer relationship management (CRM) systems, intranets, and so on. I think we both agree that the relationship between those information systems and knowledge management could use some definition.

I’m interested in hearing more from both of you on these topics.

From Ian, what applied knowledge management tactics does Newforma Project Center enable? How would you pitch the benefits of Newforma, specifically measurable metrics, to the skeptical board that I introduced in the story above?

From Batch, how does project information management software fit into a knowledge architecture, or knowledge management blueprint? What are the key knowledge assets that Newforma Project Center helps individuals to create, capture, and share?

Looking forward to your responses next week,

Chris

Ian Howell is Newforma’s chief executive officer. He’s an architect by training, with practice experience in Australia and the United Kingdom. His AEC software industry experience includes positions with Autodesk, Citadon, Alias Research and Rucaps Australia. Among his contributions to the AEC software industry, Ian is a founder of the International Alliance for Interoperability, and currently serves on the board of direction for the buildingSMART Alliance.

Bob Batcheler is Newforma’s vice-president of industry marketing and product management. Bob’s career as a professional engineer includes time at Black & Veatch and Bechtel Power Corporation. His AEC technology background encompasses a variety of roles at Autodesk and Softdesk. Bob earned bachelor’s and master’s degrees in civil engineering from Lehigh University, and qualified as a registered professional engineer in Maryland.

3 reasons why you should become a member of AEBL

In 2008, the Professional Services Management Association (PSMA) changed its name to the Association of AE Business Leaders (AEBL). Its membership is comprised of senior managers, principals and owners from design and consulting firms who share business expertise through national and regional CEO Roundtables, Step Up to Leadership seminars, and other information sharing events.

I started attending the AEBL roundtables in San Francisco last spring and have found it to be an amazing resource. The quality of presenters, content, and attendees is consistently top-notch. In fact, I was so impressed that Knowledge Architecture has joined AEBL as an affiliate member.

Here are three reasons why I think you should consider joining the AEBL community:

1) Diversity of attendees at roundtables and workshops

I’ve consistently seen a great mix of CEOs, COOs, CFOs, marketing and human resources directors, project managers, architects and engineers from A|E firms of all sizes at AEBL events. The cross-functional, cross-discipline discussion is what makes the roundtables so compelling. Attending the events are a great way to network with your peers, partners and competition.

Note: IT leaders have been conspicuously absent at these events. If you are an IT leader — I can’t think of a better way for you to start rounding out your general knowledge of the practice than attending AEBL events. If you manage or work with an IT leader — invite them to join you for the next event.

2) Step Up To Leadership

AEBL’s “best practices” business seminar—Step Up to Leadership – is an eight-week program designed for managers, associates, and other professionals to get current with a range of the industry’s best leadership and management practices. I’m currently working my way through the Fall 2009 program in San Francisco. The first two sessions, “Developing a Sustainable Vision” led by Matt Henry, CEO of Fehr & Peers and “Key Operational Metrics: Creating a Culture of Accountability” led by John Cowdry, Senior VP at ICF International were both excellent. 

The balance of the program will include sessions on differentiation, workplace trends, client and project leadership, firm ownership trends, and risk management. You can learn more on the AEBL website. There are still spaces open for the remaining sessions if you are interested in joining us.

3) Management roundtables and executive workshops

In addition to Step up to Leadership, AEBL runs a series of management roundtables and executive workshops through their regional chapters. Some past and upcoming topics include:

• “Marketing is not a Department!”
• “Improving your Project Control Systems”
• “WEST COAST CEO ROUNDTABLE: Mergers & Acquisitions”

Contact Kathryn Sprankle, AEBL’s executive director at kathrynsprankle@aebl.org if you want to be added to the mailing list or learn more about becoming a member.

4) Management roundtable - “Knowledge-driven Architecture: How architects and engineers can transform their practices through knowledge management”

OK, so I confess I have ulterior motives for getting you engaged with AEBL. (Hence the 4th reason.) In addition to supporting AEBL through Knowledge Architecture, I have joined AEBL’s national faculty as a subject matter expert on knowledge management. I’ll be leading a management roundtable in Seattle on October 14th (AEBL’s inaugural Seattle event) and San Francisco on November 4th.

You can attend this roundtable to explore the history and theory of knowledge management, learn simple organizational learning processes which you can implement in your firm, discuss the effectiveness of the most common software platforms in the AE industry, and hear how your peers are using Web 2.0  tools and social media in their firms.

Click here to register or learn more about the “Knowledge-driven Architecture”  management roundtable.

Interested in hosting the “Knowledge-driven Architecture”  management roundtable in your city? Please contact me at cparsons@knowledge-architecture.com.

Storytelling – the oldest profession.

Knowledge Architecture founder Christopher Parsons interviews himself on the power of storytelling as an applied knowledge management strategy.

You just equated storytelling to prostitution. Is there more to your statement or are you just trying to get us to read the story?

Yes.

Do you care to elaborate?

Stories are the oldest means we have to share knowledge. You can look at religious parables, Greek mythology, or even children’s fairy tales for examples of how we have historically used stories to pass along knowledge and cultural values.

There is a great section in “Made to Stick: Why Some Ideas Survive and Others Die” by Chip Heath and Dan Heath on the power of stories. They explain why stories like David and Goliath and the Good Samaritan are far more effective ways to communicate than simply instructing others to “overcome adversity” or “help others in times of distress.” When we take the time to encode values, knowledge, or information in stories we make them “sticky” and inspire others to act.

Great book, one of the best I’ve read this year. Dan Conery of Newforma told me about it.

Any thoughts on how your readers can apply storytelling in their jobs?

Sure. Start telling stories.

…..?

Fair enough. I take your point. Here’s what I’m getting at. You don’t need a corporate initiative, storytelling committee, intranet, blog or wiki to get started. We knew how to share knowledge long before we had a printing press or the internet. Oral storytelling has a long and rich tradition. Sure, books, newspapers, magazines, the internet, web 2.0 are all are excellent mechanisms for creating, capturing, and sharing stories…but none of it matters if you don’t tell stories.

What kind of stories should we be telling?

This is a great question. An architecture or engineering firm is a business that designs buildings. If you don’t design great buildings, you won’t be in business long. Conversely, if you run the business poorly, there will be no buildings to design. So I’d start by focusing on stories that help people understand how the business makes money, where clients come from, and to understand how their efforts contribute to profitability, marketing, and sales. I’d also have an equal focus on stories that help to design better buildings.

I just finished reading “Open-Book Management” by John Case. Case asks you to imagine your business as a game and all of your employees as players. He argues that in most businesses, only a handful of players (top management) know the rules of the game (how the business makes money). Imagine what a football game would be like if only the coach and the quarterback knew the rules.

I’d argue that most AE firms run this way. Projects appear, bonus checks get distributed (or not) and most folks don’t know how all this “magic” happens. Employees are paid to design buildings, put together powerpoint shows, or close helpdesk tickets. A handful of individuals are responsible for running the business and ensuring the viability and performance of the enterprise.

Demystifying the “game of business” by opening the books and teaching basic business literacy might be one of the most powerful, untapped ideas for sharing knowledge that I’ve ever seen.

Can you give a specific example of business storytelling?

Absolutely. I started reading Anne Scarlett’s blog on AEC marketing a few months ago. One of my favorites posts is “Scarlett Letter #34: So how do you know one another? Diagramming your network. Part I of II.” Here’s an excerpt:

Well, it’s fun and inspiring for AEC leaders to educate your staff on how and why specific clients were won. {Notice I say client, rather than project, as that is the attitude we should always hold when thinking about new business}. I have a fairly forward-acting client that does exactly that by including ‘how we won this client’ into the agenda for their all-office quarterly meetings. A partner uses a flipchart to demonstrate in real-time how a specific client was won: who was involved; what was their role (buyer, influencer, informant); timing; and so forth. You can even share the origin of your relationship with the various players involved. For example, maybe one of the players was a vendor source that you’ve known for years, but never actually did any business with—proving that continuing to nurture contacts in your broader network can pay off in the longest run.

How awesome is that idea? “How we won this client.” Think of all the simultaneous benefits that this technique brings you, from your staff learning where clients and projects come from to seeing that you are out there marketing and winning work.

Look, I understand that suggesting to just “open your books” might sound a bit flip. Most open-book proponents recommend that you do this in an incremental, phased approach. Getting used to the idea of sharing sensitive information will take some getting used to. There is no doubt that this would be a sea change for most firms.

However, I think that Anne’s suggestion is pretty low-hanging fruit. Telling business stories doesn’t require much in terms of resources. You don’t need an intranet or a CRM to have a major impact on your business.

Win a project, tell a story.

How about design storytelling?

This is something our industry is really good at doing. We have loads of forums, lunch and learns, conferences, knowledge communities, and industry roundtables. A smart-ass revisionist like me might even call this “Social Networking 1.0.”

Proud of yourself?

Pretty much.

So where are the opportunities with design storytelling?

It would be great if we could capture and share more stories. The challenge is in finding the time to create the content, capture it in a story and then share it. The fact that we are all busy, mobile, and geographically-dispersed only compounds the challenge. It was one thing to tell stories around the fire when we had small villages, travelled as nomadic tribes, or worked on the farm…

I’m assuming this is where technology comes in.

Yes. But only in the way that systems like books, magazines, or television were additive to face to face storytelling.

Tools like e-mail management, personal video, screencasts, blogs and wikis mean that capturing knowledge has never been easier. Sharing stories has never been easier. And yet the plain truth remains…none of the new innovations matter if you don’t take the time to create, capture, and share your stories.

Any closing thoughts?

I should close with a story right?

I think you’ve kind of painted yourself into a corner.

I thought so. Well I’m going borrow a story which I hope helps to illustrate a final benefit of storytelling - leveraging yourself through a good story.

From the Arup website:

The Key Speech is required reading for each person who joins Arup or who wants to be reminded of what we are all about, and for those who want to learn about us.

On 9 July 1970 Ove Arup spoke to a meeting at Winchester, UK, of his partners from the practices around the world bearing the Arup name. His talk was in response to the collective desire to continue working together, despite the changes that would take place as the founding partners progressively retired and gave up ownership, handing over control to the successors they would choose for these practices.

The pre-natal name of ‘key speech’ for this talk has endured, in recognition of the fact that in it Ove both states the aims of the firm and analyses in his very distinctive way the principles through which they may be achieved. From time to time we have asked ourselves whether what he said in 1970 remains valid for us, despite the fact that inevitably some specifics about the firm’s organisation and individuals’ roles therein to which he refers in passing have changed over the years. On each occasion we have found that it does, and thereby reaffirmed our commitment to these principles.

You can read the whole speech here: Sir Ove Arup’s Key Speech.

Today we might record the speech as a video, embed it in an internal blog post, or tweet it. The fact remains that this is a powerful, powerful technique for knowledge management.

Thoughts or ideas on storytelling? Please share them in the comments below or e-mail me.

Best,
Chris