Last week I wrote that I’m starting to focus on a new market for my services; for a number of reasons I’ve decided to have a go at landing clients from the craft beer industry in Western Canada. Something I didn’t mention in last week’s post is that the craft beer scene in Alberta is booming. Recent rule changes and “incentives” have combined to make it easier and more feasible to start a small brewery, so plenty of small breweries are getting started. This has me excited for a few reasons:
- more breweries = more craft beers to try;
- more Alberta breweries = more Alberta jobs;
- a booming craft beer industry = better chances of me succeeding.
In fact, I’m so excited I started a semi-serious, but mostly not, beer related blog.
Anyways, on to the point of this post …
All brewers, regardless of size, pretty much have to comply with the same governmental regulations, do the same types of activities and quality checks, maintain equipment, clean equipment, be safe, etc. What really changes are the ability and will of the brewers to invest in IT tools and services to make these things happen in an efficient, cost effective manner. Many of the brewers I’ve spoken to are using spreadsheets, whiteboards, and loose-leaf paper to get stuff done. Even those that are using some combination of brewery management and accounting software are struggling to stay ahead of things. So I’m thinking that they’d be all over this content / information / records management thing (I didn’t really think that). It turns out that those who are interested are interested in solving business problems. Go figure.
Like Every. Other. Client. I. Have. Spoken. To. they don’t care what something is called or what tool is used as long as problems are getting solved, issues are being addressed, and opportunities aren’t wasted. And like every other industry sector I’ve worked with, the size of the organization doesn’t dictate what the requirements are.
Late the week before last week I met with the CEO and the Controller of a craft brewery. We chatted a bit about beer, the beer industry, what their goals / vision are, what I could do for them, and what their challenges are. Surprisingly, they didn’t say “we have challenges managing content.” It turns out that their most pressing priority is having the information they need to make the decisions they need to make to achieve their vision. Sound familiar?
I’m willing to bet that as I talk to more and more brewers I’ll be hearing the same things I’ve been hearing for the majority of my career. Regardless of industry or geography, for-profit businesses have challenges with making decisions, being efficient, being competitive, and being profitable. Good information and effective automation can a go a long way to help companies meet these challenges, regardless of size, industry, or geography. Information is a strategic corporate asset and must be treated accordingly. In today’s environment, automation does not necessarily mean capital investments in infrastructure, expensive software licences, and spinning up a large IT department. We’re in a time and place, thanks to cloud technologies, where smaller organizations can have the type of functionality that used to only be available to large enterprises.
A few weeks ago I was approached about working with an organization to help them put together a new SharePoint 2013 site to replace the one they currently have (SP2010). The business unit that approached me is responsible for engaging with stakeholders when the company wants to build infrastructure in their operating region; let’s call the unit EE (external engagement) for the sake of discussion.
Now, before I get all ranty and critical, you should know that EE wasn’t getting much love and attention from IT; this post is not about assigning blame to EE or their Business Analyst, with whom I’ll be working pretty closely. The fact is that there are problems in how IT engages with the business that are way beyond the scope of this post. As you read this post, keep in mind that a business case has been prepared and approved by IT (a VP) and EE (a Director and an SVP).
“To enable [EE] to capture the benefits of SharePoint in our department, we need to revisit our existing 2010 [EE] Team site.” That quote is the first sentence of the main body of the approved business case for the project. The case goes on, in excruciating detail, to describe in non-quantifiable terms how implementing various features and functions available in SharePoint 2013 will benefit the department. What the case doesn’t contain is any sort of goal or objective from the business indicating why the project is necessary and what the measurable business outcomes ought to be. Nor does the case contain any criteria upon which project success will be based.
If I were to summarize the business case as it’s currently written, it would be something like “There’s a bunch of cool SP2013 stuff that isn’t being used and we think we can use it to make our site look pretty and show people what we’re doing and we’ve started a Proof of Concept (PoC) that we’re going to finish soon to show you just how pretty those SP2013 things will look on our site and we’re going to do whatever we want whether it’s standard or not even if it’s stuff that other projects and departments are really responsible for. Okay?”
In addition to containing a shopping list of SP2013 features to be deployed, the business case also makes assumptions about the way in which many of the features will be deployed. Now, having some insight into the organization, I can tell you unequivocally that many of those assumptions are incorrect because they don’t comply with standards and guidelines that the organization has adopted. To be fair, had IT paid more attention, these deviations would have been caught and much time and money would have been saved.
I, and others, have advocated for trying to get the most out of the technology organizations have on hand. However, that doesn’t mean that organizations should invent requirements that provide no discernable business benefits simply to make use of some feature that’s currently sitting on a shelf. What it means is that, once real business needs and benefits have been identified, organizations should look at the tools they have on hand before going out to acquire something else. Of course, this should all be bound by an organization’s standards and guidelines.
Fortunately, the business case has been approved only to get the business requirements done. The organization uses a pure waterfall, gated SDLC so I’m going to use that to our advantage and try to get things back on the right track. I’m also going to try and get the PoC descoped or killed altogether. Things aren’t so far down the path that they can’t be corrected, but it will take a fair bit of cajoling and coaching of the BA. We’ll also have to get IT more engaged but I have a pretty decent PM to help with that bit.
Things to take away from this story:
- Only deploy technology based on identified and accepted business needs;
- Have measurable outcomes defined so you can actually determine whether or not you’re succeeding;
- Business and IT are partners and must work together;
- If your BA isn’t that strong, make sure they are properly coached and supported;
- Don’t sign off on a business case that doesn’t contain business objectives, business drivers, or success criteria;
- If you’re not going to comply with corporate standards and guidelines, cool, but have solid justification for not complying;
- If the first sentence in your business case is something like “To enable [EE] to capture the benefits of SharePoint in our department, we need to revisit our existing 2010 [EE] Team site.”, you don’t actually have one;
- Shiny Object Disease is both preventable and curable.
 Many years ago I had a contract gig with a major airline. My sole responsibility was to evaluate non-standard IT requests to determine whether or not the provided justification was sufficient enough to warrant approving the request. I.e.: Standards and guidelines can occasionally be broken if there is valid justification.
There’s an old saying in car racing that goes something like “you can’t win the race in the first corner, but you can lose it.” There is a similar truth when talking about software. The right software will not fix your problems, but the wrong software will surely exacerbate them. This, then, is a little story about choosing the wrong software.
Just prior to Christmas 2015 I took on a small project in Vermont. It was a bit of a weird situation in that the project was a mashup of two projects I’d done the previous year; the client was in the same business as another client, and the project was the same as a different client. No matter.
The client wanted to find out why their staff wasn’t in love with the Enterprise Content Management (ECM) solution they’d deployed a few years earlier and why things were failing. With a few exceptions this could have been a copy of an assessment I did for a university (detailed in this post & case study). The key differences were the technology chosen and the business the two organizations are in. In the case of the university, at least they chose the right type of technology for their needs. The folks in Vermont kinda, sorta, almost made the right choice, but not quite.
Back in 2008/09 their legal folks decided that they needed something to manage all their documents, so they went out and sourced a document management product targeted to professional services organizations. At the time no one was thinking holistically about what the organization needed. Whatever, it’ll all work out. Uhm, no.
As they were researching what to buy, they determined that their compliance and procurement departments had similar document management needs, so decided to deploy whatever they bought to those groups as well. There’s nothing wrong with trying to get more bang for your buck, assuming that the fit is right. Right?
My client went out and selected a product and got it implemented. Now, the implementation did not go smoothly, but that was nothing to do with the product and everything to do with selecting a less than stellar implementation partner. However, that’s not what this story is about, though you really need to be careful about selecting an implementation partner.
Once they got the implementation under way, they decided that the product they chose would be their ECM standard. There was a tiny problem; the product they selected was not an ECM product. As stated on their website [name withheld] “is the global leader in professional work product management”. The vendor’s target market is primarily law firms. Over the course of the project I spoke to the vendor and a couple of peers that work for organizations that use the vendor’s tools. They all agree that the product is not suitable as an ECM platform. The two peers I spoke to said that the product is very good if you use it for what it’s designed to do, but you’d be mad to try and use it as an ECM platform. To get back to my race car analogy; it’d be like trying to compete in the Dakar with a Formula One car.
But really, how bad could it be? Well, prior to implementing the product, everyone in the company knew where to find stuff, even though it was a pain. While they weren’t thrilled about using file shares, FTP, and email to store and share content, they knew how to work with the tools they had, regardless of how prehistoric they were. Now that they have the new platform, most people in the company are more than a little fed up:
- They file stuff and can’t find it again;
- They’re supposed to send links to colleagues, but have to rely on email because security is borked;
- Where previously there were standards, now many have their own way of doing things;
- Irritation with previous tools has been replaced, in many cases, with hostility;
- This list is not complete.
It’s gotten so bad that my client is seriously considering ripping out the solution they implemented and going back to using file shares. I wish I were kidding.
As my university client found out, choosing the right technology is no guarantee of success. However, as my Vermont client found out, choosing the wrong technology is a guarantee of failure. Choose wisely and do all those other things that come before selecting and implementing technology. After all, a solution / system is a combination of people, processes, and technology.
As some of you may already know, I will be speaking about the Principles of Holistic Information Governance at the AIIM Conference in Orlando (my session is at 2pm on April 3). Here’s a brief preview of what I’ll be talking about.
This is a little story about how the Principles of Holistic Information Governance (the PHIGs) were leveraged to turn a pure Records Management project into something the entire organization, and its stakeholders, could benefit from.
I was approached by a partner to help them out on a project they are working on for a public transportation company. Their project is to put together a new web communication and presence strategy, and to implement it. Where they asked me to help out is on developing a Records Management strategy. The two projects were to be separate from each other since the RM project was really to fill in some gaps in the client being compliant with legislation and in helping them to respond to Freedom of Information (FOI) requests. There was no thought given to integrating the two projects or to looking at how an holistic approach could benefit the entire organization and its stakeholders.
As all good analysts and consultants do, I started gathering as much information about the organization and the projects as I could. The two critical documents that I had access to were the Web Communication project strategy (summary and detailed) and the organization’s 20 year strategic plan and roadmap.
There were obvious tie-ins to linking the RM project and the Web project, but selling them to the organization wasn’t easy as they just didn’t care all that much. They were happy to go forward with identifying what was a record, and subject to FOI, then just firing that content into their RM tool (which they don’t have yet). The real clincher to getting the organization to accept a PHIGged approach was the long term strategic plan. In the plan were articulated six values and five major objectives.
- Customer Service
All six of the values can be directly supported by information, provided it’s properly governed and managed, from cradle to grave.
- Develop Financial Sustainability
- Support and Shape Livable Communities
- Change the Perception of Transit
- Deliver Operational Excellence
- Strengthen our People and Partnerships
Like the values, the objectives will benefit from taking an holistic view of how information lives in the organization.
One of the other things that I did was to review the RM strategy document I was provided and link those objectives to the objectives in the Web Communication strategy and the long term strategy. It’s both funny and sad that folks get so focused on their own view of the world that they don’t see the bigger picture. The RM strategy probably had 85% of what was needed for an organization wide (I’m trying not to use the word “enterprise” too much) information management strategy.
From a technology point of view there will be many different tools used to provide the solutions that the organization will, over time, implement. But, they’ll be underpinned by the PHIGs. The PHIGs are there to help organizations take a look at how and why information exists and affects all relevant stakeholders. The PHIGs aren’t about technology; they’re about business and doing it better by understanding what you need from information.
By reordering and rewording some of the RM strategy objectives, and adding a couple of new ones, we were able to change the focus from an RM project that would provide very limited benefits, to an organization-wide information management program that will benefit all stakeholders. Of course it’ll take longer to get to the end, but at least the client has taken the first step and realized the importance of information to the proper running of the business.
Below is the presentation from my session at the AIIM 2014 conference …
This previous post was about the need for holism in information governance. This post brings up topics that you’ll have to deal with in defining holistic information governance. (I think I’ll refer to these as PHIGs – Principles of Holistic Information Governance). This isn’t going to be exhaustive or ultra-detailed; it’s just a list to guide where you need to pay attention.
Gartner defines information governance as the specification of decision rights and an accountability framework to ensure appropriate behavior in the valuation, creation, storage, use, archiving and deletion of information. It includes the processes, roles and policies, standards and metrics that ensure the effective and efficient use of information in enabling an organization to achieve its goals.
Principles of Holistic Information Governance
1 – Information is an organizational asset.
In the course of our employ we produce and receive information. It doesn’t belong to us, it belongs to our employers. As such, we need to treat it like any other corporate asset. Even if you use a personal device to produce the information, it still belongs to the organization.
Assets have acquisition costs, maintenance costs, residual value (sometimes), and get disposed of at the end of their useful lives. Tell me how this doesn’t apply to information.
If you do not understand this, stop reading and go away. There is no hope for you.
2 – Understand what you’re using information for.
How does information help you achieve strategic objectives? A government entity and a direct-to-consumer sales organization may use some of the same information, but they will use it differently and for different purposes.
Understanding what you’re using information for ought to help you understand what information you actually need.
3 – Understand where it’s coming from and where it’s going to.
Information doesn’t just magically appear; it comes from somewhere. You need to identify your internal and external information sources.
Most organizations don’t just fire information out willy-nilly. Information is intended for specific audiences, for specific purposes. You need to understand what effect your information is intended to have, and who you want/need it to effect.
4 – Understand when you need it.
The next person that says “I need this yesterday.” wins a smack in the head with a frozen mullet (the fish, not the hairstyle).
Information is needed at various points in business and decision making processes. Is real-time information really necessary or can you wait a few minutes or hours for it? Figure out when you actually need the information in order to make a decision.
5 – Understand who can and should be using it, and for what.
This is not just about security, though that’s a big piece. This is also about getting the information out to those that need it or to those that you want to influence with it. Think about it in terms of getting your message out to your target audiences.
Once the information has found its way to the audience, what are they going to do with it? Are they going to make a decision, buy something, receive a benefit…?
6 – Understand your social, regulatory, and compliance obligations.
Depending on what you do and for whom you do it, you have information related obligations. Some of these are imposed by statute, some by convention, and some are self-imposed. These obligations determine how long you must keep information, what you can do with it at the end of its life, and to whom you may or must disclose it when asked.
7 – Understand your information related risks (too much, not enough, disclosure, etc.).
If some of your information leaks, what’re the consequences and can you live with them?
If you’re overwhelmed by information how does it impact performance?
If you’re missing information can you still get stuff done?
How likely are you to be sued?
8 – Understand how stakeholders are interacting with it.
It’s not enough to know what your stakeholders are doing with information. You need to figure out how they’re doing it. It’s not enough to identify the types and locations of devices that stakeholders are using; you also need to find out if the interactions are passive or active.
9 – With few exceptions, information has a finite useful life.
Unless your information has historical/archival/archaeological value, get rid of it as soon as you can. It’s not just about the whole discovery/litigation thing; it’s also about de-cluttering and being info-efficient.
Information is a perishable good; once it’s stale or rotted, get rid of it.
10 – Make someone accountable.
Overall organizational performance, financial performance, legal, technology … they all have single-role accountability and responsibility. As, arguably, the second most important asset of an organization, information deserves at least the same level of attention as finance, IT, HR, legal, etc.
A C-level executive needs to be accountable for how information is governed and managed across the organization.
None of these ten “principles” is much good on its own; they only work as a whole. Other than the first and last, the key is to go only as deep as you need to in order to make things work for your organization. Nobody is expecting perfection; things just need to be good enough.
I’m not trying to downplay the difficulty in formulating information governance policies and procedures. However, much complexity can be avoided if common sense is applied and business objectives remain the primary focus.
PHIGs downloadable PDF
PHIGs – the new and improved slide deck …
If it doesn’t work manually, automating won’t do diddly for you; policy comes before procedure.
Somebody asked if auto-classification and retention / disposition processing had been tested in court. I’ve not been directly involved with any cases, but yeah, these things have been tested. Sometimes they passed the test, other times not. So what? The issue was not with the technology.
The thing is, if the tools you’re using are automating or supporting policies and procedures that won’t stand up in court, the tools aren’t going to help you. The purpose of tools is to implement sound policies, not to define them. They’re tools, for pity’s sake; they’re dumb. If your policy’s flawed the only thing that automation will do is allow you to make more mistakes in less time.
Back in November of 2012 I attended a Contoural event in Chicago to take part on a technology panel. As I was listening to some of my fellow panellists, something struck me (no, not a projectile from the audience) …
Silo’s and point solutions (as concepts) were mentioned a few times. Now, the focus of the panel discussion was about how to get rid of evidence in case there was any inkling your organization would end up in court as defendant. Yes, we were advocating defensible disposition and not the Ollie North method of litigation preparation. We were five techno-numpties at the front of the room, talking about how to prepare for legal action. This, my friends, is a silo’d approach. Yes, I understand that you can’t go back and start from scratch, but you can set things up for the future so that you don’t need to scramble.
The key is to define holistic Information Governance (IG) policies. By holistic I mean policies that not only cover your keester in court, but also ensure that your information is useable on a day-to-day basis. Anyone who thinks that IG is only about risk is wrong. W-R-O-N-G, wrong.
Pop quiz: What’s more risky to your organization? Not disposing of content when you can, or not having the right information to make sound business decisions?
Governance done right not only keeps you out of jail, it also helps you run your business. An holistic Information Governance model has to cover what corporate users can do with corporate IT assets (acceptable use), who can access information, how information is organized, how and when information is disposed of, whether or not user provisioned devices are allowed, etc. IG does not only cover content that’s stored in ECM-type repositories; IG covers any and all content under an organization’s custodianship (including stuff you’ve sent off to 3rd party storage providers), regardless of location or format. Yes, IG covers your ERP, CRM, LOB, and other systems. If you’re responsible for it, your IG model better address it.
Don’t get all freaked out and start thinking that IG is there to control the business and run the entire show. It’s not. IG is there to make sure the business has the best information possible to conduct core business activities. That’s it. IG supports the business, IG doesn’t run the business. IG doesn’t even dictate what technologies to deploy. It does, however, define what many of the functional and non-functional requirements are for managing an organization’s information.
Because I know some of you are gonna harp on the legal aspect …
Done right, Information Governance will help you prepare for litigation. Being in a position to defensibly dispose of content is a benefit of IG. But, defensible disposition should not be achieved at the expense of being able to conduct business and making good decisions. IG helps by balancing the need for risk mitigation against the information requirements of the core business. E.g.: It may be completely (legally speaking) permissible to turf those invoices, but is there information contained in the invoices that ought to be extracted and stored in a data warehouse for future use? If you approach IG in a fragmented fashion you’ll never know. Or you’ll know and never sort it out because all your stakeholder groups will be arguing about it forever until legal finally wins but compromises your ability to successfully run your business.
True Enterprise Information Governance (EIG) takes an holistic approach to identifying what an organization’s information needs, risks, and responsibilities are. Risk mitigation is balanced against business need and the likelihood that a risk becomes an issue. Information is organized so that those who need it can get it when they need it, but the information is also secure. Information that is outdated and no longer relevant is disposed of, defensibly. Information is an asset; Information Governance ensures that the asset is managed appropriately.
And lest ye think that Information Governance applies only to large corporations and governments … you’ve got another thing coming. The only organizations that don’t need IG are those that don’t use or produce information.
For a little more about my thoughts on IG, read this post from Sept. 2012; it’ll give you a bit more insight into where my head’s at.
Though I find Gordon Elliott thoroughly irritating, I like the idea behind his show, Doorknock Dinners. The basic premise is taking what you already have and creating something that’s better than the sum of its parts. To a very great degree the same can be done when deploying information management solutions.
Far too many organizations don’t understand what they have in their cupboards. So off they go and procure some massively expensive ECM tools and then try and build out an Enterprise grade solution and fall flat on their faces. This is exacerbated, in many cases, by not having an understanding of what the end result is even supposed to look like and by not knowing what internal capabilities (skills & tools) they already possess.
I was having lunch yesterday with some guys that are in the early stages of a project to implement physical records management. They identified some issues related to manually loading records metadata into the tool they had recently acquired. The issues include:
- Users don’t like the UI of the new tool;
- Remote users sometimes get disconnected and don’t know which was the last successful transaction;
- Some remote users work on a different cycle.
The initial thinking on the part of management was to spend time and effort to build an application solely to allow users to input the metadata (in real-time) and be assured that what they entered actually got in. My lunch companions didn’t give me hard numbers, but my guess is that the estimates came out to around 4-6 weeks of full-time effort for a consultant to build this tool. In addition to building the custom tool, effort would be required every time there was a patch or upgrade to the tool they had recently purchased.
My question to them was simply “How are you capturing metadata today?” As it turns out they already have a db tool that they use to capture the metadata. The tool works and is accepted by the users. They have the skills in-house to modify and maintain the tool. The new RM tool has batch loading capabilities. Their current tool can output metadata batches which can be loaded into the new tool. The incremental effort to modify their current tool and test the batch loading would be less than one week with no external consulting required. Any updates/patches/upgrades to the tool they recently purchased would have zero impact.
My point is that it’s all well and good to go out and buy new tools and engage consultants. Before you do so, however, understand what your current capabilities are.