—Pablo Picasso

What is enterprise content management? In this chapter, I provide an overview of enterprise content management (ECM) to provide you with a basis of ECM concepts that the rest of the book references and builds upon. I also introduce a model illustrating the life cycle of a piece of content that I use throughout this book to relate the different aspects of enterprise content management in the context of an information life cycle within an organization. From there, I discuss the difference between transitory content vs. official records as I relate each to the life cycle of content within your organization. Finally, I consider some of the costs and value associated with an enterprise content management solution.

After reading this chapter, you will know how to

• Describe enterprise content management concepts.
• Explain the difference between transitory content and official records.
• Understand and apply the content life cycle model.
• Describe the costs and value associated with an ECM solution.
• Plan your approach to an ECM project.

Understanding the Value of Enterprise Content Management

An enterprise content management program delivers long-term value because it brings together information within the organization, facilitating the organization to function and operate rather than waste inefficiencies tracking down content or basing decisions on outdated or missing information. To achieve this, ECM enables collaboration and enterprise search, simplifies administration and management, systematizes policies and processes, and automates the retention and disposition of individual pieces of content.

Enterprise content management also standardizes content repositories, organizing several well-known locations for particular types of content, easing the management burden by centralizing the administration. This helps users find relevant content based on relevant locations, but it also helps protect and secure content by having policies cascade down through an area, ensuring that the right permissions are set for a given type of content, and minimizing the risk of a security gap due to incorrect or incomplete security access controls on a piece of content.

The automation in an ECM system provides further ongoing value, reducing time lags associated with waiting for human input, and eliminating labor costs accompanying human involvement. This system automation helps reduce errors, particularly those due to human error, as it validates input and processes workflows according to predefined steps and rules. Automation also helps maintain your content by automating its cleanup.

Cleanup of content is not usually a high priority for users, especially with their more pressing priorities in their job functions. As such, the majority of manual content cleanup usually coincides with deploying a new system or upgrading to a newer version. Your first wave of value with a new ECM implementation can come from the content cleanup as you reorganize some content and dispose of other content. Your subsequent waves of value come from any policies you define to automate the cleanup of content through retention and disposition.

Once content ceases to provide value, then it is time to dispose of it; otherwise, it will accrue costs without providing any value. Content has value while it is usable to an individual or workgroup to support their job function, or while it provides information to processes, or while the organization depends on it to capture historical information. When your ECM system automates the disposition of content as it ceases to provide value, you save those costs.

What Is Enterprise Content Management?

Although the term enterprise content management has only been around since 2000, its concepts have been around as long as businesses have produced content and retained records. Before computers became so ubiquitous and digital files began to represent the bulk of content, physical files, folders, and filing cabinets made up the implementation details for enterprise content. The ECM processes at that time focused heavily on filing strategies, ergonomic cabinet layouts, and effective use of index cards to cross-reference content.

With the onset of computers and the ongoing exponential growth of digital content, organizations began looking for ways to manage the different repositories of content, to build an overall strategy for content. Motivated by things such as ensuring compliance, protecting intellectual property, or leveraging existing expertise, organizations have been evolving their enterprise content management from the world of physical content to digital content.

Before one can plan and design an enterprise content management solution, he or she first needs to understand the meaning of enterprise content management and what it represents in their organization. It is not a simple answer, and this is mostly because of the complexity of organizations and the range of information they process.

The Association for Information and Image Management (AIIM) International, the worldwide association for enterprise content management, defines ECM as the strategies, methods, and tools an organization uses to capture, manage, store, preserve, and deliver the organization’s information assets over their life cycle and within the entire scope of an enterprise. This makes a nice overarching definition that I might sum up as the means to manage information within an organization. Let’s break this concept down a little further and take a closer look at enterprise content management.

First, I need to define enterprise content. ECM is such a huge category, and you probably already have some familiarity with its vastness, hence why you might have reached for this book in the first place. There is so much content, for one, and it varies between departments with an array of different kinds. A piece of content can serve different purposes at different times or maybe even different purposes at the same time.

I created a model to visualize and make sense of enterprise content—the content life cycle model I will introduce and describe in detail in a later section of this chapter. This will help me describe content in the context of different phases or stages of an information life cycle within an organization. For now, I just want to point out the general idea of an organization and its different types of content existing in different stages, all culminating, forming the enterprise content.

I think of content as units of information—a slightly more abstract way than simply referring to content, but it also gives me a contained and countable unit, rather than the collective noun content. Focusing on a piece of content, or a contained and countable unit of information, eases the process of analyzing and designing an ECM solution, all from considering the actual items and generalizing or abstracting from there.

Units of information come in a variety of types in an organization, each with some degree of formality, some level of sensitivity, and some scope of impact on the organization. Managers may make budget and planning decisions based on the information; employees may make operational and career decisions based on the information; investors may base investment decisions on the information; and customers may make their decisions based on the information. Here’s a list of some different types of enterprise content with different characteristics to consider:

• A code of conduct policy manual: This represents a formal document describing what is and is not acceptable behavior, typically forming a binding contract between the organization and its people. In some jurisdictions, this unit of information can protect an organization or hold it liable based on the policies it defines or omits, and whether it enforces the policies consistently.
• An executive e-mail sent organization-wide announcing organizational change: This represents a formal communication from one of the organization’s leaders. Again, due to its formality and its reach, this unit of information usually has regulatory requirements because investors will base investment decisions on its content.
• A product specification document: This represents a formal document with intellectual property that an organization uses for a competitive advantage in the market. This unit of information usually has strict confidentiality requirements to secure and protect the organization’s interests.
• A document with the meeting minutes from a project team’s status update meeting: This represents a formal and historical account of the meeting, but its formality and impact on the organization depend on the scope of the project and its criticality to the organization. It may serve as a historical document for a limited audience, allowing project team members to track their progress on a minor internal project, or it may serve as a contractual document detailing delivery and sign-off for major milestones on a business-critical project.
• A user’s status update on the organization’s microblogging site: This represents a small piece of informal content, typically an opinion or reference-oriented unit of information, one created ad hoc for an internal audience and with limited structure. It usually does not drive formal or critical decisions in an organization, yet a disgruntled user may post an inappropriate or particularly offensive update, requiring an organization to capture its evidence to support disciplinary action

With such a range of content, content characteristics, and content requirements, you can see how complex the scope that enterprise content management represents. There are many variables and many things to consider at a very granular level, and they can vary by department or they can vary by stage in the content life cycle. By breaking down different parts and analyzing individual elements, you will be able to design and build up a complex enterprise content management solution, built from the ground up using each discrete class of information as building blocks. Figure 1-1 provides a partial view of the range of enterprise content in an organization.

Users might need to analyze and describe each unit of information by applying policies and security to it, initiate workflows, and associate metadata to capture information about the content, such as how and why the organization uses it, its level of sensitivity, and other information to describe the piece of content. Figure 1-2 illustrates some of the different ECM components you can apply at the individual unit of information level. Not all of the information rolls up to a single universal rule you can apply to all content in an enterprise content management solution; instead, it entails a variety of cases and exceptions. You will have to analyze and work at this more granular level of content before you can build out and understand a comprehensive and global organizational view.

This concept is akin to analyzing traffic in a city at rush hour. You cannot take a single aerial photograph and use this global snapshot to study traffic—although this view might play a part in revealing the heaviest congestion areas and highlighting where to analyze deeper. On its own, the global snapshot will not provide deep insights into what caused congestion, because if your city is anything like my city, everywhere will appear congested and busy with traffic. Instead, you need to look at relationships and the flow of traffic and traffic patterns, zooming in on individual streets and intersections, monitoring particular arteries and entry points, tracking a sample of cars to identify patterns, routes, and destinations. Similarly, with enterprise content, you will have to look at units of information, their relationships and patterns, and their flows and processes.

As you work through your enterprise content management solution, remember the key is to break down the concept of content to analyze its particulars and to look at units of information, studying their relationships and modeling their life cycle, and then you can combine your analysis to design and build your ECM solution. You can identify the characteristics of different types of enterprise content by the following content externalities:

• Drivers: Drivers answers questions about any motivating factors behind a type of content. What produces the content or causes it to come about? What conditions require the content? Who creates the content? How does he or she create it? Why do you even need a particular piece of content?
• Constraints: Constraints answers questions about how you have to treat a piece of content once it exists. Where do you need to store it? How long do you need to keep it? When do you need to dispose of it? Who can access it? Who has accessed it? What are its legal and regulatory requirements? What other enterprise content references it or bases its decisions on a particular unit of information?

I will look more closely at these questions and others in different sections throughout this book. Answering these questions and the other characteristics of content gets to the essence of enterprise content management. As I indicated earlier, enterprise content is a complex category that consists of many interrelated parts. Its parts can take many different forms and degrees of formality, and they all constitute how an organization produces, consumes, and manages its information.

Enterprise content is a term that summarizes all the content within an organization, the units of information at different stages, different uses, and different formalities. Enterprise content management, or as some people prefer, ECM, summarizes the concept of organizing and managing this diverse span of content with its diverse management requirements. The details for how you achieve this are the topic of discussion for the rest of this book.

Now that you have a good idea about what enterprise content and enterprise content management both entail, I want to build on this by defining core ECM concepts, establishing a shared understanding of the different technical terms I will use throughout this book. This will also help you understand the different aspects of an enterprise content management solution, laying the general foundation to design and build your information life cycle strategy on. In the next section, I cover and define different enterprise content management concepts that will help develop your familiarity with the topic.

Enterprise Content Management Concepts

Enterprise content management is a strategy for how to handle information within an organization. It implements a vision, encompassing how users interact with content and what the organization depends on with the content. It is not a closed system within the organization, because you cannot isolate and segregate it from how the organization functions.

It is not a packaged product nor is it a technology solution. However, technology can automate, control, and standardize certain aspects of your ECM implementation. You do not purchase an enterprise content management package, but you can purchase tools to implement your solution, a solution you design based on analysis of information within your organization and its related business processes—analysis this book will guide you through.

Your enterprise content management solution will consider your organization’s content, from the formal to the ad hoc, from creation to disposition. The end state will certainly be a technology implementation, but there is a lot of analysis for you to do before you can design that implementation. You do not have to solve everything all at once; instead, you can tackle manageable chunks as you go. Figure 1-3 illustrates a phased approach to enterprise content management.

This book will help you break down the challenge of ECM into those manageable chunks, first looking at an individual part, stepping through the analysis, and then guiding you on configuring the solution in SharePoint. Each of those parts may involve different technical terms or technical concepts, terms I will use throughout this book. As such, I think it is important to provide you with a description for some of the more popular terms, many of which you will already be familiar with, all to ensure we share a common ECM vocabulary.

The following sections list and describe popular ECM terms and concepts, grouped by document management, security management, business process management, and general information management. This is by no means an exhaustive list nor is it a conclusive glossary for this book; instead, it will help get you started with core terms I will use and later build on throughout the book.

Transitory Content vs. Official Records

There is one major dividing line determining what content life cycle stage a piece of content is in, and this is the distinction between transitory content and an official record. These two major classification categories separate your focus for the content and its organizational purpose, such as the amount of rigor you want to apply to its policies and what regulations apply to a unit of information.

Transitory content represents the content an organization has not designated as an official record, although individual pieces may or may not become part of a permanent record or a historical archive. An organization can delete transitory content once its use turns dormant, because it has no retention requirements beyond the users’ active and current need. Once transitory content reaches a stage with retention requirements, you designate a version as an official record.

Official records declare a unit of information as a permanent transaction or transcript resulting from an activity or decision, providing stable evidence the organization can base future decisions on. Typically, an organization must retain a record for a predetermined period, either to meet external requirements such as legal or regulatory compliance, or to capture internal historical archives.

One significant difference between transitory content and official records relates to how fixed or flexible a piece of content substance can be. With transitory content, a unit of information’s subject matter and contents can change. In contrast, a record must remain immutable—once you declare a unit of information as a record, the entire unit must remain unchanged to protect the integrity of the record. Where a transitory piece of content may or may not retain a detailed history of any changes, a record is a snapshot of a unit of information at a specific point in time. Any other versions of a record are new snapshots at a different point in time, and thus they constitute a new and distinct record.

You can declare a record and move it or a copy of it to a records repository, or you can declare a record in-place. In-place records allow users to continue to find content in context based on its topics or usage, allowing the record to remain part of the SharePoint site. Records you move to a records repository will centralize the content into a file plan, routing the record to an appropriate classification container within the file plan.

A record often starts out as a piece of transitory content—a draft document a group of users collaborate on producing, an electronic form progressing through the early stages of an approval workflow, a spreadsheet with a manager’s preliminary budget calculations—working its way through the transitory phase as its creators finalize the contents. Figure 1-4 illustrates transitory content progressing into an official record. A record can also skip any transitory phase, at least from the organization’s perspective, such as vendor invoices that users receive by e-mail and directly upload and declare as a record in the repository.

You will capture different types of records and you can treat them each in their own way, accomplished by applying the implementation details to an area in the file plan or to the content itself through SharePoint workflows and policies. For example, you might want to offer an archive repository to store project information for a period for reference purposes. The requirements for this particular scenario can vary greatly, depending on the archival and retention requirements.

Your requirements for content archival and retention can range from informal to formal, from internal historical interests to external compliance stipulations. For some records, your requirements might be to retain nonbusiness critical, nice-to-have historical information, all to make available just in case a user wants to reference it in the future. For other records, your requirements might be to retain legally binding information with a detailed audit trail, records that external agencies require you to maintain with some rigor.

To return to the example I just mentioned (the project team archiving their project information), this can range from informal to formal, depending on things such as the scale and scope of the project, the nature of the project information, and the ongoing business impact of the project. On the informal end of the range, you might imagine an IT project team deploying a simple intranet homepage for a department to describe the services the department offers. The documentation work products from this project might include things such as a design document and a project schedule. Neither of these documents provides any ongoing business contribution nor do they have any future business impact. However, the project team wants to archive them to allow another team to copy and reuse sections from the documents on another project.

In contrast, imagine a real estate development project team purchasing land and developing a property there on behalf of investors. The documentation work products from this project might include things such as building blueprints and financial reports. They may need to capture the blueprints for historical purposes; and since buildings last a long time, they have to archive them for at least 50 years. They also have to meet financial regulations to retain any financial reports and transaction content. The organization may need to produce either of these documents in the future to comply with an external agency’s review, such as a building inspector or tax auditor.

Your transitory content is even more diverse because it includes a huge category of content—everything from a user’s status update on a microblog site to detailed documentation a team is collaborating on and producing, or from an e-mail thread between colleagues to article pages posted to a portal. Up until someone designates a piece of content as a record, it is transitory. This represents a massive corpus of content and a major component of any enterprise content management solution. As such, I dedicated a deserving potion of this book to help you plan and design this aspect of your information life cycle strategy.

Just because it is transitory does not mean that the content is not included in any compliance, regulatory, or legal implications. If a case comes up, your organization has to identify all content relating to the case, whether or not a piece of content is officially a record yet. To an outside agency or legal counsel, any related content is relevant content. SharePoint eDiscovery manages this by enabling a case manager to discover content across any repository the search engine indexes, allowing him or her to capture and place any content on hold to preserve its integrity for the case.

I spent some time in this section defining transitory content and official records, taking a closer look at the difference between the two, and discussing how each divides the mass corpus of enterprise content into one of these two categories. For me, this is a helpful division to keep in mind when I analyze content life cycle details and I design an enterprise content management solution for an organization. I find that this is the first step to break down the complexity and sheer size of enterprise content management.

Transitory content and records also make up two major states of a more detailed information life cycle. As I continue to break down enterprise content management into its more granular parts, I look at details and stages within the information life cycle. I designed a generic model, one I called the content life cycle model, to apply and make sense of the enterprise content management problem I am addressing, a concept and process I describe next.

Understanding the Content Life Cycle Model

A model serves as a representation of a more complex system or process, providing a framework or pattern one can use to make sense of the complexity and to understand how to manage it. In this way, I designed my content life cycle model to represent the more complex concept of enterprise content management, providing a framework you can use to analyze the different aspects of your content, all by tracing the life cycle of different units of information. From there, you can design and implement an elegant enterprise content management solution in SharePoint 2013.

My content life cycle model is not the first model for enterprise content management, nor does it replace any other model you might have familiarity with. In fact, there is the Association for Information and Image Management (AIIM) International, a nonprofit organization conducting and documenting information-related research. They provide a popular information life cycle model, one often referred to by some as the “ECM 101 poster.” AIIM separates the information life cycle into these five phases:

• Capture: The process to move content into your content repository through human-created or application-created business processes.
• Manage: The tools and techniques for controlling content within an organization.
• Store: The repository for the content, including library services and any other storage technologies.
• Deliver: The means to provide relevant content for an interested audience on their preferred device through data transformation, security, and content distribution.
• Preserve: The long-term archival and storage solution for content continuing to provide organizational value or meeting an organizational obligation.

I find this model useful in considering the different aspects of an enterprise content management solution from a high level, but for my purposes in this book, I find the phases on their own overly abstract and generic, making them difficult to apply and difficult to analyze a specific piece of content within an organization. For me, the AIIM information life cycle model works well for theorizing the life cycle of information in general, but I created my own content life cycle model for looking at actual content within an organization’s SharePoint environment. In this book, I use my model to analyze how users interact with the content.

Information goes through a life cycle within an organization, not always starting from the same place nor always ending up in the same place, nor even following the same path in between. Yet the general outline or pattern of this life cycle stays reasonably consistent, at least enough for me to model a basic framework. I will build up my content life cycle model slowly for you, stepping through each part to make it clear. To start, content comes into being either from a user creating it or from a user receiving it, such as with an e-mail attachment that a user receives and then uploads to a SharePoint site. Figure 1-5 illustrates this early portion of the content life cycle where content comes into SharePoint.

Once content is in SharePoint, SharePoint begins to manage it through the product’s different features and capabilities. SharePoint manages content through specific sites using features such as policies and workflows. Figure 1-6 illustrates where in the model SharePoint manages content in the process, and in the context of disposing of transitory content using policies and workflows.

With content stored and managed within SharePoint, users will want to interact with it to base decisions on and to support their job functions. Users first need to discover content in order to interact with it, which from the system’s perspective, entails a user noticing relevant content on his or her newsfeed, or a user explicitly searching for content, such as by using the SharePoint search engine or by clicking through directories. Figure 1-7 illustrates where users discover and then interact with content in the life cycle model.

Finally, an organization needs to retain certain content for regulatory compliance reasons, evidentiary reasons, or historical reasons. SharePoint preserves content by designating it as a record. Figure 1-8 illustrates where in the model SharePoint preserves content as a record until a retention policy disposes of it.

If you compare my content life cycle model with the AIIM information life cycle model, you will notice some similarities and consistency between them. Indeed, my model follows the pattern of the life cycle that a unit of information might go through. I added some extra detail and phases to the model and I increased the verbosity to phase labels, making the models similar but not the same, increasing the details and zooming in on parts to increase its application for a SharePoint ECM solution. Figure 1-9 overlays my content life cycle model with phases in the AIIM information life cycle model to illustrate how the two models relate.

As you consider the content life cycle model, one of your critical tasks is to identify every process within the model that you can automate—from creation to disposition, and everything in between. The more you can automate in the content life cycle, the more standardized and mature you will make your enterprise content management solution.

Comparing ECM Costs and Value

Aside from the smallest and simplest organizations, an enterprise content management solution is going to be costly—the deep and thorough analysis you require to design an effective solution will require a significant investment in terms of both expense and effort. Its magnitude is just too colossal and complex, particularly leading up to and including its implementation.

If you think of ECM as an all-encompassing program rather than simply an implementation project, you can calculate and weigh its costs against its value to form a clearer picture of your long-term investment and your expected return. You frontload the bulk of your investment into an ECM program as you analyze, design, and implement an ECM solution. After you have a solution implemented, your ECM program can begin to deliver value to offset its costs. As Figure 1-10 illustrates, once you spread the program costs over the life of an ECM program, the magnitude of the costs begin to diminish, while the magnitude of value climbs.

Other costs related to an enterprise content management solution and the value derived from it are harder to quantify. For example, as I noted in the sidebar, compliance is a major component to an enterprise content management solution, and those costs associated with any risks from being out of compliance are difficult to calculate. Will a judge consider the organization in contempt of court and issue a fine if content related to a case is not forthcoming in accordance with a court order? What is the cost if an organization is unable to find a contract to exonerate their liability in the case of a lawsuit? What is the value of being able to audit and systematically prove that an organization complies with any regulatory or legislative obligation?

Some of your investment costs and the value they return are easy to calculate and quantify. Others are less explicit or only probable. Still others are more indirect and less monetary-related, such as reducing lags or wait times with automation, and facilitating group collaboration with shared workspaces. As you factor your cost-benefit analysis of an enterprise content management program, remember to consider the long-term value that a mature and sophisticated ECM implementation will return for the organization, not just its upfront implementation costs.

Approaching an ECM Program

Where do you start? These enterprise content management concepts and theories all sound great, I bet; but you might be wondering how you get started with your own ECM program. After all, enterprise content management is a massive topic and it encompasses every aspect of content within your organization, which is no small matter. The idea of attempting to take this all on at once can seem daunting, at least for me.

I am a firm believer in breaking down complex problems into smaller, more manageable units. I look to do this on almost every project that I am on, and enterprise content management is no different. If you are familiar with how I like to approach anything in SharePoint, then this will not come as a surprise to you. Essentially, my formula for SharePoint project success, whatever the project or project scope, follows a consistent cycle of phases. I always try to start with a pilot deployment of basic SharePoint functionality, something that provides a baseline to reference and expose to stakeholders, and then I build on that base with a series of project phase iterations.

I prefer frequent and focused iterations that include the following stages, achieving a tiny bit at a time within each iteration cycle, building on the previous iteration and delivering incremental value:

• Select a small piece of the larger problem
• Analyze the different aspects of the narrower scope
• Envision a solution concept and design the solution details
• Build the solution
• Test and stabilize the solution
• Release the solution

I continue repeating this cycle until I solve the larger problem or deliver enough value that my client or stakeholders are satisfied. If there are any unknown variables or unclear requirements, or if there is a high degree of complexity with an aspect, then I focus on a proof of concept deployment to mitigate any risks and refine the solution by proving out any solution concepts and assumptions before over committing the project direction on risky aspects in the solution design.

Once I am successful with releasing one focused and limited aspect of the solution, I repeat the cycle on another piece of the overall business problem that the project is working toward solving. You might notice that these phases and iterations closely resemble the Microsoft Solutions Framework (MSF), and this is because I generally adopt and apply the framework to my projects. The phases of MSF are envisioning, planning, building, stabilizing, and deploying, as illustrated in Figure 1-11.

For me, these phases provide a natural and productive progression through project iterations, frequently delivering smaller iterations, ultimately reducing the overall project risk while the process propels a project forward. Trying to take on too much at once will take excessive amounts of time to deliver anything, and it could even lead to a paralysis of the team’s momentum as the ominous task of solving the enterprise content management problem stares down at you. Yet when you scale the problem down into manageable chunks, it does not seem as intimidating.

This type of phased approach seems like a good fit for more straightforward aspects of a SharePoint deployment, such as basic collaboration sites or departmental portal sites, but the approach also works for something as large and complex as enterprise content management. In fact, you may find, as I have found, that overly large and complex projects are the most successful when you simplify them by taking an iterative approach. Do not fall into the trap of trying to tackle everything all at once; instead, break it down into simpler pieces, and then select one to start with the first iteration.

That leads into the next set of questions: How do you decide where to divide the scope of the iterations, and which one do you start with? This can present a bit of a dilemma, because you should start with a small focused piece of the your overall enterprise content scope, but you do not want to have one area within your organization dictate how every area will categorize and manage content, simply because that area went first in your project delivery. For example, if you start with the IT department, you might find they have a detailed and heavily engineered process for categorizing and managing content, simply because the department is technical by nature and people in it tend to take a system-oriented view of things. In contrast, if you started with the sales department, you might find they take an opportunity or a campaign-oriented view of things, focusing on how different aspects relate to their sales pipeline and the percentage a lead is progressing through the sales process—a much less systematic and system-driven process, resembling a more intuition and relationship-driven process.

If you focus too heavily and exclusively on a single department, you risk that department influencing, and possibly distorting, the organization-wide requirements. Conversely, if you try to implement an enterprise content management solution for every department, you will probably struggle with trying to scale to balance and manage the volume and intricacy of information across the organization.

I prefer to divide my ECM implementations into phases separated by departments, because they already form a discrete unit within the organization with an existing reporting structure of stakeholders and processes that I can use to build a project plan. However, I first like to take an enterprise-wide view of the content and common ways to categorize and manage it. For this first phase, I do not perform deep analysis, and instead I make a quick pass over the main kinds of content for each department, only doing some preliminary analysis to identify commonalities and standards that I can consider when doing a closer and more detailed analysis for each department.

From there, I divide an ECM program into departments or groups within departments, where I analyze, design, and implement an enterprise content management solution based on their requirements. For the most part, I find success through this approach of taking a quick pass for an enterprise-wide view followed by project iterations that focus on smaller groups within the organization. I may have to revisit an earlier department’s design and implementation based on new knowledge uncovered in a subsequent phase with another department, but this is not terrible and the idea of minor rework should not scare you away from taking this phased approach. Besides, you can usually automate most changes and rework through a PowerShell script.

To organize your plans, I recommend building a project plan, using either a SharePoint project task list or a Microsoft Project plan, or both. I like to build out a work breakdown structure (WBS), starting with the main project phases that I will use to divide the project into defined iterations, and then I begin to fill in the details of the summary tasks within each phase before moving down to the individual work item details. This project plan will help you plan your resources and coordinate activities with different departments and groups your project team will need to work with. Microsoft Project is usually my tool for this planning, but I also like to synchronize the project plan with a SharePoint list to communicate it with the rest of the project team and any stakeholders.

One technique I like to use is diagramming a visual representation as I plan a project approach and the major work items in a project. Figure 1-12 illustrates an example of how I might use a workflow diagram to provide a visual summary of major project tasks or phases. I use this technique both to organize my thoughts during my project planning process and then to communicate a high-level overview of the project. During the project delivery, I include copies of this visual summary to provide status updates by color-coding or adding check marks to highlight progress through each iteration cycle.

With a project plan detailing your phased approach, all you have to do now is execute on your project plan. Project plans change, timelines shift, and new work items come up all the time, but for the most part, they give you direction and they organize everyone’s efforts. I find that I revisit my project plan after each iteration phase, where I prepare for the next phase by building out a detailed list of tasks for that phase, and then I adjust any timelines or dependencies for the subsequent phases. One of my favorite benefits derived from a phased approach is that it provides a regular checkpoint where I can assess the project team’s overall progress and I can check for any problem areas that might affect the ECM program.

Wrapping Up

Enterprise content management is a complex topic—complex enough to warrant this book and many others, dedicated entirely to the subject. In its essence, it is how you manage content through its life cycle, from facilitating users who are creating or capturing content, to surfacing relevant content to users through search or social feeds, to retaining evidentiary content that the organization depends on in the future, to disposing of content once it is no longer of value. In this chapter, I provided an overview of enterprise content management and some of its core concepts, which I will build on throughout this book. From there, I explored the difference between transitory content and official records, with transitory content representing any content not designated as an official record, and official records representing evidence that an organization can base future decisions on. Finally, I described the content life cycle model and I considered the costs and value associated with an ECM solution.

Understanding enterprise content management in general is vital for designing and implementing an ECM solution in SharePoint, because the industry ECM concepts remain consistent, whereas only the implementation and configuration details are specific to SharePoint. With an understanding of SharePoint and its capabilities, you can begin to translate these general ECM concepts into the aspects of a SharePoint deployment that you will need to enable. In the next chapter, I shift to provide you with an overview of the ECM features built into SharePoint 2013 and how these features and the different SharePoint capability areas build on and complement each other as part of a comprehensive enterprise content management platform.