Rethinking SharePoint Maturity Part 4: The number of the beast…

Hi all

This is part four of a series I am writing on my ideas about how the SharePoint community can revitalise how SharePoint maturity is understood and communicated. If this is your first time reading this series, then I urge you to go back and read the first three posts in the series because I covered a bit of ground to get to here. For those of you who will not do that, here is a super quick recap.

As part of doing some book research, I came across three distinct bodies of work that I think can help Microsoft and their customers better understand, foster and cultivate SharePoint maturity. To set the scene, I started this series by taking a few cheap potshots at the SharePoint 2010 governance poster that many people use as a guide to ensure they are doing SharePoint “right”. I highlighted some of the less obvious risks with it, by comparing it to a paint by numbers representation of the Mona Lisa. While people seem to understand implicitly that colouring in a Mona Lisa template will not make it a Mona Lisa (far from it), there same cannot be said for our SharePoint paint by numbers poster. The result is a skewed version how SharePoint ‘maturity’ is perceived, because this poster ignores some critical factors.

To shine a spotlight on areas not covered by the above poster, I introduced you to the work of JR Hackman, who’s pioneering work in the area of leadership and team development contains important lessons for SharePoint teams. Hackman urges people to stop trying to look life through simplistic cause and effect lens of “If you do Z, you will get Y” and instead focus on the conditions that enable or disable success. Hackman, in his examination of leadership and the performance of teams, listed six conditions that he felt led to better results if they were in place (none of which make much of an appearance on the above poster):

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

I sometimes challenge agile development evangelists by saying “If Scrum was ‘the answer’ then there would be no need for Scrum coaches.” When you speak to good agile coaches, what they strive to do is create the sort of enabling conditions conducive to getting the best out of Agile – exactly what Hackman is urging us to do. Hackman’s insight is super important because It is incredibly common for people to say things like “now this will work for the right organisation…” or “this will work provided the right culture is there to support it,” but they do not elaborate further on what “right” actually is. Hackman challenges us to actually focus on the enabling conditions that underpinning a process, not the other way around.

To see if Hackman’s 6 conditions were applicable outside of his interest area of team development, I then examined the work done by the Wilder Research Group. This group published a book “Collaboration: What Makes It Work” which distilled the wisdom from 281 research studies on successful collaboration. Importantly for me, they looked at very different research than Hackman did, yet also broke it down to six quite similar focus areas:

1. Membership characteristics: Skills, attributes and opinions of individuals as a collaborative group, as well as culture and capacity of orgs that form collaborative groups
2. Purpose: The reasons for the collaborative effort, the result or vision being sought
3. Process and structure: Management, decision making and operational systems of a collaborative context
4. Communication: The channels used by partners to exchange information, keep each-other informed and convey opinions to influence
5. Environment: Geo-location and social context where a collaborative group exists. While they can influence, they cannot control
6. Resources: The financial and human input necessary to develop and sustain a collaborative group

Finally, I examined the work of Stephen Duffield, who took the Swiss Cheese model for risk management (which is popular in safety circles) and adapted it for organisational learning for projects. This is brilliant because the Swiss cheese model assumes that any one mitigation strategy has holes in it (hence the Swiss cheese metaphor). If you consider the SharePoint governance poster above as listing particular slices of cheese, then if you still have not met with the success you were hoping for, some important slices of cheese must be missing. So what are they?

To develop his project learning model (called SYLLK), Duffield distilled the wisdom over 500 papers on the topics of project lessons learned, knowledge management and risk management. Like above two research efforts, he also distilled it down to six key areas. Duffield’s slices of cheese were:

1. Learning: Whether individuals on the team were skilled, had the right skills for their role and whether they were kept up-skilled
2. Culture: What participants do, what role they fulfil, how an atmosphere of trust is developed in which people are encouraged, even rewarded for truth telling– but in which they are also clear about where the line must be drawn between acceptable and unacceptable behaviour”
3. Social: How people relate to each-other, their interdependence and how they operate as a team
4. Technology: Ensuring that technology and data supports outcomes and does not get in the way
5. Process: Ensuring the appropriate protocols drive people’s behaviour and inform what they do (gate, checklists, etc.)
6. Infrastructure: Environment (in terms of structure and facilities) that enable project outcomes

Why does all this stuff matter?

Now I am hoping this is not the case, but I would not be surprised that some readers have gotten to this point and are thinking “What the hell does all this have to do with SharePoint maturity?” (particularly if you have not read the 3 articles that preceded this one). So let’s address this one now…

Since 2009 I have taught a SharePoint Governance and Information Architecture class to BAs, PMs, CIOs, consultants, as well as developers and IT Pros. I’ve taught the class around the world and in every class I start by asking students to articulate what they feel is the hardest thing about SharePoint delivery. Take a look at the answers for yourself…

A Brisbane 2012 class said:

• Explaining what SharePoint is
• User uptake (“People do not like new things”)
• Managing proliferation of SharePoint sites
• Too much IT ownership (“Sick of IT people telling me that SP is the solution”)
• Users don’t know what they want
• Difficulties around SP ownership because of a lack of accountability

Not too many technical answers here it seems – in fact I am seeing connections to Hackman, Wilder and Duffield already. Looking at the seven points, they indicate we are missing some key enabling conditions like a compelling purpose, role clarity as well as the collaborative skills and attributes needed in the SharePoint team to address them (“User uptake” and “Difficulties around SP ownership because of a lack of accountability”). Perhaps we are also missing product skills (“proliferation of SharePoint sites”) and have an issue with process and structure, given the complaint of “too much IT ownership”.

Not convinced? For what it’s worth, Melbourne 2010 answered with:

• Every project is “new” (“Traditional ASP.NET web site development is ‘same old same old’)
• The solution is never the same as the initial design and the end client may not realise this. The implication is gaps between expectation and delivery
• Stakeholders don’t know what they want (“First time around what they sign off on is not what they want “)
• Projects launched as “IT projects” with no clear deliverable and no success indicators
• Lack of visibility as to what other organisations are doing
• Determining limits and boundaries (“Doing anything ‘practically’ in SharePoint is hard”).
• Managing expectations around SharePoint.
  • Clients with no experience think it can do everything
  • Difficulties getting information from and translating into design, so it can be implemented
• Legacy of bad implementations makes it hard to win the business owner
• Lack of governance
  • Viral spread of unmanaged sites
  • No proper requirements of “why”
  • No-one managing it

… and if you want to move further afield, Singapore 2012 said:

• Trying to deal with the sheer number of features
• “A totally different kind of concept”
  • A little knowledge can be dangerous
  • If you start with the wrong footing, you end up messing it up
• Trying to deal with “I need SharePoint”
• SharePoint for an external web site was difficult to use. Unfriendly structure for a public facing website
• Trying to get users to use it (Steep learning curve for users)
• The need for “deep discussion” to ensure SharePoint is put in for the right reasons. Without this, the result is messy, disorganised portals
• The gap between the business and IT results in a sub optimal deployment
• Demonstrating value to the business (SharePoint installed, but its potential is not being realized)
• Stakeholders not appreciating the implication of product versus platform
• You are working across the entire business (The disconnect between management/coalface)
• “Everything hurts with SharePoint”
• Facilitating the discussion at the business level is hard when your background is IT

Once again, if you start to distil the underlying themes behind the above answers, you can start to see how Hackman’s conditions are not met and how we are missing some of Duffield’s slices of cheese. So at this point if you are not convinced of the relevance of Hackman, Wilder and Duffield’s research by now, then I can confidently tell you two things…

• 1) I am not the SharePoint consultant that you need!
• 2) I am eventually going to become the SharePoint consultant you need! (You will see the light eventually )

The number of the beast…

Hopefully by now I have given you an appreciation of Hackman, Wilder and Duffield’s work and its relevance to SharePoint maturity. All of them have made highly rigorous research efforts, each asking different questions and utilising different research. Those of you who are more superstitiously minded might feel that I am meddling with the forces of darkness here, given that each of the three distilled 6 themes – 666

While there is no fire and brimstone nearby as I write this text, my next job was to indeed meddle with dark forces in the sense that I had to perform my own analysis of their work to draw out the commonalities and gaps. I figured that this would go a long way to laying the groundwork for gaps I see in SharePoint maturity. I won’t bore you with too much of the detail on this effort, except to say that I used Dialogue Mapping techniques to perform the synthesis. Below are a couple of screenshots illustrating the maps I built which give you a feel for what was done (click to enlarge)…

 

In a nutshell, I mapped out each authors six constructs and then mapped their behind the scenes detail. As expected, while some terminology differed somewhat , by in large there was a lot of commonality. I linked all the commonalities together in my maps and slowly, a new picture began to emerge…

Meddling with forces…

When you think about it, my synthesis of this research is not all that different from what SharePoint people do all the time when developing an information architecture to store organisational data in a meaningful and intuitive way. Just like when you have to determine an appropriate navigation structure for your SharePoint sites, with this work I had to first think about the basis for how I wanted to structure things.

First up, I found Duffield’s use of Swiss cheese model for risk inspiring and absolutely applicable for SharePoint maturity. The metaphor of holes in each slice of SharePoint governance “cheese” is vivid and confronting. The commonality in the answers I got to the above “What is the hardest thing about SharePoint?” question speaks to the fact that there are universally common missing slices of SharePoint governance cheese. I also felt strongly that there was huge potential for a clearer relationship between Hackman’s enabling conditions and Duffield’s lessons learnt. My logic was pretty basic here: Surely organisational lessons learnt (if actually learnt), should be enabling conditions next time around? It seemed to me that Hackman “conditions” and Duffield “lessons” are looking at the same thing, just from different points in time. So my intention was to develop my own Swiss cheese model using constructs (navigation labels if you will) that could be lessons learned focus areas as well as enabling conditions. That way one could truly gauge if lessons really had been learnt, because by definition they would be the enabling conditions to strive for next time around.

The other thing I was looking to do was to make things more actionable. Saying things like “have the right people”, “the right membership characteristics” or “the right culture” are not easily actionable because what exactly is “right” anyway? To that end, I think all of the authors suffered from creating constructs that were fine for their purposes, but were a bit wishy-washy when trying to be more directive and action-focused.

One particular anomaly I noticed when comparing the research was the lack of “purpose” as a construct in Duffield’s work. Hackman and Wilder both list “purpose” as one of their six factors, but Duffield’s SYLLK model makes no mention of purpose at all. I felt this needed to be addressed because lack of purpose is one of the classic symptoms of a wicked problem – a topic I have been writing about for years now. So for me, clarity of purpose is a very big slice of Swiss cheese!

I also felt that Hackman was a bit weak on some of the process/system areas. Duffield lists “process”, “technology” and “infrastructure” as key focus areas for lessons learnt on projects and the closest Hackman comes to that is “Supportive organizational context”. This is understandable when you remember that Hackman was talking only about teamwork in general. Nevertheless for our SharePoint context, I thought that Duffield was closer to the mark. Wilder turned out to be a bit in between – as they list “Process and structure” and “Resources” as two of their six areas.

There were other various things that influenced my synthesis as well, but none of them matter for this discussion. I guess you want to see the results no?

The CALL model

The result of this work is a model I have called the CALL model (Conditions to Actionable Lessons Learnt). Since this post is getting long, I will defer a detailed description of the model for the next article. But to whet your appetite, below is an image that shows what I ended up with. It adopts Duffield’s SYLLK model as its base, but highlights 8 enabling conditions (or learning areas), split across individual, team and organisation lines. Additionally, distinction is also made between the soft (people) factors and the harder (system) factors. The arrows are there to help convey the “defence in depth” idea of the Swiss cheese model.

If you go back to the start of this article and examine Hackman, Wilder and Duffield’s work, you will see all of them represented here, except I used more action focused labels. My contention is that these eight areas are what you should be considering when judging your organisation’s SharePoint maturity. The importance of considering these as enabling conditions, to be put in place right at the start cannot be underestimated. Going back to Hackman, here is what he said about the importance of enabling conditions for team performance (emphasis mine):

Let me go out on a limb and make rough estimates of the size of these effects. I propose that 60 per cent of the difference in how well a group eventually does is determined by the quality of the condition-setting prework the leader does. Thirty per cent is determined by how the initial launch of the group goes. And only 10 per cent is determined by what the leader does after the group is already underway with its work. This view stands in stark contrast to popular images of group leadership—the conductor waving a baton throughout a musical performance or an athletic coach shouting instructions from the sidelines during a game

I note that Hackman’s view doesn’t just stand in stark contrast to “popular images of group leadership” – it also stands in stark contrast to Microsoft’s SharePoint governance poster too!

Conclusion

Now I am sure that some of you are still trying to decipher the model above, or feel the urge to tell me that something is missing or that the labels for each of my slices of SharePoint maturity cheese don’t do it for you. In the next post I will spend more time going over the model and what each slice really means. Given the heritage of the source material that inspired it, I feel that it can be used in various SharePoint and non-SharePoint scenarios. So I will also spend some time talking about that.

Finally, I don’t know if any of you have noticed, but I didn’t actually develop this model just for SharePoint! In fact I have already used this model in various non-SharePoint ways too. We will also take a look at this…

thanks for reading

 

 

Paul Culmsee

www.hereticsguidebooks.com