Hi all

Welcome to part 2 about my research efforts that has led me to thinking a little differently in how we understand and measure SharePoint and organisational “maturity”. In the first post, I gave a glimpse into the work of JR Hackman, who had presented some really interesting ideas about what leads to outstanding team performance. In case you have not read the first post (damn you!), Hackman presented the notion that trying in vain to come up with the causes of team efficacy was a rather dumb idea and instead, looking at the conditions that enable great teams was a much more productive approach.

This notion of conditions over causes is really important to understand, because we all routinely get suckered into conversations about whether one process, approach or model is objectively “better” than another. This sort of discussion frustrates me and I usually find it all rather pointless because it all but ignores the underlying conditions that enabled or disabled things. As a result, we misattribute success or failure of SharePoint to how we used methods, processes and models, rather than focus on what really matters – the conditions under which those methods, processes and models operated.

Now Hackman was not looking at SharePoint projects when he came to this realisation. He was looking at leadership and the performance of teams in general. He synthesised his years of research work down to six conditions that he felt led to better results if they were in place. Those conditions are:

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

So I very much bought into Hackman’s conditions over causes argument, but wasn’t sure whether his six conditions were directly applicable to SharePoint projects. To find out, I got lucky, coming across some really great work on the subject of collaboration by the Wilder Research Group.

Collaboration: What Makes it Work

Earlier this year, I  bought a crapload of books on the topic of collaboration. One of them had the rather long title of “Collaboration: What Makes It Work, 2nd Edition: A Review Of Research Literature On Factors Influencing Successful Collaboration” written by Paul W. Mattessich, Marta Murray-Close, Barbara R. Morrisey and published by the Wilder Research Group.

This book is quite short – just over 100 pages, but it packs a heavy punch nevertheless. The core question asked in this book was “What makes the difference between your collaboration’s failure or success?” and it sought to answer the question by providing an in-depth review of lots (and lots and lots) of academic research on collaboration. In all, the authors examined more than 281 research studies on collaborative initiatives (and their success or failure) and synthesised them. I love these sort of meta-analysis studies, because I am lazy and its terrific when someone else has done the rigorous hard work!

Why Wilder matters for SharePoint

The intent of the report is to help readers expand their thinking about ways to help projects succeed, gain background information before beginning a collaboration, compare their situation with others, determine collaboration strategy including necessary ingredients, uncover and resolve trouble spots. It also provides a tool called the “The Collaboration Factors Inventory” which allows you to self-assess how your collaboration is doing against the success factors they came up with. Examples are also provided of how organizations have used the inventory as well as a case study illustrating how one collaboration assessed itself and how it  used the results to take action to improve its success.

Thus, it should be fairly obvious why this particular work should be of interest to SharePoint practitioners. After all, improving collaboration in organisations and teams is one of the core value propositions that underpins SharePoint and has done so for years now. Under the guise of “governance”, we do lots of work and produce processes (and usually lots of documentation) in the hope that we have put in the necessary plumbing for collaboration to take root and blossom. So when someone has taken the time to distil the learnings from 281 research efforts into collaborative success, there is bound to be valuable takeaways to be had for us SharePoint peeps – especially if our organisations have bought heavily into “social” features of the product.

Now while that all sounds good, there is another less obvious, but cooler reason to be interested in this book – especially given my examination of Hackman in part 1. The Wilder team found a total of 20 factors that were identified as “ingredients” for successful collaboration and guess how many categories they distilled them down to?

Six! – precisely the same number of conditions that Hackman distilled for great team performance. So, wouldn’t it be interesting to see how much overlap there is between what Hackman says are the six conditions for great teams versus Wilder’s six “differences” between collaboration failure and success?

I thought so too…

Back to the Wilder team…

So what are the factors that make a difference in successful collaboration identified by Wilder? Below are their twenty ingredients, divided into the aforementioned six categories…

• 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)
  • – Mutual respect, understanding and trust: Members of the collaborative group share an understanding and respect for each other and their respective organizations: how they operate, their cultural norms and values, limitations, and expectations.
  • – Appropriate cross section of members: To the extent that they are needed, the collaborative group includes representatives from each segment of the community who will be affected by its activities.
  • – Members see collaboration as in their self interest: Collaborating partners believe that they will benefit from their involvement in the collaboration and that the advantages of membership will offset costs such as loss of autonomy and turf.
  • – Ability to compromise: Collaborating partners are able to compromise, since the many decisions within a collaborative effort cannot possibly fit the preferences of every member perfectly.
• 2. Purpose: (The reasons for the collaborative effort, the result or vision being sought)
  • – Concrete, attainable goals and objectives: Goals and objectives of the collaborative group are clear to all partners, and can realistically be attained.
  • – Shared vision: Collaborating partners have the same vision, with clearly agreed-upon mission, objectives, and strategy. The shared vision may exist at the outset of collaboration, or the partners may develop a vision as they work together.
  • – Unique purpose: The mission and goals or approach of the collaborative group differ, at least in part, from the mission and goals or approach of the member organizations.
• 3. Process and structure: (Management, decision making and operational systems of a collaborative context)
  • – Members that share a stake in both process and outcome: Members of a collaborative group feel “ownership” of both the way the group works and the results or product of its work.
  • – Multiple layers of participation: Every level (upper management, middle management, operations) within each partner organisation has at least some representation and ongoing involvement in the collaborative initiative
  • – Flexibility: The collaborative group remains open to varied ways of organising itself and accomplishing its work
  • – Development of clear roles and policy guidelines: The collaborating partners clearly understand their roles, rights, and responsibilities, and they understand how to carry out those responsibilities.
  • – Adaptability: The collaborative group has the ability to sustain itself in the midst of major changes, even if it needs to change some major goals, members, etc., in order to deal with changing conditions.
  • – Appropriate pace of development: The structure, resources, and activities of the collaborative group change over time to meet the needs of the group without overwhelming its capacity, at each point throughout the initiative.
• 4. Communication: (The channels used by partners to exchange information, keep each-other informed and convey opinions to influence)
  • – Open and frequent communication: Collaborative group members interact often, update one another, discuss issues openly, and convey all necessary information to one another and to people outside the group.
  • – Established informal relationships and communication links: In addition to formal channels of communication, members establish personal connections — producing a better, more informed, and cohesive group working on a common project.
• 5. Environment: (Geo-location and social context where a collaborative group exists. While they can influence, they cannot control)
  • – History of collaboration or cooperation in the community: A history of collaboration or cooperation exists in the community and offers the potential collaborative partners an understanding of the roles and expectations required in collaboration and enables them to trust the process
  • – Collaborative group seen as a legitimate leader in the community: The collaborative group (and by implication, the agencies in the group) is perceived within the community as reliable and competent—at least related to the goals and activities it intends to accomplish.
  • – Favourable political and social climate: Political leaders, opinion-makers, persons who control resources, and the general public support (or at least do not oppose) the mission of the collaborative group
• 6. Resources: (The financial and human input necessary to develop and sustain a collaborative group)
  • – Sufficient funds, staff, materials and time: The collaborative group has an adequate, consistent financial base, along with the staff and materials needed to support its operations. It allows sufficient time to achieve its goals and includes time to nurture the collaboration.
  • – Skilled leadership: The individual who provides leadership for the collaborative group has organizing and interpersonal skills, and carries out the role with fairness. Because of these characteristics (and others), the leader is granted respect or “legitimacy” by the collaborative partners.

Now that you have seen Wilders six factors that influence successful collaboration, think about where you focus on your SharePoint projects in the name or guide of “governance”. How many of these factors did you consider when you started on your quest to use SharePoint for improved collaboration? Which of these really scream out at you as something worth pursuing? Go back in time and with hindsight, imagine if you had considered these and acted on it… Would it had led to better outcomes?

Conclusion

I have previously stated that collaboration is a classic SharePoint platitude, and chasing goals like “improved collaboration” are a sure fire way to create elaborate SharePoint solutions that miss the mark. Thus, this work by Wilder is a crucial resource in helping organisations determine what collaboration means to them. Furthermore, anyone interested in assessing SharePoint “readiness” (whatever your interpretation of readiness), would be well served to think about how they can incorporate the Wilder work into their readiness or maturity models. After all, how many other meta analyses of 281 studies on the topic have been done, eh?

Consider also that the Wilder team asked themselves a different question than Hackman. While Hackman framed his question around “What are the enabling conditions?” the Wilder team asked “What makes the difference?” This more broader question posed by the Wilder team explains a lot about their results. Some of their collaboration success factors can be seen as potential enabling conditions as Hackman described, whereas others are a more retrospective look on what successful collaboration looks like during and after collaboration has taken place. Consider also Hackman and the Wilder team used very different areas of research to come up with their answers. Wilder examined 281 case studies on successful collaboration, whereas Hackman used decades of research in teamwork and leadership. While research on collaboration might seem related to teamwork and leadership, in the world of academic research, you are talking about completely different bodies of knowledge.

Nevertheless, if you compare Hackman’s six conditions to Wilder’s six collaboration factors, there are more overlaps than there are differences. This I find exciting because it tells me that these independent research efforts are coalescing around the same themes. But I am going to defer a detailed examination of them both in context till a future post, because as I started to synthesise Hackman and Wilder together, I came across a third area of research that also led to some important insights – perhaps the most important ones of all… the work of PhD candidate Stephen Duffield in the area of risk and organisational learning on projects.

That my friends, is the topic of the next post…

Thanks for reading

Paul Culmsee

www.hereticsguidebooks.com

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. Continue reading “Rethinking SharePoint Maturity Part 1: Conditions Over Causes”

Hi all

We have all felt the pain of a meeting or workshop where no-one is engaged, the conversation is being dominated by the loudest or everyone is mired in a tangle of complexity and there is no sense of progress. Not only is it incredibly frustrating for participants, but it is really inefficient in terms of time and effort, reduced collaboration and can lead to really poor project outcomes.

The big idea behind the technique of Dialogue Mapping is to address this problem. Dialogue Mapping is an approach where a project manager or business analyst acts as a facilitator while visually mapping the conversation of a group onto a projected display. This approach reduces repetition by acknowledging contributions, unpacks implicit assumptions and leads to much better alignment and understanding among a group.

For SharePoint projects, this is a must and I have been using the technique for years now. Other SharePoint luminaries like Michal Pisarek, Ruven Gotz and Andrew Woodward also use the approach, and Ruven even dedicated a chapter to Dialogue Mapping in his brilliant Information Architecture book.

In Melbourne, I am going to be running a 2 day Introduction to Dialogue Mapping class to teach this technique. There are only 10 places available and this is one of the few public classes I will be running this year. So if you are attending the Australian SharePoint conference, or live near Melbourne and deal with collaborative problem solving, stakeholder engagement or business analysis, this is a great opportunity to come and learn this excellent problem solving technique.

Hope to see you there!

Paul

Hi all

I’ve been a little busy lately so haven’t had sufficient time to write many articles. This will likely continue for a while as I’m also planning the next heretical book with Kailash.

But the other day on a whim, I decided to record a short video on the topic of powerful questions. As I do more and more facilitation, strategic planning and team development work, I am constantly learning about the patterns of group conversation. This has helped me develop insights into the sort of questions that have the potential to cut through complexity to achieve breakthroughs in complex situations. I call these questions “powerful” for that reason.

It should be noted that a powerful question is not necessarily the question itself, but sometimes the the way a question is asked. To that end, in this first video, I take you through the best way I know to cut through organisational platitudes. Platitudes are phrases that often sound impressive and authoritative, ultimately hide the fact that there is not a lot of substance underneath them. While its easy to cite a blatant example like “best practice organisational excellence,” most of the time platitudes are used unconsciously and in much more subtle and dangerous ways. In fact often people ask questions or conduct workshops in such a way that actually encourage platitude answers.

So how do I bust or disarm a platitude? Watch this video to find out!

Now I plan to do a few of these videos, with each building on the last with a new powerful question. Also, I will utilise Compendium and Dialogue Mapping techniques, so you also get a better idea of the sort of non SharePoint work that myself and my colleagues get to perform. So please let me know what you think of the clip. (oh – before I forget, I strongly suggest you watch the video in full screen)

Thanks for reading

Paul Culmsee

www.hereticsguidebooks.com

Hi

In December I recorded a podcast with Nick Martin over at workshopbank.com. This was a fun interview for two reasons. Nick is a really smart guy and great to talk to, and it was Friday afternoon, close to Christmas and I was drinking a beer

In any event, these two videos present an overview of what Dialogue Mapping is all about, some of the case studies where I have used it, and a demonstration of its utility. You will learn:

• What Dialogue Mapping is and what it can do for you and your stakeholders
• Learn when to use Dialogue Mapping and when not to
• Learn how there is no setup or training that the participants have to go through when they’re in a Dialogue Mapping session
• Learn how all participants feel like they’re being heard when being Dialogue Mapped
• Hear an great case study when I used Dialogue Mapping for the first time…
• Hear how as a mapper, you don’t need to be an expert in the subject being discussed
• Glean a few insights about the Heretics guide to best practices book

To view the interview and demonstration, head on over to workshopbank.com

thanks for reading

Paul Culmsee

www.hereticsguidebooks.com

Hi all

One of the conversation areas in SharePoint life that is inevitably complex is that of records management since there are just as many differing opinions on records management as there are legal jurisdictions and different standards to choose from. Accordingly, a lot of confusion abounds as we move into a world dominated by cloud computing, inter-agency collaboration, changes in attitudes to information assets via the open data/government 2.0 movements, and of course, the increasing usage of enterprise collaboration systems like SharePoint. As a result, I feel for record managers because generally they are an unloved lot and it is not really their fault. They have to meet legal compliance requirements governed by various acts of legislation, but their job is made all the harder by the paradox that the more one tries to enforce compliance, the less likely one is to be compliant. This is because more compliance generally equates to more effort on the part of users for little perceived benefit. This results in direct avoidance of using record management systems or the plain misuse of those systems (both which in turn results in a lack of compliance).

As it happens, my company works with many government agencies primarily in the state of Western Australia, both at a state agency and local government level. We have seen most enterprise document management systems out there such as HP Trim, Objective, Hummingbird/OpenText and have to field questions on how SharePoint should integrate and interact with them (little known fact – I started my career with Hummingbird in 1998 when it was called PCDOCS Open and before SharePoint existed).

Now while I am sympathetic to the plight of your average records management professional, I have also seen the other side of the coin, where records management is used to create fear, uncertainty and doubt. “You can’t do that, because of the records act” is a refrain that is oft-levelled at initiatives like SharePoint or cloud based solutions to try and shut them down or curtail their scope. What makes it hard to argue against such statements is that few ever read such acts (including those who make these sort of statements). So being a sucker for punishment, I decided to read the Western Australian State Records Act 2000 and the associated standard on digital recordkeeping, published by the State Records Office. My goal was to understand the intent of these standards and the minimum compliance requirements they mandate, so I could better help clients integrate potentially disruptive tools into their compliance strategies.

I did this by starting out with the core standard in Western Australia – SRC Standard 8: Digital Recordkeeping. I created an IBIS Issue Map of this standard using Compendium software. What I soon discovered was that Standard 8 refers to other standards, such as Standard 2: Recordkeeping Plans and Standard 3: Appraisal of Records. That meant that I had to add these to the map, as well as any other documents they referred to. In the end, I followed every standard, policy or guideline in a recursive fashion, until I was back at the digital recordkeeping standard where I started. This took a while, but I eventually got there. You can click the image below to examine the standards in all of their detail and watch the video to see more about how I created it.

Now I need to make it clear that my map is not endorsed by the State Records Office, so it is provided as-is with a disclaimer that it is not intended to drive policy or be used as anything more than an example of the mapping approaches I use. I felt that by putting the standards into a IBIS based issue map, I feel I was able to reduce some of the complexity of understanding them, because now one can visually see how the standards relate to each other. Additionally, by taking advantage of Compendiums ability to have the same node in multiple maps, it allowed me to create a single ‘meta map’ that pulled in all of the compliance requirements into a single integrated place. One can look at the compliance requirements of all the standards in one place and ask themselves “Am I meeting the intent of these standards?”

Reflections…

In terms of my conclusions undertaking this work, there are a few. For a start, everything is a record, so people should just get over the whole debate of “is it or isn’t it”. In short, if you work for a government agency and are doing actual work, then your work outputs are records. The issue is not what is and is not a record, but how you control and manage them. Secondly, the notion that there has to be “one RMS system to rule them all” to ensure compliance is plain rubbish and does not stand up to any form of serious scrutiny. While it is highly desirable to have a single management point for digital recordkeeping, it is often not practical and insistence in doing this often makes agencies less compliant because of the aforementioned difficulties of use, resulting in passive resistance and outright subversion of such systems. It additionally causes all sorts of unnecessary stress in the areas of new initiatives or inter-agency collaboration efforts. In fact, to meet the intent of the standards I mapped, one by definition, has to take a portfolio approach to the management of records as data will reside in multiple repositories. It was Andrew Jolly who first suggested the portfolio idea to me and provided this excellent example: There is nothing stopping records management departments designating MS Exchange 2013 Site mailboxes as part of the records management portfolio and at the same time having a much better integrated email and document management story for users.

For me, the real crux of the digital records management challenge is hidden away in SRC Standard 8, Principle 5 (preservation). One of the statements of compliance in relation to preservation is that “digital records and their metadata remain accessible and usable for as long as they are required in accordance with an approved disposal authority.”  In my opinion, the key challenge for agencies and consultancies alike is being able to meet the requirements of Disposal Authorities (DA’s) without over burdening users. DA’s are the legal documents published by the State Records Commission that specify how data is handled in terms of whether it is archived or deleted and when this should happen. They are also quite prescriptive (some are mandated), and their classification of content from a retention and disposal point of view poses many challenges, both technically and organisationally. While for the sake of size, this article is not going to get into this topic in detail, I would advise any SharePoint practitioner to understand the relevant disposal authorities that their organisation has to adhere to. You will come away with a new respect for the challenges that record managers face, an understanding on why they use the classification schemes that they do, why records management systems are not popular among users of the systems and why the paradox around “chasing compliance only to become non-compliant” happens.

Maybe you might come away with some insights on how to better integrate SharePoint into the story? Then you can tell the rest of us

Thanks for reading

Paul Culmsee

paul.culmssee@sevensigma.com.au

Hi all

This message comes to you from New Zealand where I have been for the last three weeks with the family. While here, I am doing a talk on Dialogue Mapping for Tepu (a partnership between Unitec & Rosebank Business Association). If you are in Auckland or close by, then register to attend this free event and learn more about the techniques that inspired the award winning Heretics Guide to Best Practices book. I will provide a background to Dialogue Mapping and emergent design practice, cover some case studies and provide a live demo.

If you are in any sort of role that has to deal with complex problems (strategy, planning and policy development, sustainability, stakeholder engagement, etc), then the session should be well worthwhile.

When: Thursday, Jan. 31st
Where: Building 172, Room 2018, Unitec Mt. Albert campus

Door opens at 8:30 for coffee & tea
Presentation and workshop 9:00 a.m. – 10:00 a.m.
Coffee and networking, closes at 10.30a.m

Although this is not a SharePoint specific event, I urge any SharePointers in Auckland to come and be part of the discussion. The registration site with further detail can be found here:

www.catalystco.eventbrite.com

Thanks for reading

Paul Culmsee

www.hereticsguidebooks.com

Hi and welcome to the latest exciting instalment in my epic series of posts on my confessions of a post SharePoint architect. I was motivated to write this series because the mild mannered shrinking violet known as Bjorn Furuknap wrote an insightful series of articles on what it takes to be a SharePoint professional. I had always planned to write on this topic as well and opted to frame it as SharePoint “confessions” because some of my approaches do not always seem mainstream (but work!) so it feels like I am confessing my sins for using them. I chose to use the word “(post)” because SharePoint is not my fulltime gig anymore. I am very lucky to do a lot of non IT work, helping organisations deal with highly complex problems. This side of my work is where most of my insights have come from and what inspired the Heretics Guide to Best Practices book.

Thus far, we have traversed a fair bit of territory via the use of f-laws – home truths about successful SharePoint delivery that focuses on areas often overlooked for various reasons. In case this is your first visit to this series, we have covered 6 f-laws so far and I strongly suggest that you read them first…

• F-law 1: The more comprehensive the definition of governance, the less anybody will actually understand it
• F-law 2: Three is no point asking users, who don’t know what they want, to tell you what they want
• F-law 3: The chances of SharePoint success is inversely proportional to how long it takes to come up with s measurable KPI
• F-law 4: Most SharePoint objectives are platitudes: They say nothing but hide behind words
• F-law 5: Confidence is the feeling you have until you understand the problem
• F-law 6: Geeks are far less important than they think they are

In this post, we are continuing with f-law 6, focusing on aspects to SharePoint delivery where geeks have a habit of being crap…

No matter how much you polish it…

In Australia, there is an old saying, that no matter how much you try and polish a turd, it will always be a turd. In the last post, I more or less stated that some geeks have a tendency to polish turds. They do this because of a combination of an inflated view of their self-importance, mental scars from ghosts of disaster recoveries past, and a bias toward something I termed dial tone governance.

Dial tone governance refers to all of the stuff that ensures that the SharePoint platform remains pristine, consistently reliable and high performing. I noted in the previous post that this echoes what quality assurance aspires to do. This type of IT assurance for SharePoint is completely necessary, but it is definitely not sufficient. If it was, lavish praise would be heaped upon us heroic geeks for consistent fantastic SharePoint delivery.

In the last post I also channelled Neo from the Matrix and suggested that being a hero like Neo is a thankless job since, for many stakeholders, the assurance of dial tone is assumed to be there. Whether this is right or wrong is not the point, because geeks do not survive their own hypocrisy on this matter. After all, no one thanks the telephone company for providing them with dial tone when they pick up the phone to make a call – they just get pissed when it is not there.

Now while I can sympathise with unloved telephone company engineers, they actually have it easy because once they provide dial tone, their job is done. This also applies to tools like Microsoft Exchange, Virtualisation, IP networks and storage. Unfortunately with SharePoint, successful delivery is not judged on whether the level of dial tone is appropriate. At the end of the day no amount of turd polishing via awesome support, consistent process or fast response time will make a crap solution anything other than a crap solution.

So this raises a couple of questions that readers should consider:

1. Am I focusing too much (or too little) on dial tone governance?
2. What are the other governance areas that I need to focus on?

As it happens, I have some data we can use to answer them.

The hardest thing…

In 2009 I created my SharePoint Governance and Information Architecture class. The class is attended by a wide variety of roles, from BAs to PMs, CIOs as well as developers and tech dudes. It has been delivered around the world with students representing just about every industry sector (including Microsoft employees). This combination of varied audience, varied industry sectors and geographic location has provided a lot of insight, because at the start of every class, I ask students to introduce themselves, and tell the class what they feel is the hardest thing about SharePoint delivery and I dialogue map the answers.

Can you see the logic of this question? By listing all of the areas that is hard about SharePoint delivery, what should emerge are the areas we should be focusing on. Why? Well the hard bits are likely to be the areas of most risk when it comes to a failed or stressed deployment.

So let’s go through the answers given to me from a few SPGovIA classes. Maybe there are some consistent patterns that emerge. It will also be interesting to see how much of it is dial tone governance.

Brisbane 2012 and Melbourne 2010

First up, here are the answers I captured from a small class in Brisbane in 2012:

• 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

For me some interesting things emerge already, but before we get into detail, let’s look at a Melbourne class answering this question two years earlier and see if any consistent patterns.

• Every project is “new” (“Traditional ASP.NET web site development is ‘same old same old’)
• In SharePoint you can do things in many ways so the initial design takes longer
• 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”).
  • For example: We improved Ux in certain areas, but to extend to the entire feature set would take too long”
• 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

Some analysis…

The first thing that I notice is that if you go back to the start of this post and review the six f-laws, four are clearly represented here. We have stakeholders not knowing what they want which makes design hard (f-law 2), the gap between expectation and delivery (f-law 5), the problem of SharePoint projects being done as “IT projects” (f-law 6) with “no clear deliverables and no success indicators” (f-law 3). Other themes include lack of accountability and managing viral growth of sites, but the overwhelming theme that comes through for me is that of managing user expectations and buy-in.

A telling part about what is listed is that aside from the ever present issue of managing site sprawl, not too much of it is dial tone at this point. To see if this pattern continues, let’s head to Auckland New Zealand and see if the Kiwis are any more geeky than their Australian cousins…

Auckland 2011

• Gap between expectations and reality
• Accountabilities and role clarity around delivery
• Knowledge transfer and ongoing maintenance (“Not everything is written down and when people leave, key critical information is lost. For example: Business rules set up at the start are lost over time”)
• Helping people change practices (“Getting people to use it “)
• Managing the growth over time (“the challenge of a large user base wanting to use it in different ways”)
• It’s a big, complex product
• The perception of “mystique” around SharePoint (“hard to know what not to do”)
• Seen as another “IT service”
  • product selected because it’s Microsoft
  • the people who chose the product/delivering the product are IT
• Translating the capabilities of the product to the needs of the user
  • Getting the business to understand SharePoint’s capability
  • Restrictions vs freedom
• Ramp up time: The learning curve across all roles (tech and non tech)
• The challenge of user requirements: Knowing the right questions to ask

Some more analysis…

It is clear that the themes that emerged from the two classes in Australia are also consistent here. The issue of stakeholder expectations came up straight away as well as the “IT driven project” issue (“seen as another ‘IT’ service”). Once again, the only real dial tone governance issue was the problem of managing site growth over time, but even then, it was framed more of an expectations issue (“the challenge of a large user base wanting to use it in different ways”). F-law 4 also copped a mention in terms of knowing the right questions to ask to get the right user requirements.

The additional themes that I noted from this group were:

• complexity (“It’s a big, complex product“)
• change management (“helping people change practices”)
• the high learning curve of SharePoint for users
• knowledge transfer over time the challenge of a large user base wanting to use the product in different ways.

<geek alert>Now if you are reading this and you manage complex infrastructure, let me assure you that tech people were in the classes</geek alert>. Also, since Australia and New Zealand are culturally quite similar to each other, it could be argued that we are not taking into account different cultures. So let’s find out what a 2012 class in Singapore had to say…

Singapore 2012

• 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

Final Analysis

Once again the answers provided by Singapore attendees is extraordinarily consistent with the other three classes we looked at. User expectations and adoption were at the forefront, complexity was there, as was the business/IT disconnect as well as demonstrating business value. The theme of platitudes (f-law 4) and confusing the means from the ends (f-law 1) was apparent with the comment about dealing with the “I need SharePoint” issue.

I also note that the Singapore group seemed to have a greater recognition of their weaknesses – particularly with SharePoint as a “totally different type of concept” quote and last comment about difficulties facilitating discussion “when your background is IT”. I also noted one potential dial-tone comment about the difficulty of deploying SharePoint as a public facing website. Another emergent complexity related theme here is the perennial problem of SharePoint’s ample supply of features (and caveats) which risks an inappropriate up-front design decision that has negative consequences later (“Trying to deal with the sheer number of features,“ “A little knowledge can be dangerous” & “If you start with the wrong footing, you end up messing it up.”)

Finally, I particularly liked the comment about the “need for “deep discussion” to ensure SharePoint is put in for the right reasons” – that one was made by one of the Microsofties who attended the class.

Conclusions and takeaways

My own conclusion from this examination is that the responses from class attendees illustrate that dial tone governance (which is best termed as IT assurance) is necessary, but certainly not sufficient. The focus on IT assurance is a reflection of the lens that IT looks through. After all, when your performance is judged on keeping things running smoothly and reliably, it makes sense that you will focus on this.

But as illustrated by the responses, it seems that IT assurance isn’t all that hard. If it was, then why didn’t dial tone topics come up with more frequency in the responses?

So IT people, always remember f-law 1. The word ‘govern’ means to steer. We aim to steer the energy and resources available for the greatest benefit to all. Assurance on the other hand provides confidence in a product’s suitability for its intended purpose. It is a set of activities intended to ensure that customer requirements are satisfied in a systematic, reliable fashion. (I didn’t make that up by the way – that is how the ISO9000 family of standards for quality management described assurance).

The key takeaway is that to be effective and successful you actually need to apply both governance and assurance. You cannot have one without the other. Whether you have the balance right between dial tone and all the other stuff is for you to decide. So rather than focus on the stuff you already know well, perhaps it is worth asking yourself what you find hard and focus there as well.

Thanks for reading

Paul Culmsee

www.hereticsguidebooks.com

Hello kung-fu students and thanks for dropping by to complete your platitude training. If you have been dutifully following the prior 5 articles so far in this series, you will have now earned your yellow belt in platitude kung-fu and should be able to spot a platitude a mile away. Of course, yellow belt is entry level – like what a Padwan is to a Jedi. In this post, you can earn your black-belt by delving further into the mystic arts of the (post) SharePoint architect and develop simple but effective methods to neutralise the hidden danger of platitudes on SharePoint projects.

If this is your first time reading this series, then stop now! Go back and (ideally) read the other articles that have led to here. Now in reality I know full well that you will not actually do that so read the previous post before proceeding. Of course, I know you will not do that either, so therefore I need to fill you in a little. This series of articles outline much of what I have learnt about successful SharePoint delivery, strongly influenced from my career in sensemaking. I have been using Russell Ackoff’s concept of f-laws – truth bombs about the way people behave in organisations – to outline all of the common mistakes and issues that plague organisations trying to deliver great SharePoint outcomes.

So far in this series we have explored four f-laws, namely:

• f-Law 1: The more comprehensive the definition of governance is, the less it will be understood by all
• f-Law 2: There is no point in asking users, who don’t know what they want, to say what they want
• f-Law 3: The probability of SharePoint success is inversely proportional to the time taken to come up with a measurable KPI
• f-Law 4: Most SharePoint governance objectives are platitudes. They say nothing but hide behind words

In the last post, we took a look at the danger of conflating a superlative (like biggest, best, improved and efficient) with a buzzword like (search, portal, collaboration, social). The minute you combine these and dupe yourself into thinking that you now have a goal, you will find that your project starts to become become complex, which in turn results in over-engineered solutions solving everything and anything, and finally your project will eventually collapse under its own weight after consuming far too many financial (and emotional) resources.

This is because the goal you are chasing looks seductively simple, but ultimately is an illusion. All of your stakeholders might use the same words, but have very different interpretations of what the goal actually looks like to them. The diagram that shows the problem with this is below. On the left is the mirage and to the right is the reality behind the mirage. Essentially your fuzzy goal actually is a proxy for a whole heap of unaligned and often unarticulated goals from all of your stakeholders.

Now in theory, you have read the last post and now have a newly calibrated platitude radar. You will sit at a table and hear platitudes come in thick and fast because you will be using Ackoff’s approach of inverting a goal and seeing if a) the opposite makes any logical sense and b) could be measured in any meaningful way. As an example, here are three real-world strategic objectives that I have seen adorning some wordy strategic plans. All three set off my platitude radar big time…

“Collaboration will be encouraged”

“A best-practice collaboration platform”

“It’s a SharePoint project”

I look at the first statement and think “so… would you discourage collaboration? Of course not.” Ackoff would take a statement like that and say “Stop telling me what you need to do to survive, and tell me what you need to do to thrive”.

What do you mean by?

So if I asked you how to unpack a platitude into reality, what might you do?

For many, it might seem logical to ask people what they really mean by the platitude. It might seem equally logical to come up with a universal definition to bring people to a common understanding of the platitude. Unfortunately, both are about as productive as a well-meaning Business Analyst asking users “So, what are your requirements?”

With the “what do you mean by [insert platitude here]” question, the person likely won’t be able to articulate what they mean particularly well. That is precisely why they are unconsciously using the platitude in the first place! Remember that a platitude is a mental shortcut that we often make because it saves us the cognitive effort of making sense of something. This might sound strange that we would do this, but in the rush to get things done in organisations, it is unsurprising. How often do you feel a sense of guilt when you are reflecting on something because it doesn’t feel like progress? Put a whole bunch of people feeling that way into a meeting room and of course people will latch into a platitude.

By the way, the “mental shortcut” that makes a platitude feel good seems to be a part of being human and sometimes it can work for us. When it works, it is called a heuristic, When it doesn’t its called a cognitive bias. Consult chapter 2 in my book for more information on this.

Okay, so asking what someone means by their platitude has obvious issues. Thus, it might seem logical that we should develop a universal definition for everyone to fall in behind. If we can all go with that then we would have less diversity in viewpoints. Unfortunately this has its issues too – only they are a little more subtle. As we discovered in part 2 of this series appropriately entitled “don’t define governance”, definitions tend to have a limited shelf life. Additionally, like best-practice standards, there are always lots of them to choose from and they actually have an affect of blinding people to what really matters.

So is there a better way?

It’s all in the question and its framing…

If there is one thing I have learnt above all else, is that project teams often do not ask the right question of themselves. Yet asking the right question is one of the most critical aspects to helping organisations solve their problems. The right question has the ability to cast the problem in a completely different light and change the cognitive process that people are using when answering it. In other words, the old saying is true: ask a silly question, get a silly answer.

Let me give you a real life example: Chris Tomich is a co-owner of Seven Sigma and was working with some stakeholders to understand the rationale for how content had been structured in a knowledge management portal. Chris is a dialogue mapper like me – and he’s extremely good at it. One thing Dialogue Mapping teaches you is to recognise different question types and listen for hidden questions. The breakthrough question in this case when he got some face time with a key stakeholder and asked:

• What was your intent when you designed this structure for your content?

The answer he got?

• “Well, we only did it that way because search was so useless”
• “So if I am hearing you, you are saying that if search was up to scratch you would not have done it that way”
• “Definitely not”

Neat huh? By asking a question that took the stakeholder back to the original outcome sought for taking a certain course of action, we learnt that poor search was such a constraint they compensated by altering page template design. Up until that point, the organisation itself did not realise how much of an impact a crappy search experience had made. So guess where Chris focused most of his time?

In a similar fashion, my platitude defeater question is this:

So if we had [insert platitude here], how would things be different to now?

Can you see the difference in framing compared to “what do you mean by [insert platitude here]?”. Like Chris with his “What was your intent”, we are getting people to shift from the platitude, to the difference it would make if we achieved the platitude. No definitions required in this case, and the answer you will get almost by definition has to be measurable. This is because asking what difference something would make involves a transition of some kind and people will likely answer with “increased this”  or “decreased that”.

Now be warned – a hard core middle manager might serve you up another platitude as an answer to the above question. To handle this, just ask the question again and use the new platitude instead. For example:

• Me: Okay so if you had improved collaboration, how would things be different to now?
• Them: We would have increased adoption
• Me: And what difference would that make to things?

I call this the KPI question because if you keep on prodding, you will find themes start to emerge and you will get a strong sense of potential Key Performance Indicators. This doesn’t mean they are the right ones, but now people are thinking about the difference that SharePoint will make, as opposed to arguing over a definition. Trust me – its a much more productive conversation.

Now to validate that these emerging KPI’s are good ones, I ask another question, similarly framed to elicit the sort of response I am looking for…

What aspects should we consider with this initiative to [insert platitude here]?

This question is deliberately framed as neutral is possible. I am not asking for issues, opportunities or risks, but just aspects. By using the term aspects I open the question up to a wider variety of inputs. Like the KPI question above, it does not take long for themes to emerge from the resulting conversation. I call this the key focus area question, because as these themes coalesce, you will be able to ensure your emerging KPI’s link to them. You can also find gaps where there is a focus area with no KPI to cover it. As an added bonus, you often get some emergent guiding principles out of a question like this too.

The thing to note is that rather than follow up with “what are the risks?” and “what should our guiding principles be?”, I try and get participants to synthesize those from the answers I capture. I can do this because I use visual tools to collect and display collective group wisdom. In other words, rather than ask those questions directly, I get people to sort the answers into risks, opportunities and principles. This synthesis is a great way to develop a shared understanding among participants of the problem space they are tackling.

If we were unconstrained, how would we solve this problem?

This is the purpose question and is designed to find the true purpose of a project or solution to a problem. I don’t always need to use this one for SharePoint, but I certainly use it a lot in non IT projects. This question asks people to put aside all of the aspects captured by the previous question and give the ideal solution assuming that there were no constraints to worry about. The reason this question is very handy is that in exploring these “pie in the sky” solutions, people can have new insights about the present course of action. This permits consideration of aspects that would not otherwise be considered and sometimes this is just the tonic required. As an example, I vividly recall doing some strategic planning work with the environmental division of a mining company where we asked this exact question. In answering the question, the participants had a major ‘aha’ moment which in turn, altered the strategy they were undertaking significantly.

Note: If you want some homework, then check Ackoff’s notion of idealised design and the Breakthrough Thinking principle called the purpose principle. Both espouse this sort of framed question.

Sharpening the saw…

Via  the use of the above questions, you will have a  better sense of purpose, emergent focus areas and potential measures. That platitude that was causing so much wheel spinning should be starting to get more meaty and real for your stakeholders. For some scenarios, this is enough to start developing a governance structure for a solution and formulating your tactical approaches to making it happen. But often there is a need to sharpen the saw a bit and prioritise the good stuff from the chaff. Here are the sort of questions that allow you to do that:

No matter what happens, what else do we need to be aware of?

This question is called the criterial question and I learnt it when I was learning the art of Dialogue Mapping. When Dialogue Mapping you are taught to listen for the “no matter what…” preamble because it surfaces assumptions and unarticulated criteria that can be critical to the conversation and will apply to whatever the governance approach taken. Thus I will often ask this question in sessions, towards the end and it is amazing what else falls out of the conversation.

What are the things that keep you up at night?

I picked this up from reading Sue Hanley’s excellent whitepaper a while back and listening to hear speak at Share2012 in Melbourne reminded me why it is so useful. This question is very cleverly framed and is so much better than asking “What are your issues?”. It pushes the emotive buttons of stakeholders more and gets to the aspects that really matter to them at an gut level rather than purely at a rational level. (I plan to test out dialogue mapping a workshop with this as the core question sometime and will report on how it goes)

What is the intent behind [some blocker]?

This is the constraint buster question and is also one of my personal favourites. If say, someone is using a standard or process to block you with no explanation except that “we cannot do that because it violates the standards”, ask them what is the intent of the standard. When you think about it, this is like the platitude buster question above. It requires the person to tell you the difference the standard makes, rather than focus on the standard itself. As I demonstrated with my colleague Chris earlier, the intent question is also particularly useful for understanding previous context  by asking users to outline the gap between previous expectation and reality.

Conclusion…

To there you go – a black belt has been awarded. Now you should be armed with the necessary kung-fu skills required to deflect, disarm and defeat a platitude.

Of course, knowing the right questions to ask and the framing of them is one thing. Capturing the answers in an efficient way is another. For years now, I have advocated the use of visual tools like mind mapping, dialogue mapping and causal mapping tools as they all allow you to visually represent a complex problem. So as we move through this series, I will introduce some of the tools I use to augment the questions above.

Thanks for reading

Paul Culmsee

Hi all

Just to let you know that in October, I will be in the UK to run a SharePoint Governance and Information Architecture class with Andrew Woodward. Additionally, I am very pleased to offer a Dialogue Mapping introductory course for the first time in the UK as well. Work has been extremely busy this year and this is my only UK/Europe trip in the next 9-12 months. In short, this is likely to be a once-off opportunity as I travel less and less these days.

Introductory Dialogue Mapping October 17-18, 2012

• Venue: The Custard Factory, Birmingham, UK
• Cost: £995

The introductory Dialogue mapping class will arm you with a life skill that can be used in many different situations and has changed my career. If you have been following my “confessions of a (post) SharePoint Architect” series, a lot of the content is based on my experiences of Dialogue Mapping many different projects in many different industries. Dialogue Mapping is a novel, powerful and inclusive method to elicit requirements, capture knowledge and develop shared understanding in complex projects, such as SharePoint or broader strategic planning. It was pioneered by CogNexus Institue in California, and is used by NASA, the World Bank and United Nations.

My book, “The Heretics Guide to Best Practices” is based on my Dialogue Mapping work and if you liked the book, then I know you will love the course!

What does a map look like? Check out my map of the AA1000 Stakeholder Engagement Standard or my synthesis on problems with intranet search below…

I should stress that this is not a SharePoint course. If you are an organisational development practitioner, facilitator, reformed project manager, all-round agitator or are simply interested in helping groups make sense of complex situations, then you would find this class to be highly valuable in your personal arsenal of tools and techniques. When performed live during a facilitated session, it is a highly efficient and engaging experience for participants.

Please note that seats are limited in this class and it cannot be more than  10.

• Date: October 17-18, 2012
• Venue: The Custard Factory, Birmingham, UK
• Cost: £995

Aligning SharePoint Governance & Information Architecture to Business Goals October 15-16 2012

• Venue: The Custard Factory, Birmingham, UK
• Cost: £995
• Limited seats available: 12

Previous Master Class Feedback:

• "This course has been the most insightful two days of my SharePoint career"
• "…Was the best targetted and jargon free course I’ve ever been on"
• "Re-doing my draft SharePoint Governance. Moving away from blah, blah technical stuff"
• "Easily one of the best courses I’ve been to and has left me wanting more!"
• "Had a great couple of days at #SPIAUK loving IBIS"
• "The content covered was about the things technically focussed peeps miss.."

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. Based upon content provided by Paul Culmsee (Seven Sigma) which takes an ironic and subversive take on how SharePoint governance really works within organisations, 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 in this Master Class the “what” and “how” of governance down to a simple and accessible, yet rigorous and comprehensive set of tools and methods, that organisations large and small can utilise to achieve the level of commitment required to see SharePoint become successful.

Seven Sigma, together with 21apps, are bringing the the acclaimed SharePoint Governance and Information Architecture Master class back to the UK, October 2012.

• Date: October 15-16, 2012
• Venue: The Custard Factory, Birmingham, UK
• Cost: £995
• Limited seats available: 12

Thanks for reading

Paul Culmsee