I have been reading a bunch of material about sense-making. Most of online at various websites (that shall remain nameless), written by people who are scary smart. Essentially I always am looking for stuff that might augment Dialogue Mapping and improve my facilitation and analytical skills. I am in the middle of an online article that has been a bit of a struggle, so I stopped to write this quick post.

Some of the stuff that I have been reading is really good – brilliant in fact, but sadly, no-one will ever know. The great sad irony is that sense-making tools and methods are there to help a group improve their shared understanding. Yet the papers and articles that I read are so damn dry, written in a pontificatory, academic style that I, as someone who works in this area, really struggles to maintain focus after the first page. The stuff I have read offers some truly innovative methods of improving the lot of a group or team trying to deal with difficult issues. But sadly, they are destined to be ignored or remain on the fringes while practitioners persist in writing in such an inaccessible style.

I get the whole peer-reviewed thing and I think the rigour behind many of the content is exemplary. But surely, if you are creating frameworks, tools or methods to help people understand difficult issues, how is that supposed to be achieved if the explanations put that very audience to sleep?

Now excuse me while I load up with a double shot coffee so I can get through rest of the website article that I am reading…

Paul Culmsee

www.sevensigma.com.au

Hi all

If you were going to slot me into a little stereotype box, then you would slot me into the “IT pro” side of the fence. My coding is okay, but my real vein of expertise lay in infrastructure and over my career, I developed what I think is a reasonable troubleshooting instinct.

I’ve also worked with developers for the whole of my career and have the scars to prove it. The thing about developers is that they have this in-built reflex that until yesterday I did not have a word for. Then it came to me.

All developers have a little Russell Crowe inside of them!

Why do I think this? Am I suggesting that developers are handsome, rugged types who melt your heart with their piercing eyes?  Oh, please. Allow me to explain with a simple mythical conversation with Mr Crowe. Let’s pretend you are a movie director.

You: “Hey Russell, we need to do another take, your dialogue wasn’t quite right.”

Russell: “Yes it was.”

You: “No seriously, I think if you had a look you’ll find that you missed a word or two.”

Russell: “Completely impossible. You are obviously an amateur and have no idea about acting.”

You: “I’ve directed twenty films and…”

BAM!!!  (Flying telephone hits you in the head at high speed, knocking you unconscious.)

Russell: (2 days later). Okay, so there was a minor issue with my dialogue, but the script was bad to begin with”

This exchange is somewhat representative of how programmers can occasionally be when it comes to troubleshooting. I remember one case where I was the “Cisco guy” who had problems with a developer who was so utterly fixated on “the network” being the cause of problems with his media streaming application. This created the classic “dev vs infrastructure guy” showdown, which we all know is usually won by the person whose home turf the battle is fought on. Therefore, the developer blaming “the network” and then going up against the “Cisco guy” is like Microsoft trying to win search market share off Google. The battle is so one sided it’s almost cruel to participate – but you feel it is your duty to put the little upstarts in their place anyway.

I have won the majority of such battles, not because I am any good, but because the developers have thrown the metaphorical phone at me before I’ve finished asking them if they would like a coffee. As a result of their inner Russell Crowe hurling the phone so quickly, their aim is way off, and the phone usually misses me, bounces off the wall and takes out their boss or some other authoritative figure.

So, they cop some heat and sulk in the corner for awhile, but do developers learn from this? Hell, no! The reason why this is so, is because little Russell doesn’t like to lose, and when he re-emerges, he causes temporary amnesia of all previous battles. Of course, his opponent remembers all, and the next battle is even more cruel that the previous one and the outcome is assured.

So, yesterday, my friend and colleague did his first “Russell Crowe” for some time. He hit a problem, and misinterpreted the cause and went down a path that led him to a very tunnel-vision view of what was wrong and what the solution was. He described the problem he was having to me and it didn’t feel “right”, but he was pretty insistent he was on the right path. So, I asked Twitter and got back a couple of suggestions and as soon as I put one to him… BAM!! Russell Crowe appeared and threw a phone at me.

“Well, they are obviously amateurs and haven’t a clue about the SharePoint SDK” was the gist of the response.

One of the respondents was Bjorn Furuknap, who I can assure you is *not* an amateur :-).

Anyway a few minutes later we found a different way to troubleshoot which pretty quickly pinpointed the problem. My colleague was very contrite and good natured about it as I teased him mercilessly. I later mentioned to Bjorn that I had just dodged a metaphorical flying phone and he said this wonderful quote which I think sums it up.

“Of course. He’s a developer. We’re all like that. It is always some else’s fault!”

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

Not so long ago I wrote about the adventures of Governance Man and Dr Wicked. I also mentioned that there was another partner in crime. Agile Boy. Here he is in-between fighting SharePoint chaos and participating in SharePint’s!

• Name: Agile Boy
• Secret Identify: Andrew Woodward
• Special Powers: Extreme agility, TDD guruness, MVP
• Weakness: Beer and Waterfalls
• Catch-Phrase: “Beat futility with Agility!” 

Often people use metaphors to describe various aspects of SharePoint. I am guilty as charged here. One of the many that I use for SharePoint, is the metaphor of an Ikea modular storage solution to describe the new paradigm of moving from folders to document libraries, columns, views, workflow, sites, content types and the like.

But, I see a very common mistake with a lot of SharePoint metaphors that you must be careful with. People use tame metaphors for SharePoint, and this misleads.

Confused? Well consider this. There are two main types of problems in this world. Tame problems and wicked problems.

This is what a tame problem looks like according to Conklin.

• A tame problem has a relatively well-defined and stable problem statement.
• A tame problem has a definite stopping point, i.e. we know when the solution or a solution is reached.
• A tame problem has a solution which can be objectively evaluated as being right or wrong.
• A tame problem belongs to a class of similar problems which can be solved in a similar manner.
• A tame problem has solutions which can be tried and abandoned.

A wicked problem on the other hand looks a little different.

• A wicked problem is not understood until after formulation of a solution.
• Stakeholders have radically different world views and different frames for understanding a wicked problem.
• A wicked problem can be explained in different ways
• A wicked problem is always considered a symptom of another problem. 
• Constraints and resources to solve the problem change over time.
• The problem is never solved.

Yeah, I know – it’s a rhetorical question, but which category do you think many SharePoint projects fall under? 🙂

Wicked metaphors

So, just like problems, there are two types of metaphors in the world too, tame ones and wicked ones.

The reason that my Ikea metaphor works has nothing to do with Ikea itself. The point I am  making is that even with the most spectacular modular Ikea storage solution, installing it is not that hard. I mean, if you read the instructions and take your time it can be done. Even if you rush, you might have a few scratches and hit your thumb with the hammer a few times, but you will get it installed. Even so, many prefer to get an Ikea guy to come in and do it.

But, here is the rub – the Ikea guy can’t help you agree with your dysfunctional family about whose underpants should go where. Guess what – *that* is the wicked bit! Wickedness has little to do with the Ikea furniture itself. It is all about the social complexity of those who have to work with it together.

So, be careful if you say something like “SharePoint is like building a house, you need to lay the foundations first…” Why? Remember that building a house is actually a very tame problem. People do them all the time and we pretty much follow the same script. Many collaborative solutions are not tame in this way. Therefore, this metaphor misleads and is completely inappropriate.

In fact, if you wanted a more accurate house metaphor, you need to add the social complexity and organisational chaos element to it. In my version, it is still a house building exercise, but this time you are the foreman and the construction crew consists of your mother in law, Homer Simpson, Eric Cartman, Tom Cruise and Paris Hilton.

I pity the project manager who has to deal with that combination of personalities!

Thanks for reading!

Paul Culmsee

www.cleverworkarounds.com

I am kind of in a “not in the mood to write” mode, but I thought that this video of my little boy rocking out to the metal band Amorphis needed a wider audience. His musical taste is very good actually, likes System of a Down, Faith No More, Opeth, Metallica and the Wiggles 🙂

Like all 3 year old boys, he is completely obsessed with Thomas the Tank Engine, and in the middle of rocking out, he spots a train. As you will see, trains trump metal 🙂

Enjoy – what a proud father I am!

At the San Diego Best Practices SharePoint conference, I sat quietly and listened to the governance godfather himself, Robert Bogue, discussing with the other SharePoint "big kids" various reasons why InfoPath sucks in many situations and some of its current design faults. I mean, anybody who has used forms services knows what a pain redeployment is, how much of a pain managed code is, the horrible performance of web services, branding crap and the like. Thus, all were perfectly valid points.

But irrespective of how correct those points are, I’d like to categorically state why InfoPath 2007 and Forms Services are the best pieces of technology that Microsoft has ever invented.

The simple reason is this.

My wife likes it!

To fully explain the implications of why InfoPath rocks, I have created an IBIS issue map that makes the argumentation quite clear.

I rest my case.

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

Ah – this is exactly my sense of humour. My colleague Mike Stringfellow wrote a post called "Code Monkey Hates SharePoint" where he presents a quick multi-choice questionnaire of seemingly innocent questions that allows you to determine how predisposed your code-monkey is to completely butchering your SharePoint environment. Apparently there is not much difference between "the ideal SharePoint developer" and a serial killer 🙂

Good stuff – you can check it out here

A quick observation: Jeremy wrote a good post on the ins and outs of jQuery as a SharePoint band-aid. Having done a little messing with JavaScript (under duress) I had a peek at his well thought out post. After reading it however, I came away thinking that jQuery was more like blu-tack than a band-aid. I’m not sure why I felt this, but after reading the blu-tack article on wikipedia, I knew I was right.

I am now going to substitite "blu-tack" with "jQuery" and quote directly from wikipedia.

jQuery is a versatile, reusable putty-like pressure based adhesive

Check: When the project manager is breathing down your neck to "get that $%^%$ site out now", you can throw in some jQuery in a content editor web part and avoid writing anything server side.

But the clincher argument for me was this one…

jQuery can leave an oily stain on paper materials if attached for a long period of time.

Hehe! Although band-aids can hurt a lot when they come off, I think the oily stain metaphor is better 🙂

Hi all

I’ve read a few blogs on site definitions vs site templates and reading some development centric articles, particularly the alternative presented by Raymond, and expanded by Mike and summarised neatly by Chris. Being a part time developer, I found that the explanation were a little…shall we say… geeky and I had to expend far too many brain cells.

So to assist the rest of the SharePoint community who are not developers, I am going to attempt to explain the whole sorry debate to you using a more suitable analogy – boy bands. That way you do not have to worry about developer-speak.

Boy-band "definition"

There are several mandatory characteristics of being a boy band.

1. All have to be pretty-boys
   One is permitted to be tough in a non threatening way
   One is sensitive
2. There must be 5 members
3. All must be able to dance
4. Playing a musical instrument is not permitted
5. Clothes are always the latest fashion
6. Members do not write their own songs
7. Must do exactly what the record company tells them

When you create a new boy-band, you audition a bunch of hopefuls, using this core set-up and then just give them a nice radio friendly name.

Now, it really doesn’t matter which band it is, this is the formula that is followed by record producers with staggering success. But there is a catch! Change any of these parameters and the whole thing falls apart. For example, if we replace the non-threatening tough guy with a fat kid who can’t dance, teenage girls will rebel and the band will have to break up. It makes no difference which boy-band we are taking about either. You have broken the fundamental structure of how they work and the whole thing will disintegrate.

This, my friends, is a *site definition*.

Also – this is very important to note. The "boy-band" definition is an out-of-the box definition. In other words, no matter what environment that you are operating in, you will always find that the boy-band definition is there.

Boy-band templates

However, just because you have to follow this definition doesn’t mean you can’t make some changes here and there. For example, you can safely change a boy-band’s musical style from pop to light opera and "New Kids On the Block" effectively turns into "Il Divo". If "Il Divo" turns out to be popular among the user population, then the record company will want to produce more operatic boy bands. If we could take "Il Divo" and somehow save them as a template, then we can create new operatic boy-bands quickly and easily.

But the core fact remains that if you modify the original boy-band definition, this new template will crash and burn as well.

"Operatic boy-bands" and "Pop boy-bands" are therefore examples of "site templates".

Both bands are based on the underlying "boy-band" definition and as a result, cannot exist independently without that definition. So what if we want to use the "Operatic boy-band" template in another location?

Not a problem, because as I described earlier, the boy-band definition is out of the box in all locations, and therefore the templates will always be able to be used in other locations.

Unfortunately, sometimes there are limitations with boy-band templates. The bands themselves have "grown" and now realise the original *definition* they have based their template on is too restrictive and will not scale with their future "artistic requirements". There is only so much that you can do when tweaking the more limited options provided by the template model. But since they are based on the underlying boy-band definition, then we are stuck.

New Kids On The block are a great case in point. In 1994, when they released their 4th studio album, they attempted to write their own songs to the detriment of their boy-band career. As we now know that violates rule 6 of the boy-band site definition and as expected, the group split up shortly after.

New site definitions and portability

So let’s just say that we want to make the first ever "hybrid death-metal boy band". We know that we cannot do this with a template alone because it will violate the boy-band definition and the world will explode. So we have to make up a new definition to accommodate this unique requirement. Suddenly we are faced with a lot more complexity here. Instead of just re-using a template we have to come up with a brand new definition and this requires specialised expertise. We already know that once we have made up our new definition that it can never be changed, so we had better make sure that we have it right the first time.

Now, let’s say that we create our first death-metal boy band called "New Kids on the Cannibal Corpse" and launch them in Sweden – where all the good metal bands come from. We create our new definition and then set up a new record label, hire PR guys, roadies, stylists, personal assistants and it all goes terrific. Sweden loves this new music sensation. But then when they try and break into the UK scene, it fails miserably. Why? Because we don’t have a record label there. They do not know how to properly deal with a new band based on this hybrid death-metal boy band definition because they have never seen this definition before.

This is one of the problems with making up new site definitions. Since it is not out of the box, if you try and move "New Kids on the Cannibal Corpse" to a new operating environment such as the UK, the definition is missing and therefore they have no idea how to handle it. This creates a dependency issue. Before "New Kids on the Cannibal Corpse" can be launched in the UK, we have to set up the "hybrid death-metal boy band" definition there *first*. Contrast this to "Il Divo" which can tour anywhere because the "boy band" definition is out of the box and therefore already set up by default at all locations.

Future Directions

Musical tastes change over time. Fads come and go, and alas, even boy-bands go out of favour. To achieve real longevity, all bands have to occasionally reinvent themselves – in effect go through a complete upgrade process and emerge as something completely new. The one advantage that boy bands have is that their popularity among teenyboppers means that the record industry will provide assistance to help them emerge as something new.

Unfortunately, the same cannot be said with our poor hybrid death-metal boy band, who, being a custom designed product, will have no guarantees that the record company will help them reinvent.

Therefore, there are disadvantages to a custom band definition. Future upgrades are tougher. But if you have managed to remain on the boy-band definition, despite working with the reduced flexibility of being a customised template, you should be able to upgrade to a newer version with much less pain.

This is important because although you might have more flexibility when freed from the confines of a boy-band definition, you pay for it with future upgrade uncertainty.

Conclusion

So now you should be full-bottle on the difference between site definitions and site templates. So, which one should you use? At the end of the day, it depends on whether you want to be a one-hit-wonder or achieve long term staying power. However, remember the most important thing above all else…

Under no circumstances should you *ever* listen to boy-bands!

Thanks for reading

Paul Culmsee

I’ve always avoided too many pictures of myself online – I think its the little security person that sits on my left shoulder and says "privacy privacy", usually louder than the little marketing person on my right saying "go on you handsome devil!"

I was only just coming to grips with the guys at the Best Practices SharePoint Conference putting up a small thumbnail and then Arno Nel goes and puts a large one on an interview I just did for SharePoint Magazine. Damn!, I forgot to turn my collar up and put some product in my hair – where is Jeremy Thake when you need him! 🙂