Using lifecycles to improve ECM initiatives

Lifecycles are an important concept that I use in my practice on nearly every engagement. I find they can add value in a number of ways, from acting as purely explanatory models at one end of the spectrum to functioning as risk and value criteria or process modeling frameworks at the other. In this post, after learning more about what I mean by lifecycles, we’ll take a look at some of the basic ways I’ve found the lifecycle concept to be useful.

In simplest terms, lifecycles describe the changes people and things go through as a result of the work done at an organization. The best way to begin to understand them, however, is to look at some examples:

• Employee lifecycle: from job application, through hiring, onboarding, and ongoing management, to termination.
• Document lifecycle: from initial creation, through review and approval, to eventual disposition according to the corporate records retention schedule.
• Sales lifecycle: from lead, through opportunity, to proposal and contract.
• Order lifecycle: from order taking, through payment processing, to shipment and delivery.
• Asset lifecycle: from procurement, through maintenance and use, to end of life.

As this short list of sample lifecycles indicates, as a concept they’re quite simple and would make sense to most folks at an organization intuitively (or with a little explanation)—which is one reason why they can be such a useful explanatory tool during an ECM project.

In addition, most lifecycles tend to be portable, i.e., they occur across all (or almost all) organizations…after all, what organization doesn’t have employees, documents, assets, etc.? This increases the probability that the lifecycle approach will add value across a wide range of clients despite differences in size, industry, organizational structure, and so on.

Finally, lifecycles are valuable because they are a quick and effective way to focus on activities and processes that cross organizational and functional boundaries, which can help ECM initiatives break down the silos based on process area and repository that typically impair an organization’s ability to manage its content effectively.

One other thing to note about lifecycles: although we often examine them in isolation as part of project work, in the larger scheme of things, they aren’t isolated from one another at all, but have complex and important interrelationships. For example, the document lifecycle occurs as a part of nearly every other lifecycle at an organization (or at least those that rely on documents). The sales lifecycle forms the initial part of the larger customer lifecycle. The order lifecycle forms a later part of that same customer lifecycle (hopefully many, many parts!). And so on.

Now that we have a better idea of what I mean by lifecycles and why they can be so effective, let’s turn to look at some specific examples of how you can use them in your practice or at your organization to improve your ECM initiatives.

Lifecycles as explanatory models

In the most basic sense, I use the lifecycle concept to make sure everyone is speaking the same language. Organizations often have idiosyncratic terminology for otherwise common activities, whether because of industry- or organization-specific variables. In either case, before we can do our jobs effectively (whether that means gathering requirements, process mapping, or simply understanding the issues users face around managing content), we need to ensure that we understand precisely what they’re talking about. So, for example, if we’re discussing the “hiring process”, introducing the employee lifecycle concept can help us more quickly get our arms around what “hiring” actually means at to that group of stakeholders at that organization. Does it include the job posting process or the onboarding process as well as the application process? What do they consider part of the application process? And so on.

The way to introduce lifecycle into this kind of a discussion is, early on, to say something like, “Although we’ve worked with a lot of organizations around HR processes and we think we have a pretty good idea of what hiring would include at your organization, we don’t want to make any assumptions or miss anything because we were guessing. So if we look at the typical steps in the employee lifecycle, which of them would you consider part of your hiring process?”

Lifecycles as risk and value assessment criteria

In previous posts (here and here), we looked at some simple ways to use risk and value based assessments to contribute to ECM initiatives. Lifecycles can be used in both risk and value based assessments as one of the criteria that influence the assessment.

For example, in the risk management exercise in my last post, rather than using buckets based on types of risk (e-discovery, operational, and reputational) as I did there, you could begin from key lifecycle categories (such as customer, sales, order, product, etc.) and list the risks and risk mitigations associated with each of them. The advantage with a lifecycle approach is that the risks will be bucketed into categories that have immediately apparent value to users—after all, you will likely have to spend some time explaining to the average user about exactly how operational, e-discovery, or reputational risks affect the organization (and more importantly why they should care), whereas risks to the customer or product lifecycle tend to be more self-explanatory (and can often have more urgency associated with them right out of the gate).

Lifecycles as process modeling aids

In a previous post, I presented a lightweight method for process modeling that I frequently use in engagements. One issue that typically comes up during this exercise is what business activity counts as a process, exactly. Users then give examples of things they do in their day-to-day jobs, which can be everything from the hopelessly granular (telling you all the steps in putting together a single report or document) to the most general (“I’m responsible for customer service”).

Introducing the concept of lifecycles can help you move from either of these extremes to the middle ground you need to facilitate a successful process modeling exercise. For the hopelessly granular, you can say something like, “I want to make sure we stay far enough out of the weeds that we get all the information we need during this session (and respect all your time as well), so do you think that we could discuss where the work you do fits into the larger customer lifecycle and what parts of it you contribute to?”

For the responses that are too general, you can say something like, “Although we’ve done a lot of work with organizations similar to yours around customer service, we don’t want to assume what is and isn’t included in the customer service activities you’re a part of. Do you think we could use a typical customer lifecycle to as a starting point to make sure we’re all on the same page about this?”

The final word

Although this post only just scratches the surface of how lifecycles can be used to contribute to an ECM engagement, hopefully it gives you a good place to start introducing them in your own practice or organization. And if other folks out there have used them successfully (or have had challenges doing so), I’d love to discuss your experiences here, so fire away!