The truth about doing less. (First you have to do more.)

Jason Fried at Gel 2006 from Gel Conference on Vimeo.

Easy for you to say…

I’ve been working on this blog post all morning. I thought this post would be simple. Most of the information management challenges plaguing the architects and engineers we work with can be simplified by doing less. All I should have to do is write about what we see and do every day.

Here are three examples :

• A user-friendly intranet? Do less. Less content actually makes an intranet easier to use.
• A project history database? Do less. Less fields to maintain mean that the important fields will actually get captured.
• An expertise database? Do less. Nobody cares if a team member has Microsoft Word expertise. Focus on the skills such as space planning, water-proofing, or feasibility studies that your staff can really leverage in their project work.

So why has this post been so tough to write? Because I felt like I sounded too much like this guy:

Some free advice on how to do less.

Imagine that you’ve finally decided to move from a network-based image library towards a database-driven solution. You’ve never implemented one of these systems before. You decide to start asking around for advice on a successful implementation. I’m one of the people you ask. Guess what my advice would be?

Chris: “Do less.”

You ask me to elaborate.

Chris: “Start by going after the most important projects. You don’t need to chase down images for every project your firm has ever done. For example, seismic upgrades or executive bathroom remodels can probably wait until round two, or three, or never.”

You thank me for my advice. I’m not done.

Chris: “I’d also limit your scope on the number of images you try to harvest from your teams. You should focus on the images that will help you tell the project story now and in three, five, ten years down the road. Focus on the images that endure, not every version of every rendering or site photo that your team took during the project.”

That’s helpful you think. Less projects and less images. Focus on the stuff that matters. You thank me again for my advice.

(I’m still not done.)

Chris: “I saved the most important advice for last. Limit your image keywords to 20 to 30. Your users are going to howl at first. They are going to come with lists and lists of keywords which they “must have” if the system is going to work for them. Their combined lists could easily top 250 keywords. This is fine. This is beginning of the process. Your work, and your team’s work, is to eliminate the fat. A system with 250 keywords won’t get populated and will be difficult to use. Fight for 25 keywords at launch.  Stare them down. Play chicken. Do not bend.”

Now you have what I think is the best advice possible on implementing an image management system. I’ve seen it work firsthand with many of our customers and followed the same approach when I was a CIO.

Scope ruthlessly. Design more. Do less.

Here’s the thing – doing less is more difficult than doing more and requires more upfront work. Doing less requires more thinking and more prototypes than doing more. Doing less requires more political savvy than doing more.

You could take the easy way out. For example: 

• The easy way to implement an image management solution would be to placate your users and just add more keywords.
• The easy way to design an intranet would be to let your users go nuts and upload whatever they want and design their own pages.
• The easy way for Jason Fried and his software company 37Signals to please their customers would be to implement every feature that his customers ask for.

Each of the three approaches above will end up in solutions that are complex. Complex solutions are expensive to maintain, difficult to support, and horrible to use.

Doing less requires more work in the short run but leads to simple, sustainable, usable solutions in the long run.

Somehow “Scope ruthlessly. Design more. Do Less.” doesn’t have the same ring as “Do Less.” But I think that it’s the complete truth.

Want to become a knowledge-driven firm? Build some “T-players” and get yourself a coach.

                                                                Bad News Bears © mptvimages.com

The following post is in response to a comment left by Randy Deutsch on the KA Connect LinkedIn group. Click here to join the KA Connect LinkedIn group and read (or join in on) the full discussion thread.

Randy,

I agree and disagree with your latest comment about the role of the writer, librarian, and teacher in a knowledge-driven firm. But before I respond, I’d like to share a story with you. You’ll see that the idea of a “T-consultant” is something we have in common. 

Chris

“The T-consultant”

My first job out of college was with a large technology consulting practice which served the Fortune 1000 as well as several dot-com clients. We had lots of technical experts on the team — business analysts, database designers, user interface designers, web and software developers, quality assurance experts and functional testers. Of course we also had partners, project managers, and the expected administrative staff.

The western region of our company was about 100 people when I joined. The guy that ran it was named Chris Lord. Chris was excellent at taking the new consultants under his wing and teaching them about the business. One thing that Chris was particularly passionate about was the question of "What makes a good consultant?" His big idea was that the most powerful consulting practices were full of "T-consultants."

Chris explained to me that the advantage that our firm had over many of our larger competitors - Accenture, IBM, and the like - was that our consultants not only had technical depth in at least one area (the "|" in the T) but were also horizontally savvy  (the "–" in the T.)  One of the ways that Chris ensured that we had breadth as well as depth was to make sure that all of our consultants got experience in as much of the full lifecycle of bringing technical projects to life as possible.

Chris felt that the horizontal integration of our teams differentiated us from the rest of the market. Most firms simply reinforced their expert culture and ended up with silos of expertise. Or they were staffed with generalists who had no depth. The truly exceptional consultant could go deep in at least one technical area but also speak intelligently to the whole process.

Chris was the architect of the team and the culture. Another way to describe Chris was as our coach.

Play to their strengths

Your March post on “T-Shaped BIM” was spot on with Chris’s philosophy. Here’s my takeaway:

Each player in an IPD project should bring their vertical expertise (architecture, structural engineering, fabrication, etc.) to the table in a concerted effort to become horizontally integrated through IPD.  The truly successful IPD teams will bring empathy for their fellow collaborators to the project because they have made the effort to experience and understand each other’s roles and expertise. In short,  successful IPD teams will be made up of “T-players.”

I think the same thing is true when it comes to sharing knowledge.

You wrote in your comment that:

"… to play collaboratively we need to wear multiple hats, see from more than one perspective. Our titles and roles become in the process smeared. There’s no time at the table to be "just" a librarian, writer or teacher. You have to nurture the development of all three."

I agree (to some extent) that all of us should have the responsibility to embody the writer, the librarian, and the teacher. Creating, capturing, and sharing knowledge are basic skills that we should all develop and employ in our daily work.  Understanding all three activities is the horizontal integration, the "–" in the T.

However, I also believe in the Marcus Buckingham approach which suggests that one should prioritize playing to people’s strengths over shoring up their weaknesses.

You are going to have folks with communication skills in your organization who will create amazing content.  Those “writers” might not have the “librarian’s” temperament or organizational skills. So focus on getting them writing.

Conversely, there are people in your organization whose organizational talents make them great librarians,  yet they are not strong communicators, written or orally. Put them in charge of organizing content on your intranet or website and/or hounding your writers for more content. Librarians naturally gravitate towards bringing order from chaos, so empower them to do so.

In a "T-organization" we recognize that knowledge management is a team game. The larger the organization, the more opportunities exist to leverage the diverse strengths of the team.

The trick is orchestrating the performance…

Coaches - The missing team member

The good news is that architecture and engineering firms often have their “role-players” in place.  Writers, librarians, and perhaps teachers busily execute their various roles and produce “stuff” on a regular basis. Yet all too often we see that individuals and teams within firms are working in isolation from each other as they struggle with organizing information and sharing knowledge.

In other words, we usually find that there is “knowledge work” going on inside of architecture and engineering firms. Very rarely do we find “knowledge management” or  especially “knowledge leadership.”

The following excerpt from your comment made me realize that I was missing a key role from my triumvirate:

"As much as I love the triumvirate of Writers creating Librarians capturing and Teachers sharing, why is it the most valuable team members are inevitably those who embody all three characteristics in one person?"

I think that the person you are describing is the coach. And most firms don’t have a coach to orchestrate their efforts to organize information and share knowledge. Here’s why they should:

Coaches set the vision for the team, develop a plan, establish roles, and motivate the team to perform.

Coaches channel the “knowledge work” of the writers, librarians, and teachers to makes sure that their efforts align with the organization’s vision and objectives.

Coaches “embody all three characteristics in one person” and can leverage the collective strength of the organization by tapping on the individual skills of the role-players. And the best coaches realize that their best players are “T-players.”

A couple questions

Here are a couple questions back to you. (Not just Randy, the “collective you.”)

Why is leadership missing from most architecture and engineering firms efforts to organize information and share knowledge?

Do you agree that coaches could help?

Are you actively building a team of “T-players?”

Establishing a vision for knowledge management: Be like Gordon Ramsay.

                                                                                                                            © NASA

Back to Chef Ramsay

A couple of weeks ago I wrote about Chef Gordon Ramsay’s formula for turning around failing restaurants:

Establish a vision. Do less. Do it well. Fix the decor. Work as a team.

Watch a few episodes of Kitchen Nightmares and you’ll see that this formula is devastatingly effective. It is also remarkably simple.

Step one in Chef Ramsay’s turnaround plan is to establish a vision for the failing restaurant. Most of the restaurants Chef Ramsay turns around are drifting without a clear identity, trying to be everything to everyone. In recent episodes he’s helped restaurants to position themselves as “healthy and fresh,” “family-style Italian,” and “from farm to table.” 

Chef Ramsay uses the vision for the restaurant as an armature for decision making.

Want to use frozen food? That doesn’t fit the vision of “from farm to table.”

How about using grapefruits from Mexico or apples from China? Nope. Out. Find a local fruit.

Can’t figure out how you are possibly going to decide which cheeses to serve in the dessert course? Draw a 100-mile radius around the restaurant and find a local farm making cheese within those boundaries.

This surely isn’t the first time someone has presented you with the benefits of using a clear vision to articulate your priorities and align a team. Yet virtually none of the restaurants Gordon Ramsay turns around have a clear vision. Why?  Planting your flag in the ground means shutting down other options and risking criticism from others. It requires discipline and clarity in communications.

In other words, defining a clear vision is difficult. Yet simple.

A vision for knowledge management

One of the challenges architects and engineers face is that they don’t know how to start organizing information and sharing knowledge. The sheer volume of both is so daunting that the opportunities for improvement seem simultaneously unlimited and exhausting. Many times they give up before they even get started.

There is more information to be organized in architecture and engineering firms than can possibly be organized. There is more knowledge created every day in architecture and engineering firms than can possibly be captured or shared. 

Enter the importance of clearly articulating a vision for knowledge management.

What is typically missing is a clear vision for what matters. What information do we absolutely need to manage? What knowledge is critical to our success to create, capture, and share? When all information and knowledge is treated equally, analysis paralysis and inaction is sure to follow.

Be like Gordon

Here’s my advice for those who are struggling with organizing information and sharing knowledge – be more like Gordon Ramsay.

Articulate your vision for knowledge management. Repeat it consistently. Use your vision to make decisions about what information gets managed and what knowledge you target for capturing and sharing.

It is difficult work. But the answer is simple.

Next post we’ll pick back up with step two: Do less.

“Knowledge Nightmares”: What would Gordon Ramsay do?

                                                                             © FOX Broadcasting Company

Denise and I got rid of our TV seven years ago. We had several blissful years of control over our lives. We dodged most of reality show mania. We missed the first two seasons of Lost. Best of all, we avoided advertising.

Then came Hulu.

Now we cannot stop watching Kitchen Nightmares.

A simple premise. Repeated.

Restaurant owners on the brink of shutting down call in star chef Gordon Ramsay to help them save their restaurants. They are between half a million to two million dollars in debt. Their restaurants are empty. They’ve tried promotions and gimmicks to no avail. They know they are failing. The restaurant owners, many of them chefs, have accepted that they need help and have asked for it.

There is only one problem: All of the restaurant owners think that the food is excellent. (Hint: It isn’t.)

The Kitchen Nightmares formula

I read Jason Fried’s new book last weekend. REWORK is excellent. Go buy it and read it. I’m a big fan of his blog, his software, and his first book, Getting Real. 

Turns out Jason has been watching Kitchen Nightmares as well. He has a short essay in REWORK about the formula Gordon Ramsay uses to turn around a restaurant. It goes something like this:

1. Establish a vision. Most of the restaurants Chef Ramsay turns around are drifting without a clear identity, trying to be everything to everyone. In recent episodes he’s helped restaurants to position themselves as “healthy and fresh,” “family-style Italian,” and “from farm to table.”  
2. Do less. Chef Ramsay cuts down the number of items on the menu by at least half. (This episode is an extreme and entertaining example.)
3. Do it well. Most of the chefs on Kitchen Nightmares are using either frozen food or dated ingredients or both. Gordon pushes them towards fresh ingredients.
4. Fix the decor. While fixing the food is first on the agenda, Chef Ramsay always overhauls the “look and feel” of the restaurant to align the decor with the vision and the new menu.
5. Work as a team. Many of the chef-owners cannot delegate and bark at their staff. Chef Ramsay puts in a proper organizational system so that chefs and owners can leverage themselves and grow their team.

In REWORK, Jason Fried suggests that software companies should apply Gordon Ramsay’s Kitchen Nightmares formula to their products. He argues that most software is a meandering, bloated, feature-rich, mess of code.

Putting everything customers ask for in the product (on the menu) only spreads developers (chefs) thin as they try to support an ever expanding code base.  Software product managers need to look back to their visions and hold fast when it comes to making decisions about  adding new features to their products. Jason’s central thesis is that by doing less and doing it well, software companies will have happier customers.

What would Chef Ramsay say about your knowledge management strategy?

If you have been reading the Knowledge Architecture blog you probably know how this story is going to end. I’ve written recently about overly ambitious and bloated project history databases which try to capture everything and end up capturing nothing. At the end of the post I suggested the following:

1. Create one source of truth by consolidating project history from multiple locations into one database.
2. Keep your project history database simple by prioritizing fields which actually get used.
3. Assign a librarian to each field you want maintained. You may well have different librarians for different types of fields. (For example, QA/QC tracking, project roles and responsibilities, location of the record copy of the half-size set, and project descriptions might be maintained by four separate librarians.) 

Going forward, you should only add fields into your project history database when you have a clear “use case” for how each field will get leveraged and assign a librarian to maintain it. 

Think about the Kitchen Nightmares formula above:

Establish a vision. Do less. Do it well. Fix the decor. Work as a team.

If Chef Ramsay came into your firm, what would he say about how you manage knowledge as he progressed through each of these five steps?

Feel free to share your answers in the comments or e-mail me directly.

I’ll be back after KA Connect 2010 with a five-part series on how architects and engineers can apply the Kitchen Nightmares formula to turn around their knowledge management efforts.

Is your project history database “bloated with no accountability” or “streamlined with a librarian?”

                                                                                                               © RyanJLane

“Things that get used don’t get dusty.”

– Denise Parsons

The way forward is simple. But it requires discipline.

Most architecture and engineering firms have some sort of project history database. In fact, they usually have more than one.  Project history can be found in enterprise systems like Deltek Vision, custom FileMaker or Access databases, Excel spreadsheets and Word documents, and folders of InDesign templates.

An effective project history database should help your firm to answer  “the 5 Ws and an H” - who, what, where, when, why, and how – of your firm’s experience.

Here are a few examples of questions a project history database should be able to answer:

“How many LEED Certified buildings has our firm built?” “Who was the project manager on the Pacific Tech University Lab Remodel?” “What projects have we built for public universities in Washington state in the last 5 years?”

The majority of the project history databases I’ve seen don’t get used. They don’t get used because they are either incomplete or inaccurate or both.  The reason for the poor quality of information is that the databases have too many fields and nobody assigned to maintain them.

Because there are no initial costs to creating fields (and because the technology makes it so easy)  folks tends to create fields to hold the answers to any question they might ever want to ask without concern for the long-term costs of usability and maintenance.

Spring cleaning

Here’s what I think you should do to develop an effective project history database:

1. Create one source of truth by consolidating project history from multiple locations into one database.
2. Keep your project history database simple by prioritizing fields which actually get used.
3. Assign a librarian to each field you want maintained. You may well have different librarians for different types of fields. (For example, QA/QC tracking, project roles and responsibilities, location of the record copy of the half-size set, and project descriptions might be maintained by four separate librarians.) 

Going forward, you should only add fields into your project history database when you have a clear “use case” for how each field will get leveraged and assign a librarian to maintain it. 

A confession

I confess to having built a couple overly ambitious project history databases in the past. (I’m reformed now.) We review several project history databases a month through our consulting work.  I’ve seen enough examples of the “bloated with no accountability” variety of project history databases to advocate a “streamlined with a librarian” approach to our customers.

I’m currently designing Knowledge Architecture’s internal project history database. I’ll be the biggest user of our database but also the librarian. (You can bet we’ll have a streamlined design.)

Interested in help cleaning up your project history database?

Drop us an e-mail.

“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.