To recap, we have spent the last two posts delving into the deep structure of problems by using an issue based mapping method. This post will continue in that same vein, but I am going to move a little faster this time and cover more argumentation with a little less explanation. I’ll also finish off with some other interesting aspects to IBIS and dialogue mapping that we haven’t covered so far.

That is because SharePoint’s technical complexity gives rise to social complexity. At the end of the day, we all have vastly varying behavioral and learning styles, we all come from varying organizational cultures, have different skills in varying disciplines and have different value sets and life skills. A collaborative platform almost by definition forces us to confront and work through this social complexity

This is the second article in a series which examine factors causing the sort of organizational inefficiencies that lead people to use products like SharePoint. My first article in the series examined individual learning and behavioral styles and their impact on communication and how those same learning and behavioral styles [...]

This is the first article in a short series that will be looking at factors causing the sort of communication problems that underpin the motivation to implement a product like SharePoint. When you think about why you want to implement SharePoint, it tends to boil down to an improvement in efficiency brought about by improved collaboration between individuals or teams.

The One Best Practice to Rule Them All: Part 1
The One Best Practice to Rule Them All: Part 2
The One Best Practice to Rule Them All: Part 3
The One Best Practice to Rule Them All: Part 4
The One Best Practice to Rule Them All: Part 5
The One Best Practice to Rule Them All: Part 6

This [...]

Rittel identified ten common characteristics of wicked problems. I remember quite distinctly, reading through that list for the first time, having this strange sense of relief. Of the characteristics, most of them had *clearly* manifested in my SharePoint-gone-haywire project. The relief stemmed from the fact that it was a recognized phenomenon with a tendency to defy traditional problem solving techniques.

Welcome to the fourth post in my series on how to deal with the true root cause of project failure. The first three posts were really to set the scene for this post where I will explain the basics of my craft for resolving some of this.

I am going to tell you the first best practice that you should master. If you master this, all of the other best practices will fall into place. It goes beyond SharePoint too. Failure to do this, and all of your other best practices may not necessarily save you. In fact they can actually work against you.

Michael Sampson (author of Seamless Teamwork) will be running a full-day master class on using SharePoint for Collaboration in Atlanta on March 26. Lee Reed, another author here on EndUserSharePoint.com, is the host for the day

Long before people defined society by the Stones vs. the Beatles, mankind teetered on the Athens vs. Sparta question and SharePoint is no exception.