Several weeks ago, Alan Pelz-Sharpe tweeted an observation that I have observed many times that is paradoxical in nature.
Many/Most CMS projects fail, but few/any CMS professionals have ever worked on a failed project 🙂
While this quote was likely referencing more Web Content Management (WCM) efforts than the broader world of Content Management, I have noticed this as well. In fact, this is something that seems to be true among all branches of Content Management.
Aside from people hiding their failures, I think there is an additional factor.
Failure begets Transition.
Before I dive into that, I will now confess to my least successful projects. I am only listing projects where I had a significant role and am aware of the final outcome for the project.
I am going to go in chronological order. I am hiding client names and I am sure that some of this is colored by my ego and the passing of time.
- In the interest of full disclosure, one of my first assignments when I was a hired-gun for PC DOCS didn’t go well at all. I was performing my first installation at a new client and it failed. There was an error code that I was unfamiliar with combined with a message that didn’t clear things up. We called support, but the client was unhappy that a “hired-gun” had to call support. Being inexperienced at dealing with clients, I probably didn’t manage things ideally. I was pulled-out after half-a-day. I assume that they installed it finally and they likely had a successful project.
- My company was brought in to help with a Documentum project for a government client. The prime contractor had agreed to an aggressive deadline before completing the acquisition of the software or possessing any domain expertise on which to base any estimates. We came in and hit the first phase date with a lot of hard work. It wasn’t well received as we never had direct access to the end-users who were not impressed. We proceeded to improve things and strive for the next set of promised functionality. Halfway through that we had to receive an extension. The prime requested to not extend me because I kept pushing for more access to users and proper requirements gathering to get things done correctly. I was also becoming friendly with the client which can be dangerous as a sub-contractor. My team stayed behind and eventually the system failed, costing the prime their larger contract. To be fair, I’m not sure I could have saved everything had I stayed on the project. This was the project that validated the importance of all the best practices I had heard of over the years.
- I was brought into an enterprise-wide Content Management and Records Management (RM) project based upon Documentum right at the beginning. Things were going well until politics and poor planning crept into the project. It was a Documentum project for a company with two cultural groups created during a merger several years previously. The client decided to let one side of the company run the technology and the other side run the business requirements. Did I mention that the two groups happened to be separated by an ocean? Meanwhile, the RM consultants spent a lot of money to create an unwieldy records plan that was apparently based upon the concept that the users love to classify their documents. (For the record, they don’t.) Shortly afterwards I got a new job in a move unrelated to the project. The company records manager then “moved-on”. Shortly thereafter, the client switched to SharePoint solution for its “ease-of-use” and deployment. The project seemed to become a success, but it was a much longer road than anyone believed. The company I was with did see it through to the end even with the architect leaving during the development phase.
There are likely some others, but those are the major ones. Still a pretty good record.
The Transition Factor
A large number of people on Content Management System (CMS) projects are participating on their first project. If it fails, it is usually their last project. The project leaves a bad taste in their mouth and they move on to non-CMS projects. They never become a “CMS professional”.
Frequently I hear about projects that failed because there were no CMS professionals to help steer the project. I, and many acquaintances, have been brought in to “fix” or “restart” initiatives that are failing or have failed in the past.
Implementing a CMS isn’t easy. Oh, installing it can be a snap, but using it correctly, assuming you selected the one that best meets your requirements, is a challenge. Even now that I am out of consulting, I still heartily recommend leveraging a few CMS professionals the first time out of the gate. This includes selection, not just implementation.
Once you’ve had that help to jump-start you and your teams capabilities, you’ll find that success becomes the rule. When you learn these simple rules, success actually becomes routine:
- Manage the project. This isn’t just the project team, it is the key stakeholders. It isn’t just the schedule, but everyone’s desire to see the project successfully hit those milestones. It isn’t just the deliverables, but everyone’s commitment to making sure that they are done correctly. One team, one goal.
- Pick the right CMS. If the solution is dictated by the Content Management System and not the other way around, success becomes challenging. Business requirements should drive the technology.
- Have experienced resources. The lead architect/designer needs to have experience with the project. Training only goes so far. If necessary, hire someone to fill that role for the first project. Experience project management is also a must. They don’t need to have direct experience with CMS projects if they are good and have resources that are experienced to lean against.
- Change management matters. People are resistant to change. You have to work make people open to working with the new system. If not, the CMS can be perfect and still fail. How to do this varies by organization, so chat with experts and others in your industry to determine how they achieved success.
Will all my future CMS projects succeed? Maybe. Part of that will be because now that I am out of consulting the number of projects that I have a hand in will be less. Of course, I could be consulting again in a few years. You never know.
Success is not Perfection
I want to add one more thing. I don’t think I ever had a “perfect” project. I’ve has some that went extremely well and survived multiple attempts to be replaced by newer solutions. There were always things that could have gone better.
People say that failure is important because it teaches you. I think that you can learn more from success. You learn what works as opposed to what doesn’t work. As no success is perfect, you still learn from the effort and improve from there.
That ability to learn is how you become a successful CMS professional.
10 thoughts on “The Content Management Expert Paradox”
Well said and great points; I especially like the call out for change management, which gets even more challenging when a CMS-adopting organization goes light on training.
I’ve heard “change leadership” as a friendlier term as well–change can be directed from peers and the top and become part of a company culture.
Software consulting is deceptively hard because it can span across code, servers, people, project management, and even include meetings with a client’s senior-to-executive management. I agree that it gets easier with experience–business led requirements, communication, and project management all matter.
Content management is deceptively simple because it’s “only a few fields and publishing,” right?
many who fail end up suffering from Ecmaphobia http://bigmenoncontent.com/2009/08/14/do-you-have-ecmaphobia/
still seeking a cure
I still find it odd (ok maybe nuts) that many people attempt the “drive by” requirements gathering on ECM initiatives and then wonder why the initiative is not successful!
There are a few crucial points that lead to a demise of a CMS project. I’ve seen plenty as I deployed ECM, BPM, and RM solutions over the last 7 years. It all boils down to two things, the first one is requirements the second one is looking at the final deliverable not as a system, but as a solution that solves a business problem. Deploying a solution is a lot more involved than just a system and I don’t see a lot of organizations tackling it from the right perspective.
I’ve started to give back some of my lessons learned through my blog to help postpone the receding hairline for as many folks as will read and apply what I write about.
An expert is “a person that has made every possible mistake within his or her field” — Niels Bohr
Part of my enthusiasm in consulting recommendations is something along the lines of “trust me, if you do that then you’ll have problems. It’s happened to me.”
I think you can be an expert without making all the mistakes. Maybe just witnessing most of them is enough? How about actually learning on those mistakes?
I agree with you thought, following guidance without questioning it first is a sure way to fail. It’s good when people review your project documents and ask hard questions, it helps create a better product in the end.
True, but a baseline of an appropriate number of scars is often helpful :-). Agreed that witnessing, or even talking directly with others who have gone through related experiences, is helpful.
If ever there was a time for the iceberg metaphor… CMS implementations be they ECM, WCM or any other, without a proper pilot to guide the process from inception to completion, are doomed to fail or fall to the bottom of the ocean.
In the WCM space you often hear web agencies that don’t consider other existing infrastructure or IT that think, it’s technology so it’s ours and ours alone.
It’s odd that companies will hire a CPA but fail to do the same when it comes to Content Management.
Comments are closed.