Two sides of e-discovery
Last week I led a conference session at the Arizona IT Symposium on Managing Information for Litigation, Audit, and Regulation. The session presented the framework we use for assessing and improving an organization’s ability to meet the typical information management requirements associated with these compliance activities.
As useful as that framework can be—and as useful as I think some of the session attendees found it—we spent a good deal of time talking about a more fundamental issue, one that’s at the heart of how any organization structures its response to litigation, audit, and regulation, i.e., the distinction between pre-trigger and post-trigger activities. The distinction is important because an organization needs to approach these two sets of activities differently to be successful at each, particularly in the case of litigation management.
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.
Surprising thoughts on IT portfolio management
I was in Phoenix this Thursday to lead a conference session at the EFM IT Symposium on managing information for litigation, audit, and regulation. I got there at 8:30 for breakfast and, with two cups of decaf on the table in front of me, was ready to sit through a pleasant (but more than likely underwhelming) keynote address. What I got, however, was refreshingly more than I had expected.
Russ Bostick, CIO at Conseco (which is rebranding to CNO Financial Group), was the speaker, and the topic was IT Portfolio Management—which doesn’t exactly jump off the page as compelling for an 8:30 am slot running on decaf…but before we even got through the first slide, it was clear that we all were in for a valuable 45 minutes.
Risk-based ECM decision making
In a previous post, we looked at ways to use process analysis to inform ECM decision making. In this post, we’ll look at one way to use a risk analysis to do the same.
Review of Let’s Get Real or Let’s Not Play
Let’s Get Real or Let’s Not Play: Transforming the Buyer/Seller Relationship, Mahan Khalsa and Randy Illig
I discovered this book while preparing a series of internal workshop sessions on client relationship building at my firm. I read a number of books that were concerned with relationship building in one way or another, and Khalsa and Illig’s work is head and shoulders above the rest for three reasons.
COE alignment
In a previous post, we looked at some of the reasons why I see COEs fail in my practice. Two of those reasons had to do with the alignment between the COE and the larger organizational context:
- Failure to align with the aims and goals of the larger organization
- Failure to adapt to changing conditions in the larger organization or marketplace
In this post, we’ll take a look at one approach to establishing and maintaining alignment both within the COE as well as between a COE and the larger organization and the marketplace.
Process-based ECM decision making
In my work with clients, I’ve found that many issues and challenges related to ECM initiatives can be overcome by using the results of business process analysis (BPA) to drive decision-making. In this post, after a brief overview of the particular flavor of BPA I use, I share how BPA can contribute to two typical ECM initiatives: content migration and taxonomy.
The particular approach to BPA I use is far from a comprehensive, Six Sigma type undertaking, because the goal is not to fix the process under consideration (that’s business process redesign – BPR) but to gain an understanding of the process in order to use it as the foundation for making key decisions related to the ECM initiative.
Given that goal, BPA is a fairly straightforward exercise that can be accomplished rapidly. The process goes something like this:
8 reasons COEs fail (Part 3)
In this post, we conclude our consideration off the eight reasons COEs fail with reasons 6-8.
#6. Inappropriate COE model for the process area, business activity, or capability the COE is meant to address
As I touched on in reason #3 in the last post, there is a continuum of authority that any given COE sits on, from purely advisory to authoritative, i.e., from here’s a recommended way to do things to here’s the way they must be done. This is one of the axes that COE design must consider: the other is from strategic to operational activities, i.e., will the COE only be involved in deciding what will be done, or also in deciding how to do it?
8 reasons COEs fail (Part 2)
In the last post, we looked at the first two reasons COEs fail. In this post, we continue our look at the eight reasons COEs fail with reasons 3-5.
#3. Lack of top down support
Even if a COE is positioned to meet a real organizational need, without some measure of top-down support, it faces an uphill battle to remain relevant and avoid becoming simply one more committee in the eyes of the wider organization. It’s possible, of course, for a COE to be relevant, respected, and do productive work with no executive-level support, but it’s more difficult, and the kind of work it can do at the organization is more limited than it could accomplish with that support.
Without getting too deep into COE design principles, there is a continuum of authority that any given COE sits on, from purely advisory to authoritative, i.e., from here’s a recommended way to do things to here’s the way they must be done.
8 reasons COEs fail (Part 1)
In my last series of posts (and in the spirit of John Mancini’s 8 Things page), I looked at eight reasons why a COE might be a good choice for some organizations. In this next series of posts, I turn to consider the eight main reasons I see COEs fail—or at least struggle—in my own practice. Here they are in a nutshell:
- Failure to address a real organizational need
- Failure to align with the aims and goals of the larger organization
- Lack of top down support
- Gaps in stakeholder representation
- Insufficient time commitment from COE members
- Inappropriate COE model for the process area, business activity, or capability the COE is meant to address
- Culture clash between COE and larger organization
- Failure to adapt to changing conditions in the larger organization or marketplace
With that, let’s turn to look at the first two.
agile ramblings 