This article provides a step-by-step method for using organization-specific business processes to build a flexible, strategy-driven taxonomy that identifies and qualifies existing content, as well as crisply defines requirements for content creation and development.
A Brief History of Content Management
The typical approach to content management has swung from one extreme to another. First, there was the corporate librarian, who reviewed, qualified and validated useful and reusable information—one document at a time. As the knowledge economy gathered steam and the amount of content produced increased exponentially, this approach became inefficient.
At about the same time, the Internet exploded onto the scene, introducing the notion of “search.” Companies readily adopted the search approach as a way to manage their content-saturated enterprises. Using brittle taxonomies implemented via automated categorization technology, search offered an exceptionally low-cost-per-content-asset solution, but it captured everything. Thus, the chaos of navigating the Web was replicated within the secure firewalls of the enterprise.
This flattened productivity and most certainly did not result in the promised content utopia. Search was the wrong metaphor at the right time. While the Web is arbitrary and random, thus demanding a search environment, businesses are not. Businesses are transactional. They produce goods and services and are organized around functional areas and business processes.
Bringing Business Discipline to Managing Content
Adopting a business process perspective is an ideal method for collecting and evaluating content requirements within the context of business strategy. Business processes imply rigor, and they have rules that enable you to apply a precise discipline to your thought processes. Applying that discipline to the development of content helps organize and simplify thinking around a complex and often daunting task. The benefit is that your processes will be better thought-out, better explained and probably more efficient. Also, your content will be directly linked to its purpose, not just sitting on desktops, file servers or offline in file cabinets, waiting to be discovered.
In practice, you must decide what kinds of information facilitate, enhance and impact activities (e.g., rules, laws, guidelines, templates). You must also consider the “flow” of the process—where does content initiate or drive an activity as an input? When is it the result or output of an activity—where does it go, and what does it impact or initiate next? Thus, you can produce a robust, multidimensional view of your business that clearly identifies relevant content needs that are specific to every single activity within any given process.
When you first put on your process thinking cap, it may take a bit of adjusting before it is a snug and familiar fit. Adopting a business-process perspective is tough, at least initially. Processes slice through an organization—they don’t fit into tidy, departmental silos. Tools and techniques have been developed over the past quarter century to facilitate process thought, and each has its own strengths and weaknesses. The key to understanding business process methodologies lies in knowing that most techniques are really nothing more than semantics, providing a common language—a way for you and your team to communicate with exceptional clarity.
Bottom line: Developing content using process as a guideline doesn’t require you to invest in technology to model processes, nor do you need an army (or even a squad) of high-priced consultants. You just need to learn some techniques and rules. More importantly, you either need to know your business or have access to subject-matter experts within your organization who do.
Applying a Business Process Methodology
To identify and better manage content, use a methodology that shows a “system” view of a process. This provides you with a structure to track the assignment and refinement of content requirements throughout the process model. You need at least three views of a process: an outline view, an activity detail view and a sub-activity/sibling view.
Working through each of these views allows you first to define and view business strategy and key activities; second, to map content requirements for each activity; and third, to continually refine relevant content as the activities become more and more granular. Ultimately, you produce a process-driven content taxonomy that helps identify and match existing content for collection, and serves as a baseline architecture for future content development.
View 1: Modeling the Process
Modeling, or outlining a process is straightforward. You break down or decompose activities into greater and greater detail (“process” is merely a label for the highest level of collected activities). Think of it as a table of contents that becomes increasingly detailed. This can be captured as a flow chart (as in Figure 1), as an indented hierarchy like a Windows file structure or in a spreadsheet or in Microsoft Project, which allows you collapse sub-activities (tasks) so they are easier to manage visually.
Here are some process-modeling considerations:
- Think in stages: Processes go through three stages when captured at the enterprise level. Strategic activities define operational activities, which in turn define tactical activities, the points at which work actually occurs. Tactical activities can be decomposed to an even greater degree of granularity.
- Limit your scope: Drill down to where you have the greatest pain or lack of clarity regarding content needs. You can always come back and refine, but first focus on the areas that will bring you the best results.
- Pick a point of view: The same process can be modeled from different perspectives. The CEO, sales managers and account managers all have different views, which could be meaningful and provide different content requirements.
- Apply clarity and brevity: Try to use as few words as possible to describe the activity. And keep it active, not passive, by making the activity name a verb followed by a noun.
- A process model is a guide: Though you don’t always have to follow every single step, you should at least capture all potential variations. Think of process models as best-practices road maps. (See Figure 2.)
View 2: Detailing the Activity
Once you’ve outlined the process, select an activity for focus. In a perfect model, you would start at the top of the process model. But since we are concerned about building a content taxonomy, we can begin at a more detailed level and scale up if and when we need to do so.
Once you have selected an activity, think about relevant content. Aspects of an activity that “control” or constrain, regulate, facilitate and guide performance of the activity are typically content-rich. For the activity shown in Figure 3 as “Qualifying a Sales Lead,” required content includes:
- Sales guidelines.
- Product/service information.
- Qualification templates.
- Market characteristics.
- Laws and regulations (that impact customer qualification).
Content requirements can also be uncovered looking at the inputs and outputs to an activity. An input could be a spreadsheet or e-mail with a new “lead,” and a content output could be the updated spreadsheet qualifying (“Qualified Lead”) or disqualifying (“Disqualified Lead”) the lead.
Figure 3 shows the beginnings of a taxonomy of content requirements that can be built to great detail.
View 3: Modeling the Sub-Activities
Building out the content taxonomy is as simple as following the trail blazed by the process decomposition. In a decomposition model, sub-activities inherit the characteristics of the parent activity. The goal is to refine the inherited content requirements into sub-requirements, so that they match precisely to each sub-activity.
In the example, “Sales Guidelines” was inherited from the activity called “Qualify Sales Lead.” Now, by evaluating the sub-activities, sales guidelines can be refined into two more precise sub-requirements called “Sales Strategy Guidelines” and “Lead Qualification Guidelines.” (See Figure 4.) Repeat this exercise for each of the inherited content requirements. Once complete, select a new sub-activity to focus on and repeat.
Reviewing and Refining the Taxonomy
If you walk through enough activities, you will find that a significant amount of content is common across the entire process, or across many processes. This is not unusual, since businesses generally operate around common goals and shared objectives. This realization helps you better understand that the inventory of content that provides the greatest learning value is not always unique to a single activity, but fairly broad in its use. For example, the lead qualification guidelines identified as a requirement associated with the qualification process could also have significant influence on marketing and PR processes. By minimizing redundancy, management of learning content is made simpler.
Now, put away your process model, and review your taxonomy as a stand-alone structure. Identify blatantly redundant requirements and merge them. Look for semantically similar requirements, and align or combine them where it makes sense to do so. You might want to reference your process model to better understand how you arrived at the current structure.
Populating the Taxonomy
It may seem like a lot of work to reach this point, but the value lies in forcing yourself and your subject-matter experts to think through things that may be second nature, but that you have never had to communicate in such detail.
On the bright side, you’re almost done. Perhaps the simplest way to find content to fill the inventory for your new taxonomy (and to provide a useful output as well) is to create a file structure on a common server that mirrors the taxonomy. Then, assign subject-matter experts to different “branches” and have them collect the best examples of content that fit into the taxonomical buckets. Certainly, you can also use a content- or knowledge-management system, or even a spreadsheet that captures relevant metadata (author, description, etc.) and content location.
Use a spreadsheet as the mechanism to capture your baseline architecture, and document where there is no learning that meets the content requirement. This spreadsheet becomes invaluable, serving as your to-do list of learning content that is determined to be high value, but does not exist. As you move forward in creating the content, you’ll know exactly what you need, and how and where it is needed.
Conclusion: Three Significant Benefits
First benefit—remember the epiphany that occurred as the taxonomy began to blossom? Many identical content requirements appeared across many different activities. The truth is that while most organizations are awash with content, only some of it is highly useful. The vast majority is either infrequently useful, coincidental to the business or simply has too little value and impact. However, many technology approaches to managing content promise value in every single piece of content. Frankly, the tip of the iceberg may be good enough.
The second benefit is the detailed and useful “to-do list” that can help deter-mine future content development.
Third is the creation of a highly detailed best-practices framework. Should you continue down this path and write a narrative describing each activity, the information could have tremendous impact on learning curves and ongoing training as a best practices manual or a digital tool in a learning environment.
Digital implementation is perhaps the most logical evolution of your taxonomy. The business processes that you have mapped could serve as navigation and an interface to learning as employees seek and retrieve content in the context of their job activities. Digital implementation could also provide the precise tracking mechanisms that give useful feedback on activities, content requirements and instances. This feedback not only validates the usefulness of your learning content, but also the learning experience itself.
David Ian Forbes, co-founder of Contextware, serves as its chief executive officer and chief technologist. He has more than two decades of experience in information design, usability engineering, marketing and media. David can be reached at email@example.com.