People often ask about tips for getting started with their SharePoint project, and usually my advice is to keep things simple and focus on what SharePoint does best (and avoid what it doesn’t do as well). Normally whenever these words come out of my mouth, I’m very aware of how silly it must sound to someone because it sounds rhetorical. But the fact of the matter is that failure to follow these two little tips is the reason why most SharePoint projects jump the tracks.

The K.I.S.S. principle
If you aren’t familiar with the acronym K.I.S.S., it stands for Keep It Simple Stupid/Silly/SharePoint. The solution to any problem should be reasonably simple, but just for clarification that doesn’t mean that I’m advocating a specific way of solving the problem. For example, we’ve all talked to stakeholders who have some problem to solve, and we’ve probably all heard (or proposed) solutions that are the technical equivalent of a Rube Goldberg machine (i.e. In these cases, you might address the original problem but would likely end up with long-term supportability issues.

If you happen to find yourself in a position where a complex solution has been proposed by someone (or maybe you’ve been the one who proposed it), the best thing is often to step back and look at the original goal. Many times the answer is to improve and streamline the process (executives love stuff like that!), or maybe it would be possible to just make the technical solution less elaborate so that you’d still get business value but not the perceived “perfect world” solution. In my experience, it is okay. Remember that you can always enhance functionality in the future, but it is far more difficult to dial back complexity once it has been implemented.

If you ignore the K.I.S.S. principle, you run the risk of delivering an overly complex solution that might be difficult to support and use. This can lead to loss of trust by your stakeholders. Start simple and create things that create real value for your stakeholders. If you do it right, they’ll ask you to do more, which is a very good problem to have!

Focus on what SharePoint does best (and avoid what it doesn’t do as well)
It seems like obvious advice to focus on what SharePoint does best and avoid what it doesn’t do so well. But when you are starting a SharePoint project, this could mean the difference between success and failure. You should be honest and ask yourself if you (or your team) really understand SharePoint well enough that you could be confident to propose a solution. And if it turns out that there’s a gap in your understanding, that’s okay too. We’ve all be there. SharePoint is a big product. But there are plenty of ways to close that gap, through books, training, online resources, or even getting some good help from an experienced external resource.

One last thing
The other piece of advice that I normally tell people is to “avoid doing things that are hard.” Let me give you an example: We’ve all been in meetings where a business user asks for something, and the technical team looks at each other with pure horror, but then for some strange reason someone says to the user, “Yeah, we can do that.”

This advice isn’t intended to mean that you should never implement anything difficult on a SharePoint project; the real moral is to pick your battles. Depending on your experience level of you or your team, what you consider difficult is going to vary. The most common issue I see is that a team that is experienced with other technologies, usually .NET, takes on a SharePoint project and then quickly realizes that things are more complex and nuanced than they expect. Usually one of two things happens: They either try to simplify functionality, or they forge ahead and implement something that many times that wouldn’t be considered a “best practice.”

The reality is that every project is going to require that we tackle some difficult requirements. The analogy that I usually use to describe this is that back when I was in college, I’d try to be mindful of the courses that I was registering for. I knew that as I got closer to graduating, some of the courses I needed to take were going to be very difficult. I tried to spread these difficult classes out so that I never took more than one or two at a time and balanced them out with much easier classes. You can do the same thing with your SharePoint project: Split it up into several phases and try to spread out the more complex functionality so that it doesn’t become too overwhelming.

Another thing to consider is that the complex functionality often takes more time to implement. Spreading that functionality into phases allows stakeholders to see things sooner. It normally makes a project go smoother when functionality can be rolled out for people to start using sooner as opposed to later. This approach also makes it easier to make small course corrections along the way as people start to use the functionality, which tends to lead to a better product in the long run.

It seems like it wasn’t that long ago that I did my first SharePoint project. I’ll never forget when my boss walked past my cube, clapping his hands and shouting, “Who wants to do SharePoint?” That person ended up being me. Things have turned out pretty well, but I learned a lot of hard lessons during that first project—many of which I’ve shared in this short article.

I’d be interested to hear from readers about these tips or others that they give. You can find me on Twitter:

John Ross is a SharePoint MVP and Senior Consultant with SharePoint911. He has over eight years of experience implementing solutions for clients ranging from small businesses to Fortune 500 companies, as well as government organizations. John is coauthor of the books “Professional SharePoint 2010 Branding and User Interface Design” and “Real World SharePoint 2010: Indispensable Experiences from 23 SharePoint MVPs.” Visit his blog at