Apr 11 2008
Why Do SharePoint Projects Fail? – Part 1
In honour of the CleverWorkarounds’ coffee rating system used in other posts, this post is rated on tequila shots. You will soon find out why…
CleverWorkarounds tequila shot rating: 
Asking why SharePoint projects fail is like asking why people pay money to see Steven Seagal movies, why Americans think Australians actually drink Fosters or why men leave the toilet seat upright. The answer is, they just *do*.
So let’s peel back the onion that is a SharePoint project going bad and see what we can find (apart from tears).
To make this exercise more palatable, let’s play a drinking game. If you answer YES to any of the questions below, you have to down a double tequila slammer. So get your salt and lemon ready and let’s go.
(Quick reference: Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, Part 8)
- Does the problem statement state that it will “improve” something but not say by how much?
- Has this project been given a catchy acronym as part of a communications plan?
- Have mouse pads/screen savers/mugs been distributed with the aforementioned acronym?
- Have you undertaken the requirements analysis phase *after* the product has been chosen?
- Do your stakeholders have varying interpretations on what ‘the problem’ actually is?
- Do your stakeholders have vastly different backgrounds, skills and understanding of what is to be delivered?
- Do your stakeholders suggest that the project has only one shot to get it right?
Feeling a little tipsy yet?
- Do the requirements change on a daily basis?
- Has the project scope ballooned in size and dependencies?
- Do project team members get pulled onto other projects/tasks?
- Do any of the project stakeholders indulge in office politics/empire building?
- Do the requirements change *again* on a daily basis?
- Does one (or more) of your stakeholders talk to each other only via using the project manager as a proxy?
- Has the budget been revised upward more than once?
- Has the time estimates been revised upwards?
- Are any of the stakeholders using delaying tactics on signing off on requirement, scope and budget?
- Do the damn requirements change *yet again* on a daily basis?
Now some of you have got to be practically passed out! (Please excuse me if I schlur my words with the next questions…)
- Have you forgotten the original problem the project was meant to solve?
- Do project meetings go on and on (and on and on…)?
- Have you made a new politically incorrect version of the catchy acronym? (see the second question)
- Do your fellow project team members believe the project is now a giant waste of time?
- Are you starting to go to the pub at lunchtime and not bother coming back to the office?
- Has the project manager started looking around for a new job?
- Oh not another $%#^$& requirements change!!!
- Have additional external business analysts/advisory consultants been called in?
Now I’ll bet that most readers have been involved in projects like this and I doubt whether any readers are still conscious if you counted how many tequila shots you’ve just ingested. So after you wake up, completely hung-over like the poor fellow to the right, have a couple of Berrocas and let’s move on (sorry you US readers, I don’t think you get Berroca over there – your loss).
For what it’s worth, a lot of my posts where I make stereotypical digs at different roles/personalities in an organisation are really inspired by dealing with the personality aspects of wicked problems.
Now wait just a dog gone second!
If you look closely at the questions from our little game above, you will notice that not one of those questions mentioned or implied SharePoint. This is both deliberate and important, because SharePoint doesn’t exactly stand alone when it comes to IT projects that go pear shaped. SAP and Oracle for example have their fair share of bad projects.
This is not just an IT discipline problem either. In fact, quite a lot of academic research has been performed, examining the characteristics of projects that go bad. The term “wicked problem” has become the defacto standard description of the phenomenon. So let’s examine some of the more interesting research into wicked problems.
History Lesson 1 – Horst Rittel
The original “yoda” of this area has got to be Horst Rittel. In 1973 he co-authored a paper with Melvin Webber about the nature of problems in relation to planning and social/public policy. A lot of it isn’t exactly riveting reading, but despite being 35 years old and written for a specific discipline (planning), not much has changed 
Rittel and Webber characterised “planning problems, i.e. wicked problems” by ten “distinguishing properties”. I have listed them below and yanked some quotes along with my interpretation/paraphrasing to get the point across more succinctly.
There is no definitive formation of a wicked problem.
- The information needed to understand the problem depends on one’s idea for solving it … Every textbook of systems engineering starts with an enumeration of these phases: “understand the problem or the mission”, “gather the information”, “analyse the information”, “synthesise information and wait for the creative leap”, “work out solution”, or the like. For wicked problems, however, this type of scheme does not work”
Wicked problems have no stopping rule
- … because (according to Proposition 1) the process of solving the problem is identical with the process of understanding its nature. You can always try to do better as your understanding grows. This leads to the presumption that additional investment of effort might increase the chances of finding a better solution.
Solutions to wicked problems are not true-or-false, but good or bad
- Judgements on the effectiveness of solutions are likely to differ widely based on the personal interests, value sets, and ideology of the participants.
There is no immediate and no ultimate test of a solution to a wicked problem
- Any solution, after being implemented, will generate waves of consequences that may yield utterly undesirable repercussions which outweigh the intended advantages.
Every solution to a wicked problem is a “one shot operation”; because there is no opportunity to learn by trial-and-error, every attempt counts significantly.
- “One cannot build a freeway to see how it works”
Wicked problems do not have an enumerable (or exhaustively describable) set of potential solutions
- There are no criteria which enable one to prove that all solutions to a wicked problem have been identified and considered
Every wicked problem is essentially unique
- By “essentially unique” we mean that … there always might be an additional distinguishing property that is of overriding importance … one can never be certain that the particulars of a problem are consistent with previous problems already dealt with.
Every wicked problem can be considered to be a symptom of another problem
- As you investigate problem causes, there is a tendency to discover that the current problem is the symptom of a larger problem. The level at which a problem ’settles’ cannot be decided on logical grounds. Rittel implies here that this characteristic makes phase-based problem solving as described in the first characteristic. “Marginal improvement doesn’t guarantee overall improvement. For examine, computerisation of an administrative process may result in reduced cost, But at the same time it becomes more difficult to incur structural changes in the organisation, because technical perfection reinforces organisational patterns and normally increases the cost of change.”
The existence of a discrepancy representing a wicked problem can be explained in numerous ways. The choice of explanation determines the nature of the problems resolution.
- “You might say that everybody picks an explanation of a discrepancy which fits their intentions best”
The planner has no right to be wrong
- This final distinguishing property is not as relevant as the previous ones. Rittel asserts here that when scientists propose a theory in the “search for truth”, they do not have to be right. Rather, the theory is validated by its ability to withstand peer review and repudiation over an extended period of time. Wicked problems on the other hand, do not have this luxury. “Planners are liable for the consequences of the actions they generate”.
So aside from the last one, I think Rittel and Webber pretty much got it right. I especially appreciated the “systems engineering” phases in the first distinguishing property, “understand the problem”, “gather the information”, “analyse the information”, “synthesise information”, “work out solution”.
Whatever your acronym, DMAIC, DFSS, DMADV, [insert flavour of the month here], it seems the process is really not different – just the acronym
Anyway, that’s enough academia for one night. In part 2 of this series, we will examine later academic work on wicked problem theory, and then turn our attention specifically to SharePoint.
Bye for now
Paul
April 11th, 2008 at 6:16 am |
[...] CleverWorkarounds has a good article about it, comparing it to a drinking game which I think is classic. Again, it’s not the tool. They also have another article about selling MOSS that’s pretty “interesting”. [...]
April 11th, 2008 at 8:01 pm |
Nice One! I’m about to pass out, and i’ve only done the first few questions, i’ll have to pick it up again chomorrow after I is bought anuvva bottle of tequila (hic)
April 12th, 2008 at 11:35 pm |
[...] Culmsee at Clever Workarounds has a new post called Why Do SharePoint Projects Fail which can also be played as a drinking game Technorati tags: SharePoint, Governance, [...]
April 14th, 2008 at 6:27 pm |
[...] Why Do SharePoint Projects Fail? – Part 1 [...]
April 15th, 2008 at 8:39 am |
[...] to Part 2 of a series that examines why SharePoint projects fail. If you have come straight from Part 1, you probably still have a hang over and would most likely not want to see tequila ever again! But [...]
April 15th, 2008 at 10:21 pm |
[...] This post,of course , is having fun at the expense of IT departmental stereotypes. However, under this bizarre story filled with pent up sarcasm and in-jokes there are some serious themes buried. My next post will be the serious version of this post, where I will talk about some of the considerations, risk and constraints trying to find a solution for a tool, and not letting this turn into a ‘wicked project‘. [...]
April 19th, 2008 at 10:20 pm |
[...] Part 1 introduced you to tequila slammers, as well as the pioneering work by Horst Rittel and the concept of wicked problems. [...]
April 22nd, 2008 at 9:05 pm |
[...] Why Do SharePoint Projects Fail? – Part 1 [...]
April 25th, 2008 at 12:02 pm |
[...] post has started with some attempt at humour, before getting into some theory. We’ve had a drinking game, insulted project managers by painting them all with the same brush, and have had a mythical [...]
April 25th, 2008 at 11:25 pm |
[...] Why do SharePoint Projects Fail? – Part 1 [...]
April 26th, 2008 at 2:11 am |
[...] Part 1 [...]
May 8th, 2008 at 12:45 am |
[...] How to prevent derailing SharePointI’ve read Paul Culmsee’s articles with great interest on Project Failure and will be helping him continue his series in the next few [...]
May 9th, 2008 at 5:24 pm |
[...] Why do SharePoint Projects Fail? – Part 1 [...]
May 10th, 2008 at 7:35 am |
[...] reading Joel’s post, I took the time to read the Why SharePoint Projects Fail (Part 1, 2, 3, 4, and 5) posts by Paul Culmsee. The posts are a great read for project managers, technical [...]
May 12th, 2008 at 12:16 am |
[...] you have followed events thus far, I covered off some wicked problem theory, before delving into the bigger ticket items that contribute to SharePoint project failure. In the [...]
May 12th, 2008 at 3:00 am |
Another case for/of Murphy’s Law
No matter how well you prepare, someday, somebody will screw it up!
May 17th, 2008 at 1:58 pm |
[...] if you are in an organisation suffering from wicked problem symptoms because of differing versions of the truth among stakeholders, you could do worse then all [...]
May 21st, 2008 at 1:46 am |
[...] you have read the “project failure…” series, ROI, or the organisational maturity posts, you will see a parallel here. Seems that [...]
May 27th, 2008 at 9:30 pm |
[...] the first time, I suggest you go back and read this series from the start. You will learn all about tequila slammers, why Microsoft is like Britney Spears, Bill Gates selling SharePoint to Sergei Brin and the [...]
May 29th, 2008 at 5:23 pm |
[...] Why Do SharePoint Projects Fail? – Part 1 [...]
June 3rd, 2008 at 9:53 pm |
[...] the last of a long series written over the last couple of months (well, last for now anyway). We started this series with an examination of the pioneering work by Horst Rittell in the 1970’s and [...]
June 11th, 2008 at 2:26 am |
[...] doubt about it, but the propensity to fail is higher than you might expect. (For more on that topic see this series I wrote a little while [...]
June 14th, 2008 at 9:09 am |
[...] about it, but the propensity to fail is higher than you might expect. (For more on that topic see this series I wrote a little while [...]
June 26th, 2008 at 11:49 pm |
[...] in a SharePoint project are at this stage in their learning, then you are on a dangerous slope to SharePoint project failure if you proceed too [...]
June 27th, 2008 at 9:55 am |
[...] soooo wish that I had seen this when I was writing the "SharePoint Project Failure" series as I actually touched on some of these [...]
July 15th, 2008 at 12:46 pm |
[...] especially while a shared understanding is still being developed. But right here is the root of project failure – not just [...]
July 23rd, 2008 at 6:17 pm |
[...] Warning: SharePoint can create chaos if not used properly Posted on July 23, 2008 by koenvosters As I am still facing quite a few clients who are still interested in just deploying SharePoint within their organisation without thinking upfront about the why, the what, the who, the where and the when, articles like the one on InfoWorld make my life a little bit easier, as with a bit of luck they end up reading it as well
. SharePoint is a great product, it does support an insane amount of features, it is a nice platform to build applications on, but it is not the magical product that will solve all your problems. I like to compare it with a nice room, with a television, lots of drawers to organize your clothes, cd’s, dvd,’s and what not. Having a nice room like that is great, and you can do lots of things in it. But you can also make a complete mess of the room, no matter how nice it was when you first “deployed” it. So define a strategy, define WHY you want to use SharePoint, which problems it will solve and where these solutions fit in the bigger picture. If you are doing a pilot, preferably by starting with one division/audience, make sure you have an idea upfront how it fits in the bigger picture, and scope it. Or your pilot will become production, you will get more and more requests as other divisions hear about what is going on, and you’ll end up with an environment that is unmanageable. Another nice read on this topic are the series : Why do SharePoint Projects fail? [...]
July 23rd, 2008 at 10:04 pm |
[...] especially while a shared understanding is still being developed. But right here is the root of project failure – not just [...]
July 28th, 2008 at 10:42 pm |
[...] a look at Paul Culmsee’s set of articles on Why SharePoint Projects Fail and Thinking SharePoint. Very useful stuff and also very [...]
July 29th, 2008 at 12:57 am |
[...] have previously written extensively on SharePoint project failure. In some ways that particular series is just as much about "thinking SharePoint" as this [...]
August 7th, 2008 at 12:16 am |
because sharepoint is too complex?
August 7th, 2008 at 12:41 am |
I think I get to product complexity in part 3 or 4
August 12th, 2008 at 11:27 pm |
[...] please take a timeout and head over to Paul Culmsee’s blog and read the series of posts on "Why SharePoint projects fail". Paul points out all the reasons why sometimes the best efforts of Project Managers and [...]
August 13th, 2008 at 4:34 pm |
[...] is their inherent subjectivity. When I wrote my series on "SharePoint ROI", "project failure" and even "Thinking SharePoint", I expected a negative feedback on the expectation [...]
August 14th, 2008 at 8:01 am |
[...] Why Do SharePoint Projects Fail? – Part 1 Szenzációs cikk a SP projektek hibáiról, meghiúsulásáról, stb. Készíts elő tequilát, mielőtt elkezded olvasni! (A sorozat további részei a cikkben linkelve.) (tags: sharepoint2007 project projectmanagement) [...]
September 11th, 2008 at 11:03 pm |
[...] I wrote the series on SharePoint project failure, I had (and still have) a strong belief that I had gotten fairly close to the root causes of many a [...]
September 25th, 2008 at 1:03 am |
[...] but it has not been a success. There are various reasons;I have cited them in detail in the project failure series, so I won’t rehash all that here. (I’d suggest reading parts three, four and [...]
September 25th, 2008 at 9:37 pm |
[...] to SharePoint then, how about I point you at somebody else’s blog instead? Paul Culmsee writes an amusing and informative SharePoint blog which puts my efforts to shame. I strongly advise [...]
October 3rd, 2008 at 10:17 am |
[...] 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 [...]
October 31st, 2008 at 9:34 am |
[...] Just a few weeks ago, Paul Culmsee at Seven Sigma wrote a voluminous five part blog post entitled, Why Do SharePoint Projects Fail? Paul is a very entertaining writer and I recommend that series in particular. I've [...]
November 17th, 2008 at 3:40 pm |
[...] Once again I leave you on an Information Architecture note. Someone who only knows a clan culture will very likely put together a SharePoint solution vastly different to someone who has only known hierarchical culture. The prevailing culture will always win the technology battle, no matter how passionate the individuals are. Even organisational stakeholders in a SharePoint project often make this mistake with the "build it and they will come" approach and think that making the technology available will change the culture . This is both naive and dangerous and has the effect of setting yourself up for project failure. [...]
February 12th, 2009 at 7:29 am |
[...] *encourage* you to take the bits that make logical sense for you. As I wrote in Part 8 of the "SharePoint Project Failure…" series, I found it ironic that implementation of many of these methodologies fell victim to [...]
March 17th, 2009 at 4:00 pm |
[...] 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 [...]
March 20th, 2009 at 3:25 am |
[...] Once again I leave you on an Information Architecture note. Someone who only knows a clan culture will very likely put together a SharePoint solution vastly different to someone who has only known hierarchical culture. The prevailing culture will always win the technology battle, no matter how passionate the individuals are. Even organizational stakeholders in a SharePoint project often make this mistake with the "build it and they will come" approach and think that making the technology available will change the culture . This is both naive and dangerous and has the effect of setting yourself up for project failure. [...]
April 30th, 2009 at 5:34 am |
[...] bookmarks tagged tequila slammer CleverWorkarounds » Why Do SharePoint Projects Fa… saved by 1 others xXNarutosLilSisXx bookmarked on 04/29/09 | [...]
July 16th, 2009 at 5:24 pm |
[...] insightful blogging at CleverWorkarounds and in particular his series focussed on the importance of shared understanding in preventing SharePoint projects from [...]
November 29th, 2009 at 8:49 pm |
[...] ratings for a while, so I thought that this post was apt for dusting them off. If you check the Why do SharePoint Projects Fail series, you will see that I use tequila shots or coffee at times. In this case, I will use the [...]