On the twitterverse recently, someone stated that because of a problem of excessive SharePoint site sprawl, they were going to institute a new site approval process. On the surface this remedy seems to be perfectly reasonable. After all, there is a clear problem that has emerged and in the name of governance, we have taken steps to address it via this new process.

There is only one small problem with this. It’s probably the wrong thing to do or at best, a minor facet of what to do.

Before I explain why, consider another scenario that I am sure all of us have experienced. You have a problem so you call your bank, ISP or some other provider of services that you have paid for. You encounter an operator or customer service representative who seems hell-bent on closing your call at all costs, whether you think the problem is solved or not. Common examples of how this plays out is the oft used “well I will close this call and you can call back and log a new one if there is still an issue” line. A more subtle, yet equally frustrating one that even Microsoft have used on me is the “well you logged the problem as X, but in reality its Y. So you will need to close this call and re-log a new call for problem Y”.

The underlying reason for this is very likely that the performance of the person on the other end of the line is judged on time spent handling your call. The logic would be that the speedier a call is closed, means the less time users have spent on tech support, which indicates good outcomes for customers.

Alas, if only that were true. Anybody who has been on the receiving end of this sort of treatment knows full well that the opposite happens. As a customer, you get frustrated and pissed off. More dangerously for the organization, this sort of indicator conveys a warped representation of reality. Essentially the operator has altered their behaviour to maximise their performance according to this measure of “effectiveness”. Customers who are paying the money are not necessarily satisfied. In fact they are more often than not dissatisfied. Therefore, the notion that length of support calls somehow lead to happier customers is a fallacy. In the longer term, customers will tire of crappy outcomes and take their business elsewhere.

This success indicator is a mirage, and in actual fact contributes to the nastier, longer term problems of customers ending up with competitors.

So with that said, lets go back to our Sharepoint site sprawl issue. Before instituting such a policy, I ask the following simple question.

So why are there lots of sites?

Now there will be various reasons, but the most common answer I get back from this is:

Users don’t know any better.

This assertion is pretty easy to test too. Take a look at the sites in the wild west of a chaotic SharePoint install. Since most site templates in SharePoint have a single document library, it is common to see many hundreds of sites with a single document library in them. Clearly, people simply aren’t aware that they can do things like add more libraries or lists to a site or they are unwilling or unable to do so. I have experienced users telling me that if they had have known, they would have never created a site for a particular collaborative activity.

Side Note: SharePoint’s own attempts to be “intuitive” is the problem here. For a start, sites build navigation by default so people get duped into using sites to create navigational structure when its wholly inappropriate. Secondly, creating a new site is inferred as the right thing to do. To see why, go to the site actions menu and what is a default action there? You guessed it – create a site. SharePoint out of the box actually contributes to users forming this mental model of how SharePoint hangs together).

So clearly, many instances of excess site sprawl is symptomatic of something deeper. Users do not know that there are potentially better alternatives. This leads us to a somewhat rhetorical, yet critical question:

What does an approval process do about users not knowing any better?

Many times such approval processes shift the burden of creating the site to an authorised party like IT, after a requestor’s boss has given it the go ahead. Naturally, people will have to do more paperwork to get approval and it might take longer. Furthermore, maybe their request will be rejected under certain circumstances. But at what point will they learn that there is more to life than sub sites? Even after instituting the approval process, we still may end up with a heap of sites with a single document library in them. Have we really addressed the real issue?

Do you see the parallel? The sort of thinking that decided an approval policy is the answer to site sprawl is the same sort of thinking that decided that call times are a reliable indicator of customer outcomes being met. Both treat the superficial, visible symptoms of a problem, not the underlying cause. Furthermore, both end up leaving stakeholders with crappy outcomes in the longer term. Your support calls are still frustrating and you are still using SharePoint in a sub optimal fashion.

More scarily though is that we have deluded ourselves into thinking we have dealt with the problem. SharePoint governance is often built around this sort of superficial thinking. If a governance plan weighs as much as a door stop, and gets about as much attention as a door stop, then you might be making this mistake.

What about legacy?

This problem is more common than you think. There is a more systematic pattern of delusion that can happen in project management. Check out the diagram below.

Seen this diagram before? It is very common on project management books and presentations. We have a pyramid that implying that to have quality, we have to have time, cost and scope balanced and understood. Like the site approval policy, this seems perfectly reasonable on the surface. But unfortunately, by its very nature can cloud us to what is really important.

Below is an example of a project output – the Sydney Opera House. During my classes, everyone recognises it and there is always someone who has been there. In fact people come to Sydney just to see it. In term of economic significance to Sydney, it is priceless and irreplaceable. the architect who designed it, Jørn Utzon, was awarded the Pritzker Prize (architecture’s highest honour) for it in 2003.

So I ask you the question:

Was this a successful project?

I ask this question to people all around the world and the answer is always a great big Yes. But if we look at this project through the lens of our quality triangle above, the view changes.

Why?

Well, here are a few fun filled facts about the Sydney Opera House.

• The Opera House was formally completed in 1973, having cost $102 million.
• The original cost estimate in 1957 was $7 million.
• The original completion date set by the government was 1963.
• Thus, the project was completed ten years late and over-budget by more than fourteen times.
• Ultzon, the designer of the opera house never lived to set foot in it, having left Australia in disgust, swearing never to come back.

“Utzon soon found himself in conflict with the new Minister. Attempting to rein in the escalating cost of the project, Hughes began questioning Utzon’s capability, his designs, schedules and cost estimates. Hughes eventually stopped payments to Utzon. Unable to pay his staff, Utzon was forced to resign as chief architect in February 1966 and left the country never to return. Utzon has never seen the completed work that brought him international renown”

Harsh huh? Clearly, when judged through the “quality” lens of time, cost and scope, this project was a unmitigated epic fail that makes SharePoint look like a walk in the park.

The example of the Sydney Opera House serves to remind us that when all is said and done, we judge quality across something deeper than time, cost and scope alone. That something is legacy.

People remember legacy, not scope

So when you look at the Opera house through the lens of the quality triangle, you are making the same mistake as the call-center KPI and the well intentioned site creation policy. You are taking a superficial view of things and in doing so, missing more subtle, but ultimately important factors. In fact you are treating symptoms and not looking for the “story beneath the story” that caused the visible symptoms in the first place.

Yet…

Why do we go to the time, effort and cost to put in tools like SharePoint? It is because we see that it can take us to a better place than we are now. After all, if we didn’t believe this fundamental truth, then we wouldn’t spend the that time and money working on it. This notion of a “better place” implies that we are trying to escape a legacy of the past – such as poor information management practices, inefficient process, silo organisations and so forth.

As illustrated by the Opera House example, people do not remember time, cost and scope. What they do remember acutely however is legacy.

So what is a more reliable indicator of quality? Who visits the Opera house and takes a photo of it because it was such a breathtakingly bad example of project management 101? No, they take their photo because it is unique, has value and people want to experience it for themselves. Its the legacy that they remember, cherish and want to be a part of.

As a result, there is a critical lesson here for all SharePoint practitioners (from the nerdiest of nerds to the hippiest of web 2.0 pundits). Ask yourself, “what legacy is my governance actions going to leave”, because if you fail to consider the legacy of your approaches to SharePoint delivery, you are probably dooming your organisation to the very same legacy you wanted to escape in the first place!

And that’s just tragic.

So I think that PM 101 diagram needs to be redrawn because it misleads – especially for complex, adaptive or wicked problems. To me, considering time, cost and scope without legacy is delusional and plain dumb. Legacy informs time, cost and scope and challenges us to look beyond the visible symptoms of what we perceive as the problem to what’s really going on.

When I get time, I will post several examples of how I was able to utilise this sort of thinking in a future post, but I hope this gives you some food for thought.

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

www.spgovia.com

Hi all

Just a quick post to let you all know that in around 11 hours I’m off on a long flight back to US shores – my first trip for quite some time. We will be in Seattle, Portland, Bend, San Francisco and Napa. I am really, really looking forward to this trip for a number of reasons.

• Its my first ever SharePoint Governance and Information Architecture Class in the US and I intend to deliver a knockout class. The class has essentially sold out (at the time of writing one remaining place looks like its about to be filled). Erica Toelle has been absolutely brilliant, has placed a lot of faith in me and I do not intend to let her, or any of the attendees down.
• I’m also speaking at the Seattle SharePoint User Group in early May 5th (with Ruven) and also speaking at the Bend SharePoint User Group on May 9th, both on some SharePoint Governance Home Truths. I don’t get to the US very often and that is not going to change anytime soon, so I suggest you don’t assume you can wait till next time, because that may be a while! If you know someone who needs a bit of an intervention or some governance “deprogramming”, then send them my way!
• A major, major milestone this year has been achieved. My Beyond Best Practices book is finally complete! I am super excited by this book too. I think we have really delved into areas that no other book has really done in terms of collaboration and dealing with complex, difficult to solve problems. We are sorting out publishers so hopefully there will be some face to face meetings when I am in San Francisco and I will be able to give you some relatively firm dates on when it might grace a bookshelf, iPad or Kindle. (I’ll cover some stuff from the book in the Seattle class).
• I’ll have an opportunity to catch up with the likes of Erica Toelle, Ruven Gotz, Christian Buckley, Bill English, Jeff Conklin and a number of other people who I rarely get to see “in the flesh”. Maybe there is time to squeeze in another musical collaboration with Mr Buckley eh?
• Best of all, my family is coming with me and we are taking a holiday while we are here – wohoo!

So if you are in Seattle between May 1-7, or the Bay Area between May 10-13, get in contact!

See you soon!

Paul

For one night only USA…

Ah, Erica Toelle – what a legend! Thanks to Erica and Fpweb, I’m thrilled to confirm that the Seattle SharePoint Governance and Information Architecture class is all systems go. Save the date as its very likely indeed to be the only SPIA class in the USA in 2011.  If it wasn’t enough that Erica will be joining me, but Ruven Gotz will be there too.

Thursday and Friday, May 05-06, 2011. (http://spiaseattle.eventbrite.com/)

The location is the Silvercloud Inn, 14632 SE Eastgate Way Bellevue, WA 98004

In this multimedia extravaganza of a blog post, lets take a closer look at this class and what you can expect. Below is a snippet of a talk I did in New Zealand called “SharePoint Governance  Home Truths”. This clip shows a little diagnostic test that I do on my audience, to see whether they have experienced the visible signs of wicked problems. If you want to know why you should go to SPGov+IA, then take my 2 minute test yourself.

If the two minute test has taken your fancy, then you might want to see what is in store on the course itself. Below is the first half-hour of module 1 (in the form of a conference session), as well as the accompanying slide deck.

Course Information:

Download Course Outline (PDF)

Download Class Flyer (PDF)

Most people understand that deploying SharePoint is much more than getting it installed.  Despite this, current SharePoint governance documentation abounds in service delivery aspects. However, just because your system is rock-solid, stable, well-documented and governed through good process, there is absolutely no guarantee of success.  Similarly, if Information Architecture for SharePoint was as easy as putting together lists, libraries and metadata the right way, then why doesn’t Microsoft publish the obvious best practices?

In fact, the secret to a successful SharePoint project is an area that the governance documentation barely touches.

This Master Class pinpoints the critical success factors for SharePoint Governance and Information Architecture and rectifies this blind spot.  Paul Culmsee’s style takes an ironic and subversive view on how SharePoint Governance really works within organizations while presenting a model and the tools necessary to get it right.

Drawing on inspiration from many diverse sources, disciplines and case studies, Paul Culmsee has distilled the "what" and "how" of governance down to a simple and accessible, yet rigorous and comprehensive set of tools and methods that organizations, large and small, can utilize to achieve the level of commitment required to see SharePoint become a successful part of your enterprise.

Some workshop sessions are hands on, we provide all of the tools and samples needed but please bring your own laptop.

Course Structure:

The course is split into 7 modules, run across two days.

Module 1: SharePoint Governance f-Laws 1-17:

Module 1 is all about setting context in the form of clearing some misconceptions about the often muddy topic of SharePoint governance. This module sheds some light onto these less visible SharePoint governance factors in the form of Governance f-Laws, which will also help to provide the context for the rest of this course

• Why users don’t know what they want
• The danger of platitudes
• Why IT doesn’t get it
• The adaptive challenge – how to govern SharePoint for the hidden organisation
• The true forces of organisational chaos
• Wicked problems and how to spot them
• The myth of best practices and how to determine when a “practice” is really best

Module 2: The Shared Understanding Toolkit – part 1:

Module 2 pinpoints the SharePoint governance blind spot and introduces the Seven Sigma Shared Understanding Toolkit to counter it. The toolkit is a suite of tools, patterns and practices that can be used to improve SharePoint outcomes. This module builds upon the f-laws of module 1 and specifically examines the “what” and “why” questions of SharePoint Governance. Areas covered include how to identify particular types of problems, how to align the diverse goals of stakeholders, leverage problem structuring methods and constructing a solid business case.

Module 3: The Shared Understanding Toolkit – part 2:

Module 3 continues the Seven Sigma Shared Understanding Toolkit, and focuses on the foundation of “what” and “why” by examining the “who” and “how”. Areas covered include aligning stakeholder expectations, priorities and focus areas and building this alignment into a governance structure and written governance plan that actually make sense and that people will read. We round off by examining user engagement/stakeholder communication and training strategy.

Module 4: Information Architecture trends, lessons learned and key SharePoint challenges

Module 4 examines the hidden costs of poor information management practices, as well as some of the trends that are impacting on Information Architecture and the strategic direction of Microsoft as it develops the SharePoint road map. We will also examine the results from what other organisations have attempted and their lessons learned. We then distil those lessons learned into some the fundamental tenants of modern information architecture and finish off by examining the key SharePoint challenges from a technical, strategic and organisational viewpoint.

Module 5: Information organisation and facets of collaboration

Module 5 dives deeper into the core Information Architecture topics of information structure and organisation. We explore the various facets of enterprise collaboration and identify common Information Architecture mistakes and the strategies to avoid making them.

Module 6: Information Seeking, Search and metadata

Module 6 examines the factors that affect how users seek information and how they manifest in terms of patterns of use. Building upon the facets of collaboration of module 5, we examine several strategies to improving SharePoint search and navigation. We then turn our attention to taxonomy and metadata, and what SharePoint 2010 has to offer in terms of managed metadata

Module 7: Shared understanding and visual representation – documenting your Information Architecture

Module 7 returns to the theme of governance in the sense of communicating your information architecture through visual or written form. To achieve shared understanding among participants, we need to document our designs in various forms for various audiences.

Putting it all together: From vision to execution

Attendees will be taking home a manual ~480 pages, containing the Seven Sigma Shared Understanding Toolkit CD with a sample performance framework, governance plan, SharePoint ROI calculator (Spreadsheet), sample mind maps of Information Architecture. These tools are the result of years of continual development and refinement "out in the field" by Paul Culmsee and have only been recently released to the public through this Master Class.

More Information:

• Praise for SharePoint Governance and IA Masterclass

Refund Policy:

No refunds will be issued for attendee cancellations once payment is recieved.  Class cancellation by the organizer will result in a refund less transaction fees.

http://spiaseattle.eventbrite.com/

I received this today and I had to post it. In New Zealand recently, Paul McTaggart of Gen-i stopped me and complimented the governance and information architecture course that some of his staff have attended. I am truly humbled by the feedback that he just sent through…

Practical, relevant and seriously funny: These attributes are seldom seen together in a training session.

However, Paul Culmsee has practical, real world experience having worked on complex (wicked) projects which provides him with the background and understanding of what works and why.

Discover the immutable f-laws of SharePoint projects. Cry and laugh when you identify the reality of you own organizational platitudes, but breathe a sigh of relief when you see that there is a way out and that SharePoint Governance and Information Architecture can be achieved with everyone sharing the same understanding of where you are now and where you are trying to get to.

Paul also supports you new found realization of what needs to be done by providing you with the guidance, tools and methods that you can take from the classroom and apply to your complex (wicked) problem projects to make them work.

Basically it is all about people (gaining shared understanding), process (knowing how to get from here to there) and then the technology (SharePoint).

My team now uses the concept of shared understanding and the tools that the Governance and Information Architecture Class has provided to get customers “on page” before we design and code in SharePoint land.

Paul McTaggart

ECM Business Manager

Gen-i a division of Telecom New Zealand

Thanks for reading

Paul Culmsee

Hi all

For those of you that enjoy reading this blog, I really need your help. I am running my SharePoint Governance and Information Architecture master classes in North America and Canada in May 2011. This is a bit of a “one night only” thing, because it is a damn long way for me to travel, so I rarely visit the USA and I have never been to Canada. It’s unlikely that I will be back here for some time.

My SharePoint governance class has been run in London, Dublin, Sydney, Perth and Wellington. It is also about to be run in the Netherlands in May by 21apps. Responses have been terrific from attendees thus far. In May, I will be in the US/Canada, in the following locations:

• Seattle: May 5-6 2011 (http://spiaseattle.eventbrite.com/)
• Toronto: May 12-13 2011 (http://spiatoronto.eventbrite.com/)

I’ll also be running a class in Brisbane in June too.

Seattle is looking good at this stage, but Toronto is not. If any Canadians reading this blog would like to see this class happen in your shores, then please help us by spreading the word. Without your help, we may not be able to commit to Toronto at all.

If you want to see what you are in for, then why not watch the video below from the New Zealand SharePoint conference where I cover the first half an hour of the course. Imagine two days of such fun and frivolity!!

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

Hiya

A few months back I posted a relatively well behaved rant over the ridiculously complex User Profile Service Application of SharePoint 2010. I think this component in particular epitomises SharePoint 2010’s awful combination of “design by committee” clunkiness, along with real-world sheltered Microsoft product manager groupthink which seems to rate success on the number of half baked features packed in, as opposed to how well those features install logically, integrate with other products and function properly in real-world scenarios.

Now truth be told, until yesterday, I have had an unblemished record with the User Profile Service – being able to successfully provision it first time at all sites I have visited (and no I did not resort to running it all as administrator). Of course, we all have Spence to thank for this with his rational guide. Nevertheless, I am strongly starting to think that I should write the irrational guide as a sort of bizzaro version of Spencers articles, which combines his rigour with some mega-ranting ;-).

So what happened to blemish my perfect record? Bloody Active Directory policies – that’s what.

In case you didn’t know, SharePoint uses a scaled down, pre-release version of Forefront Identify Manager. Presumably the logic here to this was to allow more flexibility, by two-way syncing to various directory services, thereby saving the SharePoint team development time and effort, as well as being able to tout yet another cool feature to the masses. Of course, the trade-off that the programmers overlooked is the insane complexity that they introduced as a result. I’m sure if you asked Microsoft’s support staff what they think of the UPS, they will tell you it has not worked out overly well. Whether that feedback has made it way back to the hallowed ground of the open-plan cubicles of SharePoint product development I can only guess. But I theorise that if Microsoft made their SharePoint devs accountable for providing front-line tech support for their components, they will suddenly understand why conspiracy theorist support and infrastructure guys act the way they do.

Anyway I better supress my desire for an all out rant and tell you the problem and the fix. The site in question was actually a fairly simple set-up. Two server farm and a single AD forest. About the only thing of significance from the absolute stock standard setup was that the active directory NETBIOS name did not match the active directory fully qualified domain name. But this is actually a well known and well covered by TechNet and Spence. A quick bit of PowerShell goodness and some AD permission configuration sorts the issue.

Yet when I provisioned the User Profile Service Application and then tried to start the User Profile Synchronisation Service on the server (the big, scary step that strikes fear into practitioners), I hit the sadly common “stuck on starting” error. The ULS logs told me utterly nothing of significance – even when i turned the debug juice to full throttle. The ever helpful windows event logs showed me Event ID 3:

ForeFront Identity Manager,
Level: Error

.Net SqlClient Data Provider: System.Data.SqlClient.SqlException: HostId is not registered
at Microsoft.ResourceManagement.Data.Exception.DataAccessExceptionManager.ThrowException(SqlException innerException)
at Microsoft.ResourceManagement.Data.DataAccess.RetrieveWorkflowDataForHostActivator(Int16 hostId, Int16 pingIntervalSecs, Int32 activeHostedWorkflowDefinitionsSequenceNumber, Int16 workflowControlMessagesMaxPerMinute, Int16 requestRecoveryMaxPerMinute, Int16 requestCleanupMaxPerMinute, Boolean runRequestRecoveryScan, Boolean& doPolicyApplicationDispatch, ReadOnlyCollection`1& activeHostedWorkflowDefinitions, ReadOnlyCollection`1& workflowControlMessages, List`1& requestsToRedispatch)
at Microsoft.ResourceManagement.Workflow.Hosting.HostActivator.RetrieveWorkflowDataForHostActivator()
at Microsoft.ResourceManagement.Workflow.Hosting.HostActivator.ActivateHosts(Object source, ElapsedEventArgs e)

The most common issue with this message is the NETBIOS issue I mentioned earlier. But in my case this proved to be fruitless. I also took Spence’s advice and installed the Feb 2011 cumulative update for SharePoint 2010, but to no avail. Every time I provisioned the UPS sync service, I received the above persistent error – many, many, many times. 🙁

For what its worth, forget googling the above error because it is a bit of a red herring and you will find issues that will likely point you to the wrong places.

In my case, the key to the resolution lay in understanding my previously documented issue with the UPS and self-signed certificate creation. This time, I noticed that the certificates were successfully created before the above error happened.  MIISCLIENT showed no configuration had been written to Forefront Identity Manager at all. Then I remembered that the SharePoint User Profile Service Application talks to Forefront over HTTPS on port 5725. As soon as I remembered that HTTP was the communication mechanism, I had a strong suspicion on where the problem was – as I have seen this sort of crap before…

I wondered if some stupid proxy setting was getting in the way. Back in the halcyon days of SharePoint 2003, I had this issue when scheduling SMIGRATE tasks, where the account used to run SMIGRATE is configured to use a proxy server, would fail. To find out if this was the case here, a quick execute of the GPRESULT tool and we realised that there was a proxy configuration script applied at the domain level for all users. We then logged in as the farm account interactively (given that to provision the UPS it needs to be Administrator anyway this was not a problem). We then disabled all proxy configuration via Internet explorer and tried again.

Blammo! The service provisions and we are cooking with gas! it was the bloody proxy server. Reconfigure group policy and all is good.

Conclusion

The moral of the story is this. Anytime windows components communicate with each-other via HTTP, there is always a chance that some AD induced dumbass proxy setting might get in the way. If not that, stateful security apps that check out HTTP traffic or even a corrupted cache (as happened in this case). The ULS logs will never tell you much here, because the problem is not SharePoint per se, but the registry configuration enforced by policy.

So, to ensure that you do not get affected by this, configure all SharePoint servers to be excluded from proxy access, or configure the SharePoint farm account not to use a proxy server at all. (Watch for certificate revocation related slowness if you do this though).

Finally, I called this post “consequences of complexity” because this sort of problem is very tricky to identify the root cause. With so many variables in the mix, how the hell can people figure this sort of stuff out?

Seriously Microsoft, you need to adjust your measures of success to include resiliency of the platform!

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

• The facets of collaboration Part 1–Meet robot barbie
• The facets of collaboration Part 2–Enter the matrix!
• The facets of collaboration Part 3-The feature jigsaw
• The facets of collaboration Part 4 – BPM vs. HPM

Hi all

Welcome to another exploration of the collaborative world through a lens called the facets of collaboration. If you are joining us for the first time, I am writing a series of posts that looks at how our perception of collaboration influences our penchant for certain collaborative tools and approaches. SharePoint, given that it is touted as a collaboration platform, inevitably results in consultants never being able to give a straight answer. This is because SharePoint is so feature-rich (and as a result caveat-rich), that there are always fifty different ways a situation can be approached. Add the fact that many clients do not necessarily know what they want and learn about their problem by examining potential solutions, we have all the hallmarks of a wicked problem in the making.

These wicked problems, underpinning SharePoint, often results in Robot Barbie situations (cue the image to the left), which is the metaphor that I started this series with. Robot Barbie represents everything wrong about SharePoint deployments, as it is symptomatic of throwing features at a platitude, pretending to be solving a real problem and then wondering why the result doesn’t gel at all. It is a pattern of behaviour that is similar to an observation made by the very wise (and profane) Ted Dziuba who once spoke these words of wisdom.

If there’s one thing all engineers love to do, it’s create APIs. It’s so awesome because you can draw on a white board and feel like you put in a good day’s work, despite having solved no real, actual problems. Web 2.0 engineers, in addition to their intrinsic love of APIs, have a real hard-on for anything having to do with a social network. For example, developing a Facebook application lets them call their shitty little PHP program an "application" running on a "platform," like a real, live computer programmer does. Make-believe time is so much fun, even for adults.

Apart from making me giggle, Dziuba may have a point. Elsewhere on this blog I have spent time explaining that there are different types of problems that require different approaches to solving them (wicked vs. tame). My conjecture is that collaboration itself is exactly the same in this regard. People who espouse a particular type of tool or approach as the utopian solution to collaboration are taking a one size fits all approach to a multifaceted area and even worse, treating that area as a platitude. Anyone who calls themselves an Information Architect and doesn’t at least give cursory examination to the dimensions or facets of collaboration is likely to be doing their stakeholders a disservice.

All of us have certain biases, and I am no exception. For a start, I am generation X – the so-called cynical generation. Apparently we whinge and whine about everything and then blame it all on generation-Y. Thus, if cynicism is the gen-X stereotype, then I will happily accept being the poster child. I mean seriously, all of you vanity obsessed, self interested generation y’ers, if you spend a little less time preening and more time thinking, we might get some wisdom out of you (see – I am such a cynical gen-X right now).

So let’s recap the facets of collaboration. The model I came up with identifies four major facets for collaborative work: Task, Trait, Social and Transactional.

• Task: Because the outcome drives the members’ attention and participation
• Trait: Because the interest drives the members’ attention and participation
• Transactional: Because the process drives the members’ attention and participation
• Social: Because the shared insight drives the members’ attention and participation

In the last post, I used the model to examine the notion of Business Process Management versus Human Process Management and looked at some of the claims and counter claims made by proponents of each. This time let’s up the ante and talk about something curlier. We will examine the notion that social networking in the enterprise is the answer to improving collaboration within the enterprise. On first thought, it makes perfect sense, given the incredible success of Facebook, LinkedIn and Twitter. Nevertheless, there is ongoing debate about the use and value of social tools in the enterprise driven by their rise outside of organisational contexts. One particularly strongly worded quote is from Aaron Fulkerson, co-founder and CEO of MindTouch who doesn’t mince his words:

This class of software forces business users to adopt the myopic social visions imagined by the developers, which are nearly identical to their corresponding consumer web implementations. In short, social software is not solving business problems. In fact, these applications only serve to treat symptoms of the problems businesses face. They exacerbate the real problems within businesses by creating distractions and, worse, proliferate more disconnected data and application silos.

Ouch! Even within the SharePoint community there is significant variation of opinions as to the value of social. While I better protect the innocent and not name names, I have spoken with several well known SharePointers who think social is a giant waste of time, versus those who see real value in it. Irrespective of your opinion, you cannot ignore the fact that social is a significant game changer with effects still being felt. While web 2.0 has dropped off the Gartner hype cycle, its effect on particular sectors has been far reaching. Now it seems that all sectors have a 2.0 on the end of their name. For example:

• Enterprise 2.0
• Education 2.0
• Legal 2.0
• Government 2.0

Clearly, if things were just a flash in the pan, why are governments around the world trying to revitalise their public sector by utilising these tools?

Look at Microsoft as another example. They have, I think smartly, recognised industry trends and reacted to them via the introduction of a number of new SharePoint features, such as tagging/folksonomy via managed metadata, ratings columns, enhanced wiki capabilities and a significant investment in the capabilities of my-sites. Their clients now have the option to leverage these features should they choose to do so.

So just as there are naysayers, there are the pundits. Many people cite the reasoning that these features are necessary to attract and retain the next generation of workers, who have grown up with these tools in their personal lives. Whether this claim is valid is debatable, but I have to say, I really like the Enterprise 2.0 slide deck below by Scott Gavin for a number of reasons. I think it encapsulates the 2.0 vision, underpinned by social/cloud technologies very nicely. I sometimes ask people to discuss this slide deck in my IA classes and discussion is equally polarising as social networking in the enterprise itself. Some people think it represents the vision for the future, and others think it is hopelessly idealistic and doesn’t reflect cold, hard reality. Take a look for yourself below…

And the survey says…

Using the facets quadrants, we can start to see patterns for success of these tools for the enterprise and whether Aaron Fulkerson’s argument has merit or whether Scott Gavin is on the right track. An interesting use of the facet diagram is to plot where various tools and technologies are located. in my classes, I ask people to plot where Facebook belongs on facets diagram. Guess where it is usually drawn? 

While some people will draw Facebook at various levels on the vertical axis, everyone pretty much describes Facebook (and LinkedIn)  as trait based, while being highly dominant on the social quadrant. As discussed in the last article, if I ask people to plot a crowdsourced tool like Wikipedia, the dominant characteristic is always trait/social. In other words, people maintain and update Wikipedia articles because of their interest in the topic area, not because it helps them get something done.

Clearly, big social networking technologies are successful in the "trait based social” quadrant. In other words, we tend to use Facebook more for common interest collaboration than to solve a task based collaborative issue (such as deliver a project). Another interesting thing about a lot of social networking technologies is that for many, our work-based collaborative life tends to be more task based, compared to our non-work which is more trait based. In other words, for a lot of us, our work life revolves around working with a group of people for a common outcome and if it was not for that common outcome, we wouldn’t necessarily have much in common (I risk falling victim to my own generalisation here – so I will come back to this later in the section titled “Why User Buy-In Is Hard”).

When you look at where Facebook sits in the quadrant, it begs the question of how well this type of tool (or the building blocks it is based on) would work in an organisation that is project (task) based and highly transactional. To that end, consider a project management information system, such as the basic one that Dux espouses in his book or the more complex one that Microsoft sell to organisations. Where do you think it belongs on the quadrant?

When I ask people to plot their project management information system, I typically get this response:

I speculate that the further away two tools lie on the spectrum, the more likely we are to have a robot-barbie solution if you blindly mix features that work well in each individual quadrant. The wiki argument I made in part 3 seems to support this contention. If you recall, in part 3 of this series, I mentioned that I ask every attendee of my classes if they had ever seen a successful project management wiki.  Irrespective of the location of the class, the answer was pretty much “no”. I noted that where I had seen successful wikis tended to be where the users of the wiki were linked by strong traits.

Looking Deeper

While that is interesting, I think the facets diagram tells you more than it intends. Obviously, it is clear that these project management systems such as MS Project Server are oriented toward task/transactional (“getting things done”) aspect of project delivery (ie, time, cost, scope, budget and the like). While some people might point to this and say “there you go – I told you all that social crap was a waste of time – bloody gen-Y and their social networking hubris”, I feel this is naive. If task based transactional tools are sufficient, then why do so many projects fail?

I have stated many times on this blog that shared commitment to a course of action requires shared understanding of the problem at hand. The act of aligning a team to project goals and developing this shared understanding is the realm of the task/social quadrant (the top left), where insights and outcomes come together. When I ask people to name tools that live in this space, few can name anything. Obviously, most project management systems are devoid here. Worst still, we subsequently delude ourselves to thinking that shared understanding can come from a few platitudinal paragraphs labelled as a “problem statement”.

Social networking pundits implicitly recognise this issue (and frequently butt heads against command and control type project managers as a result). But i feel they make the mistake in applying a one size fits all approach to collaboration and apply trait based tools as a panacea when they are not wholly appropriate. The social tools seem to fit exceptionally well into the top right quadrant, but not in the top left.

In fact the only tools that spring to mind that belong in the top left category are the sensemaking tools that my company practice, such as Dialogue Mapping.

Where’s the proof, Paul?

So I guess I am arguing that using social tools because they are the “choice of the new generation” ignores a few home truths about the nature of these tools versus the nature of organisational life. Just because Microsoft provide the tools for you, tells you that they are hedging their bets rather than having any more insight than you or me. So to test all of this, let’s use the facets model in a different way to back up some of my observations and suggestions in this post. Guess what happens when I ask people to plot SharePoint itself on the facets map?

When I asked SharePoint practitioners to do this, they initially drew SharePoint 2007 as a circle over the entire model. Once they did so, they would very often adjust the drawing to emphasise transactional over social collaboration as shown below.

When practitioners were asked to draw SharePoint 2010, they usually indicated a higher representation in in the two social quadrants, but favoured the trait based social over task based social as shown below.

What was interesting about this experiment is that very few people drew SharePoint over the entire facets of collaboration. Social collaboration with SharePoint it seems, only stretches so far. This leads me onto more conjecture, and now we get to the bit in the post where we name a giant SharePoint elephant in the room.

Structured tools for social collaboration?

Many collaborative tools purport themselves as operating in the social space. SharePoint 2010 clearly does so, principally due to the Managed Metadata service, pimped MySites with tagging/rating capabilities. But SharePoint’s core heritage is database/metadata driven, document based collaboration. If we go back to our definition of social collaboration as dynamic, unstructured, with sharing of perspectives and insight through pattern sensing, then social collaboration is clearly not a predefined interaction.

Yet, database driven tools like SharePoint, and its building blocks like site columns and content types require considerable up-front planning to install and govern. Many, many inputs need to be well defined and furthermore, unless you have learnt through living the pain of things like content type definitions in declarative CAML, SharePoint buildings blocks are difficult to maintain/change over time. SharePoint suffers from a problem of reduced resiliency over time in that the more you customise it to suit your ends, the less flexible it gets. In the case of social collaboration the problem is worse because we are trying design for outputs where the inputs are not controlled. Trying to turn something that is inherently organic and emergent to something that has an X and Y on it may be misfocused and destined to fail in many circumstances. The realm of well-defined inputs is the realm of transactional collaboration, where workflow and business process management thrive and change is much more controlled before SharePoint ever gets a look in.

SharePoint excels at transactional scenarios as this is its heritage – after all, the majority of its feature set is oriented to transactional collaboration. The fact that people are prepared to draw SharePoint as dominating across across the transactional half of the facets diagram illustrates this.

But this raises interesting, if not slightly heretical question. If we need to use information architects to get a collaborative tool deployed for social collaboration (to get those inputs defined), then are we pushing the solution into the transactional side of the fence? Recall that in part 3 of this series, I looked at document collaboration and noted that when asked to draw team based document collaboration, people typically drew it operating in the social half of the matrix (pasted below for reference). I also noted in part 3 that for team based collaboration, rules and process are much less rigid or formalised with regards to document use and structure. I then referred to a recent NothingbutSharePoint article where a large organisation’s attempts to introduce the usage of content types largely failed. Like the seeming lack of success of wiki’s for task based collaboration, maybe content types simply are not the ideal construct as you move up the Y axis from transactional to social?

Now do not assume that I am anti metadata/content types here as this is not the case at all. Content types rock when it comes to search and surfacing of related information across a site collection (and beyond if you use search web parts). What I am calling out is the fact that if the SharePoint constructs that we have at our disposal were the panacea for social collaboration, where are the best practices that tell us how to leverage them for success? Perhaps the nature of the collaboration taking place plays a part in the lack of take-up reported in the aforementioned article? Those who advocate highly structured metadata as the only true solution may in fact be pushing a transactional paradigm onto a collaborative model that is ill-suited to it?

The knowledge worker paradox – one of the reasons why user buy-in is hard

Finally for now I’d like to cover one more aspect to this issue. Last year, one of my students looked at the facets and said “Now I know why my users aren’t seeing the value that I see in SharePoint”. When I asked him why, he explained:

“Many of my users are transactional and governed by process – that’s their KPI. Here I am as a knowledge worker, seeing all of these great collaborative features, but I am not judged by a process or transaction. I don’t live in that world. I forget that someone whose performance is judged by process consistency is not going to get all excited by a wiki or tagging or a blog.”

I call this the knowledge worker paradox and it is reminiscent of what I said in part 4 where we looked at BPM vs. HPM. Each role on an organisation is multifaceted. For many roles, there is varying degrees of transactional work taking place. Accordingly some people are very much process driven just as much as they are social driven. Gross generalisations that make statements that “80% of people are knowledge workers or perform knowledge work” do not help matters. In fact they serve to feed the one size fits all mentality that has proven to be detrimental to projects when people fail to recognise that some projects have wicked aspects.

SharePoint people are almost always knowledge workers. Thus if you, as a knowledge worker who is rarely governed by transactional process, think that you have the vision to prescribe a SharePoint driven meta-utopia to meet transactional needs without having lived that world, then if your results are not what you hoped for then to me its hardly surprising.  My student in this case realised that he had been approaching his user base the wrong way. Like Jane in part 1, he did not take into account the dominant facets of collaboration for the roles that he was trying to sell SharePoint into.

When you think about it, the whole argument around records management versus collaborative document management is in effect, an argument between a transactional oriented approach, versus a social oriented one. It is the same pattern as BPM vs. HPM. In records management, the paradigm is that management of the record is more important than the content of the record. Furthermore, that record shouldn’t change. Yet with team based document collaboration, without content there is no document as such and furthermore, the document will change frequently and require less strict controls to grease the gears of collaboration.

Both records oriented people and social pundits commonly make the same mistake of my student, where they force their dominant paradigm on everyone else.

Conclusion

Food for thought, eh?

This is probably my last facets of collaboration post for a while. It is one of these series of articles that I feel has value, but I know it won’t be read by too many 🙂 Nevertheless, I do hope that anyone who has gotten this far through has gotten some value from this examination and sees value in the model to help users make more informed Information Architecture decisions for SharePoint and beyond. I certainly use it now in most engagements and hope that it can be improved upon as a tool, or somehow incorporated into some of the SharePoint standards or maturity model stuff that is out there.

Remember the most important thing of all though. Despite all I have said, it is still definitely all generation y’s fault!

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

Hiya

I recently participated in the Australian and New Zealand community SharePoint conferences and had a blast. First up, I was given the opportunity to keynote the Australian conference on day 2, where I spoke about SharePoint Governance home truths. It received very positive feedback and I was told by a lot of people that it really made them rethink their governance approach. In fact, in the New Zealand session, as I was going through some of the common mistakes people make, I could see people cringing as they knew they were guilty as charged. One attendee buried her head in her hands when I started talking about the “buffet of platitudes” (what is the “buffet of platitudes” you ask? Come to my class to find out! 🙂

The community challenge in Australia was a real highlight. This was a new addition to the conference where a group of conference attendees delivered a SharePoint solution for a not for profit organisation. WorkVentures was the organisation selected and the challenge progressed over three sessions, facilitated by SharePoint community leaders. Session one (Define and Design), was a business session which aimed to work through the high level requirements that WorkVentures had for an intranet, their aims for what they hope it would achieve and what they wanted included.  

This post was written on the assumption that you are familiar with some of Seven Sigma’s methods. If not, then we suggest you stop and read a couple of foundational posts first – especially if these maps do not mean much to you.

The Importance of Goal Alignment…

Nick Hadlee was supposed to chair this define and design session, but was unable to get to the Australian conference due to the earthquake events in Christchurch. As a result, I ended up inheriting this role, so I roped in Andrew Jolly to help me on this, because we have a lot in common and work in a similar way. User surveys had been conducted with WorkVentures staff and management, which gave some insights into potential focus areas for SharePoint. Even so, I had no way of knowing whether those potential focus areas made strategic sense. To resolve this issue, we examined WorkVentures 2009 Annual Report to understand their core purpose and strategic focus areas and various business units. After all, it is all well and good to develop some SharePoint functionality, but if you can’t see how that component helps achieve strategic objectives, how do you know it is the right thing to do?

The annual report proved to be a goldmine. It stated that WorkVentures had embarked on an enterprise improvement strategy prior to SharePoint and the community challenge being on the radar. This enterprise improvement plan, incorporating quality management, IT, HR and business strategy development, provided us the context to focus SharePoint as an enabler that fitted within the plan.

Andrew wasn’t due to fly into Sydney until the evening before the conference. So the day before the conference, Debbie Ireland and I visited WorkVentures on-site, meeting with the CEO, CFO and Marketing Director. The purpose of this visit was to ensure a shared understanding among us all of the alignment of the SharePoint community challenge outputs to the WorkVentures vision, purpose and strategic focus areas. From this conversation, which I mapped, some really interesting stories enabled them to pinpoint one of the key success factors for any SharePoint implementation at WorkVentures – “Bridging Silos”.

Ultimately, we identified four key areas of strategic focus for SharePoint that aligned to WorkVentures strategic goals. Below is a screenshot of the end-to-end alignment in map format . This map was used during the “define and design” conference session to help focus attendees on the purpose of SharePoint for this organisation, as well as noting the key areas that we would have to do well, to consider SharePoint a success.

Stories that led to the goal

Lawrence Luk – the CFO of WorkVentures told Debbie and I several captivating stories that surfaced the bridging silos area of focus. One interesting facet of WorkVentures was that staff from the whole organisation came together once per year – at the Christmas party. This is because each WorkVentures “division” or “business unit” is in effect a separate mini-company, with different goals, customers, vertical markets and regulatory requirements. Thus the problem of silos isn’t a negative one in the sense where dysfunctional “culture” is blamed as such. More that it was the simple fact that each business unit didn’t have a lot in common with other business units. The silo effect was a by-product and it was not driven by negative behaviours.

A great example of this was one particular business unit, Connect IT. It solicits organisations to donate old PC’s, which provides opportunities for skills development for disadvantaged people by teaching them how to refurbish these PC’s. These refurbished PC’s are then sold at low cost. A KPI for this program is the number of organisations donating old PC’s to WorkVentures to sustain ConnectIT. Lawrence had the experience where WorkVentures financial auditors, who had been doing the books for two years prior, asked him why they hadn’t been approached to donate PC’s as they had some. Lawrence realised that he almost missed a great opportunity to help the ConnectIT division achieve one of their key KPI’s. Furthermore, the auditor should never have had to ask themselves. Instead all WorkVentures staff should have this core KPI instilled and internalised so that they could proactively seek out these opportunities to help the other business units.

Another couple of interesting contextual facets illustrated that there were other forms of silo that went beyond a purely divisional basis:

• Most backoffice staff had never been to the Campbelltown office, where all of the “coal face” work took place with the community.
• English was a second language to many staff.
• Not all staff had their own PC’s.

These stories catalysed the conversation to many other examples of missed opportunities, where one business unit has the means to make a massive difference to the results of another. On reflection, it was realised that the nature of WorkVentures business units, being so independent of each-other, inevitably had a silo effect. There was a lack of awareness organisation-wide of the core KPI’s of each unit, hence bridging (not breaking) these silos became a key theme. If SharePoint was to have a long lasting, successful legacy, then it had to play a part in addressing this issue.

The define and design session live…

From there, with invaluable help from Andrew Jolly, we planned and then executed the requirements session with a conference audience of around one hundred people. We split the session up into several areas and the map below shows how we structured it.

After Microsoft did their intro, Debbie explained the context of the community challenge via a short PowerPoint presentation. I then took the chair and explained the vision and areas of focus map (the image above) and stressed to the audience that they were going to be participating in this session as well. I also stressed that no matter what solutions or ideas they came up with, they had to justify them against the four key focus areas, which I went through.

Then we got down to business where I dialogue mapped, with Andrew and I co-facilitating. We decided to focus people’s attention to the core goal of bridging silos as a topic area itself, and ask the audience how SharePoint could indeed bridge silos. We utilised three of the examples that Lawrence gave us  and then leveraged the wisdom of the (large) crowd to solicit ideas. Below is the dialogue map that shows the richness of this discussion (click to enlarge). You will see in this map that for each story told to us by Lawrence, we asked the question “How could we mitigate this with SharePoint?”. The purpose of asking the question this way helped the audience to focus on SharePoint as an enabler to a greater end – and not to be a tool looking for a problem to solve.

Given that we only had around 45 minutes to work with, Andrew and I could only spend around 15 minutes on the bridging silos area. But the map above shows that a lot of very valuable rationale from the audience was captured. The real benefit though was focusing the audience onto the broader goals and how SharePoint could enable them. This was critical to do, because now we had to switch focus from the lofty world of goal alignment to focusing on how SharePoint building blocks could be used to achieve specific ends.

We examined how SharePoint could augment the existing newsletter based method for dissemination of information within WorkVentures. We showed the audience what sample WorkVentures newsletter looked like and reviewed some of the key contextual aspects to newsletters within WorkVentures in terms of their creation, management, reach and format.  We reminded the audience about the importance of bridging silos and then called for ideas from the audience as to how SharePoint could improve the dissemination of news. What was particularly great about this session was that audience members began to relate SharePoint ideas against the key focus areas and identify some of the governance aspects that would be required to make it work.

For example, if you look at the map below (click to enlarge), one of the ideas for the newsletter was a fairly technical one: leveraging “word automation services to extract list or story items and create a PDF”. On first glance one might think “wow that’s fairly heavy” (and not to mention quite nerdy), but the justification for this idea was that it would still account for those WorkVentures users who do not have a PC and therefore access to the portal. Another idea was “Have backoffice staff create the content” on the basis that in doing so, they would get a better feel for coal-face issues that they typically do not see normally. When you think about it, this idea is not SharePoint at all, but more of a strategy for how SharePoint should be adopted and accountabilities for doing so (i.e. a governance approach!)

The key point here is that In both of these examples, audience members were clearly relating their ideas back to the previously established goals, which in turn were aligned to the WorkVentures vision, purpose and key strategic focus areas. Not bad for a couple hours work eh?

With the little time that we had left, we also looked at site navigation and structure, where the audience resolved that WorkVentures would be best served by a hybrid navigation model that was functionally driven primarily (i.e. task based navigation), but then divided into divisional areas. (As opposed to a purely organisational structure driven navigation model).

As you can see below, we made a point of always showing the four areas of focus for SharePoint overall, to ensure that decisions made were informed by them.

Conclusion

I have to say that given the timeframe and constraints, I think we did a great job of developing a shared vision for SharePoint, how it fitted into WorkVentures organisational and strategic context, and then focusing a diverse audience into looking at SharePoint building blocks through that lens. The dialogue maps were very rich, with some terrific ideas, and WorkVentures staff were thrilled to see the alignment of SharePoint to their strategic goals.

I use similar methods to this for non IT projects too, and I think that if we had a week to work on WorkVentures, we would have created something really special. Nevertheless, from my point of view, I think that the community challenge is an terrific idea, I enjoyed being a part of it, and I have to offer special thanks to Debbie and Andrew in particular for helping to make this into a really great mini-engagement. Hopefully we can do it all again next year.

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

Wow, Christian Buckley doesn’t waste any time. First up, watch this video then I will explain:

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

Monte Carlo simulations are cool – very cool. in this post I am going to try and out-do Kailash Awati in trying to explain what they are. You see, I am one of these people who’s eyes glaze over the minute you show me any form of algebra. Kailash recent wrote a post to explain Monte Carlo to the masses, but he went and used a mathematical formula (he couldn’t help himself), and thereby lost me totally. Mind you, he used the example of a drunk person playing darts. This I did like a lot and gave me the inspiration for this post.

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.