This article is referencing concepts and terminology common in “Knowledge Management” (“KM”) and “Adoption & Change Management” (“ACM”) and assumes that the reader has at least some experiences in one or the other. It also references the use of SW solutions and “collaboration tools” as a means to realizing organizational benefits, and value, of KM concepts.

I have inserted links to articles explaining some of the concepts where appropriate.

I have touched upon this topic in a few of my earlier posts, how we often mistake a Knowledge Management, or a Collaboration tool project, for being a technology project. I will go out on a limb here and be Boolean:  It is not.

I am also intentionally calling it “Knowledge Change” as opposed to “Knowledge Management”, because when we try to implement a new KM process, solution or Collaboration tool, we are inevitably facing a Change Management effort. Not a “system implementation” effort or “adoption” effort. Perhaps in the rare exception, if an organization is already fully embracing KM principles, have defined and successfully implemented a knowledge-centric business model and managed to create and nurture a truly collaborative culture, they could possibly be doing a 1:1 replacement of one KM platform to another. I think anyone who’s been involved in any KM/Collaboration effort would agree with me when I say that is a close-to utopian scenario.

So, let’s focus on the large majority, rather than the rare exceptions.

Most of us work in organisations that truly wish to embrace a collaborative culture and leverage the collective knowledge of the organization to achieve more. Pretty much common sense in any knowledge worker organization, isn’t it? But it is a lot easier said than done as many of us also work in organisations that have a long(ish) history of engineering-driven, development-centric and traditional organisational structures. In this case I am thinking of organisations that quite typically are hierarchical and organized around geography and/or functions, rather than organized around capabilities or knowledge areas.

There are probably a fair number of barriers as well, in the shape of policies and processes, that prevents knowledge from flowing freely and effectively between those functions and/or geographies. And in some cases, there may even be barriers in-between levels within the hierarchies, in terms of roles and seniority.

Finally, the demographics of the work force will also likely, yet inadvertently, create additional barriers based off what kind of moral values and/or academic principles we were exposed to in our formative years. Someone born in the 50’s or 60’s for example may have a much higher focus on “perfecting before sharing” than someone born in the 80’s or 90’s. I believe that nationality/culture also plays a role in that area.

Does any of this sound familiar?

In those cases, implementing a new Knowledge Collaboration platform or Collaboration solution, is so much more complex than process change or a tools implementation project, because it immediately becomes a project to change culture and behaviours.

Here are a few things that are at the top of my mind, that I think you may find useful to consider.

• To change culture, you must change individual behavior
• To change behaviour, you must undo existing habits
• Undoing habits takes leadership, dedication and patience

I am making an assumption here that everyone has a good understanding of what we mean by [Organisational] Culture, are familiar with Peter Drucker’s statement that “Culture eats strategy for breakfast”[1] etc., so I will not delve into defining “culture”.

A second assumption I am making is that most of you are familiar with Adoption and Change Management fundamentals and know Prosci’s ADKAR or Kotter’s 8-step Change Model, so I will not go into those but skip right into the more challenging parts associated with those: Sponsorship, leadership and perseverance.

Culture is more than Vision, Mission and Values

So it takes more than a few strategy sessions, or management consultants to change it. Culture is the collective values, actions and behaviours of the company employees, so if we want to change it, we need to change the mind-sets and behaviours of everyone who works there. From top to bottom. Having active and visible (Executive) sponsorship is fundamental but it is not enough. We must avoid falling into the trap that so many of us have fallen into and forget about the middle management layers. They are crucial to drive any sustainable change because they are the people who manages the majority of the work force and if they do not ask for the change, it will most likely not happen. It matters a lot less what my CEO says, in practice, than what my direct manager and perhaps his/her manager says, doesn’t it? “Middle management” is the key change agent that can make the difference between failure and success.

Acquiring new habits would be a lot easier if we did not have to get rid of existing ones

Just think about your last New Year’s resolution – how many days did you last on that diet, or going to that gym 3 days a week, once you got passed Jan 1st? All of us have habits. Good ones and bad ones and they are all hard to change but most difficult to change are the bad ones. Then add to that the dimension of having previously been rewarded for one type of behaviour (“the bad habit”), now being asked to do something different (“the good habit”). It will be hard for everyone and it will be even harder for people with tenure. Therefore, rewards and recognition are key, but they are not a silver bullet.

Patience is a virtue that very few of us possess

Learning anything new takes patience and practice for most of us, as well as perseverance. But it does become a little bit easier if the people we look up to and respect are leading by example, or if there is a reward at the end. But carrots and sticks alone won’t do it either. It will take repetition, consistency and alignment between the spoken and the acted messages, and role models that repeatedly demonstrate the desired behaviours. In addition to awareness, readiness, knowledge etc., which are the Change Management 101’s, we need to walk the talk. We need to stick with the program and keep pushing the same message over and over in various ways, shapes and forms.

There are of course many more challenges, opportunities and aspects of driving cultural change in the context of KM (as in any context!) but I am going to leave you with these three and I hope that this article will spark some healthy conversations and generate some knowledge sharing. This is a big topic and there is a lot we can all learn from each other.

[1] Some argue he never said this, but it is most often attributed to him, so let’s go with that for now.

While “going agile” is not an end in itself, there are circumstances where an agile content strategy can help achieve desired business outcomes. In part 1 of this two-part blog series, we discuss content team implementation of agile ceremonies which have brought success to EK clients. In part 2, we’ll follow up with a discussion of traditional Scrum roles and how they can be applied to content teams.

Agile Content Team Ceremonies

More than just meetings, agile ceremonies are designed to empower teams by maximizing the investment of each team member’s time. Here are some examples in which EK has successfully employed agile ceremonies to empower content teams.

Content Sprint Planning

Anyone who’s ever worked on a content team knows that creating a prioritized content backlog is arguably the greatest value which agile can add to content strategy. Content tasks often come to content teams in a flurry of urgent requests and unrealistic timelines. Adding incoming requests to a product backlog and making that product backlog visible to stakeholders can go a long way towards setting realistic expectations for content production timelines.

Once the content backlog is established, sprint planning meetings provide an opportunity for content teams to engage in dialog with the product owner and discover the business objective, audience, and topic of content tasks.

In this example the product backlog consists of all tasks in the “To Do” column.

As with any sprint planning meeting, estimating the amount of effort it will take to accomplish each content task is essential. We’ve found simple metrics to estimate effort such as T-shirt sizes (small, medium, large, extra large) are helpful for non-technical teams like content teams. Reformatting that PDF to ensure it’s 508 compliant? That’s a small task. Producing that new user help video? That’s a large task.

Once T-shirt sizes are agreed to for each upcoming task you can chart the content team’s velocity. As with any agile team, ensure the team commits to a realistic amount of work for the sprint – based on their known velocity. But let’s be honest – it’s highly likely that a content team will be asked to take on more than they can realistically handle. It’s also highly likely that “urgent” tasks will be requested mid-sprint. Business stakeholders requesting urgent content tasks will have to be educated about new agile processes – and their business value.

Content Daily Stand-Up

Once a content team has committed to completing the tasks in the current sprint (the main outcome of the sprint planning meeting), daily stand-up meetings are essential to achieving this collaboratively set goal. The typical format is 15 minutes in which the entire team answers three questions:

• What did you complete since our last stand-up?
• What do you plan to work on today?
• Are there any roadblocks in your way?

Daily stand-ups are an opportunity for the entire team to explicitly commit to meeting the goals of the current sprint at the beginning of each day. This may mean dynamically adjusting tasks which are assigned to team members. If one team member has completed a first draft of a new publication, perhaps another team member can jump in and offer to review it and give feedback. If one team members is a stronger writer and is struggling with a visual design, they can ask for assistance. The focus of the daily stand-up is on the team working together to complete all of the tasks in the sprint, shifting tasks and offering expertise as needed to best make that happen.

Content Sprint Review

The focus of a development sprint review is to ensure that the goal of the sprint is met – often a final check against acceptance criteria. Usually, the team presents to the product owner. Content publication is usually not as technical and the business requirements are relatively easy to understand. An entire ceremony to validate that acceptance criteria are met is not as valuable for content teams.

For content teams, it is really easy for the completion of daily tasks to go unrecognized. Does anyone stop to take notice when a routine article is published? It’s not only large publication milestones that deserve recognition.

Sprint reviews in the form of “Demo Fridays” can be a good strategy to ensure that the work of your content producers is valued. Each member of the team has the opportunity to show off all new content which was published during the week. The ScrumMaster sets the tone here, and it should be celebratory, honoring tasks completed, noting attention to detail and quality, and acknowledging roadblocks overcome.

Content Sprint Retrospective

Sprint retrospectives cultivate the culture of continuous improvement which is so essential to content teams. Content production is a bit of an art, with an emphasis on soft skills like writing with style and clarity. These skills require continuous honing – there’s always more to learn.

The goal of a sprint retrospective is not to improve content production skills, but rather to improve the agile processes which enhance content production. However, the inclusion of sprint retrospectives in the processes of your content team models the continuous improvement which is so critical to the overall culture.

Recently a content team which worked with EK discovered and implemented a process improvement due to a retrospective. The content team was using Trello to manage content tasks and a subset of business stakeholders were uncomfortable with the platform. This was causing poor communication during the editorial process. These particular business stakeholders were creating a spreadsheet where each row was a task. Rather than force the business stakeholders to use Trello, the team revised their process to link from Trello to their stakeholders’ spreadsheet. The hybrid approach enabled more regular communication with the stakeholders, but still honored the content team’s processes.

Conclusion

Agile ceremonies are just one component of agile processes, but they are a highly visual and recognizable one. When people talk about “going agile,” they often default to agile software development, but agile ceremonies (and other agile practices) can empower many kinds of teams – including teams of content producers. Do you need help empowering your content teams with agile practices?  Contact us at Enterprise Knowledge – we can help.

In your organization, is there a distinct strategy behind the people side of your organizational change, or is there simply a collection of tactical communications or training activities that need to be “managed” during a rollout? Change leadership requires the courage of swimming upstream, often against the ingrained habits of your organization.

There is a difference between truly leading change and just managing it:

• Change Leadership: Executives and managers take a personal interest in the change project succeeding and unite people behind a common vision.
• Change Management: Relying on predetermined communications and training to meet behavioral change goals. While these tactics will undoubtedly be a part of every change plan, they are not enough to ensure adoption.

We often see this challenge in our knowledge management initiatives, where regular emails about a new collaboration tool do not lead to desired levels of adoption. Regardless, whether your organization is currently going through changes related to people, process, technology (or all at once), change leadership is crucial to success. Change leadership underlines the importance of the change and ensures appropriate resourcing and priority. Change leadership is also better suited to a complex, rapidly-changing environment, which reflects most organizations.

How to Lead Change

Don’t treat behavioral change like an afterthought. Many change practitioners are brought in right before a launch or even after a project has already failed once. This makes the job of encouraging adoption much more difficult: at EK we find that most people take time to process new changes and integrate them into their daily work – something that the change team may have already done because they were aware of the change sooner. This concept is especially true for difficult changes such as changing roles or organization structures. Leading change in this way means that the behavioral change required from people is a priority from the onset of the project.

Ensure sponsors show their dedication. Often, all change activities are delegated to external consultants or those within an organization who do not have influence on the direction of the change. While bringing in experts can greatly increase chances of high adoption, fully outsourcing change activities will undermine the change effort. It is crucial that people who have institutional trust and decisionmaking authority take on the role of sponsor and that they make a concerted effort to be involved, active voices throughout the change. An absent sponsor on a project where change is “managed” can make the people being asked to change feel like they have no say in the outcome and can exacerbate resistance.

Enable people to change, don’t force them. Sometimes leading change means adjusting an approach based people’s previously misunderstood needs. Making the change easier to digest with the help of the people involved is an evolving conversation. This requires less focus on dealing with people considered “troublemakers” and more on truly listening to and acting on people’s concerns – perhaps about user experience, unnecessary features, or institutional knowledge that is not being tapped in the change project. To create even more opportunities for people to change, you could try an iterative, or agile approach to rollout. This will help build trust as people’s input improves the technology, process, or organization structure after each iteration.

Are you managing change but not yet leading it in your organization? EK’s change management consultants can help you put together a strong change strategy. Contact us to learn more at info@enterprise-knowledge.com.

Our KM Consultants help organizations improve the way they capture, share, and reuse information. Many KM projects focus on managing unstructured information like documents, emails, and web pages. While this type of unstructured information is critical, it is not the full enterprise of an organization’s knowledge. What about databases, reports, and dashboards? To fully encompass an organization’s knowledge and information, both structured and unstructured information must be addressed. The most impactful Knowledge and Information Management approaches are those that not only cover both structured and unstructured information, but manage them together in an integrated manner. A well-defined ontology is a critical path to link structured (databases and reports) and unstructured information.

An organization that successfully links their structured and unstructured information through ontologies can see meaningful improvements in the findability and discoverability of their information. An ontology will create connection between all information, meaning that information becomes a web that may be traversed by your end users to better find and use the information they seek. This leads to greater productivity, collaboration, and overall satisfaction.

The easiest way to understand how ontologies can help link structured and unstructured information is through examples. This blog shares two different examples showing how an ontology can associate these two different types of content.

• Merging customer information with customer metrics
• Mining product information

Merging Customer Information with Customer Metrics

The Problem

A large financial services firm that worked primarily with corporate clients needed to integrate customer metrics into their customer intelligence portal. The portal was a central location for news and information about their customers to improve sales and account management. The content included formal customer documents (contracts, invoices and license agreements), news, and call notes. A separate data warehouse team had a database of key customer metrics. The firm wanted a way to show key metrics about a customer while people were reading news, documents, or call notes about that customer.

The Ontology Solution

The firm used their customer database to seed an ontology that included a customer entity type. Each customer entity was assigned attributes like industry, status, and customer number using information from the customer database. This list of customers and their attributes was loaded into an ontology management and entity extraction tool, like PoolParty. The entity extraction tool was run against the content repository to identify references to customers in the content. Once the entities were identified and tagged, the structured and unstructured information could be linked.

The portal content was organized by customer, industry, and topic. The customer and industry information comes from the ontology. When users look a document that mentions one of their customers, they also see metrics about the customer and their industry.

Mining Product Information

The Problem

A manufacturing company was looking to find patterns about product defects in order to improve the reliability of the products they manufacture. They had information in a variety of formats:

• A database of information about product defects and returns;
• Defect reports with problem descriptions; and
• User comments from their website.

The manufacturer needed a way to mine all of this information to identify patterns that would allow them to improve the way they manufactured their products.

The Ontology Solution

An ontology was the best way to link this content together for analysis. The manufacturer created an ontology that included the following entities:

• Products
• Parts
• Defects

Products store the name of the product, its SKU, and the unique identifier that can be used to link it back to the product database that contains the structured information. Parts include the name of the part, any similar names, and manufacturing information. The defects are a list of common problems that will grow as more information is captured.

The products were loaded into the ontology management tool with the SKU and product identifier so that they could be linked back to the database. We entered part information and common defects in the parts and class entities. Entity extraction was run against the unstructured content (defect reports, surveys, and social media). This allowed us to identify new defects and parts and associate them with the products aligned with the content.

The manufacturer was able to use SPARQL (an ontology query language similar to SQL) to see relationships between defects, parts, and products that were not easily visible before. Using SPARQL queries, the manufacturer was able to see that 2-3 parts that were used across the product line accounted for most of the defect descriptions. This information would not have been available without associating problem descriptions with defect and return information from their product database.

Conclusion

As you can see from these two examples, an ontology is a great way to link structured and unstructured information. Ontology products like PoolParty automate much of the process and make it an affordable and scalable solution. The next time you revisit your organization’s Knowledge Management capabilities do not limit yourself to documents and web pages. Use ontologies to integrate databases and reports so that you have a true Knowledge and Information Management (KIM) solution.

EK can help make the integration of your structured and unstructured information seamless. For more information contact us at info@enterprise-knowledge.com.

I recently ran a workshop for one of EK’s clients that was designed to discover, document, and then model how their internal social network (Yammer in this case) was running in their organization. The idea was to figure out if the company could use Yammer less organically and more deliberately for communication and collaboration.

The company is relatively new to social networks. They turned Yammer on about 7 months ago and initially just let it run, watching how employees used it without any real institutional encouragement. The result was about what you would expect: Pockets of “early adopters” established groups and began using the tool to connect with relatively small networks of employees. Its adoption was far from widespread and its impact on the organization was small. It wasn’t central to how the company worked or exchanged information.

About 3 months ago, the communications department took matters in hand and began to look seriously at how it could use Yammer as a more official – and more managed – internal communications and collaboration tool. They recognized that Yammer would continue as an organic collaboration tool among self-forming groups, but they wanted to do more. With EK’s help, the communications department took a step-by-step approach to institutionalizing and managing Yammer in the organization.

First, we provided an official channel for the CEO to post video and text messages to employees. Channeling CEO messaging and videos through Yammer provided an official endorsement of the tool and a ready and willing audience, namely all company employees.

Second, we embedded Yammer into their redesigned portal. We put each employee’s “My Feed” on the home page to balance traditional corporate communications content with more dynamic and personalized social posts.

Next, we developed an avatar in Yammer for employee communications. Posts in Yammer from “employee communications” rather than from a named individual added an official, institutional dimension to Yammer posts. In addition to the My Feed on portal home page, we embedded a Yammer user feed that displayed only posts from the employee communications avatar. This provided an announcement channel for the company that displayed both on the portal home page and on employees’ mobile devices via the Yammer app.

Finally, we ran the workshop to understand how all of these uses of Yammer – both organically created groups and more strategic uses – could come together in a unified way. During the workshop we charted Yammer along three dimensions:

• The various types of authors that post to Yammer (e.g. the CEO, company leadership, corporate communications, regional leadership, subject matter experts, project team members).
• The various types of messages posted by specific types of authors (e.g. organization announcements, stories and anecdotes, earnings reports, holiday greetings).
• The specific audiences each message type was directed toward (e.g. all company, project teams, regional groups, individual facilities, affinity groups)

The resulting interaction model gave a holistic view of how Yammer is used in the organization and how it could best be managed. By diagraming the model and communicating it throughout the company, employees now have a better idea of how to use their social network effectively. They know what types of groups to join, where to post various types of messages, and how the Yammer group that they just created fits into the overall collaboration network.