It’s time for another installment of the Nine Keys to SharePoint Success. It’s been nearly nine months since I wrote the original blog post that defined the nine key things that your SharePoint implementation should have to be successful. This is key number five and the first in the area of cultural change for the organization. And this post has been by far the hardest for me to write. We’ve moving into areas which are a bit more sensitive to the organization – in part because they echo how we exist as humans.
The psychological behaviorists argued that introspection should be abandoned as a psychological technique, instead focusing on things which were objective and measurable. While I support the idea that we cannot rely solely on introspection to help us understand ourselves, I also believe that we should use introspection to help us understand more about ourselves. Alcoholics Anonymous kicked off a 12 step program movement which has resonated throughout the globe as a model for treating all kinds of addictive behaviors. Step four is “Made a searching and fearless moral inventory of ourselves.” This is clearly introspection – as objectively as our egos will allow. The irony of the fact that behaviorists wouldn’t like introspection is that the 12 step technique is successful because it changes behavior in part due to a heavy dose of introspection. Here as in a 12 step program our goal is to change behavior – that is we want to ensure that we’re doing the behaviors that lead to better SharePoint outcomes.
Those who have been in and around 12 step programs will tell you that step 4, the introspection is one of the most difficult steps in the program. Our ego actively protects us from admitting our faults. (As Daniel Gilbert said in Stumbling on Happiness, it’s our psychological immune system) Every person has faults. I have faults and limitations. You have weaknesses and opportunities for growth. Your best friend struggles with something. Your mother sometimes fails. Your father doesn’t always succeed. Despite this we all fall into the trap of trying to hide our faults. We feel like we need to portray an image of perfection to the outside world. Those with a Christian church background may have heard Romans 3:23 “for all have sinned and fall short of the glory of God.” You may notice that the word is “all” not “some.” We all have our limitations. None of us are perfect. It’s just as true that we want to hide these faults.
If you’re still with me you may be asking how our personal hang-ups impact the organization. Well, we reflect (or project) our personal beliefs into the organization. Jonathan Haidt in The Happiness Hypothesis wrote about our propensity to personalize input. Instead of accepting it as a statement, we internalize it as a character flaw. The key here is that a character flaw is much harder to solve than a simple weakness. I say simple weakness because weaknesses can be simple to resolve. I do not have perfect vision, neither does three quarters of the population. We don’t think about ourselves as being fundamentally and irretrievably flawed because we can’t see perfectly. Neither does someone walking down the street say “Look at that poor person, they have to wear glasses.” If you’re one of the few people who don’t need vision correction, I’m sure you’ve got another equally solvable limitation.
When we talk about how there are gaps in the organization – whether they’re simply structural observations about missing skills or whether they’re an inventory of projects that have gone wrong, we have a strong tendency to make those problems about us. We believe that we failed in creating a corporate structure without gaps – as if that were possible. We believe that we should have somehow known exactly how and when each project failed and should have presented it. On the one hand we will violently defend our weakness and in other hand internally we’re all too happy to heap on the blame.
The sinister part of our resistance to acknowledge and accept our limitations is that this is the core of how we hold ourselves back in life. If your struggle is anger management you may find that you spend a great deal of time and money on drywall repair. If you’re bad at balancing a checkbook or paying your bills, you’ll spend more money on overdraft and late fees. An anger management class would be cheaper than constantly repairing drywall. Some assistance with a system for balancing a checkbook and paying bills on time would save much more than you spend.
At an organizational level we’re positively lousy at the same sorts of introspection that we struggle with personally. To admit that we have a flaw or a gap in the organization means that we’re somehow personally flawed as well. We personalize that a defect means that someone isn’t doing their job – even if no one has the job to do.
Consider the situation where an organization is attempting to implement an Enterprise Content Management (ECM) system. They’ve never had an ECM system and they don’t have anyone in the organization that knows how to create the structure for the metadata for the files. There is no experience with creating an information architecture and not surprisingly when the solution is implemented the poor information architecture results in lower adoption. Who is to “blame” in this situation? No one has the skill – it may be that no one even realized the skill was necessary. In a typical post mortem (use post action review if that’s more comfortable to you) of the project it’s identified that information architecture was the problem – however, someone will likely get tagged as being responsible for creating it better.
This intent on identifying a person to blame for a weakness leads the person who’s in the hot seat to seek to create excuses. What else can they do? Everyone is looking for a scape goat and they really don’t want to be it. Like children crying out “Not it” immediately after someone proposes an unpleasant role; we try to keep from being the center of the problem.
Blame and Fault Finding
There’s a radical difference between getting to the root of a problem – to figure out what happened or what went wrong – and trying to figure out who was wrong and who is at fault. Honest evaluation is about finding the root of the problems and an awareness of what the organization is good at – and is not good at.
There are numerous reasons leading back to human nature and psychology that lead us immediately to deflecting blame from ourselves and on to other people. The simple truth is that if a system fails then we’re at fault (we’re to blame) for the failure – a failure to realize that the system would fail. However, if the problem is another person we realize that we’re not responsible – because we’re not responsible for other people. Despite what we say with our lofty efforts to find problems with systems we often revert to trying to find problems with people.
Consider for a moment the 5 Whys technique which is used for root cause analysis. How could using a time-honored approach and asking five simple – one word – questions lead to problems? The answer lies in the perceived tone of the question. Questions based on ‘Why’ are often accusatory – there by leading to a defensive response containing deflection, excuses, and often confusion. Even when a why question is asked with the heart of curiosity, it can be heard in an accusatory tone. This is particularly evident when the person has experienced accusatory people in similar roles or has had a significant personal relationship with an accusatory bias. (E.g. parent or spouse) Business Analysts – who are responsible for eliciting requirements and matching solutions are often encouraged to never ask ‘Why’ questions.
As I mentioned in my review of Diffusion of Innovation, there’s a tendency even in viewing innovations as wanting to blame the people instead of the technology – as was the case in the design of car safety. By explaining a way the problem on “idiots behind the wheel” we failed to look at how we could design systems to improve the chances for success.
Ultimately, blaming or finding fault finding in a person doesn’t help because every human is imperfect. Even if you remove that person from the system the next human will make mistakes too – and maybe different and more difficult to detect mistakes to discover. There’s an assumption that humans will be perfect instead of assuming that people are necessarily flawed and the systems we put around them should expect this and accommodate this expectation.
It isn’t that a particular person does – or does not – have flaws. Rather we all have flaws, the better question, the one that leads to a better evaluation, is what components are the system are insufficient to ensure success of a project. If you recognize a gap in requirements gathering, project management, information architecture, development, or infrastructure – why not supplement your team with the additional skills you need – upfront instead of suffering through a failing implementation. (The old saying that a stitch in time saves nine is appropriate here.)
Ownership and Acceptance
There are two key skills that will diffuse the blame and fault finding. They will help evaporate the personalization. The first is simply owning a problem. This sounds counter intuitive – and it is – however, it’s amazingly effective at stopping a “witch hunt.” When you own the problem. When you admit that somewhere in your area of responsibility there is in fact a problem and you’re aware of it, you stop others from trying to prove to you that you do have a problem.
It may sound like I’m saying that you should personalize the problem and own it. That is partially correct. I’m suggesting that you own it. You admit that it was something you could have done better. However, personalization is about making it about who you are – I’m not suggesting that. I’m suggesting that you can be imperfect and make a mistake without it being a character flaw. If I am late for a meeting it doesn’t mean that I can’t tell time.
The other skill is the one you need to be able to own the problems. That is acceptance. Accepting that you can make a mistake – and that all people make mistakes is incredibly freeing. When you accept this fundamental truth, you are more willing to own your part in causing bad outcomes – and you’re more willing to accept it from others.
Working at Getting Help
In an economy we have to make decisions about what we will and won’t do. We don’t get to make our decisions in a vacuum. We have to make our decisions on where to invest our efforts based on the greatest benefit. However, sometimes we make our investments based on what we know to invest in – rather than those things which are hard to invest in.
If you’re used to investing in supplementing your infrastructure skills with outside resources, chances are that you’ll continue to do this. You already know who to talk to. You know the vendors, the rates, and the issues. Making an investment in an area that you’ve never considered before – like information architecture – is challenging because you don’t know who to call nor do you know what to expect. What does it take to create an information architecture? What exercises will you go through? How much time will it take?
Interestingly if you’re familiar with infrastructure and even if you’ve outsourced it for years, you will have built up an awareness of what needs to happen. You know about the planning and the testing and the day-of activities. Because you’ve been a part of successful projects – run by outside parties – you’ve become more able to successfully implement something that may have previously been difficult. However, nothing is as easy as letting someone else manage it – unless allowing someone to manage the infrastructure part of the problem means that you won’t be able to manage some other part of the project.
Honest evaluation is – in part – a revisiting of the evaluations that you’ve made in the past. There was a time when the most cost effective solution to putting together a flyer was to hire a printing company to create the flyer for you. They owned specialized and expensive desktop publishing software. Today with Microsoft Word and Microsoft Publisher, most of us wouldn’t think of asking a printer to create a simple flyer for you. Either you’ll ask a design firm for something important – or you’ll do it yourself if it’s simple. We used to send out to have color copies made now most of our copiers – now called multi-function devices – can print in color. In my office, I have a sophisticated DVD duplicator which will print directly on the surface of the DVD after it’s burned. There was a time – not so long ago – when you would pay a specialized company to burn 500 DVDs and you would warehouse those that you didn’t sell. Today we print up batches of 20 or 50 and sell out of our inventory until we make more. Also because of the DVD production, we have a professional paper cutter which is capable of cutting hundreds of sheets of paper simultaneously, so we don’t even have our DVD covers cut down.
Honest evaluation is knowing where the inflection point is between having had something outsourced and when it’s time to get the solution accomplished differently.
Most folks are familiar with after-incident reviews and post project reviews called post mortems. Those reviews, however, are after the event has happened. The review may be helpful for the next event (or project) but it does little for the existing one – and as was pointed out in Lost Knowledge the “lack of absorptive capacity” may make it difficult for the knowledge to be used on the next project. So a useful exercise is to do a pre-mortem exercise, as was recommended in Sources of Power. This exercise requires that the participants accept that the project has failed at a future time and they’re trying to determine why. The goal is to turn over stone that could have led to the failure of the project. The perspective that it MUST fail for the exercise and that the goal is to identify the most likely candidates for the failure often leads to exposing many things which may not otherwise have been thought of. (Psychologically speaking it’s difficult for humans to identify gaps in existing plans. By focusing on the idea that there was a failure forces you to look for them differently.)
Facts not Feelings
One of the other keys to getting to an honest evaluation is staying focused on the facts and not the feelings. It’s one thing to say that “I think we manage projects pretty well around here.” That’s a feeling. What does the data actually say? How many projects come in on-time and on-budget? If you’re like most organizations, not many projects come in on-time and on budget. However, knowing this and examining the reasons – which is frequently changing requirements or bad requirements – gives you a place to look when doing your pre-mortem. It might be easy to say that I’m speaking out of both sides of my mouth here – saying that post mortems aren’t valuable and then suggesting that you use the output of previous post mortems as feedback to the pre-mortem process. However, that’s not really what I’m saying.
What I’m saying is that you should absolutely do post-mortems – however, you should recognize that you may not be able to get the value out of them – unless you use them as feedback into a process of actively evaluating the next project.
Developers shouldn’t test their own code. Authors shouldn’t edit their own work. Why? Because the same cognitive processing that lead to the fault will lead to not seeing the fault when you do any sort of a review. The value of an outside perspective is that it gives you a different way to process your situation. In the book Thinking, Fast and Slow Kahneman spends a great deal of time talking about the two “systems” going on in our head and how even our own outside view can be valuable. That embedded experts often fall into group think and fail to process what they know the truth to be based on the context of the question. He also discusses at length the problem of WYSIATI – What You See Is All There Is. This bias is based on the assumption that you have no blind spots – which in truth all of us have.
Pulling in outside resources brings in new views and perspectives that change what the group sees. Whether it’s bringing in – or bringing together non-competitive peers – or bringing in an experienced consultant, the different perspectives will lead you to a different set of challenges – and different ways of evaluating whether your organization has the skills and talents necessary to be successful.
Putting it Together
Honest evaluation is by no means easy. It’s by no means automatic. However, without truly assessing your strengths and your weaknesses, how can you possibly expect that you’ll be successful at a SharePoint project which is so complex and difficult to get right?