Kristian Kalsing was written a really terrific post, not just because he quoted yet another bloody international standard that I will have to now read (ISO15489). But because, drawing on his experiences of the world of SAP, he has observed that there are some important lessons that can be learned for SharePoint engagements. SAP (okay, well Basis anyway) is a world that I experienced way back in 1999 and, boy, can I write some stories about social complexity and project failure about that era!

Kristian observes that on SAP projects, the roles of consultants are typically very clearly defined and discipline based. For example, there are infrastructure (Basis) consultants, developers and functional consultants. Even within functional consultants, there are sub-disciplines of expertise. (Hope you don’t mind me quoting you Kristian).

The point is that the consultant configuring the finance module is basically an accountant and the consultant configuring the HR module probably studied human resources at university. In the SAP world, it would be absurd to take someone who has configured materials management or plant maintenance with one client and ask them to configure HR with the next. In SAP, the specialisation does not stop with the functional areas of the product. There are also functional consultants building up experience in certain industries. E.g. supply chain management can be very different when talking coal mining compared to running supermarkets.

Kristian observed that this notion of functional consultants does not occur in the SharePoint world. However, he qualifies this by observing that SAP is much bigger than SharePoint and therefore a direct comparison is "bit of a stretch", yet lessons can be learned. On the ‘bigger’ point I actually disagree and think that the context of ‘bigger’ is relative (and I look forward to Kristians’ opinion on my take). SAP and ERP systems are massively bigger and more complex than SharePoint – without a doubt. SharePoint may not be as big as SAP in terms of feature-set and complexity, but it can actually be just as big as an ERP system in terms of the impact on the day-to-day workings of staff.

To paint a gross generalisation, with an ERP system, often all that many end-users will ever see is a system to enter their time-sheets and perhaps perform some HR functions such as apply for leave or check pay-slips. Not everyone directly sees or interacts with, say, financials, plant maintenance and the like. But you can be pretty damn sure that everyone saves files to G:\ drive on a daily basis. (Substitute whatever your drive letter is that represents your jungle that is the file system).

More staff = more social diversity = more differing opinions = more complexity = bigger scope = more options = even bigger scope = wicked problem

Therefore, it is not a case that "lessons can be learned from the SAP world", but it is a case of "lessons should be learned from the SAP world".

But here is one additional (admittedly subjective) point to consider.

ERP systems have a really bad failure rate. Does the fact that there are discipline specific functional consultants involved really hold the key to project success?

Don’t get me wrong. I think that SharePoint functional consultants are a critical piece of the puzzle and, by god, the world can do without Microsoft gold partners throwing one of their "technical" people at what is essentially a project with a huge training and advisory component. But succeeding in SharePoint – or any other discipline involving complexity and a large diversity of stakeholders, goes deeper than that.

The difference between a "functional consultant" and a "great functional consultant" is not only domain specific knowledge. It is the art of helping diverse stakeholders to disentangle complex problems from a cluttered maze of overlapping issues, the moving target of requirements into an environment where all participants have a shared understanding.

I’ll have more to say about this as I delve deeper into the "One best practice…" series.

Thanks for reading

Paul Culmsee

Hi all

This is part of a somewhat self-indulgent story of how I came to practice a craft that has made a profound difference on how I approach and manage SharePoint projects. If you have not read part 1, then I suggest you stop now and read that first. This post will really not make a lot of sense, otherwise :-).

In my last exciting instalment, I had concluded with the time where I discovered the term “Wicked problems” and the work of Horst Rittel, who coined the term. In his landmark 1973 paper, Rittel identified ten common characteristics of wicked problems. I remember quite distinctly, reading through that list for the first time, having this strange sense of relief. Of the characteristics, most of them had *clearly* manifested in my SharePoint-gone-haywire project. The relief stemmed from the fact that it was a recognised phenomena with a tendency to defy traditional problem solving techniques. The characteristics with which I immediately identified are marked in bold below.

1. There is no definitive formulation of a wicked problem.
2. Wicked problems have no stopping rule.
3. Solutions to wicked problems are not true-or-false, but better or worse.
4. There is no immediate and no ultimate test of a solution to a wicked problem.
5. 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.
6. Wicked problems do not have an enumerable (or an exhaustively describable) set of potential solutions, nor is there a well-described set of permissible operations that may be incorporated into the plan.
7. Every wicked problem is essentially unique.
8. Every wicked problem can be considered to be a symptom of another problem.
9. The existence of a discrepancy representing a wicked problem can be explained in numerous ways. The choice of explanation determines the nature of the problem’s resolution.
10. The planner has no right to be wrong (planners are liable for the consequences of the actions they generate).

But the real clincher – the moment that made me realise that my frustrating journey through standards, methodologies and best practices was finally coming to an end was the 5th characteristic. “Every solution to a wicked problem is a “one -shot operation”. When I read that one, it was as if my famous “Skype-vs-SharePoint” guy suddenly materialised in front of me and mooned me saying over and over again “I can collaborate on Skype, too!”

For those of you who skipped part 1 despite warnings, “We only have one shot at this” was pretty much a word-for-word quote on what was said to me in the haywire project that started all of this.

Is it any surprise that I felt I was onto something here?

Digging deeper

When I read Rittel’s 1973 paper, I began to get a deeper understanding of what he meant by his first two characteristics that I didn’t immediately identify with. Namely “there is no definitive formulation of a wicked problem” and “wicked problems have no stopping rule”.

I soon realised that these two characteristics were actually the most *prevalent* characteristics of complex IT projects and therefore, the list was even *more* relevant to me than I had originally thought. After that, I was a convert. Rittel explained the first characteristic as follows…

The information needed to understand the problem depends upon one’s idea for solving it. That is to say: In order to describe a wicked-problem in sufficient detail, one has to develop an exhaustive inventory of all conceivable solutions ahead of time. The reason is that every question asking for additional information depends upon the understanding of the problem–and its resolution–at that time. Problem understanding and problem resolution are concomitant to each other.

The second characteristic, “no stopping rule”, is a natural consequence of the above issue. Again, quoting Rittel from 1973…

Because (according to Proposition 1) the process of solving the problem is identical with the process of understanding its nature, because there are no criteria for sufficient understanding […] , the would-be planner can always try to do better. Some additional investment of effort might increase the chances of finding a better solution.

Skype-vs-SharePoint guy, who now has the credit of being one of the most significant unwitting teachers of my career, went from not knowing any difference between SharePoint and Skype, to suggesting work items that already existed in the project plan, to telling us how we should build our information architecture based on 1990’s era document management systems. It was crystal clear that he went through this iterative process of changing his understanding of the problem based on how much thought he had put into the solution.

The sad fact was that Skype-vs-SharePoint guy was not unique. He might have been an extreme case, but in reality, he was simply the latest in a long line of users and stakeholders who I would have previously dismissed as idiots, computer illiterate or just plain tossers. Is it any wonder why we have the scourge of “scope creep” and “vague and incomplete requirements” that are so commonly cited as project failure factors? How many times have you banged your head against the wall thinking “How can we build a system when they don’t know what they want!”?

Problem fundamentalism

So in a way, we, as solution architects, developers and consultants, are just as much at fault as those users who we chastise because they “don’t know what they want”. Why? We fail to recognise or account for the immutable fact that understanding of a problem is not cut-and-dry. It almost certainly will change over time as people mull over, work through, learn from and grapple with the nature of a problem and the complexities of the interlocking issues that form the problem. To make matters worse, we all do this *individually* and at *different speeds* with *different value sets*. Inevitably, we arrive at different conclusions based on different paths we take on making sense of it all.

That cyclical nature of understanding the problem, based on understanding the solution, does not automatically stop once the scope document has been signed off, either. It will continue over and over again as a perfectly natural part of the learning process. With that in mind, consider all of the studies that have looked into factors causing project failure (uncle google shows up many studies). All of the usual suspects are there. For example…

• Scope creep
• Incomplete requirements
• Unclear objectives
• Lack of user involvement
• Unrealistic or overly optimistic time frames
• Lack of resources

blah…blah…blah – I am sure that you have seen these before.

If you accept Rittel’s assertion that the problem and the solution are intertwined and concomitant, then it is clear that the sorts of factors listed above are merely *symptoms*, not causes. *Of course* there are incomplete requirements and scope creep. There would have to be incomplete requirements and scope creep almost by *definition* for a complex project. For a long time I had instinctively felt this way, but I couldn’t quite put my finger on it… until SharePoint-vs-Skype guy, Horst Rittel and Jeff Conklin showed me the way.

At the end of the day, it all boils down to this:

Projects fail principally because there is a lack of *shared understanding* among the participants of that project. Additionally, shared understanding is a prerequisite before the key thing that makes or breaks a project – shared commitment.

(Stunned silence … Paul hears pin drop)

I can imagine some reader comments at this point:

• “Big $%#$ deal, tell me something I don’t know”.
• “What the….you made me read through one and a half blog posts for *that*?”
• “So what theory-boy, tell me *how* to actually develop shared understanding”
• “Paul can you tell me the difference between SharePoint and Twitter?” 🙂

To be fair, I think most people know instinctively that a lack of shared understanding is the major cause of projects being comatose before they barely got off the ground. But if it was so obvious why does scope continue to creep? Why are objectives still unclear? And, why are requirements and specifications incomplete? To answer that, we need to turn the “shared understanding” assertion around and ask it in this way.

Let’s suspend reality and just assume for a minute that all participants have an *identical* deep and tacit understanding of a really complex problem. Would we still have the incomplete requirements, unclear objectives, scope creep, unrealistic time frames that are cited as project failure factors?

I say “no” from a philosophical standpoint, but a “Well, yes… but much less than what normally happens” from a pragmatic standpoint.

Thus, I started to look at my SharePoint engagements through different eyes and became what I now think should be called a “problem fundamentalist”. I began to believe that if you could achieve the utopian dream of complete shared understanding among participants at the very start of a project, then really, you could use any methodology you like to actually manage the problem and implement the solution. The common factors of project failure would fall drastically.

So finally for now, is it simply just a matter of dealing with the little question of *how* to actually achieve this goal of shared understanding?

We will talk about that in part 3…

Thanks for Reading

Paul Culmsee

This is a post or three that I have really been looking forward to writing, and it is a long time in the making for various reasons. Some of you, after reading it, will no doubt wonder if I have been taking magic mushrooms or something similar, but if the feedback from the SharePoint Best Practices conference is anything to go by, then maybe a couple of readers will have the same sense of realisation and clarity that I had.

I am going to tell you the first best practice that you should master. If you master this, all of the other best practices will fall into place. It goes beyond SharePoint too. Failure to do this, and all of your other best practices may not necessarily save you. In fact they can actually work against you. Hence the “Lord of the Rings” inspired title of this post.

Before we begin, I have to make a confession. I am not a 100% full time SharePoint consultant anymore. Don’t get me wrong. I still do, and will continue to perform a *heck* of a lot of SharePoint advisory and pick through the wreckage of many a chaotic installation. But I have worked hard to develop a new skill over the last year that has proven to be particularly powerful and profound in my SharePoint practice. The response of those SharePoint clients with whom I have used this craft has been overwhelmingly positive. The thing is though, this craft has started to take on a life of its own and now I am being called on to use it outside the SharePoint realm – despite SharePoint being the whole reason I found it in the first place.

So to explain this craft I really need to explain how I came to find it.

“I don’t know what I am delivering anymore”

Back in  late 2006, I was the infrastructure architect at a mid sized MOSS early adopter. This organisation came from a place of pretty low maturity around their document, knowledge and information management practices. As I have subsequently come to understand and recognise, many organisations coming from this place have a tendency to try to boil the ocean, via a phenomena that I previously termed the “panacea effect“. At one level, a big ambitious SharePoint platform was brilliant learning for me personally because I got to put in a multi-server farm as well as the IBM SAN storage, clustered SQL, network load balanced web front end servers, extranet config, custom authentication, publishing and just about everything in between. All in all the perfect site for the tech geek to learn the guts of SharePoint infrastructure and develop an early instinct for governance at that level.

But that wasn’t the problem area – that was actually the *tame* part of the SharePoint project. This project started to unwind pretty quickly for other reasons. Under pressure and eager to produce, the Microsoft enamoured sponsor pushed hard. Each stakeholder had *radically* different world views of what we were doing, and pinning down scope and requirements was an exercise in futility, project time estimates were crashed by more than half because they were more than the sponsors original naive estimate that went to the board of directors. The thoroughly frustrated project manager said to me one day “I don’t know what I am delivering anymore”.

CleverWorkarounds’ Hindsight Rating: Stop now – just stop now.

Around this time I decided to have a chat with some of the major stakeholders because I was really worried about this project to the point that I was thinking of resigning. It seemed that the various stakeholders never actually spoke to each other, instead using the project manager as a kind of proxy. I thought that maybe a few one-on-one, more casual meetings might break a few deadlocks and frustrations.

So, sitting in a coffee place with one particular stakeholder, I was asked the question that was the catalyst for where I am today.

“Paul, can you tell me the difference between SharePoint and Skype?”

(When I told the audience this at the Best Practice conference, I was met with disbelieving laughter. I can tell you that at the time I didn’t laugh – I was so taken aback by the question I just about choked on my double-shot latte!). 

“Well”, he explained, “I can collaborate with anybody in the world using Skype for free, and even call regular land lines very cheaply. Why should I pay half a million bucks for SharePoint to collaborate?”

CleverWorkarounds’ Hindsight Rating: Project participants can hide a lack of understanding longer than you think. Have you ever been in a meeting where you are unsure or do not feel fully informed? It is very common for people to sit quietly rather than stop and say “Sorry, I don’t understand this.”

I spent a lot of time with this stakeholder after that, and little by little I was able to get across various SharePoint basics like libraries, lists, columns and views. What happened next though was that this stakeholder started to suggest we do things that were already in the project plan (he never read it originally because he didn’t understand it). Later he gave me a records based taxonomy from a company that he used to work for in the mid nineties. It was one of those library inspired, record centric taxonomies like what I described in the document management/death metal article. He had decided that all document libraries farm-wide should use 5 common site columns – no more.

He said another thing to me around this time which was also very influential.

“We have one shot to get this right. If we get this wrong, we are going to set the company back years”.

You will understand the significance of this comment soon enough…

Off to the cave…

I think I have told enough of this story that you already know the outcome. There were other stakeholders of course with their own peculiar views of the world, and there were various things we could have done better at all levels. But fundamentally, I was dealing with a guy who’s understanding of the problem clearly changed, the more he learned and the more he thought about the collaboration problem. All of the other stakeholders went through this thought/learning process as well.

This project was something that stuck in my mind for a long time after and I was determined to never ever let this happen again. I mean, we all know SharePoint is technically complex, but the “SharePoint vs Skype” conversation for me was a watershed moment. If I were the PM, how could I have seen this coming and mitigated it early? How could we have gotten into the implementation phase for someone to ask such a question? He sat in all the meetings with everyone else and he saw the famous SharePoint pie chart like everyone else. What was wrong with our processes? Did we need to use a best-practice methodology? Did I need to learn to train people better?

It was time to go off to the metaphorical cave and meditate for a while. (Jeremy Thake once called me the theory master – now you know why).

I dug out my PMBOK books. “Maybe the PMO was implemented too rigidly or with too much dogma?” I thought. But after re-reading that stuff I still couldn’t satisfactorily reconcile the Skype question. We spent days and days developing the project management plan – it was a good plan for its time and anticipated a lot of stuff. It was clear that at least one of the stakeholders never read it beyond a basic skim or perhaps the executive summary.

So I looked at COBiT as it was supposed to be about controls and oversight. I really liked COBiT, especially the RACI charts and the maturity model. To this day I think it is one of the best designed and most elegantly constructed standards out there, but it suffers from being *so* high level and abstract that is really only useful at CIO/board level. In fact COBiT really is an umbrella that sits across all of the other ones, so by itself I think it is next to useless. Thus, it really wasn’t going to be a practical help in dealing with this problem of stakeholder understanding.

What about ISO9001? I mean, it is all about quality right? Maybe we had a quality issue? Maybe some insights were to be found there? Would a quality management plan have helped? Maybe a little bit – I mean I learned the fun you can have with the non conformance clauses. But the issue was *not* what to do once I found a quality problem. The fact that it had become a quality issue means that by definition, something went unnoticed or ignored and then caused some unwanted event to occur. Thus, I needed to recognise it much, much earlier than when it becomes a quality issue.

(ISO9001, if you have not yet read it, will cure even the most hard-core insomniac – guaranteed).

Hmmm, perhaps the answer lies in process improvement? Maybe if we used a best-practice methodology to map out and understand our processes, it would have resulted in a more optimal information architecture exercise. I had watched teams argue over process and accountabilities when we started talking to them about metadata and workflows during the information architecture sessions. So I hit the books on process improvement and business process modelling methodologies – a very crowded space with many standards and theories.

Three things popped up here. IBM’s BPMN (Business Process Modelling Notation), the process improvement methodology Six Sigma (and its variants) and a great book by Geary Rummler called “Improving Performance: How to Manage the White Space in the Organization Chart (Jossey Bass Business and Management Series)“.

I became excited as this was definitely getting closer to what I was looking for. As I read more, I saw potential. BPMN was simply a method to create consistent, easy to understand process flow diagrams and in fact, one of my colleagues has become a master at this craft. But that didn’t address the ‘art’ of process improvement. I found that often when trying to map a process with a group, the group would often start to recognise flaws or flat out disagree on how the process ran within the organisation. Inevitably, as a process mapper, you would sit back and “process debates” would take over the meeting. Clearly there was a step missing.

I also liked the emphasis on data centric decision making of Six Sigma and the emphasis on measurement. I went very low-brow and bought Six Sigma for Dummies and devoured it. As I read it, I started to remember my old high school maths because Six Sigma is very analytical and data driven. Much of what Six Sigma teaches is very, very good from a philosophical standpoint, but it did seem so “epic” and seemed to be geared around “big bang” change.

All of process improvement methodologies were process-heavy and structure-heavy. I feared that the same dogma that I had seen derail the good intentions of PMBOK would affect Six Sigma in the sorts of organisations that I had involvement with. I read a great online document later that suggested Six Sigma in real life had more of a two sigma success rate which I found unsurprising.

I also looked at Lean/Kaizen and a zillion variants. In the end I started to get lost and frustrated. Process improvement (and by association, strategy theory) is an insanely crowded place and some other time, I will write about the various fads as they have come and gone.

The Eureka Moment

Okay so I read a lot of stuff (and now have forgotten most of it). All of the methodologies and practices that I studied had some excellent parts to them, and in fact, most *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 the same sorts of “people” issues that derail the original project. The whole ‘big bang’ style approach, whether it was a software project or a best-practice methodology seemed to suffer the same sort of hit-or-miss fate.

Then in one of those times when you randomly surf wikipedia (the fountain of all authoritive knowledge 😉 ), I came across the term “Wicked problems” and the work of Horst Rittel from the early 1970’s. In Rittel’s era, he was talking about a particular class of social policy and planning problems like “What shall we do about the global financial crisis” or “What should we do about global warming”, “What should we do to solve the Palistinian issue?”. Such problems are insanely tough to solve. But as I read about the *characteristics* of a wicked problem as described by Rittel, and subsequently by his student Conklin, I realised that both were describing *exactly* my first MOSS 2007 project.

While I am not suggesting a MOSS project is a wicked problem the way that Rittel or Conklin envision it to be, those “characteristics” or “properties” of wicked problems were so applicable to my experience that is was scary.

Phew!

Since I have been waffling on far too long, I’ll stop things now, and in the next post, I will delve into wicked problems in more detail, both Rittel and Conklin’s definitions, as well as my own definition, that I used at my Best Practices SharePoint Conference session.

• The one best practice to rule them all – Part 2
• The one best practice to rule them all – Part 3
• The one best practice to rule them all – Part 4
• The one best practice to rule them all – Part 5
• The one best practice to rule them all – Part 6

Thanks for reading

Paul Culmsee

Hi all. I’ve just posted my Best Practices Conference slide deck for the Wicked Problems session, along with the maps that I used during the demonstration. Expect a typically long post really soon now, to delve into much more detail about all of this 🙂

For what it’s worth the conversion to slideshare was a bit wonky, so just contact me if you want a pptx version.

Iframe below too small? Then go here for the demo issue maps

[iframe /BPCMaps/Best_Practices_Share_192168511229769555699.html 800 600]

To quote the brilliant singer Kate Bush, "wow wow wow unbelievable!"

Well, it is all over, and boy what an experience! For those of you who were not aware, I had the honour of attending as well as presenting at the San Diego SharePoint Best Practices conference. I had two topics, but I’ll post a report about those in another post. This post is going to sound like one of those long acceptance speeches at the academy awards as I have to give out kudos’ to all the people who I hung out with.

I sat in on as many sessions as I could, particularly the ones around requirements gathering, information architecture and strategy. It was fascinating that each person who spoke on or around this topic, such as Paul Galvin, Ruven Gotz, myself and Peter, all had varying approaches and I learned something from all of them. Some amazing talent – truly brilliant minds, wonderful speakers and great topics.

Some of the speakers – guys like Robert Bogue and Evan Burfield (above) just leave me in awe. There is not a damn thing that they say that I disagree with. Pretty much any good idea that I have had, Rob has thought of it first and developed it far, far further than I ever have. Just wait until you see his upcoming governance DVD – I’ve seen the mind map and holy freakin’ crap!, the length and breadth of what he has put together will make it an absolute *must have*. I had been working on similar material, but after seeing how far he has taken it, trust me and just buy his DVD – I’m hoping to be a reseller :-). Forget "Sharepoint Shepherd", I humbly bow to the "Governance Godfather – Robert Bogue" (you can license that title from me Rob 🙂 )

Also Rob, if you are reading this I went looking for you at SharePint to jump on your lap and do a fanboy photo (and I was going to risk messing with your hair). Lucky for you I guess, you had left by then and my evil plan was foiled – but Joel wasn’t so lucky 🙂

Mr Oleson – what can I say? I owe him a heck of a lot, as if it wasn’t for him I wouldn’t have been a presenter at this conference. Joel mate, you were on the phone when I came to say my heartfelt thanks for vouching for me and making this happen. I never crossed your path after that and I feel bad that I never got to. I’m going to get the SharePint photos from Ruven, although Joel, I am sure that your legal people will send me a cease and desist letter for that fanboy photo that I took with you. Mind you, I think there are other photos that you should be more worried about! But hey, what happens on tour, stays on tour right? 🙂

Ben Curry from Mindsharp – you I owe the biggest thanks of all. Conceiver of it all and the heart and soul behind this event. Visionary guy, worked his arse off, willing to risk bringing in several untried and untested relative unknowns like myself. He nailed *exactly* how a best-practice conference needs to be. Although sessions and topics were technical or development centric at times, make no mistake. This was all about headspace and critical thinking, so I was like a kid lost in a candy store.

Gary Lapointe is another person who left a big impression on me. I am well aware of his awesome capabilities and I found him a really down to earth, genuine and humble guy and I really, really wanted to have a beer with and chat to some more. I am totally buying you beers next time.

Paul Galvin. Spent the whole conference saying hello but never really crossing paths properly until the last hour or so. Loved your presentation and enjoyed your insights, regret not having more time to download your brain.

I also enjoyed hanging out with the poms, who seem to deal with satirical aussie humour a little better than the Americans. Andrew Woodward, Phill Duffy, Brett Lonsdale all were great company and good fun. Brett – I look forward to doing good things with Lightningtools and Combined Knowledge.

Then there were the metalheads. Todd Klindt was a riot and its obvious that he was put on this earth to loiter around SharePoint conferences. He had everyone near him in complete stitches. I was not aware of his metal leanings which raised his stock big-time in my book. Therefore, I have made it my personal mission to convert him to Opeth. Todd is actually a bit of a wuss when it comes to the the death vocals, so it’s a little like a Microsoft guy saying they like Linux but have never used anything but Ubuntu. But rest assured, I think I can bring him around 🙂

Also Mike Watson and attendees Anders Rask and Paul Kolasky demonstrated their exquisite taste in music. When pontificating various aspects of SharePoint became tiresome, the conversation seemed to turn to metal music. It’s amazing how much creativity can come out of a conversation like that too. After a few beers, Anders, Mike and I had a great idea for a new educational SharePoint site, and I still kinda liked it in the cold light of day when I was sober again. But I haven’t asked the other two whether they still think its a good idea or whether it was just the beer talking.

But fun and frivolity aside, what was the most satisfying (and exciting) was those moments where you discover your kindred spirits – both speakers and attendees. People who think alike, who’s philosophies and outlook are absolutely aligned in the same "zone" as your own. They may address problems in different ways, and may even be in different SharePoint sub-disciplines. But you just *know* that there is something special there – it is like you all collectively "see" though the same eyes, and the whole is so much greater than the sum of the parts.

So to Ruven Gotz and Peter Serzo, it was an honour to be able to meet with you, watch your presentations and I valued the dialogue very much. Ruven for the record had the best impromptu one-liner of the entire conference. When an audience member suggested an alternative software package to what he used, he replied by saying he’d been married to his wife for 27 years and he was pretty happy with her as well – had the audience in stitches. Peter Serzo dragged a freakin’ piano from the lobby to his session room at 2am and spent another hour practicing. Then the next day he presented half of his conference seated at the piano playing various ditties. Brilliant stuff.

Both of your presentations set off all sorts of light globes in my head, and set the creative juices flowing. I really believe there is the nucleus of something special there and I feel some future collaboration in the very near future.  Andrew Woodward will definitely be a part of it (although he doesn’t know it yet – hehe).

So, who knows? If the feedback from my sessions is good, I might manage to wrangle an appearance at the UK one?

Hi all

I have been extremely quiet on the blogging front lately, because I have been extremely busy, splitting my time between working on my two presentations for the up-coming Best Practices SharePoint Conference, as well as wearing my undies on the outside (ala superman), deep in the bowels of some unhealthy SharePoint farms, nailing various technical and governance issues and helping organisations regain some lost assurance. On top of that, I’ve also been doing a lot of non IT related work in a group facilitation discipline.

I thought it’s about time I emerged from this big mushroom I find myself under to let you know more about what I will be speaking about, as well as some of the other speakers and topics that I really looking forward to. Seriously, we are in the company of giants with this conference. The caliber and quality of the speakers has me wondering what the hell I am doing there!

I mean we have all the "A list" big kids of the SharePoint world there. Gary Lapointe is a freakin’ bona fide superstar! – via his STSADM extensions, he has saved the asses of more SharePoint admins and developers than even Joel has. Robert Bogue is an even better all-rounder than Andrew Symonds (sorry non cricketing countries you won’t get that analogy) and touches on a wider variety of topics than anyone else I have ever come across. Then there the likes of Andrew Woodward, Ben Curry, Bob Mixon, Eric Shupps, fellow metalhead Mike Watson, Ruven Gotz and Todd Bleeker just to name a few!

Somehow I have to squeeze in a beer with all of them yet stay sober enough to present. That’s a tough ask!

Anyway, both of my sessions are in the CIO stream and I think are rather topical given the current financial crisis crap that is happening around the world.

My first session is called "How to avoid SharePoint becoming a wicked problem". This is a pet topic of mine – something that I have spent a lot of time on, and developing new skills in (hence the aforementioned facilitation work). For the record, I didn’t make up the term "wicked problem" – its been a subject of academic research since the term was first coined in the early 1970’s. This session is going to cover a lot of what I have learned on this topic including how to spot SharePoint wickedness early, recognise it for what it is, and apply the *right* sort of tools and techniques to mitigate it.

I do worry that people will find some of my stuff a little too left field, but I do have the results to attest to the value and power of these techniques and I am really looking forward to sharing my methods and comparing with what has worked for other presenters and attendees.

The second topic is on the topic of good old SharePoint Return on Investment (ROI). I’m one of these people that believe most things can be measured or quantified. I’ve always wanted to return to my series on "How to Speak to your CFO" and continue down that road. Given we have entered once in a lifetime era of falling profit, plummeting asset prices, reduced budgets, costlier finance and great uncertainty, my quest for bringing a lasting peace to the cold war between managers and geeks moves to San Diego 🙂

My aim for this session is to allow non SharePoint people to understand where some of the hidden costs are SharePoint, as well as show SharePoint people the basic financial tools for ROI modelling and secondly, I will explain how to build an ROI decision model and provide a scenario that we will try out some different assumptions with.

As for the rest of the veritable *buffet* of topics – where do you start? First up, I am torn between Bill’s "Aligning your Information and Findability Architectures using SharePoint Server 2007 Technologies" and Yoda Bogue’s "Selling Governance in your Organization". If I go to Bill’s session, then I’ll definitely be attending Robert’s Governing Development in SharePoint session.

In the afternoon, it gets even harder! You have "Transform the My Site into an Information Hub" by Mark Eichenberger, Bob Mixon’s "Learn why Taxonomies are the Most Important Part of any Document or Information Asset Management System, How to Facilitate the Government out of Governance by Virgin Carrol and Nuts and Bolts Governance- Practical Application of the Concepts

.. and that’s just day one!

Seriously people, no matter that sort of SharePoint sub disciplines push your buttons, you are going to get extreme value for money here. You will come away with an amazing amount of material that will result in real and tangible cost savings across various areas of the SharePoint realm.

If you live in California or anywhere in the US – there is no excuse 🙂 If *I* have to spend 25+ hours cooped up in  plane just to get there and survive the jet-lag to present, then you should come on down and join the fun.

Hope to see you there!

Paul Culmsee

This project was not SharePoint, but I have seen some people try and do this with SharePoint. But you can imagine how much stress this project would have caused to participants.

The South Australian government has pulled the plug on its $5 million records management system project, ending a five-year saga plagued by repeated cost blowouts, delays and confusion

http://www.australianit.news.com.au/story/0,24897,24510560-15306,00.html

I can’t help but feel that if this particularly wise and insightful document written by their federal government counterparts had been written a couple of years earlier, some of sting just might have been taken out of this example of expensive project failure.

Many of the most pressing policy challenges for the APS involve dealing with very complex problems. These problems share a range of characteristics—they go beyond the capacity of any one organisation to understand and respond to, and there is often disagreement about the causes of the problems and the best way to tackle them. These complex policy problems are sometimes called ‘wicked’ problems

Critically, tackling wicked problems also calls for high levels of systems thinking. This big picture thinking helps policy makers to make the connections between the multiple causes and interdependencies of wicked problems that are necessary in order to avoid a narrow approach and the artificial taming of wicked problems

Read the full document here:

http://www.apsc.gov.au/publications07/wickedproblems.htm

(Nerds are going to find this post dead boring).

Before I start, let me state that I am a believer in the Honey and Mumford theory of learning styles, as well as the Marston DISC assessment. I think both are closely related, and go some way to explaining many mysteries of the world like – "Why are there Metrosexuals?", "Why doesn’t everyone listen to Opeth?" and most importantly of all "What goes on in the strange world that is the engineer mind"?

"Engineer mind"?

Don’t bother googling that term because I made my own definition. I’m really referring to tech nerds generally, but the definition actually extends beyond nerds to a certain type of personality that tends to be a combination of an Activist learning style with a Steady/Conscientious DISC profile.

The point is that engineer minded people live in a factual world. Questions are factual and answers are usually pretty absolute. An engineer’s dogma also has a way to make facts more ‘factual’ in their eyes as well.

For a chunk of the rest of humanity, factual questions are not quite that factual. In many contexts, particularly political ones, a factual question is often open to more liberal interpretation.

This is in essence why engineers dress badly and sales people commonly exhibit metrosexual tendencies. 🙂

Continue reading “It’s all in the way you ask the question…”

Hi

Well, here we are at part 8 in a series of posts dedicated to the topic of SharePoint project failure. Surely after 7 posts, you would think that we are exhausting the various factors that can have a negative influence on time, budget and SharePoint deliverables? Alas no! My urge to peel back this onion continues unabated and thus I present one final post in this series.

Now if I had my time again, I would definitely re-order these posts, because this topic area is back in the realm of project management. But not to worry. I’ll probably do a ‘reloaded’ version of this series at some point in the future or make an ebook that is more detailed and more coherently written, along with contributions from friends.

In the remote chance that you are hitting this article first up, it is actually 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 subsequently examined some of the notable historical references to wicked problems in IT. From there, we turned our attention to SharePoint specifically and why it, as a product, can be a wicked problem. We looked at the product from viewpoints, specifically, project managers, IT infrastructure architects and application developers.

In the last article, we once again drifted away from SharePoint directly and looked at senior management and project sponsors contribution. Almost by definition, when looking at the senior management level, it makes no sense to be product specific, since at this level it is always about business strategy.

In this post, I’d like to examine when best practice frameworks, the intent of which is to reduce risk of project failure, actually have the opposite effect. We will look at why this is the case in some detail.

CleverWorkarounds tequila shot rating..

    For readers with a passing interest in best practice frameworks and project management.

For nerds who swear they will never leave the "tech stuff."

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

Hi all

Welcome to the 7th post on this series delving into the murky depths of SharePoint project failure. I’m sure that even if you haven’t used SharePoint, or been involved in a SharePoint project, most will have experiences of being sore and sorry from a project gone bad and the content presented in this series thus far has been somewhat familiar.

Speaking of sore and sorry, I am writing this post days after buying the kids a Nintendo Wii. I’m not a geek-toy kind of guy, so I’m usually a little behind when it comes to consumer gadgets, but what a brilliant product it is. I am completely addicted to Wii Sports (especially the tennis and baseball), but after two days, I am feeling muscle ache like I have never felt before. I can barely move!

So I’d better stop playing that damn game and get back to business. In the unlikely event that you are hitting article seven for 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 wonderful land of chocolate where projects never fail.

More recently, we targeted the infrastructure and development geeks in posts five and six. Now it’s time to cast our lens over the guys who control the budgets and get paid way more than you and I. So of course it is the project sponsor and senior management in general 🙂

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