Now I am writing this at 8am and around 10pm last night I recorded this vid with him and now it has photos, montage and credits. I don’t think he slept.

The story behind this goes back a bit. When Dux first told me he was going to do a rap – I think 2 years ago or more at a Best Practices Conference – and showed me the lyrics to “SharePoint is Nice Nice Baby”, I thought “no that will never work because its framed too nicely”. (Of course I was completely wrong and Dux stole the show and continues to do so. )

Anyway, to me Mad World (the Gary Jule version) seemed the perfect song for SharePoint because it gave me the right sort of subtlety to work with my cynical sense of humour. Much of the lyrics were done years back and I sent them to Ruven Gotz and Peter Serzo who both sent back some mods. Somehow by chance the subject came up again in Wellington New Zealand with Christian Buckley. Christian happens to be a great singer who has been in bands in his past. Our hotel lobby had an old piano so the scene was set.  A bit of Lennon/McCartney-esque collaboration (Culmsee/Buckley of course) on lyrics and we were ready to go.

We did one take, with Mark Miller providing magnificent cinematography (the flowers fade in and fade out was sheer gold)

In case you are interested, here are the full lyrics as far as I remember them… enjoy!

All around me are new interfaces

Shared workspaces, my-site places

Run by admins who can’t tie their laces

Page loads snail pace, backups no trace

 

Out of box is just so boring, i think its kind of sad

My dreams of coding c-sharp are the best I ever had

I find it hard to tell you, the root hive’s really toast

When coders put in SharePoint its a really really

Mad world, Mad World

 

Metrosexuals try to make it facebook

Where’s my hairspray? where’s my hairspray?

Using designer to create a workflow

No-one follows, no-one follows

 

Out of box is just so boring, i think its kind of sad

My dreams of coding c-sharp are the best I’ve ever had

I find it hard to tell you, the root hive’s really toast

When coders put in SharePoint its a really really

Mad world, Mad World

 

Content database is like Godzilla

8 hour backups, 8 hour backups

Mess with settings inside web.config

Where’s my homepage? where’s my homepage?

 

Out of box is just so boring, i think its kind of sad

Code monkeys blame their admins but their memory leaks suck bad

I find it hard to tell you, the sequel’s out of space

When tech-geeks put in SharePoint its a very very

Mad world, MOSS world

                      

No Tags

So here is my attempt to explain what Monte Carlo is all about and why it is so useful.

I have previously stated, that vaguely right is better than precisely wrong. If someone asks me to make an estimate on something, I offer them a ranged estimate, based on my level of certainty. Thus for example, if you asked me to guess how many beers per day Charlie Sheen has been knocking back lately, I might offer you an estimate of somewhere between 20 and 50 pints. I am not sure of the exact number (and besides, it would vary on a daily basis anyway) , so I would rather give you a range that I feel relatively confident with, than a single answer that is likely to be completely off base.

Similarly, if you asked me how much a SharePoint project to “improve collaboration” would cost, I would do a similar thing. The difference between SharePoint success and Charlie Sheen’s ability to keep a TV show afloat is that with SharePoint, there are more variables to consider. For example, I would have to make ranged estimates for the cost of:

• Hardware and licensing
• Solution envisioning and business analysis
• Application development
• Implementation
• Training and user engagement

Now here is the problem. A CFO or similar cheque signer wants certainty. Thus, if you give them a list of ranged estimates, they are not going to be overly happy about it. For a start, any return on investment analysis is by definition, going to have to pick a single value from each of your estimates to “run the numbers”. Therefore if we used the lower estimate (and therefore lower cost) for each variable, we would inevitably get a great return on investment. If we used the upper limit to each range, we are going to get a much costlier project.

So how to we reconcile this level of uncertainty?

Easy! Simply run the numbers lots and lots (and lots) of times – say, 100,000 times, picking random values from each variable that goes into the estimate. Count the number of times that your simulation is a positive ROI compared to a negative one. Blammo – that’s Monte Carlo in a nutshell. It is worth noting that in my example, we are assuming that all values between the upper and lower limits are equally likely. Technically this is called a uniform distribution – but we will get to the distribution thing in a minute.

As a very crappy, yet simple example, imagine that if SharePoint costs over $250,000 it will be considered a failure. Below are our ranged estimates for the main cost areas:

If you add up my lower estimates we get a total of $140,000 – well within our $250,000 limit. However if my upper estimates turn out to be true we blow out to $435,000 – ouch!

So why don’t we pick a random value from each item, add them up, and then repeat the exercise 100,000 times. Below I have shown 5 of 100,000 simulations.

So according to this basic simulation, only 2 out of 5 shown are below $250,000 and therefore a success according to my ROI criteria. Therefore we were successful only only 40% of the time (2/5 = .4). By that measure, this is a risky project (and we haven’t taken into account discounting for risk either).

“Thats it?”, I hear you say? Essentially yes. All we are doing is running the numbers over and over again and then looking at the patterns that emerge from this. But that is not the key bit to understand. Instead, the most important thing to understand with Monte Carlo properly is to understand probability distributions. This is the bit that people mess up on and the bit that people are far too quick to jump into mathematical formulae.

But random is not necessarily random

Let’s use Charlie Sheen again to understand probability distributions. If we were to consider the amount of crack he smokes on a daily basis, we could conclude it is between 0 grams  and 120 grams. The 120g upper limit is based on what Charlie Sheen could realistically tolerate (which is probably three times the amount of normal humans). If we plotted this over time, it might look like the example below (which is the last 31 days):

So to make a best guess at the amount he smokes tomorrow, should we pick random values between 0 and 120 grams?  I would say not. Based on observing the chart above, you would be likely to choose values from the upper end of the range scale (lately he has really been hitting things hard and we all know what happens when he hangs with starlets from the adult entertainment industry).

That’s the trick to understanding a probability distribution. If we simply chose a random value it would likely not be representative of the recent range of values. We still have to pick a value from a range of possibilities, but some values are more likely than others. We are not truly picking random values at all.

The most common probability distribution people use is the old bell curve – you probably saw it in high school. For many variables that go into a monte carlo, it is a perfectly fine distribution. For example, the average height of a human male may be 5 foot 6. Some people will be larger and some will be smaller, but you would find that there would be more people closer to this mid-point than far away from it, hence the bell shape.

Let’s see what Charlie Sheen’s distribution looks like. Since we have our range of values, for each days amount of crack usage, let’s divide up crack usage into ranges of grams and see how much Charlie has consumed. The figure is below:

As you can see, according to the 50% of the time Charlie was not hitting the white stuff particularly hard. There 16 occurrences where Charlie ingested less than 10 grams. What sort of curve does this make? The picture below illustrates it.

Interesting huh? If we chose random numbers according to this probability distribution, chances are that 50% of the time, we would get a value between 0 and 10 grams of crack being smoked or shovelled up his nasal passages. Yet when we look at the trend of the last 10 days, one could reasonably expect that its likely that tomorrows value would be significantly higher than zero. In fact there were no occurrences at all of less than 10 grams in a single day in the last 10 days.

Now let’s change the date range, and instead look at Charlie’s last 9 days of crack usage. This time the distribution looks a bit more realistic based on recent trends. Since he has not been well behaved lately, there were no days at all where his crack usage was less than 10 grams. In fact 4 of the 9 occurrences were over 60 grams.

This time, utilising a different set of reference points (9 days instead of 31), we get very different “randomness”. This gets to one of the big problems with probability distributions which Kailash tells me is called the Reference class problem. How can you pick a representative sample? In some situations completely random might actually be much better than a poorly chosen distribution.

Back to SharePoint…

So imagine that you have been asked to estimate SharePoint costs and you only have vague, ranged estimates. Lets also assume that for each of the variables that need to be assigned an estimate, you have some idea of their distribution. For example if you decide that SharePoint hardware and licensing really could be utterly random between $50000-$60000 then pick a truly random value (a uniform distribution) from the range with each iteration of the simulation. But if you decide that its much more likely to come in at $55000 than it is $50000, then your “random” choice will be closer to the middle of the range more often than not – a normal distribution.

So the moral of the story? Think about the sort of distribution that each variable uses. It’s not always a bell curve. its also not completely random either. In fact you should strive for a distribution that is the closest representation of reality. Kailash tells me that a distribution “should be determined empirically – from real data – not fitted to some mathematically convenient fiction (such as the Normal or Unform distributions). Further, one should be absolutely certain that the data is representative of the situation that is being estimated.”

Since SharePoint often relies on some estimations that offer significant uncertainty, a Monte Carlo simulation is a good way to run the numbers – especially if you want to see how many variables with different probability distributions combine to produce a result. Run the simulation enough times, you will produce a new probability distribution that represents all of these variables.

Just remember though – Charlie Sheen reliably demonstrates that things are not often predictable and that past values are no reliable indicator of future values. Thus a simulation is only as good as your probability distributions in the first place

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

p.s A huge thanks to Kailash for checking this post, offering some suggestions and making sure I didn’t make an arse of myself.

                      

Technorati Tags: Charlie Sheen, estimating, monte Carlo, ROI

Note: This post and content is really going make utterly no sense unless you have watched Zoolander. Even if you have seen the movie, before you launch into the webcasts, some scene setting is required.

The business need

Some time ago, Peter and I were contracted by the Derek Zoolander School for the Really, Really Good Looking after Derek saw Microsoft’s new SharePoint diagram when he accidentally picked up a “Computerworld” magazine. Apart from matching Derek’s suit colour rather nicely, the diagram captivated his imagination with the notion of “Insights”.

Zoolander thought that “Insight”, sounded like the perfect look to follow up from the highly successful “Magnum”, which he used to save the Malaysian prime ministers life. He took the diagram to his wife, and demanded that he must have “Insights” at all costs.

Zoolander’s wife saw the business problem that “Insights” would help to address. You see, the Derek Zoolander School for the Really, Really Good Looking, at great expense, custom developed an ERP system to manage everything you needed to know about male models. The system was called the “Computerised Records for Attractive People”…

The CRAP system stored all sorts of interesting information about male models, such as tracking their “hotness”, as well as important detail such as stated age versus actual age, and any cosmetic procedures that they have undertaken. After a long and expensive consultation, Peter and I concluded that SharePoint 2007, integrated with SQL Reporting Services, was the perfect solution to create the all important “Insights” that Zoolander so desperately needed.

As a result, we conducted a project kickoff meeting with Hansel and Peter tried to explain the architecture of reporting services using a nice diagram.

… but we worked out pretty quickly that this was not the way to explain how it all worked to poor old Hansel…

So instead, we went the live demo route. Being male models, custom development was totally out of the question. This solution had to be done using all out of the box methods in a quick and easy manner. Below are the four live demos that were recorded and now you can use them as inspiration for your own male modelling school.

• Our first webcast illustrates how we were able to create a meaningful report from the CRAP system within five minutes.
• The second webcast expanded on this idea, by illustrating how reports can be parameterised and linked together for drilldown reporting.
• The third demo modifies the user profile store to allow for recording of each users unique ID in the CRAP system
• The last webcast strings this all together for the final demonstration where we pimp the report to make it dynamic with no custom code.

The 5 minute report	Drilling down with Derek
User Profiles for the really really good looking	Pimp my report

We hope you find some value from these webcasts and we look forward to hearing about your hot new look as a result!

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

                      

No Tags

There is this wonderful way to look at the world, through a lens of something called “Complex adaptive systems”. Unfortunately with a name like that, it is automatically doomed to be only spoken of and understood by, a small subset of those sort of dishevelled looking nerdy guys who others take the piss out of when they are not around.

The notion of complex adaptive systems explains many things, including why salesman can unintentionally really be damaging to an organisation. I thought that I needed to write about this, and given that I am going to talk about sales guys, I had to write in a manner commiserate with their level of understanding of how the world works. Since the chances of a sales guy reading my blog is probably low, I should be safe

So here we go.

Here is a sales guy. Although us geeks think they are assholes, for this metaphor we have to change our context of what an asshole actually is. I think of him more of a guy who gathers food and brings it to you.

Here is the world for a sales guy. He finds work, and feeds that work into the mouth of the organisation. For performing such a feat, he gets to nibble off a small morsel of the meal to keep for himself. If he feeds the organisation enough and makes it grow, he will get enough morsels to grow rather nicely himself. This is a pretty sweet deal if you are good at finding food, because your reward is a percentage of what you push into the organisations mouth. Therefore it is in the sales guys interest to find as much food as he can for the organisational “body”. In fact his performance is directly attributed to doing exactly that in the form of quotas or sales targets

At the other end of the chain, the implementers have to digest what has been fed them from mouth and produce output that makes clients happy. Therefore it is the people in the organisation that actually implement a project who are actually the assholes, not the sales guys. As a result, I can say with some confidence that most people reading this post, like myself, are all assholes.

As this cycle perpetuates over time, the body in between these two ends grows. To continue to feed this body and keep it growing, we need to seek out more food. To do this we try and incentivise our sales people to supply more food by offering them larger morsels if they make more ambitious targets.

Never forget the assholes

Now we all know that we have to eat a balanced diet with healthy foods. But some people find it a pain to do all of that preparation and effort and instead go and grab some Chinese takeout instead. To a sales guy who is being rewarded for the amount of food being delivered to the organisation, fast food is great! Remember that the sales guy only takes just enough of the food for no lasting effects and is the furthest away from the assholes to feel the negative effects on the organisational as a whole.

Now our sales guy starts to look like the image below.

Therefore, this process of incentivising sales guys by the amount of food that they pass into the mouth is not without its risks and often can damage the long term health of the organisational body. Fast food can be tolerated now and again of course. For example, we all get the occasional hankering for Kentucky Fried Chicken every 6 months or so, and delude ourselves that this time, unlike all of the other times, it will actually not be oily enough to power a small town and leave you with that queasy feeling that you get when your heart labours against your cholesterol.

This can be a self perpetuating cycle. For example, the sales guy feeds the organisation a blisteringly hot spicy lamb vindaloo. Naturally is a very unpleasant experience for the assholes and as a result, what is delivered to the customer is (literally) crap and costs much more than anticipated. This cost bleed puts pressure on the sales guys to feed the body to make up for the wasted time, effort and cost. But the sales guy is so far away from the assholes, it does not occur to him that it was the spicy lamb vindaloo was the wrong meal. Nor too, does he receive any feedback to let him know that the burning sensation still lingers.

So what does he do? He feeds an even spicier lamb vindaloo to the mouth. Why? because he now has learned how to find spicy lamb vindaloos and is reaping the rewards of many tasty morsels – a perfectly reasonable practice given that he is now put under pressure to deliver more food.

Despite good intentions…

This cyclical phenomenon is called the “ring of fire” and afflicts many organisations who just can’t seem to deliver projects on time and budget. The customers of these organisations, fed up with getting nothing but crap, start to look elsewhere, thereby increasing pressure and starting the cycle again. Management get all flustered and usually blame the assholes.

The essence of the notion of the complex adaptive system is that the assholes and sales guys need each-other. Attempting to optimise the sales guys performance in isolation, ultimately has a negative impact on the assholes, which in turn has a negative impact on the organization as a whole.  The organisation is a system that comprises of many parts that interact in different ways. The system is perfectly capable of self organising and self optimising. For example, if the sales guy feeds the organisation sushi and next time it is fed a burrito, the assholes have a certain amount of tolerance to deal with that. But when you optimise one end (reward for food) without considering the assholes at the other end, you actually reduce that tolerance to deal with change!

The lesson that should be learned here is that the command and control methods of problem solving or project management that operate by optimising one part of the system, will usually work in the short term, but to the long term detriment to the system as a whole. The result that I have seen first hand for many IT organisations in particular, is that they have developed a certain reputation in the market for being a bit on the nose because of their seeming inability to get a project completed. Once this happens, it is very very difficult for them to regain the lost trust.

Microsoft for example, has taken years to win back the hearts and minds of geeks for their actions more than a decade ago.

What sort of fast food is SharePoint?

If SharePoint were a fast food, it would either be one of those giant steaks that you get your name on the wall if you finish, or the Guatemalan chilli that sent the normally invincible Homer into the spirit world. It is so seductive to the sales guys because it is in demand, but their distance to the assholes means that they will think it should be just like any other IT infrastructure oriented project to install. Therefore, some integrators will be doomed to repeatedly bite off more than they can chew and by the time they realise it, the long term damage will be done.

So what do you do?

If you accept that the organisation is a system and that optimising one part of it will likely impact the rest of the organisation, often in unpredictable ways, then incentivising has to be more strategically focussed. In other words, the true performance indicator on a good sales guy is actually the success of the project, because it is a much more reliable indicator of the sort of food being passed to the mouth and results in customer goodwill – social capital. If sales guys received their morsels based on the success of the project as a whole, then it would force them to interact more with the assholes to achieve that end and think a little more carefully about what they feed the organisation.

But self interest is a very strong force and there are very few sales guys that would be enthusiastic about that idea. This is of course the other big problem. The longer you leave it, the harder it is for an organisation to make the changes necessary to produce the outcomes that they aspire to.

If you want to see that in practice, look no further than the Copenhagen climate change conference.

Final note about thinking in terms of systems

Of course, if we are taking a complex adaptive systems view, then one could argue that the affect of all of this would be that your sales guys will leave and find organisations who feed them bigger morsels with much less effort of (heaven forbid) being judged on real outcomes. As a result, opportunities for sales may be lost to competitors and the organisation still suffers as a whole

This is the dilemma of systems thinking and what frustrates the hell out of the “command and control” world. You can just end up with a giant talkfest and never actually make a decision on anything because systems adapt in ways that can’t be predicted.

Is it any therefore wonder that command and control usually wins out? 

Thanks for reading

Paul Culmsee

                      

No Tags

Recently and the root question of the day was whether her little brother (Liam) should get a cat for Christmas. We already have a cat named Jessica and a detailed conversation unfolded, where my 5 year old outlined his reasons to the family. We all had a good laugh and by the end if the session, my 5 year old changed his mind and decided that he’d rather ask Santa for some lego. 

Check out how it unfolded.

Start: Root question, some basic background and Liam’s first two answers

Round 2. Mum and dad challenge both of the initial ideas and Liam offers a potential counterpoint. Unfortunately, Liam has the perfect comeback that his mother and I cannot argue with – Santa will take care of it!

Round 3. Liam offers a new reason why he should get a cat. It will help him with spilt milk. When challenged on the grounds of the new cat eating fish as well as milk, and the possibility of the cat not liking milk, Liam offered to hiss at it to protect the fish.

Round 4. Unable to get buy-in for the milk idea, Liam switches tack and comes up with quite a clever idea that has some merit. Our current cat has a particular talent for catching mice and then leaving what is left of them at the back door for our approval. Liam suggests that we can grow vegetables in the garden because of the fact that two cats are now hunting mice, thereby reducing the population (not bad logic for a 5 year old). Unfortunately for Liam, he is reminded that our current cat also has a habit of chewing plants in the herb garden now.

Round 5. My personal favourite. Mrs Cleverworkarounds suggests that Liam should not get a cat because there will be more cat poop to clean. When asked who will clean up said poo, Liam was adamant that it would not be him. When pressed for suggestions, he firstly says he will cover the mess with Kleenex and as alternative suggests that we can get a “cleaner man” to pick up the poo. When Liam was further challenged as to who the cleaner man is and how to find him, he suggested the police would help. He also then hit upon the idea of teaching the cat not to poo as well!

This proves that mapping discourse does work. At this point, faced with the prospect that he would have to clean up after the cat, Liam conceded defeat and asked for Star Wars lego instead.

The full map in context can be found below (click for the full size version).

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

                      

No Tags

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

                      

No Tags

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

                      

No Tags

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

                      

No Tags

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

                      

No Tags

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!

                      

No Tags