Actually, it explains a lot about why SharePoint can be a tricky product to get right. To see why, let’s take a memetic view of organisational life.

Visualising problems is one of the areas we discuss in our book exclusively for readers of EndUserSharePoint.com.

Symptoms: Using MOSS 2007 SP2 and Office 2003 SP3, users complained that metadata on documents went missing. Consider the scenario below where we have a sample document library.

Often as a SharePoint consultant, you are faced with the situation where you can see plainly that a client who is new to SharePoint, is a high risk of condemning their organisation to a path that will end in tears.

I was recently involved in facilitating discussions and debate on the topic of governance for the leadership team of a public/private/community sector consortium. It was absolutely light years away from SharePoint governance, yet they struggled with it just as much as we do – and they get paid lots more than us!

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.

I know what you are saying. Is there really that much of a big deal over whether a question is deontic or instrumental? You wouldn’t think so, would you, but SharePoint projects are prone to take on wicked tendencies for reasons previously discussed. One of the techniques for dealing with wicked problems is through shared understanding among participants. A complex product like SharePoint often has inevitably fluid requirements that arise from different levels of understanding. Therefore, even small misunderstandings at the start of the journey can become big problems if the delivered product includes assumptions that were never tested.