Mark forwarded me an issue from a SharePoint user in Australia. This user had hit a brick wall while working on a custom SPD workflow.

I worked on creating a mailing list for a public facing SharePoint site. I really had some constraints because I was only allowed to use SharePoint Designer and the browser. I’m not used to these situations because I am mainly a software engineer. However, it was a very nice experience. I applied lots of knowledge and I worked around the constraints. I decided to put the experience and workarounds together into an educational series of articles to help SharePoint end users and administrators create their own mailing list without writing a single line of .NET code.

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

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.