June 30 is the end of the financial year here in Australia, and it has become very busy for me, which is rather annoying as it distracts me from advancing my evil plans for world domination (oh and blogging too).

It seems IT departments are realising they still have some budget left, and of course well all know the prevailing wisdom that you want the same or bigger budget next year, you had better spend all of this year’s budget. So what better thing to do with that spare cash is to put in SharePoint, eh?

Unfortunately for me, I have been deep in SharePoint related proposals and tender responses that are motivated somewhat by budget spend. Thus I am dealing with questions like the obvious “how much does it cost” and “how long will it take”, without any knowledge of how the organisation sees SharePoint fitting into their circumstances. I think if you have followed my project failure series thus far you will appreciate that I find these two questions in particular, a sign of pain to come by client and integrator alike.

So if you are an IT Manager and have some budget left over, here are my suggestions.

1. Do a team building exercise (like paint-balling) for your staff, and just accept the fact that they will gang up on you and hunt you mercilessly for all the crap you have put them through
2. Take them to the pub for the afternoon, put a bar tab on in recognition of their efforts
3. Go and buy the CMS Watch SharePoint report.

Continue reading “A critique of the CMS Watch SharePoint Report”

Hi again and welcome to part 6 of my series on the factors of why SharePoint projects fail. Joel Oleson’s write-up a while back gave me 5 minutes of fame, but like any contestant on Big Brother, I’ve had my time in the limelight, been voted out of the house (as in Joel’s front page) and I’m back to being an ordinary citizen again.

If 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 last post, we pointed our virtual microscope at the infrastructure aspects that can cause a SharePoint problem to go off the rails.

Now we turn our magnifying glass onto application development issues and therefore application developers. Ah, what fun you can have with application developer stereotyping, eh! A strange breed indeed they are. As a group they have had a significant contribution to the bitter and twisted individual that I am today.

The CleverWorkarounds tequila shot rating is back!

for a project manager in denial 🙂

for the rest of us!

Continue reading “Why do SharePoint Projects Fail – Part 6”

This post is going a little off-track from the previous 5 posts around SharePoint project failure and I promise I will get back on track again soon. I felt that I had to talk about this topic while we are looking at the nature of project failure, wicked problems and SharePoint. Not sure if it is really a part 6 so I have made a new, separate interlude in between the project failure series. Why don’t you let me know, reader, if you think this belongs as a part of the “project failure” series!

My wife is studying a business course at university and I have been reading some of her reference books. One book was particularly good and really got me thinking about technology’s contribution to global organisations and how at this scale, most problems likely have a large degree of wickedness.

This edited book is called Global Strategies: Insights from the World’s Leading Thinkers (The Harvard Business Review Book Series), and it is well worth reading – even for you technical geeks.

What it does is look at the strategy, and execution of strategy, that has led some organisations to make the transition from regional to global success story at the expense of their competitors. We are talking corporations with tens of thousands of employees here too, and the CEO perspective really hits home to you – the sheer *mammoth scale* of it all.

Trying to change a culture at an organisation of 20 employees can be an insurmountable challenge. Try 45,000 employees across 15 subsidiaries in 10 different countries. (Makes a SharePoint rollout seem like a walk in the park.)

Continue reading “Globalisation, Strategy, Technology and Organisational Maturity”

Hi again and welcome to this seemingly endless series of posts on the topic of SharePoint projects gone bad.

We spent a couple of posts looking at problem projects in general before focusing specifically on SharePoint. If you have followed the series closely, you will observe that haven’t talked much on technical aspects of the product yet. If you were expecting me to pick apart annoying aspects of the architecture then unfortunately, you will be disappointed because I really don’t believe that it is a big factor in why SharePoint projects fail. Besides which, 90% of SharePoint blogs are on technical/development content anyway.

So where am I going with part 5 then you ask?  I am indeed delving into technical aspects, but once again it is all about the people involved.

So now its time to take a few cheap-shots at the geeks. (After all, they are sensitive souls and we don’t want them to feel left out do we). For the purposes of this post, infrastructure people, tech support, system administrators can be lumped into the same ‘geek bucket’.

Geeks can also cop it like Project Managers do, when projects take on wicked tendencies. They will implement the agreed requirements, but the stakeholders feel that the end result isn’t what they wanted. In the ensuing fallout that happens when the project sponsor realises that say, half a million bucks has been blown with little to show for it, blame is inevitably directed their way, whether justified or not.

Continue reading “Why do SharePoint Projects Fail – Part 5”

Hi again

Welcome to part 4 of this series, which examines the factors that contribute to SharePoint projects causing much pain and suffering among project teams. Each 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 conversation with Bill Gates successfully selling MOSS to the good people at the company GOOSUNACLE.

On a serious side, we have looked at the Rittel definition of a wicked problem, looked at its relevance in IT projects and then considered some SharePoint specific factors, namely the “Microsoft Factor” and the “Panacea Factor”. Let’s continue down this road…

The New Product Factor… what does it do again?

This is a big problem area, certainly for the next couple of years. To properly explain it, I can draw a parallel to what happened in 1998-2002 when organisations moved from NT4 domains to Active Directory. Infrastructure people who have been involved in Active Directory projects will be nodding in agreement at this point.

In 2000 when Active Directory was released, it was a major advancement over Windows NT4 domains. It was not a simple incremental update, but essentially a whole new approach to how Microsoft networks were structured and managed. Microsoft released an absolute barrage of white papers, along with seminars and tutorials way in advance of release, explaining how it all worked. I have to admit though that as an infrastructure engineer at that time, it didn’t make much sense to me then, because a white paper is one thing, but actually using the product in the real world is another.

What was interesting about that time was that “Active Directory” became somewhat of a buzz word, and it was marketed as the be-all-and-end-all of life, the universe and everything. Just to demonstrate how nuts it was, I recall that Cisco and Microsoft made an announcement with big fanfare, trumpeting the fact that the management of all of your Cisco devices would be done via Active Directory!

WTF? “That never happened!”, I hear you AD and Cisco nerds exclaim.

Well here is the proof – god I love google sometimes 🙂

Choice quotes are always useful – Here is an article from 1998. http://www.cnn.com/TECH/computing/9811/19/cisconds.cdx.idg/

Microsoft and Cisco have been working for 20 months now on a project entitled Cisco Networking Services for Active Directory. The delivery date of that integrated product is tightly tied to the ship date of Windows 2000, which at the time of the Microsoft/Cisco partnership was supposed to be before the year’s-end. Microsoft is now saying that Windows 2000 will not ship until the middle of 1999.

So have you ever managed a Cisco network using Active Directory (apart from Radius authentication)?

So, fast forward 8 years and we now have a ton of collective real world experience, a set of mature best practices, and countless books on the subject. Active Directory projects are really not that complex at all. But back when it first came out, there was no collective expertise, and mistakes were made.

I have been involved with a few Active Directory revamp projects over the years, and every one of them was a project of consolidation, clean-up and simplification from the previous attempts at it. To this day I have never been called in to increase the complexity of an Active Directory to solve business issues.

Why am I telling you all this? Quite simple really, SharePoint is still in the hype stage, real world experience is still lacking, but more importantly, best practices are not mature. This is not helped by the way Microsoft and partners market the product. Right now, that is also very similar to Active Directory in 1999-2001. Let’s now look at that more closely.

(Mis)use of terms, ambiguous marketing and buzzword abuse

Okay, first up let’s take a closer look at a chart that pre-sales consultants will know well. Take a look at any of the terms in the outer ring and you basically have entire fields or disciplines where people spend their entire careers. So SharePoint can do all of that with one product, huh? Dang! It must be super-duper, finger-lickin’, umpa-lumpa good then!

Microsoft is in the business of selling licenses to use their software, and judging on their revenue and growth, SharePoint has been a rampaging success. I dislike their marketing material and will get into that in a minute, but at the end of the day it has worked for them. If I was developing a product to be used across many different organisational types and vertical markets, I’d probably end up doing exactly the same…

All of the disciplines above also happen to be buzzwords in their own right. When that happens, it is an irresistible target for savvy marketing campaigns to try and fit products into that space. Sometimes buzz-words come from odd sources too. Sarbanes Oxley is not a discipline, it is a legislative framework which has been widely used in marketing, especially by companies offering products in the security space – and judging by the current financial crisis in credit markets, have these products helped at all with the intent of SOX?

If I believed everything that was marketed to me, surely I would be throwing off gorgeous women in presales or strategy meetings? I mean, I use Lynx deodorant and it worked for the dentist…

(That ad is so wrong and I love it! – If you see a broken image here your company blocks youtube. Here is the link)

So let’s now focus on where SharePoint marketing has the potential to do more harm than good. My issue with this ‘chart’ is this: Explain to me what “Business Intelligence” actually is. Define “Content Management” or “Collaboration”. (Don’t cheat and go to wikipedia! – that is the place people go just before they have a meeting and want to sound like they know what they are talking about.)

The very fact that these areas are entire disciplines in themselves means that their meanings vary vastly to different people. Given that human beings like to categorise things into little boxes, the more generic a discipline, the more sub-definitions and branches within the discipline there are. Additionally, these sub-definitions and branches introduce their own terminology and acronyms.

I previously lamented the fact that the term “document management” is totally abused all the time and it leads to confusion and bad projects. What is funny, is that term is not even used in the above chart! So where does document management fall under? Content management or collaboration? It all depends on your definition of “document management”, doesn’t it?

Crap! It’s bad enough that we can’t agree on what the hell “document management” is and then I’m not sure where it fits anyway!

I have to say though, that “Business Intelligence” and “Collaboration” are even more misunderstood than document management. I was asked by a stakeholder of a million dollar SharePoint implementation if I could explain the difference between SharePoint and Skype! What the…! But his justification was quite simple. “I can collaborate with anyone cheaply with skype, as I can talk to them whenever and wherever I want. What does the added cost of SharePoint give me?”.

It is still a “what the…” moment, but really, you can’t fault why he asked such a question.

Conclusion

So to finish off part 4 section, let’s take a moment, pause and recap one of Rittel’s properties of a wicked problem. “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.”

Do you think that Microsoft pie chart really helps customers? Hmm, I think not.

I just had a cartoon idea moment (Paul digs out photoshop). I think the image below says it all.

more to come… stay tuned!

Paul

This third post in the “Who do SharePoint Projects Fail” series has been hard to write, not because I am struggling with ideas, but because I have too many! It is hard to put all the reasons why SharePoint projects go wrong into a coherent chain of logic.

In the first two posts in this series, we did a basic examination of wicked problem theory.

Part 1 introduced you to tequila slammers, as well as the pioneering work by Horst Rittel and the concept of wicked problems.

Part 2 also delved into the murky depths of academic history to demonstrate that even back in the seventies when ABBA stole the hearts and minds of teenyboppers around the world, at least some people had time to look at wicked problems in relation to building IT systems.

If you take away anything from part 1 and 2, it is this.

• Too many tequila slammers hurt
• Before you blame the product, the project manager, the stakeholders, the nerds, the methodology or anything else in vicinity, go back to the problem you are solving and determine its ‘wickedness’

Now we will finally look at this large, complex, scary beast known as SharePoint. I have no means to quantify how much of a percentage of project problems arise from issues related to “the product”, but it definitely happens. Unsurprisingly enough, it is easy to argue that some of the areas that I highlight below are people issues, but we still get to indulge in Microsoft bashing – and who doesn’t enjoy a bit of that eh?

Continue reading “Why do SharePoint Projects Fail – Part 3”

Hey there.

Welcome 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 if you missed the first article, there is a drinking game to be played first 🙂 .

Now as it happens, we haven’t even gotten to SharePoint yet. That’s because to examine why SharePoint projects fail, one has to examine why “projects” fail. Part 1 introduced the work of Horst Rittel and the term ‘Wicked Problem’. His work was not related to IT problems per se, but most of the ten characteristics he described 35 years ago are applicable to IT projects. Although subsequent academic works have refined (and in some cases criticised) his work, it still stands up pretty well in my opinion.

When you examine the various survey based studies undertaken on the success rate of IT projects, bad projects have a significant root cause at the initiating and planning phases. My own personal experience pretty much corroborates the studies and in hindsight, it’s plain that the worst of them were wicked problems.

In this post, I am going to play the role of the “ghost of wicked problems past” (think Dickens: A Christmas Carol). I am going to take you on an exciting, magical journey back in time, to examine some of the early work on wicked problems, and show that in the 25-35 years since they were written, not a heck of the wisdom imparted has found its way to prominence 🙂

CleverWorkarounds tequila shot rating with a redbull thrown in (on account of the history lessons):

Continue reading “Why do SharePoint Projects Fail? – Part 2”

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)

Continue reading “Why Do SharePoint Projects Fail? – Part 1”

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.