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