Yesterday (May 30, 2016) I read this article which contends that Box, Dropbox, and others are not content management platforms. I was considering not linking to the article and just putting up screen shots of the main points, but I decided on the link instead. The article is nothing but FUD (Fear, Uncertainty, Doubt) being spread by an on-premises content management provider (props for dropping Gartner, Forrester, and AIIM names though). As a bit of a refresher on where I stand, you might want to read this whitepaper I wrote last year (sponsored by Box, 12 pages long). By the way, I tried to post a comment to the article, but it seems the site’s not taking comments (mine had a couple links).
Without further ado I’ll get into the counter arguments to the author’s “five reasons why cloud file sharing platforms can’t touch document management software platforms from an enterprise functionality standpoint” …
- Security at all costs – If the author had written something about data residency I would have bought it, probably. However, the author goes on about a bunch of FUD, and does nothing to dispel it. The author also illustrates her lack of knowledge, not only of security issues, but also of the capabilities of the cloud players. She implies that many think that on-premises security is better, which we know isn’t the case. Major hacks and leaks have come primarily from on-premises data centres.
- Document storage and beyond – uhm, just plain wrong. Sure, it may take a combination of tools to achieve the same level of functionality that one could achieve with a traditional, legacy suite such as OpenText, Filenet, or Documentum, but is that really a bad thing? Haven’t we already accepted that the whole ECM world is actually changing and the way forward is platforms, integrations, and API’s? I have. Has someone forgotten the abysmal success rate of traditional ECM deployments?
- Not yet ready for primetime – What? This is 2016, technology is changing and advancing more rapidly than ever. No one has a 10+ year window any more to demonstrate anything. Those traditional ECM players you mention are precisely the reason people and organizations are going to the cloud. Traditional ECM platforms are old and out of date. Yes, some are making changes, re-architecting, and adding CLOUD -FREAKIN’-CAPABILITIES-DAMMIT!!!
- Migration issues – Really? You really want to go there? How ‘bout migrating from OpenText to SharePoint? Or from Documentum to Filenet? Or from what you’re selling to anything else? Or from file shares to whatever the hell you want to name? Migration sucks. Always has sucked. Always will suck. Cloud or on-premises makes no friggin’ difference.
- Performance concerns – hahahahahahahahahahahahahahahahaha!!! Ha. That’s cute.
- It’s ON-PREMISES for ***** sake!
Now I’m just angry and irritated. I need a drink.
I’m not saying that everyone should move everything to the cloud, but at the very least think a bit and don’t buy into the nonsense spouted by some people who may have something to gain by spreading FUD. The fact is that managing content in the cloud, whether via cloud capabilities of legacy vendors or via the “new” vendors, is perfectly viable. The key is to know what your requirements are before choosing a technology.
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.
I wanted to try something a little different for this post. I’m doing an assessment of what went wrong with Alfresco for a Canadian university. They purchased Alfresco back in 2008/09, initially to handle some of their web content needs. Things haven’t gone so well. Below is a quick wrap up email I sent to the project sponsor after the first few days of stakeholder (patient?) interviews …
I just wanted to give you a quick recap of the last few days:
- Of the people I spoke to, no one advocated for getting rid of Alfresco
- Unless something to the contrary comes up in the next few weeks, there is no reason to believe that Alfresco is the problem
- Alfresco was likely the wrong choice back in 2008/09, but the product and company have since matured to the point where it’s no longer the case
- There is a general feeling that Alfresco is/was underfunded, under-resourced, and lacking in executive buy-in / mandate
- It appears that there is no executive support or commitment to mandating Information Management practices using Alfresco as a standard tool set to implement
- There was/is an element of Alfresco (or any ECM platform) being a magic bullet, rather than a platform on which to build solutions
- It seems that all the Alfresco initiatives over the years have been done as individual projects, rather than under a program of managing information
- The consulting services engaged focused on the mechanical & “how to” aspects of Alfresco and related tools, without any of the advisory & “what should we do, why we should do it” services
At this point it’s my opinion that the problems are cultural and environmental. If the culture and environment change Alfresco will succeed, providing the right resources are engaged in the right way. If the culture and environment don’t change Alfresco will fail, as will any other platform brought in.
If I were to start an enterprise software company today, I’d give the licenses away. No, I am not thinking about open source at all. I’m thinking about services, non-core functionality, and integration. I’ll stick to Enterprise Content Management software, but the principles are applicable to any enterprise grade platforms or suites (we can debate what “enterprise” means until the cows come home to roost, but not here or now).
Let’s face it; you can go and pick almost any large ECM suite and the core functionality is going to be pretty much the same across all of them. For the sake of this discussion, let’s define core functionality as:
- Check in / check out
- Basic search
- Basic workflow
- Some sort of UI (usually pretty crappy)
There is no substantive value differentiator to be had in choosing one over another. In fact, if any one of those items were missing, I doubt the software in question would even qualify as an ECM tool. I also think that in the very near future, file synching and sharing (e.g.: EMC’s Syncplicity and OpenText’s Tempo Box) could become core functionality (if it were my company it would be).
So, I’m going to give you the basics for free and I’m not even going to charge you for training and maintenance. I will charge you for implementation (if it’s on premises or on hosted infrastructure) and support, though. Why would I be so generous? Because I am really friggin’ smart. I want your organization to deploy, use, scale, and extend my software. I want you to realize that what really sets my software apart from the competition is the people I’ve got advising you, architecting your solutions, and deploying to your people.
What enterprise is going to live with just core functionality beyond a proof of concept phase, if that long? Even if they do, how long until they figure out that they’ll get way further if they hook up content services (yes, I said services) to other enterprise or line of business systems.
Don’t get caught up in the whole “if it’s free there’s no value” thing; it’s bogus. You need to understand the difference between cost (what you pay) and value (what you get). Besides, I already told you it’s not free, sort of. You’re going to have to implement the software. I or a partner can do it for you, and you’ll get billed. You can have your internal folks do it, and you’ll get billed to get them trained. It comes down to paying for the knowledge and expertise, not for the tool.
The value proposition for core content services (or content as a service if you prefer) is in pushing the content to other systems (processes+people+tools), and in being the core repository for content across the organization. Once your content is in the repository and being managed with the basics, only then am I going to start charging you for the add-ons. Add-ons are not by any means trivial, but they are not core for all organizations. For example, Digital Asset Management (DAM) – not everyone needs it, but to those that do it’s critical. And I am going to charge you for it (license and services). Hey, you want to use someone else’s DAM solution because it’s more suitable for your organization? Cool, but I am going to charge you for the integration. Same goes for web content management, ediscovery, records management, migration tools, large file transfers, etc. Integration to desktop tools, other enterprise systems, line of business systems, and cloud services? Damn right I’m gonna charge you.
“But what happens when partners do the initial implementation? You won’t make any money.” Truthfully, I don’t care. What I do care about is being at least as diligent about selecting partners as you are about selecting technology and service providers; I want partners that are every bit as invested in your success as I am. I want you, me, and the partners to be a triumvirate. If I really want a shot at success, I have to make sure that you succeed, regardless if you engage me directly or not. The only way I am going to do that is to support my partners as much as I support you, and to be there when their skills have gaps.
“But they’re a partner, how can they have skills gaps?” Well, because they’re partners and not my staff. Partners are never going to be as close to the product as those who build the product; it’s a fact. Besides, they’re out in the field implementing stuff and gathering feedback. That’s what I want them to do. And if I’ve set my partner model up properly partners are integrated into my processes and supported. My partners are also a revenue stream.
I don’t want any schmoe that’s done one implementation and read some stuff to be running amok out there. I want partners that can do as good a job, maybe even better, than my own staff can. I am going to spend time and money making sure partners are up to the task, and for that partners are going to pay me. If you want to work with the schmoe, that’s on you. Don’t come crying to me when it all goes wrong. Do come to me to help you fix it. I promise not to say “I told you so”. As long as there’s long-term success, I’m not too concerned about short-term faux-pas.
I don’t own or run a software company, and I’m not about to start one up; I’m an analyst/consultant with Digital Clarity Group. We help organizations get stuff done, including selecting technology and service providers. I hope that I’ve made you think about a few key things as you ponder your technology and vendor choices:
- Cost does not determine value – lots of open source and low cost tools are every bit as good as stuff you’d pay a fortune for;
- Regardless of cost, knowledge is far more valuable than tools;
- Clients, service providers, and vendors must, must, must be in a symbiotic relationship to truly succeed.
And if you happen to be looking for some guidance on selecting technology or service providers, reach out; we’re happy to chat. You should also check out our European and North American service providers guides (note that they are specific to the Customer Experience market).