Several years ago – it seems almost like in another lifetime, I wrote two articles: "Seven Keys to SharePoint Success" and "Seven Signs your SharePoint Project is in Trouble". These were written for SharePoint Advisor magazine, later renamed to Advisor's Guide to SharePoint. The articles are no longer publically available but I've got the original articles which I recently reread. The articles were written in the spring of 2006 – before even SharePoint 2007 was released. They were a slight tilt on the risk matrix, I created for types of SharePoint projects and their risks. By that I mean that the problems that were exposed in the matrix were the same sort of things being tested for in the articles. So some six later, I wanted to revisit the keys to success and warning signs in a blog post but reframing them all as keys to success.

In an attempt to refine and reorganize the keys to success and the warnings, I've introduced some categorization into the items. Before they were simply a quazi random list of things, this time around I want to group them into areas since they do share some similar characteristics. I also combined a few things, eliminated a few that didn't really fit any more due to the way the product has changed, and try to get them into an order that flowed logically a bit better. The result are three categories: Activities missed, Culture change, and Simple things.

Activities Missed

Everyone is busy. Sometimes we simply forget to do the things we know we should do. We're all looking to take short cuts – to cut corners, however, sometimes corners are cut and they do more harm than good. John Kotter, a professor emeritus at Harvard Business School and author, cautioned that skipping earlier steps in his eight step change model would mean problems later on. (Check out my review on Kotter's book Leading Change.) The same problem exists if you skip (or skimp) on these activities in SharePoint. Let's take a look at four often overlooked activities.

Shared Vision

Sure. Everyone believes that they want generally the same thing. Everyone wants a way to share documents and track tasks. That is what led to SharePoint as a solution in the first place. However, is there a single shared vision of what SharePoint success looks like? In most cases the answer is no. The arguments abound. Like the story of the blind men and the elephant where each felt a different part of the elephant and had a different perception of the elephant. In most organizations if you try to nail down a single vision of how SharePoint will be used it will feel like herding cats. However, just because something is difficult doesn't mean that it's not the right thing to do. Ensuring a single vision at the start helps to reduce the thrashing that will happen later in the project.

So how do you do it? You plan it like you would plan any other web site. Start with the users (or personas), collect the use cases (what will they be doing), and then plan the visual design (use wireframes, mockups, and prototypes to ensure that you get to a visual design everyone can agree on.)

Business Connection

You may have a shared vision with everyone finally on the same page. However, there's an important question that's often missed, overlooked, or underexplored. That question is what will be business get out of the implementation? If an organization invests in a new piece of manufacturing equipment there's a specific tangible ROI for the equipment. Someone knows exactly how many parts have to run through that machine before it's going to start making money for the organization – and how many years it should be able to continue to churn out parts making greater profits for the organization.

SharePoint isn't exactly like a piece of machinery. It's not something with a single fixed purpose and the desire to run a high number of identical transactions through. Because it's not like a piece of machinery and it can be hard to quantify the value to the organization, many organizations simply give up and don't bother to try to generate an ROI – but this can be devastating to the project.

The long term measure of a successful project isn't in its completion on time or on budget. The long term measure is whether the project enabled the organization to be more successful, more profitable, or more agile. If you're going to make sure the business gets value from the project you're going to have to align with some need the business has – and that means building a connection to business value.

I'm not saying that you have to have a rigorous ROI calculation for your SharePoint project – it's unlikely that you could generate any ROI with confidence; however, what I am saying is that you should try to generate an ROI. The benefit is in the process not in the outcome. By trying to put together an ROI you'll deeply investigate areas of potential match between business needs and SharePoint capabilities. You'll identify specific areas that will have high return – if you can get SharePoint deployed and get users to use it. You can use these points as your metrics for evaluating whether the project was successful or not.

Planning Measurement

Recently, I decided to try to lose a little weight. What was the first thing I did? I bought a scale. Why? Well how could I determine if what I was doing was working or not? My weight loss journey isn't over – and it won't be for a long time – but the small successes are there because I have a specific measurement to indicate success (or failure) and I'm using it.

In most organizations there wasn't a step on the plan to identify the key metrics for project success – or the metrics that were developed were things like up-time or performance. While these are fine IT metrics for service delivery, they don't say much about how useful it is to the business.

Some organizations have a slightly more enlightened view and have metrics on page views or the number of visits to a site in a period of time like a month or so, but this still misses the importance of connecting the metric with the business outcome.

Truly enlightened businesses are finding metrics like reducing the time to respond to a request for proposal by 1 day within a month or improving customer satisfaction scores by 1 point over the next three months. Those metrics are specific, objectively measurable, and time constrained. Make time for developing the measurements in your project – and make sure they're tied to the business needs you're solving.

Evangelization

Most IT based project plans stop when SharePoint is installed – or at most 30 days after launch. This misses the important process of building support for the solution and for use of the platform. From one perspective the project ends with the working SharePoint site, from another perspective the project starts with a working SharePoint site. From there it's time to get people engaged with the platform and to get them to start to use it to drive business value.

IT departments aren't used to evangelizing solutions. You don't have to evangelize the use of email. There's never been a time when the IT department had to encourage people to fill in their timesheets so they could get paid – although the payroll department may have. It's a rather foreign thing to think about how you may need to try to encourage people to use a platform that has been deployed.

However, SharePoint is a different kind of solution. It's a powerful platform on which users and IT can deliver solutions. Think about it this way, the telephone is a great invention but it took years to develop call centers, interactive voice response systems, voice mail, and the other solutions that are built on top of dial-tone to make the humble phone more valuable. Users need to know how SharePoint can be used and how it will help them. If you want to get users engaged you're going to have to evangelize the benefits of the platform. Extend – or reopen – your SharePoint project plan to include the need for education and evangelism after the solution is available to users.

Culture Change

Corporate culture can change. It's absolutely possible to change the way the organization works. Like cleaning a petri dish and starting over – or introducing a new reagent – you can change your culture, however, that's hard. Here are some culture change components that you can actually do.

Honest Evaluation

One of the things that's difficult to do as an individual is to look inside of yourself. Thinking in psychology circles says that objective introspection isn't possible. Whether it's possible or not, it's not something we do well. The biases for evaluating ourselves are well documented. (Check out the Happiness Hypothesis if you want research references.) Looking at the organization that we are in may not be as difficult but it's certainly not the easiest thing. The problem is that if you don't do the introspection, if you don't look at what your organization is good at – and what it's bad at – one of the bad things is going to jump up and bite you on your SharePoint project.

Back in 2009 I wrote a pair of blog posts: four most common corporate delusions and the fifth and the sixth most common delusions. If you need to kick yourself in the pants and take a look at what your organization does well – and what reality is, go read them. If you're not up for facing reality that directly, perhaps you could look at the last five projects in your organization (or your IT organization) that were late or over budget. They may not have been a failure, but there's probably something you can learn about what you should watch out for in a SharePoint project.

Reframe Your Relationship to Your Business

Users are the source of all problems. Clients are the consultant's only problem. Or are they? The natural reaction to users as a group is that they're noisy. They don't read. They don't understand. They don't follow directions. While all of these may be true of some of your users it's probably not true of all of your users. Yet, we –as all humans do -- tend to generalize. We tend to build up a negative feeling to users in general because of a few "bad apples." In some organizations this has built up to the level where there's a hostile business-IT relationship where the business wants nothing more than to be able to use some other provider for IT services.

Perhaps your view of the business is not as insidious as the above but you're stuck taking orders from the business. You get detailed "requirements" from the business that are over specified leaving nothing to doubt nothing to innovation and nothing to take advantage of. They've buried design into the requirements without understanding. They don't know what's easy or hard – or ways to make the hard easy while accomplishing the same goal. A better framing of the relationship is of co-solution creators. This requires IT to spend more time understanding the needs of the business and to elicit creative problem solving. Candidly neither are easy.

The business may be frustrated, having felt like they've clearly articulated their needs – without understanding that they've articulated their solution not their needs. They probably don't really know exactly what's driving the requirements, they don't know who asked for what or when they were asked for. Walking through the "why" behind the requirements is important because it's a path where both the business and IT get in the boat and try to find solutions together.

Platitudes

If you read a corporate mission statement and at the end you're wondering what that meant – you're not alone. Many corporate, divisional, and project mission statements are filled with meaningless platitudes. Platitudes are flat, dull, or trite remarks, especially one uttered as if it were fresh or profound. (Thanks Dictionary.com) With the occasional rare exception, a mission statement is a collection of platitudes. The problem with a platitude is that on the surface it looks good. However, when you walk behind the buildings you realize they're just Hollywood sets. They're a face with nothing behind them.

If you've been in large corporations for any amount of time when asked to create a mission statement you'll automatically gravitate to a string of jargon and platitudes until people quit disagreeing with it. The problem is that the fact that no one disagrees with it is a good indicator it's a platitude. Some conflict about your mission statement is good. If no one could reasonably disagree with the mission statement – you've got more work to do. People can't reasonably argue with platitudes – but then again platitudes won't get everyone thinking the same way either. If you need some motivation to break out of the platitudes consider this quote from Alfred P. Sloan, the former CEO of General Motors: "Gentlemen, I take it we are all in complete agreement on the decision here… Then I propose we postpone further discussion of this matter until our next meeting to give ourselves time to develop disagreement and perhaps gain some understanding of what this decision is all about."

Simple Things

There are some really simple things that you can do which will help drive success in the project but they're often overlooked.

Right Defaults

The German-American psychologist Kurt Lewin said that behavior is a function of both the person and the environment. That is to say that you can't ignore the environment when you're trying to drive behavior change. Blink, Switch, Mindset, and The Happiness Hypothesis are all books that talk about how environment can impact a user. Despite the evidence and theory about how environments influence behavior, most organizations don't take the simple steps necessary to make it easier for users to do the behaviors they want.

For instance, if the goal is to get users to stop putting their documents on their local hard drives and instead they should put them in their my site, then simply changing the default file save location in Office can have profound impacts. Changing the available site templates from which users can create sites to the company customized versions can help to ensure consistency across the enterprise. Simple changes like hiding the templates that you don't want users to use can dramatically increase compliance with the policies of the organization.

The first questions to ask when asking the users to do something should be: "How can we make this default behavior?"

Imperfect Solutions

Perfection is expensive – and ultimately unattainable. Perfection of anything that we have is in context. Was your computer perfect when you bought it? Did you configure everything you wanted just exactly right then after three years or so you realized that it was too slow, it didn't have a fingerprint reader, or no integrated blue tooth. The problem is that we change our definition of perfect to suit the circumstances. In his book Paradox of Choice, Barry Schwartz speaks of Maximizers and Satisficers. Maximizers have to have the best. They're crushed when they realize they've not made the absolutely best choice. Satisficers on the other hand look for something that meets their standards and stop. If something better comes along the next week they may want it but they're not depressed about what they have.

We're all a bit of a maximizer and a bit of a satisficer. The problem is that maximization is very expensive. Expensive monetarily, expensive in time, and expensive in terms of the weight it puts on your psyche. Those people who tend to maximize more tend to be less happy.

However, in IT (and in business sometimes) we're taught to completely solve the problem. However, this isn't always the best choice. Sometimes it's better to pick an 80% solution for 20% of the cost than to pay 100% of the cost to get 100% of the benefit. (Five times more expensive for a 25% gain.)

To keep from working to perfect solutions, shift your mindset to a fixed expense and prioritize goals from high to low. However far you can get with the money you have is how far you get.

Missing Keys

So those are my nine keys to SharePoint success. What are yours?