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

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

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

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

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

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

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

Paul McTaggart

ECM Business Manager

Gen-i a division of Telecom New Zealand

Thanks for reading

Paul Culmsee

 

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

Hi all

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

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

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

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

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

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

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

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

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

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

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

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

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

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

And the survey says…

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

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

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

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

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

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

Looking Deeper

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

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

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

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

Where’s the proof, Paul?

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

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

 

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

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

Structured tools for social collaboration?

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

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

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

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

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

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

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

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

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

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

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

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

Conclusion

Food for thought, eh?

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

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

Thanks for reading

 

Paul Culmsee

www.sevensigma.com.au

Hiya

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

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

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

The Importance of Goal Alignment…

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

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

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

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

Stories that led to the goal

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

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

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

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

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

The define and design session live…

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

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

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

 

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

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

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

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

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

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

Conclusion

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

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

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

Hi all

A big chunk of last year had me off under a metaphorical mushroom, putting together several days of courseware on the topic of SharePoint Governance and Information Architecture. My take on these topics are influenced from some odd places, and the course drew on a lot of the non IT work that I do, that involves collaboration on some very complex problems indeed.

In November and December of 2010, we took this “on the road”, so to speak, firstly in Dublin, then London and Sydney. The courses were sold out and feedback was terrific. Here are a few choice quotes (check out the hyperlinks for full reviews)

---

“Did it meet my expectations? Well I’d have to say that it far exceeded them. There had obviously been a large amount of effort in preparing the courseware and modules. They covered the important missing links currently absent from the Microsoft and traditional training courses” – Wes Hackett.

“I’ve just finished the second day of the SharePoint 2010 Governance and Information Architecture Master Class presented by Paul Culmsee with the support of Andrew Woodward . I can wholeheartedly say it was one of the best courses I’ve attended both in content and presentation style and they deserve a lot of credit for putting together a fantastic course. Paul in particular has put a huge amount of effort into the slidedeck, sample documents and enormous manual (almost 500 pages worth!) let alone all the great additional insight he could provide in person over both days” – Brendan Newell

“Finally …. after 12 years in the IT industry a course which covers some of the fundamental issues governing project success.   This course is a real eye opener and a must for any IT professional involved in project planning and delivery” -  Stephen McWilliams

“I just came back from the best technology training I have had in years: a world-first Microsoft SharePoint Elite Information Architecture course designed and delivered by Paul Culmsee. It has taught me a great deal across ALL facets of the day-to-day work that I do as a SharePoint architect” – Jess Kim

Based on this and similar feedback, we are going to do it again. Locations confirmed so far are London (#SPIAUK), Sydney (#SPIAAU) and Wellington (#SPIANZ) in February and March 2011 and in the pipeline is The Netherlands (#SPIANL) and at least a couple of US cities!

In addition to the unique content on these classes, I am honoured to announce that I am now authorised to teach the official Cognexus Issue Mapping courseware – the only non Cognexus Dialogue Mapping practitioner authorised to do so. As such, we will be running the inaugural Issue Mapping class in London in late February as well (wohoo!)

So, here are the details for each location:

(Register now) February 21, 2011, London   #SPIAUK SharePoint Governance and Information Architecture Master Class (Download Flyer)

(Register now) February 23, 2011, London #IBISUK Issue Mapping Master Class (Download Flyer)

(Register now) March 10, 2011, Sydney  #SPIAAU SharePoint Governance and Information Architecture Master Class (Download Flyer)

(Register now)March 14, 2011, Wellington #SPIANZ SharePoint Governance and Information Architecture Master Class (Download Flyer)

(Register soon) May 9, 2011, Utrecht, Netherlands (watch this space)

Wondering what to expect in these classes? Read on!

 SharePoint Governance and Information Architecture Master Class. 2 full days of real world, examples knowledge and techniques

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

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

This master class pinpoints the critical success factors for SharePoint governance and Information Architecture and rectifies this blind spot. Paul‘s style takes an ironic and subversive take on how SharePoint governance really works within organisations, while presenting a model and the tools necessary get it right.

Drawing on inspiration from many diverse sources, disciplines and case studies, Paul has distilled the “what” and “how” of governance down 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.

Master class aims:

• Present SharePoint governance and Information Architecture in a new light – focus on the “blind spots” where the current published material is inadequate
• Cover lessons learned from Paul’s non IT work as a facilitator and sensemaker in complex large scale projects
• Examine the latest trends in the information landscape for industry and government and review studies that inform governance and Information Architecture efforts
• Present an alternative approach to business-as-usual SharePoint governance planning that focuses on real collaboration
• Provide quality information that is rigorous yet accessible, entertaining and interesting

Master class outcomes:

• Understand the SharePoint governance lens beyond an IT service delivery focus
• Develop your ‘wicked problem’ radar and apply appropriate governance practices, tools and techniques accordingly
• Learn how to align SharePoint projects to broad organisational goals, avoid chasing platitudes and ensure that the problem being solved is the right problem
• Learn how to account for cognitive bias and utilise tools and techniques that help stakeholders align to a common vision
• Understand the relationship between governance and assurance, why both are needed and how they affect innovation and user engagement
• Understand the underlying, often hidden forces of organisational chaos that underpins projects like SharePoint
• Understand the key challenges and opportunities that SharePoint presents for Information Architecture
• Learn how to document your information architecture
• Practical knowledge: Add lots more tools to your governance and IA toolkit!

Course Structure: The course is split into 7 modules, run across the two days.

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

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

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

Module 2: The Shared Understanding Toolkit – part 1:

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

Module 3: The Shared Understanding Toolkit – part 2:

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

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

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

Module 5: Information organisation and facets of collaboration

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

Module 6: Information Seeking, Search and metadata.

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

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

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

Putting it all together: From vision to execution

As a take home, we will also supply a USB stick for attendees with a sample performance framework, governance plan, SharePoint ROI calculator (Spreadsheet), sample mind maps of Information Architecture. These tools are the result of years of continual development and refinement “out in the field” and until now have never been released to the public.

Note: The workshop sessions will be hands on, we provide all of the tools and samples needed but please bring your own laptop.

Issue Mapping Master Class. Your path towards shared understanding and shared commitment

“Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them.” Laurence J. Peter

Presented by: Paul Culmsee

Courseware by: Cognexus Institute and Seven Sigma

“Not another $#%@*$ meeting!”

All of us have felt the frustration of walking from yet another unproductive meeting, wondering where the agenda went. Yet, as problems become more complex, meetings are still the place where critical strategic decisions are made.

What is Issue Mapping?

Issue-Based Information Systems (IBIS) is a sense-making framework used to support group discussions to assist all involved to come to a shared understanding. It visually maps participants’ points of views, problems voiced, the rationale and reasons leading up to decision(s). The maps can be easily read and understood by everyone, even by those not part of the discussion group.

Why Issue Mapping?

• Maps detailed rationale behind decision-making as well as the decision; maps the thinking process of the group
• Concentrates on pros and cons to an idea, encourages and explores all views, taking the sting out of differences
• Represents and clarifies diverse points of views, conflicting interpretations and goals, inconsistent information and other forms of complexity
• Everyone gets a chance to speak, if they want. People are heard and contributions are acknowledged. Interruptions, repetition and dominance of the loudest decreases
• Keeps participants on topic because they can visually see the progress of the discussion
• Keeps everyone’s attention
• Meeting progress/result can be seen
• Map helps participants come up with ideas/arguments
• Visual display of progress to review summary if need so the brain can absorb the bigger picture and appreciate the validity and value of a larger perspective
• Avoids jumping to easy answers or superficial conclusions
• Promotes deeper reasoning, rigor and even wisdom
• Everyone can visually see everything discussed- leaves no room for misunderstandings
• Documents can easily be attached to map to back up ideas
• Participants can see effectiveness of mapping and genuine will try to make it more productive

About Seven Sigma

Issue Mapping is a life skill that can be applied to many different problem domains and scenarios. Participants will gain proficiency in a craft that can be applied long into the future, to help them and others bring clarity and convergence to the management of complex problems. At Seven Sigma, we practice Issue and Dialogue Mapping routinely and this has brought us many satisfied clients. The Mapping in itself is part of the ‘secret sauce’ that makes Seven Sigma’s reputation renowned.

Seven Sigma Business Solutions is the only recognised designated partner of Cognexus Institute, founder of the art of Issue Mapping, in the world. We recognise that without reaching shared understanding, you will find yourself at yet another meeting, rehashing the same unresolved problems, listening to the same arguments month after month. Or, if a decision has been made, it has not been followed up to fruition due to lack of commitment/buy-in.

We are proud to be part of your journey towards shared understanding and shared commitment.

Master Class aims and outcomes:

• Be able to create great maps – issue maps that are clear, coherent, and inviting
• Immediately start using Issue Mapping effectively in your work and life; the class will focus on practical experience and map building
• Command a rich range of options for publishing and sharing maps
• Lead with maps: create direction, momentum, and energy with issue maps
• Quickly and effectively do critical analysis in dynamic situations
• Organize unstructured information and discover patterns and connections within it
• Make critical thinking visible for inspection and analysis
• Recognise early, the symptoms of wicked problems and the forces behind group divergence
• Recognise the importance of capturing the rationale behind decisions, as well as the decisions themselves
• Rethink the traditional approach to meetings and decision making
• Start capturing the rationale leading up to the decisions by using IBIS and Compendium software

It will also give you a deeper understanding of:

• The fundamentals of IBIS and Compendium
• The structural patterns that give clarity and power to issue maps
• How decision rationale is represented in a map

This master class will be hands on – please bring your own laptop with Compendium software (freeware) installed.

Duration: 2 days, with homework after the first day

Audience: For both IT and non-IT audience; those involved in highly complex projects including leaders, consultants, facilitators, organisational development professionals, change agents, managers and engineers.

Prerequisite: An open mind geared for shared understanding and shared commitment

Michal Pisarek wrote a nice write-up of what makes a good SharePoint Analyst. I feel I have something to offer here, given that I…

1. am a cynical old bastard
2. am an opinionated old bastard
3. have had some opportunities that not too many SharePoint people have had
4. wrote this post on a plane while suffering jetlag 🙂

I am going to argue that as a SharePoint ”analyst”, the worst thing you can do is act like an analyst.

I previously wrote about the identity crisis that Business Analysts have which became apparent to me when I spoke at a BA World Conference last year. The gist of my point in that post came from my observations of a panel discussion on role of a BA within Agile development. I noted that the whole discussion seemed based on an underlying presumption that the role of the BA was to translate between IT and “the business". Agile by its very nature, shifts the ground out from under this assumption which caused a bit of consternation on the part of the panel. My takeaway from this, was that a role does not define the person. The body of knowledge of your discipline (in this case BABOK) is not the one truth. When you think about it, the body of knowledge by definition, consists of the lowest common denominators of a discipline of knowledge – a starting point. This is because the skills that you have built are your skills. Sure, you can write about them, but that only conveys a small dimension of what your skills entail.

Essentially, if everybody followed the BOK as the source of the truth then all consultancies would look the same. (Thinking about it, now you know why all large and expensive management consulting firms tend to sound the same…hehehe 🙂 )

The point is that it is the knowledge that you have earned that makes you what you are and what customers want. Knowledge comes from making mistakes, not by confirming your rightness. Therefore, people who practise constant learning by trying things out, challenging their models of reality, always build a hugely valuable corpus of tacit knowledge that is locked up in their brain where knowledge is connected and related in ways that form insight. It is because of this unique insight, that customers rarely want a “Business Analyst”.  They want Joe or Bob because of what Joe or Bob, as individuals, bring to the table. (Kailash writes about this in more detail if I am leaving you scratching your head at this point. I am going to quote him in a reply to Richard Harbridge).

The point I would like to emphasise, however, is that best practices cannot capture tacit knowledge. Codified best practices (or standards) are therefore necessarily incomplete. One of the things standards don’t tell you is how you should “practice the practice”. Practices have to be customised or adapted to specific organisational contexts before they can be practiced. The process of customisation invariably involves the creation of tacit knowledge to fill in the missing bits. This is why I used the word “rediscover” to describe this process, rather than “customise” (or “adapt”) : the former gives a better sense for the magnitude and type of effort involved whereas the latter suggests that minor tinkering will do the job (which it won’t).

So, here is a tip. Don’t define your own wellbeing by a role title or adherence to a body of knowledge because, if you do, you will inevitable have an identity crisis. The world simply moves on and with it, the problems that people are trying to solve tend to wriggle out of the domain of any single BOK. Any attempts to resist this will eventually become dogma and then we have “memetic smackdowns” as I describe in this EUSP Post.

Okay, so now that I have finished a mini rant, I’d like to address the whole “analyst” thing. Don’t get me wrong – it’s not the title of the role I am going to talk about here, but the analyst paradigm itself. That is, the notion that my purpose in life is to take some requirements, go to a back room, spend time “processing” and “synthesising” those requirements, translating away between "IT and “the business”, before formulating a solution for the customer.

This does not work well with most SharePoint projects! Especially ones that seek to “improve collaboration”.

Many people fail to see why this is the case, yet given the huge gap between the SharePoint that Microsoft shows you versus what you see on the ground, you would think that it would be kind of obvious. For what it’s worth, understanding why the analyst paradigm is dangerous also neatly explains why IT is generically predisposed to struggling with SharePoint.

Consider the following projects:

• Implementing Microsoft Exchange for a global organisation
• Implementing Active Directory for unified and policy based user and resource management
• Replacing PBX with a Voice over IP system
• Upgrading your wide area network from site to site VPN’s to MPLS managed WAN
• Determining support and escalation procedures for a SharePoint deployment
• Replacing a Windows XP/Office 2003 desktop environment with Windows 7/Office 2010

In the above list, if you ask the question “Will users accept and adopt this?” the answer is a fairly clear yes. At the end of the day, no matter what version of Exchange is in, Microsoft Outlook is still Microsoft Outlook. What the user sees is an Inbox and so long as mail comes in and goes out – they are happy. All Active Directory is to a user is a username and password to get to their computer. Irrespective of how clever the routing is in a Voice over IP system or a WAN network, a phone is just a phone. You can plan for support and escalation procedures for SharePoint, but at the end of the day, people will use the SharePoint system because it is the right solution for them. Sure they might get pissed if they have bad technical support, but if the solution is crap then no amount of awesome support structure is going to change this.

This, my friends, is the realm of the analyst paradigm!

You see, if you ask me to deploy Active Directory or Exchange, I will ask you a bunch of questions about your number of sites, number of users, communications infrastructure and the like, and I know that users will use it. I actually don’t need to talk to them. Oh sure, someone might do some communications planning, but I don’t need to address user adoption because adoption is already there! People adapted to email, telephone and Microsoft Windows years ago.

Instead, I can go into a back room, read a bunch of whitepapers and design/deployment guides and blammo. Here is your solution and here is how much I think it will cost. Better still, I can use waterfall style of project methodology because as a specialist, I have done this before and have expertise. I can tell you what needs to be done in considerable detail and break it down into a plan.

What it all boils down to is that there is a clear relationship between cause and effect, characterised by answering YES to the “If I do this, will users accept and adopt this” test. But most IT departments (and most IT integrators) are going to default to the analyst paradigm because many of their other projects tend to be in the above category. This analysis based mode of project delivery is very much ingrained into the reptile brain of a lot of IT professionals through years of repetition of implementing these types of projects. After all, it’s just IT, right?

Also, note that many of these type of projects are characterised by being very technically complicated. Some are insanely so and require specialist technical expertise. This is the realm of the supremely skilled person who performs an analyst function with a body of knowledge behind them. The whole industry certification process is built on this fundamental underpinning and works really well with things like Cisco and Microsoft in areas like Exchange, Active Directory and the like.

Now, consider the following projects or initiatives (I am deliberately picking things where people may disagree with me so go with me, ok).

• Coming up with an navigational structure for a SharePoint collaborative portal
• Installing SharePoint to improve collaboration
• Replacing a folder based file share with a metadata based document repository
• Designing a new road layout for a local suburb
• Putting in a new intranet
• Putting in a records management system
• Installing a new time tracking system

In all of these problems, it is difficult to answer yes to the “Will users accept and adopt this” question. Sure, you can go all big stick and say “We will force them to” but that fails the “accept” part of the test. Therein lies the danger for the analyst paradigm. You can go off to the “back room” and use your body of knowledge, read best practices and “analyse” until the cows come home. Until you deliver the solution, you will not know if it will be accepted.  The cause and effect relationship is not clear until after an action has been taken!

The reason you can’t confidently answer yes is that all of these projects above require adaption on the part of the target audience. Adaption leading to adoption is a hit and miss affair. While we might like to think that we are all rational, clearly we are not. If you want rational, think Dr Spock from Star Trek – and even he got mad sometimes! Office politics and organisational inertia stems from the irrational world. Butt covering by positioning for “blame avoidance” for decisions made by fear and anxiety are commonplace. If you work in a large organisation and listen carefully to a typical meeting, the logic and facts that are spoken out loud are rarely what matters compared to the complex non spoken interplays that go on underneath the words.

For what it’s worth, I added a non IT example of designing a new road layout for a suburb. A rational analyst might think that residents have to accept the solution by definition because, after all, once a road is in, that’s it. But what typically happens is that residents of that neighbourhood see the plan, petition, form lobby groups and harass the hell out of their local political representatives. If this is enough to make the politician edgy then they will vote the plan down before it ever happens. Sure it might have been a good plan, but it’s gone now and the chances of further buy-in are greatly reduced.

The pure analyst is often taking a rational approach to an irrational problem space. Sorry folks – this is simply asking for trouble. Like the politician who does what they think will keep them in power versus what is logical shows the rational world does not always get a good look in. A good example in SharePoint land, is the “metadata is good and folders are bad” thing. Any metadata fanboy with this mantra often find the hidden organisation will beg to differ 🙂

So, what do we do then?

The facilitator paradigm instead aims to elicit resolution of problems using dialogue between stakeholders by achieving a greater degree of shared perception of the problem situation. Unlike the analyst paradigm, there is no back-room approach as such. By definition, we need to collaborate to do this. (Fancy that, eh? Collaborating to deliver a collaborative platform – who would have thought!)

Now, I am not talking about facilitation in the classic sense with everybody sitting in a room in a circle and plays team building games. Some of the best project managers and business analysts I have met are facilitators without necessarily knowing it. What I mean by facilitation is that our starting point is to leverage the wisdom of the crowd, by creating an environment conducive to participants being able to surface the irrational as well as the rational. Only in this way, can we come to a shared understanding of a problem and what should be done about it.

I previously termed this the holding environment, and it really is. A great business analyst or project manager knows this instinctively, and uses many tools (as well as some coercion and sometimes their own ego surrendering) to bring it about.

If you take anything away from this post, remember this. Anytime you cannot confidently answer the “Will users accept and adopt this” question, it is highly likely that not all users see that there is even a problem yet. Therefore, expecting people to magically buy-in and adapt when they don’t recognise the problem is never going to fly. Like trying to get a Darwinist to accept that intelligent design should be taught in schools, someone who does not believe in it to begin with, is not going to easily buy into a solution that requires them to change their beliefs and therefore behaviour. 

Conclusion

When you think about it (rationally!) we usually look at SharePoint as an enabling technology that can address a legacy of poor collaboration and information management. Yet, how can the world of the analyst work out if their solution will create the very same legacy without all stakeholders being on the same page?

So remember, in a project where the cause and effect relationship is not clear, use the facilitator paradigm and stop being such a bloody analyst!

Thanks for reading. Comments most welcomed .

Paul Culmsee

www.sevensigma.com.au

 

In 2011, I will be posting sections of my Governance and Information Master Class here. Much of the content consists of mental models, alternative frames of reference, pattern and practices as well as other tools and methods, specifically for the facilitator paradigm. This is my interest area and feel the analyst paradigm is already well represented in the SharePoint space.