Fun with "wicked problems"

How the hell can wicked problems be fun? I’d better explain, hadn’t I…

I’ve been struggling with a blog post for a few days. I’ve wanted to blog about SharePoint’s propensity to become a  dreaded “wicked problem”. I will get to that post eventually, but for now I thought that I would share with you something that made me smile while researching it.

First up, a really quick (wikipedia) definition of a “wicked problem”, particularly Jeff Conklin’s definition. According to Jeff’s research, wicked problems have four characteristics:

• The problem is not understood until after formulation of a solution.
• Stakeholders have radically different world views and different frames for understanding the problem.
• Constraints and resources to solve the problem change over time.
• The problem is never solved.

SharePoint projects can easily become wicked problems, and I promise that I will post more details on the varied reasons. But while researching into the nature of wicked problems and strategies for mitigating the risk of them, I came across some literature that suggests that one of the key strategies is to counter them is … wait for it …

…collaboration!

So in short, to stop SharePoint projects from turning into wicked projects, we have to collaborate!

Collaborate, eh? Then we’d better undertake a project to implement a collaboration system so we can collaborate better. Oh wait – we *are* implementing a collaboration system. It’s this new cool tool called SharePoint…

Oh, dude this is too hard man… I have the munchies.