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 …
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.