The Natural Irrationality of Implementing CMS

Editor's Notes

• #2: This presentation started with a book.
• #6: The book is “Smarter, Better, Faster,” but Charles Duhigg. He also write “The Power of Habit” a few years ago. The second chapter of the book is basically about hunches. How come we sometimes just know that something is off? Where does intuition come from? And can it be taught?
• #7: In this chapter, Duhigg talks about the idea of mental models. We constantly constructing scripts or descriptions or models of situations in our heads. For anything that happens in our lives, without knowing it, we have some archetype in our heads of that thing. The situation could be anything – it could be a conversation, cleaning the house, driving through an intersection. In our heads, we have some kind of representation of that thing.
• #8: The important point is that we construct models in our heads of how things are supposed to be. For different situations, we have an idealized concept of it in our head.
• #9: We’re constantly comparing what we perceive to this model. We constantly ask ourselves, “How does my present reality compare to this model?” Does it overlay perfectly? If not, what are the deviations of my reality to the model?
• #10: We learn to small bad situations. If something is off, we often don’t know why, we just know that something is wrong.
• #11: Back to content management implementations, how do we develop this intuition in regards to client relationships and projects? We’ve all had projects where we thought things we a little off, but we pressed forward. Then, a year later, we look back and think, “Why didn’t I see those signs?” This is actually known as “The Historian’s Fallacy,” which is best summed up as “Hindsight is 20/20.” Everything makes sense in hindsight, because we have the perspective of the events which have happened since then. What happened in the past has been embeliished with everything that happened in-between. At the time, those events hadn’t happened yet, so our perspective in that moment simply can’t be compared to our perspective now.
• #13: We’re going to talk about client baggage – some of the fallacies that clients bring with them – and we’re going to talk about mitigation strategies for this baggage. When we talk about mitigation, we’re going to talk about it in a tactical sense – what are specific things we can do – and a strategic sense – what are the larger themes this is speaking to?
• #14: It would be nice to think that no one brought baggage to a project. It’s nice to live in a world where everyone is perfectly clear-headed and rational, but that’s often not the case. Everyone – client’s and integrators alike – bring baggage. [[ Discuss history of the sculpture ]]
• #16: First off: The Phantom Menace Clients tend to have tunnel vision
• #17: Clients have tunnel vision. Their vision is directed down a tunnel toward a goal, and that’s all they can see.
• #19: People don’t write case studies about things that didn’t happen. This is a manifestation of both Survivor Bias and Action Bias. Survivor Bias says that we are influenced by the status of the survivors. If I surveyed the survivors of a shipwreck, I might conclude that the average passenger on the ship was a good swimmer and therefore be confused why so many people died. That would be inaccurate, because perhaps all the bad swimmers died in the shipwreck. I’m influenced by the state of the survivors, because those are only people I have access to. The same is true of case studies. In situations where a project failed, there might not be anything to write a case study about. Port-mortems are sadly rare. History is written by the victors. To write a case study or a blog post or a white paper, you have to have something interesting to say. No one reads about people who are struggling just to maintain fresh content on their websites with an average CMS.
• #21: [Read] There’s a joke that every CMS is “the worst CMS ever.” New clients often apologize for the state of their CMS. “I’m sorry for what you’re about to see. We clearly have the worst CMS ever.” Then we see it, and, often, it’s not that bad. And they seem almost shocked when you tell them this. No matter how bad your CMS is, we’ve probably see worse. And clients have this nirvana in their heads of where they should be, when they don’t realize that they have to undertake a journey to get there. They look ahead to the goal and want to jump right there, but there’s usually a whole sequence of steps they need to take before they get there, if they ever do. Personalization is huge right now – this industry is pushing personalization so hard. But 90% of clients have trouble just managing content for a single channel. If you’re having trouble managing content for the default, anonymous audience, you have zero chance of personalizing content for other audiences.
• #24: [Read] This is obvious, we all know. Metrics are sadly lacking in this business. Many organizations can’t even tell you what constitutes a conversion or desirable outcome.
• #25: [Read] We talked earlier about mental models, and this is true on the client side as well. Clients have mental models in their heads of what a successful project outcome looks like, but they can’t really articulate this. Often, this plays into The Phantom Menace – they have some idea in their heads of what everyone else is doing, and they want to try and get to that point themselves. But they don’t know what everyone else is doing, so they want you to get them to a place which they’re not even sure exists. They just know they want to be there.
• #27: This is a quote from a Supreme Court ruling in the 60s. It was an obscenity trial about hardcore pornography, and Justice Potter Stewart wrote this. The famous sentence is there in bold. He was saying that he couldn’t define what hardcore porn was, but he would know it when he saw it. This is a perfect example of the mental model idea we’ve been talking about. We have a mental model of what a good project looks like, and we compare reality to it. Our clients have a mental model of what they think they should be doing, and they will compare the project outcome to that.
• #28: In the end, for many projects, this is what evaluation boils down to. [Read] The client will look at the end result, and they’ll subconsciously evaluate how it makes them feel. Does it make me feel like I’m a professional? Does it make me feel like my organization is of a higher caliber than when we started? Does working with the CMS make me feel sophisticated? Does it make me feel like I have advanced tools to deal with advanced problems? Will my peers think more of me or my organization because of what we’ve done here? How does the result make me appear to those who evaluate me? Do I feel more professionally secure because of what has happened here? These are the questions and evaluation criteria that no one talks about.
• #29: This should probably be how clients frame it. [Read] When I can look at the outcome, overlay that against my model of where I thought we should be, and feel good about that – that’s how I’ll evaluate this project.
• #31: We’ve established that a lot of clients start out with (1) an inaccurate picture of where they need to be, and (2) no metrics or concrete idea of the final state they need to get to. Because of this, they haven’t constructed a series of steps to get there. Part of this is clearly our job to advice our clients down this road, but clients will often solve their own problems and fixate on inconsequential things.
• #32: [Read] Clients will fixate on things they either think (1) are valid markers for a successful project – obvious features of their mental model – or, (2) things they think can be solved effectively and conclusively – things which can be done and checked off to give some sense of accomplishment.
• #34: Workflow: this might be the most over-purchased thing in all of CMS. Very few situations require comprehensive, airtight workflow. I maintain that the best workflow model in the world is somebody saying, “Hey, come take a look at this and tell me if I sounds right…” Exhaustive management: we spend a lot of time managing assets that provide no reasonable return on management. If you can’t manage the copyright notice at the bottom of the site, the world isn’t going to end. If that requires a template change, no one is going to die. We tend to think that absolute, comprehensive management of every byte of output is a badge of honor, might it might actually just be a sign of wasted effort. Dashboards: we love dashboards. We love the illusion of control that they give us. We love the idea of surveyed vast expanses of data, because we tell ourselves that we could just make such better decisions if we only had access to better data. Dashboards are like crack in this respect. Multi-site management. I am not saying that multi-site management is universally bad, but it can be complicated when the sites different greatly, because code and design and assets can’t be very site-specific. And sometimes we put huge amounts of effort into running another site out of the same CMS instance when it would have been so much easier to just standup another instance. But we don’t want to do that, because that makes us feel bad, so we doggedly pursue the idea that everything can be run from one place and we pour money after this goal to no actual benefit.
• #35: This is the question we don’t ask a lot. [Read] If I’m running the New York Times, then perhaps workflow is exactly what I need. If I put up a different affinity microsite every day, then perhaps multi-site management would be hugely beneficial to us. But can we describe this? Can we answer this question and defend our answer? Do we have any metrics on this answer or decision?
• #36: I wrote this blog post for O’Reilly a couple months ago. In it, I echo a lot of the thing I’m talking about here. I have a phrase in this article: ROM; “Return on Management.” What return does integrated something with our CMS provide? If we considered “management” as a generic term do describe integrating anything with our CMS – be it workflow, site management, dashboards – what return do we get out of that effort. Anything?
• #39: In Greek tragedy, the characters would usually get themselves into an awful mess by the end of the play. Sometimes, the playwright struggle to find a way for everyone to get out of it. In some cases, the playwright would make a God appear – either by lowering them from a crane, or raising them up through the stage trapdoor. The God would show up and – BOOM! – everything would be resolved. This became known as “deus ex machina,” which literally translates to “God from the machine.” God sprang forth from some contraption, and everything got better.
• #40: [Read] This is what our clients want, and – to be fair to them – this is what the industry has promised them. At no time does a vendor say, “Our software is okay. It will make things slightly better for you.” That is not a tag line that will sell software.
• #41: Here’s the truth: #1: [Read] Rarely do I see situations where the technical CMS platform is the main problem. It certainly contributes, but often the problem came from outside the CMS. The CMS might have exacerbated it, but it didn’t start it. So, by definition, it cannot solve it. #2: [Read] People don’t like to look to things that already exist as sources of a problem. Before implementing a new CMS, our client likely already has people and processes. Those things are usually held as sacrosanct. #3: And here’s why: [Read] We already have people and process, and most clients can make changes there without significant expense. So those are problems that can usually be fixed without a CMS implementation. So…why weren’t they? If those were the problems all along, why didn’t we just fix them without doing a huge implementation? #4: With new software, you go from nothing to something. You go from 0 to 1. You can effectively say, “we have something now that we didn’t have before, and that makes all the difference.” You can say that your problems couldn’t have been fixed in the past because you didn’t have the means to fix them, but after the implementation you fill have those means, so let’s do this.
• #42: What we have are clients who believe that software will save them, and – again – this is our own fault. We have oversold clients for years on how instantly perfect everything our software and implementations are going to make everything.
• #44: If there is one thing I could change about this industry and practice, this is it. [Read] This is so destructive. It causes clients to have unrealistic expectations, and it CMS vendors to do dumb things. This is the manifestation of deus ex machina – God from the machine – if God was listening and stressed out about resolving everything. We have such high expectations for software, that we expect it to do everything. When it doesn’t, we think that it has failed us in some way. Vendors listen to this, and they get locked in an arms race to (1) include everything possible in their platforms, and (2) increase the expectations of clients that their platforms do everything.
• #46: [Read] The biggest example of where CMS vendors have over-reached is into marketing functionality. I’ve seen several CMS vendors lose their way by concentrating so hard on marketing functionality that they let management functionality wither. I believe – hope, really – that this industry is going to retract a bit. What I would like to see is management vendors handling management and marketing vendors handling marketing, and them concentrating on working togethjer.
• #47: Analytics is a great example. In the last 10 years, vendors have tried so hard to build analytics packages into their systems. I have never seen one of these sitations that couldn’t not have been done better in Google Analytics. Not one.
• #52: It would be lovely if we could always count on the client to provide a set of metrics that we could use for project evaluation. Unless they come to you with this, it’s not likely to happen because they often don’t even know what their success metrics are. You can try to work with them to define metrics, but they’ll likely be in the “I’ll know it when I see it” frame of mind, so even if you get metrics from them and hit those metrics, there’s no guarantee that they’ll think the project is a success.
• #53: What we need to try and do if find their success model, not their success metrics. Try to help them define what a successful project looks like for them. When it’s over, how have things changed? This is a phrase I like to use. [Read] I’ve found, from experience, that the answer to this question can sometimes spin a project in a completely different direction.
• #55: What do we think of when building a house? What’s the mental image that we get?
• #56: I did a sidebar in my book about all the non-construction things we have to do if we’re going to build a house and move into it. It was the biggest sidebar in the book – it stretched across three pages. Here’s a quick except. These are all things we have to do and manage to move from one house to another, and none of this includes the part about building the new house.
• #57: [Read] And, how far backwards and forwards does your plan stretch from development? How far in advance of development do we start doing non-development tasks, and how part site launch do we go?