Rethinking SharePoint Maturity Part 1: Conditions Over Causes

Hi all

I have been hitting the books lately, doing various bits of research, all related to plans for a new book.  While most of that research would not be of too much interest to readers, some of it turned out to be quite profound and has significant implications for anybody interested in SharePoint governance/maturity/readiness, as well as risk management, organisational learning, knowledge management and team development. So if you are spending your days delving deep into the bowels of the SharePoint 2013 apps model, oAuth and Azure Service Busses, then maybe this article is not for you. However if you manage or are responsible for people or projects that delve deep into the bowels of the SharePoint in areas like the apps model, oAuth and Azure Service Busses, then I strongly suggest you read on.

My contention is that the SharePoint community in general is looking at “SharePoint maturity” in a sub-optimal way and this series of posts is going to try and rectify the situation. To do this, I have started by weaving together a few different threads of really interesting research from three unrelated sources, namely J R Hackman, the Wilder Research and the work of PhD candidate Stephen Duffield. We will look at what lessons we can learn from each before distilling all of their messages together. By the time we are done here, I hope to present you a practical tool to help you in your SharePoint endeavours, as well as many other projects and scenarios.

Who is J R Hackman?

From the late sixties, Richard Hackman spent his career researching and teaching about team performance, leadership effectiveness, and the design of self-managing teams and organizations. He died in 2013 and one of his last papers he published was called “From causes to conditions in group research.” I really loved this paper because, unlike many academic papers, it was easy to read and was full of wisdom. Hackman died of lung cancer, and I am not sure if he was aware of this when he wrote this paper, but you can see in the writing that he was reflecting on his long career and in my view, this paper is his swansong.

Hackman explained how he spent years and years examining the factors that make teams work really well. He studied hundreds of teams (not just project teams mind you, but sporting teams, orchestras and flight crews), with the aim to distil the causes of success. Each time Hackman thought he had the causes figured out he would create a model, plug his model into a stats program, work with real teams to see if the application of his model led to better performance.

On the surface, this approach seems like a logical thing to do. After all, if we can work out the magic levers that cause team success, then organisations would surely work better because they can start to pull those same levers. Unfortunately though, reality never fitted the models. Hackman realised he had been asking the wrong question…  (I will get to that in a moment).

Why Hackman matters for SharePoint?

So have you guessed why I told you about Hackman yet? Much of the SharePoint community (especially the good folks at Microsoft) are making the same mistake he did. To prove it, I am going to have to seriously injure a SharePoint sacred cow by looking at the most famous painting in the world.

Take a look at the diagram above. It is clearly a model of the famous Mona Lisa painting by Leonardo da Vinci. The implication in this model is that if you filled in the numbered areas with the right colours, you too could have your very own Mona Lisa. So what do you think? If we painted this model, would it look like the real Mona Lisa that is being modelled?

Unlikely… Instead it would look extremely amateurish and everyone instinctively realises this.

So with that, consider this SharePoint sacred cow – in the form of the diagram below. Recognise it? It’s the oft cited SharePoint 2010 governance poster. In SharePoint 2007, this was a downloadable document, but with SharePoint 2010, Microsoft realised that this didn’t work so well and replaced it with a friendly paint-by-numbers poster. Like our Mona Lisa above, the inference is that if you ensure you have done all of the things listed on this poster, your SharePoint success will be assured. However unlike the Mona Lisa example above, many people are blind to the fact that painting this particular model will also likely result in something amateurish.

The issue that afflicts both the Mona Lisa and SharePoint 2010 paint by numbers models is they are retrospective. They take the myth of the ideal solution and break it up into its constituent components (or causes). With the Mona Lisa example, someone has looked at the colours and shapes that are used in the painting and used that as a basis for you to create your own Mona Lisa. With the SharePoint governance example, they have taken the mythically perfect SharePoint installation and looked at all of the factors they believe comprise it.

But here is the thing… It took Leonardo da Vinci years to master the craft of painting and along that journey there would have been many missteps and reattempts. In the case of SharePoint governance model, it ignores the myriad of missteps that SharePoint teams inevitably go through in delivering lasting SharePoint solutions. Furthermore, the model infers that if you “painted the numbers” you can somehow bypass the inevitable missteps and get straight to a SharePoint Mona Lisa!

This leads to another issue. If your organisation has a strong blame culture, models like the SharePoint Governance one above can become a framework for blame apportionment.  Instead of helping the organisation to better unlock value, they end up hindering the organisation and having the opposite effect to what is intended. Witness the many organisations who end up drowning in the inevitable process and documentation that results from “painting the numbers” because this reduces anxiety of teams who feel that they need to be seen to be “doing things the right way.” Very little value has been unlocked of course, in fact barriers have been put up, but hey – people now feel good because at least their ass is covered by a document.

So we don’t have reality in the above poster – but a model of reality that infers the path to SharePoint success. Like Hackman discovered with teamwork and leadership, if you apply this model to reality and then measure the effect is has, often you find that it doesn’t stack up!

Back to Hackman…

I mentioned earlier that Hackman spent years trying to develop his “teamwork” equivalent of the SharePoint governance poster except the title would have been something like “5 Steps to creating great teams.” Each time Hackman applied the models he lovingly researched and developed, he found they did not make the difference in outcomes that he expected. Being an academic, he initially did what most academics do and tried to refine his models and then re-test them against real life teamwork. But this didn’t seem to work either and his models got no closer to affecting outcomes in a reliable fashion.

It was then that Hackman started to wonder whether he was leaning the ladder against the wrong wall. In other words, he wondered if trying to determine the causes of team efficacy by looking at successful teams retrospectively and developing causal models was the wrong approach. So he changed his focus and asked himself a very different question – a question that we all should be asking in all of our endeavours…

What are the enabling conditions that need to exist that give rise to great teams?

Now if, at this point, you think that this is the same question as “What are the causes of great teamwork” I beg to differ.

Consider this: if you have ever argued with someone about whether a SharePoint solution, a methodology or some process is great or completely sucks, eventually someone will say something like “Well it can work for the right organisation.” The implicit reality here is that under certain conditions, something that works for one organisation may completely suck for another (thereby causing a problem with the use of “best” practices). So the genius of Hackman is that he effectively said well stop arguing about whether one thing is better than another and focus on what the enabling conditions are instead. Think about it – if project managers and developers did this, we would be able to avoid enduring the endless “scrum is great” vs “scrum sucks” debates.

In terms of making better use of the SharePoint governance poster, one might ask “What conditions need to exist for our SharePoint governance approach to be successful?” In looking at SharePoint maturity, you would ask “What conditions needs to exist for our organisation to raise its SharePoint maturity level?”

In the case of Hackman, he re-examined all of his work on teams and synthesised it down to six conditions, arguing that irrespective of what else you did or what methodology you used, having these conditions tended to lead to better results. (By the way, the fact that there are six conditions is significant as you will find out in later posts.) Hackman did not attribute any one condition over any other, instead arguing that all were needed for teams to have a greater chance of being high performing. They were:

1. A real team: Interdependence among members, clear boundaries distinguishing members from non-members and moderate stability of membership over time
2. A compelling purpose: A purpose that is clear, challenging, and consequential. It energizes team members  and fully engages their talents
3. Right people: People who had task expertise, self-organised and skill in working collaboratively with others
4. Clear norms of conduct: Team understands clearly what behaviours are, and are not, acceptable
5. A supportive organisational context: The team has the resources it needs and the reward system provides recognition and positive consequences for excellent team performance
6. Appropriate coaching: The right sort of coaching for the team was provided at the right time

Now that you have seen Hackman’s conditions for teams, think about your SharePoint projects. Did you have these conditions in place when you started? If you had them, would this had led to better outcomes?

Conclusion

I believe that there is a huge misattribution of success or failure of SharePoint to the methods, processes and models used, rather than the conditions in which those processes are operating. While this attribution error persists, people will continue to get suckered into low-value debates about whether method X is better than method Y, or whether the “5 pillars” to SharePoint nirvana is better then the “6 steps.”

Also exacerbating this “causes over conditions” problem is that enabling conditions rarely get codified in procedures, governance models, bodies of knowledge or certifications. As a result, the very thing that leads to success (the conditions) is entirely absent from the models that we use and we end up with paint by number type posters like the SharePoint 2010 governance model. Don’t get me wrong, I don’t hate the model above, it’s just that when the enabling conditions are not there and the promise of nirvana is not reached, these models will be seen as flawed and people will look to the next model to address the gap. Witness how the SharePoint 2007 governance checklist was a 30 page document and in 2010 it became a poster. It appears that the cause attributed to the lack of success of that document was that the document was too long or too hard. My contention is that the format of the content had little to do with success or failure. Instead, I contend that most organisations attempting to use it did not have the right enabling conditions in place to begin with.

So Hackman, despite looking at a completely different discipline of teamwork and leadership, gives us a key foundation as to how to raise the bar of SharePoint solution delivery: Focus on enabling conditions rather than attributing causes!

The next question that arises is whether Hackman’s 6 conditions are directly applicable to SharePoint projects or beyond? To answer that question, we are going to continue on our research journey. In the next post, we will look at some really interesting work on the subject of collaboration by the Wilder Research Group.

Thanks for reading

Paul Culmsee

www.hereticsguidebooks.com