Hi all and welcome to another small piece of my SharePoint architect manifesto. In the previous post I introduced you to the notion of f-laws, which were first coined in a book co-authored by Russell Ackoff. In the process of developing a SharePoint governance and information architecture class, I was inspired to use the idea of an f-law because they appealed to my contrarian sense of humour and also contained some interesting nuggets of wisdom. I ended up coming up with a heap of f-Laws for SharePoint, and plan to write an article to cover each one.

In the last post, we learnt that f-Law 1 was all about the contention that the more you try and define what governance is, the less anyone will actually understand it. If you never read the first SharePoint Governance f-law then I suggest you do so, because these articles do tend to build on the foundation set from the previous. On that note, the focus of todays f-law extends on one that Ackoff himself came up with. All I am doing it putting a SharePoint bent on it…

F-Law 2: There is no point in asking users, who don’t know what they want, to say what they want.

This f-law comes with an additional corollary: There is even less point in thinking that you already know what they want! (IT departments – I am looking at you here!)

The definitive way to explain this f-law is to leverage the work of one of my mentors – Jeff Conklin. In 2007 I read a paper of his that literally changed my career. It was titled “Wicked problems and social complexity” and despite me reading many papers since, to this day it is one of the best introductions to complex problem solving you could ever read.

In this paper, Jeff talks about the fact that many prevailing methodologies suggest that the best way to work on a problem is to follow an orderly and linear “top-down” process, working from the problem to the solution. You begin by understanding the problem, including gathering and analysing “requirements” from customers or users. Once you have the problem specified and the requirements analysed, you are ready to formulate a solution and eventually implement that solution. This is illustrated by the red line in the figure below.

Now many project managers, cheque signers and just about every program management office I have ever worked with try to operate this way because it promises order, certainty and control. This is understandable when ones performance is being judged on getting stuff done to an agreed time and cost. It is also understandable if you are a manager and will get your ass kicked if you blow your budget. There is only one teeny issue. For some scenarios, it simply does not work.

In Conklin’s paper, he detailed a 1980’s case study at the Microelectronics and Computer Technology Corporation (MCC) that looked into how people solve problems. A number of designers participated in an experiment where they were give a one page problem statement – not too different to many SharePoint business cases I have seen. Participants in the experiment had to design an elevator control system for an office building. Despite participants being experienced and expert integrated-circuit designers, none had ever worked on elevator systems before. Each participant was asked to think out loud while they worked on the problem. The sessions were videotaped and analysed in detail.

Below is what really happened. Check out the green line…

Clearly, the subjects in the elevator experiment did not follow a linear approach. They would start by trying to understand the problem, but they would immediately jump into formulating potential solutions. Then they would jump back up to refining their understanding of the problem. Rather than being orderly and staged like the red line, the line plotting the course of their thinking looked more like a seismograph for an earthquake. Now if you are looking at the green line and thinking “my god I better put a stop to that sort of shenanigans,” consider what Conklin had to say about it in his paper:

These designers are not being irrational. They are not poorly trained or inexperienced. Their thought process was something like: “Let’s see, idle elevators should return to the first floor, but then, you only need one elevator on the first floor, so the others could move to an even distribution among the floors. But the elevators need to be vacuumed regularly. I suppose we could add a switch that brought idle elevators down to the first floor. But then what happens in an emergency?” In other words, what is driving the flow of thought is some marvellous internal drive to make the most headway possible, regardless of where the headway happens, by making opportunity-driven leaps in the focus of attention. It is precisely because these expert designers are being creative and because they are learning rapidly that the trace of their thinking pattern is full of unpredictable leaps.

When I am speaking at conferences I like to mess with project managers in particular (who doesn’t eh?), because they are an easy target and already an insecure lot to begin with. I will ask the audience if anybody has an industry certification, such as a PMP or Prince II. Several hands usually go up. I then point to the phases of the above diagram and ask them if – when they were studying hard to obtain their certification – they actually followed the discrete phases that everybody else is supposed to follow. No single person has ever suggested that they did, instead all acknowledging that their process of learning looked more like the green line. I then point out that I’ve always found this perversely funny that people follow the green line to learn a process that tries to insist that everybody else must follow the red line. Ironic huh?

Knowing vs. learning problems

It should be stated at this point that you can use the red-line approach for certain types of problems so I am not outright dismissing it. In fact, within SharePoint projects there are indeed elements that can work quite well this way. The green line on the other hand, represents a phenomenon that Conklin called “Opportunity driven problem solving” and is the de-facto way we work on problems that are new or novel. For example, if you have ever experienced an “aha” moment, it was probably a leap of cognition that followed the jagged green line up or down, where you suddenly saw the problem in a different light. (Shhhh… don’t let your project manager know because you will have to fill in a form of some description!)

In these types of problems, we do not start by gathering and analysing data about the problem because the problem itself is moving target and varies depending on different stakeholders and their world views. Thus, there is no pure and concrete understanding of “the problem” because it is still forming as you think about solutions. In short, the jagged green line is a picture of learning. Quoting again from Conklin:

The more novel the problem, the more the problem solving process involves learning about the problem domain. In this sense the waterfall is a picture of already knowing – you already know about the problem and its domain, you know about the right process and tools to solve it, and you know what a solution will look like. As much as we might wish it were otherwise, most projects in the knowledge economy operate much more in the realm of learning than already knowing. You still have experts, but it’s no longer possible for them to guide the project down the linear waterfall process. In the current business environment, problem solving and learning are tightly intertwined, and the flow of this learning process is opportunity-driven

I believe that many innovations stem from the opportunity driven, creative leap of faith of the green line. On that note, I’d say that one of the greatest opportunity driven learners had to be Einstein. An article by Mort Orman suggests that Einstein was intrigued by “holes” in prevailing theories and enjoyed posing “mind riddles” to himself, just to see if present theories could satisfactorily explain them. Unlike many others who might have given up when they got stuck, Einstein was persistent and kept at it for 10 years before he came up that little formula everyone knows. After explaining this story at conferences, I sometimes ask people “Do you think Einstein used waterfall when he came up with relativity?” No one has said yes yet…

Implications…

The pattern of behaviour between the red and green lines represents the difference between a knowing problem and a learning problem. With a knowing problem, the problem is clear to all participants and even though it might require specialist expertise to solve, many of the variables are well understood. But for a problem that is novel or requires learning from participants Conklin’s case study illustrates that:

1. People will examine potential solutions just to explain the problem.
2. Each instance of examining the solution will impact the understanding of the problem.

Given that SharePoint is almost always starts out as a learning problem for the majority of participants, I do not see the point in trying to fight that green line. Instead, it is critical that you work with it rather than against it. The difficulty people have with this is that to do so conflicts with that promise of certainty, order and control that the red appears to offer. Why? Well among other things, you have to:

1. Expect fluid requirements and scope changes
2. Involve stakeholders from the start (they have to live with the result and their up-take is presumably a key KPI)
3. Expect resistance and pullback from stakeholders (because people attribute more to what they perceive to lose compared to what they might gain)

Above all, you have to avoid penalising people for their learning. If you put barriers in front of people who are trying to improve their understanding of a multi-faceted problem they will eventually disengage from you. If you want to guarantee this sort of disengagement, go right on ahead and solve some problem before your stakeholders even realise there is a problem. Then when they do realise, smack them with the metaphorical baseball bat known as the scope variation form. One of two of those babies and those annoying stakeholders are guaranteed to go away. A pity your solution will go away with them but hey, it was in scope right?

Confessions…

I deal with this core issue of not penalising learning in a number of ways… some of which I have outlined in blog posts and many that I will cover in detail as we progress in this series and examine more f-laws. If you simply can’t wait for me and want “the answer” then I have news for you. If it were that easy there would be a “best practice” for it and someone would have created a certification by now!

So instead I will give you a couple of KPI’s to work to.

• KPI 1: You get to a stage where your clients questions are “informed”. It is pretty easy to tell as a SharePoint professional where your stakeholders are at in their understanding of SharePoint. Over time there is a certain level of maturity in the questions asked of you and the way they are asked. This reflects both stakeholder learning as well as your ability to teach. If you get to this stage, you have increased your chances of SharePoint success significantly, which leads onto the next KPI…
• KPI 2: You get to the stage where your clients are asking you well informed questions that you don’t know the answer to. Trust me that they will not mind that you don’t because their awareness of the product will no longer be naively simplistic anyways. You will also have developed a great collaborative partnership by then too. Also don’t forget my quote from Horst Rittel in the midwives post. There is a symmetry of ignorance with complex problems. The knowledge required to solve a complex problem never resides with a single person.

This leads me onto the final KPI:

• KPI 3: Your clients should start telling you stuff about SharePoint that they have done that you have never done before or didn’t know you could do. In short, they will start teaching you stuff.

If you can create those conditions, be happy that they don’t need you that much anymore.

Thanks for reading

Paul Culmsee

www.hereticsguidebooks.com

www.sevensigma.com.au

Bjørn Furuknap you have gone too far this time! There I said it.

On behalf of the SharePoint community, I feel that someone needs to speak up about your reprehensible behaviour, so I have taken it upon myself to right the wrongs that you so needlessly inflicted onto the community. You see, Bjørn has gone and written a non controversial post on the confused role of the SharePoint architect. I am extremely concerned about this abrupt change of behaviour and worry about the example he is setting for the young and impressionable members of the SharePoint community. If Bjørn keeps going down this rational road, then he will make the rest of us look irrational and tip the delicate balance of the SharePoint blogging ecosystem into unknown territory. In other words, we will lose the excuse of “Well, at least I’m not as nuts as Furuknap!”

That said, I have been meaning to write about insights from my life as a (post) SharePoint architect anyway. I have a few of my own lessons learnt and Bjorn has inspired me to finally get a few written down. So in this preamble post, and in a forthcoming series on common SharePoint governance mistakes, I will give you a dose of the opinionated world according to Paul, but I will back it up with some juicy references that you can check out for yourself if you are that way inclined.

Why (post) SharePoint Architect?

You might be wondering why I referred to myself as a “post” SharePoint architect. Unfortunately its hard to answer this question without sounding self-indulgent so I will keep it brief.

In 2007, I got my first non IT gig in a highly complex urban planning project. I had no contribution to make in terms of technical or discipline knowledge to this project at all. My job was to enable others to develop a shared understanding on a highly complex problem they all faced, to enable shared commitment to a course of action. Since that time, this non IT side of my work has continued to grow in terms of number of clients and the scale of the problems being tackled. Like any skill, I have gotten better with practice, which in turn has led to larger and more complex scenarios.

This year in particular, I’ve helped the executive teams of several large organisations re-find their purpose, realign their strategy and make some very difficult and courageous decisions in redesigning their organisations. Just to be clear, we are not talking SharePoint and we are not talking IT. I am talking about how these organisations adapt to changing conditions that, in some cases, affect their very existence. These organisations span the public and private sector across Australia.

From a SharePoint perspective, you could say I have moved from the server room to the meeting room and now to the boardroom. In spite of my self-indulgence warning earlier, you have to admit – this is damn cool!

Who’s misunderstood anyway?

So with that little preamble done, let me return to Bjørn’s post. He feels the SharePoint architect role is misunderstood and I agree with this, but in a different way. I feel the core issue is that SharePoint architects themselves are often the ones who misunderstand what they need to do and how they should go about it. This in turn manifests in the rest of the world not understanding what they ought to be doing.

To elaborate on this contention, let’s meet the four most common SharePoint architect stereotypes that I see in organisations:

The SharePoint architect who used to be a developer

This stereotype comes in two flavours. The alpha developer who had attained top dog status among peers via bluffed programming prowess, or the developer who always struggled and finds that this is a way to get out of hands on coding. Either way, this person still lives through the SharePoint object model. They will focus on ensuring that there are unit tests, solid source control and solutions packaging regime. Utilising the object oriented view means that metadata is king and folders are to be despised. They will not think twice about utilising content types in any situation because it is completely obvious that you would work this way. Their information architecture will be a work of art, and they are not shy in telling everyone so. To sum up, their SharePoint solutions will be logical, well coded to defined standards and completely useless to users.

The SharePoint architect who used to be an infrastructure guy

This stereotype tends to bewilder clients and colleagues alike with a seemingly endless set of options and considerations that need to be made up front. It is likely this architect will introduce SharePoint via the pie/frisbee diagrams, but discussions will focus on architecting for scalability, security and fault tolerance. This architect will likely mandate strict governance rules on those cowboy developers, untrustworthy site admins, and downright scary users to ensure that the environment remains pristine. Accordingly, SharePoint Designer will be outlawed – it’s so obvious that one shouldn’t even be asking why. Any burden imposed by these governance rules will be seen as a necessary evil and will be addressed by mandatory user training and besides, the next SharePoint version will definitely address the gaps. Their solutions will be scalable, architecturally sound and completely useless to users.

The SharePoint architect who thinks they are an enterprise architect

This stereotype – despite their obvious protests to the contrary – is the right brained equivalent of the infrastructure guy. This person absolutely gets off on making models because conceptual reality does not involve making any actual commitments. In fact as soon as there is any push to a commitment, they feel an irrepressible urge to resist and push everyone back into make-believe world. Over-utilising the line “Oh, I am business you see, not technical” as if it’s a sign of maturity, they will plan, plan and plan again, drawing many cool diagrams on whiteboards but never a task on a Gantt chart. The models they come up with are abstract, over-engineered and they always fall deeply in love with them. They won’t let anybody touch their models for fear of their abstract thing of beauty being messed with. The irony is that the basis for their models will actually be underpinned by some solid theoretical frameworks. Unfortunately, this person actually doesn’t understand them in any depth, but the terms used sound really cool. Their solutions will be … Wait, who am I kidding? They won’t have any solutions because they plan forever…

The SharePoint project manager who thinks they are an architect

This stereotype is arguably the most dangerous of the lot because they are driven by the need to “Get Things Done Now!” whether those “Things” make sense or not. Consequently, they jump into solution mode without a full understanding of the real problem the business is facing. Scope documents, plans, schedules and Gantt Charts abound, but the chances are that all these are geared towards solving the wrong problem. Talking to annoying stakeholders just gets in the way of the scope statement and besides, that’s what Business Analysts are put on this earth to do anyway. Their solutions will be built to time and cost, but completely useless to users.

“Let’s drill halfway…”

Bjørn also spoke of architects needing breadth of knowledge over depth of knowledge. This is completely true, but is not the full story. You see, there is a common bad habit that our stereotype architects often make; a bad habit that is in common with many other consultants who end up doing damage to organisations.

Irrespective of their breadth of knowledge or otherwise, these architects act like doctors prescribing remedies. They breeze into organisations, making sweeping statements that contain cool sounding maxims like “business value.” Then, using their clearly superior intellect based on years of experience and that cherished breadth of knowledge, they assess the organisational symptoms and prescribe the appropriate SharePoint medicine to address them.

I can hear it now… “Got an organisational headache? Just take this SharePoint content-type three times a day and see me if pain persists.”

I’m sure people can see the obvious problems with this approach (If you can’t then you are in the wrong business – seriously). One of the many issues is that organisational symptoms are often just visible manifestations of deeper underlying issues. The late, great Russell Ackoff once stated that you would not use brain surgery to cure a headache, despite the pain being felt in your head. Instead you would take a pill, even though there appears to be no direct relationship between the pill and the pain being experienced. Ackoff mused that organisations routinely use brain surgery for their headaches and tools like SharePoint are the blunt instrument of choice to do the drilling. Add to this, the technical complexity of SharePoint means that brain surgery has to happen in discrete phases.

“Okay guys we don’t have enough budget for this, so let’s drill halfway into the skull for phase 1.”

The SharePoint midwife…

SharePoint architects have to understand that the solutions they architect are actually not for them. “Gee Paul that’s profound,” I hear you say sarcastically. While this statement might sound obvious, why is it that many architects exhibit behaviours that contradict it?

If you want to know why this happens I suggest that you read part 1 of the Heretics book. But rather than rehash that here, let’s see what we can learn about problem solving from the insights of Horst Rittel and Ron Heifetz. In case you are wondering, no they are not SharePoint MVPs. Rittel coined the term “wicked problem” and is highly influential in various fields due to his early insights into complex problem solving. Heifetz is well known for his work on the theory and practice of adaptive leadership: how to mobilise people through what he termed adaptive change.

Note: If you have not heard of the term “wicked problem”, then go and read this old post of mine. It’s assumed knowledge here…

Rittel stated that when solving problems, nobody wants to be “planned at.” Additionally, the knowledge required to solve a complex (wicked) problem never resides with a single person. Instead, there is a symmetry of ignorance (I love that term). Rittel characterised symmetry of ignorance as situations “where both expertise and ignorance is distributed over all participants and no-one ‘knows better’ by virtue of degrees or status.” Accordingly, the process of problem solving must involve those who are directly affected by the problem. These are the key stakeholders “living” the problem, rather than experts who “know” the problem theoretically. The aforementioned experts should guide the process of dealing with a wicked problem but not impose solutions. In Rittel’s words, the planner is the “midwife of problems rather than the offerer of therapies.” It is the group that must come up with the answers.

Ron Heifetz echoed Rittel in his advice to leaders. One key strategy of adaptive leadership is to give the work back. Heifetz warned that when a leader undertakes to solve a problem, the leader becomes the problem in the eyes of many stakeholders. The implication is that the leader also becomes the convenient scapegoat if the solution goes awry as blame can be attributed to the leader. Instead by placing work where it belongs—with employees responsible for doing the work—Heifetz argued that issues will be internalized and owned by the parties best placed to deal with them. The best solutions, he maintained, are when the people with the problem become the people with the solution.

Confessions…

Given what Rittel and Heifetz have to say, it should be little wonder that I feel SharePoint architects should not be doctors prescribing remedies. SharePoint is often an adaptive change because you are asking people to change their behaviours. Those architects (and management consultants) who act like doctors tend to find out fairly quickly that the solutions they so lovingly come up with do not always get traction. Therefore, as Rittel suggests, a SharePoint architect needs to be more of a midwife than a doctor. It’s the client who is giving birth to this thing and you are there to create the conditions for them to make that journey as stress free as one can. Who is the one who has to adapt and live with the result anyway? Certainly not the consultant.

For some, this comes at a cost to architect ego because architects often have to let go of their creations. An architect cannot revel in the glory of their masterpiece if those affected by it do not buy into it. It will have a crappy legacy no matter what the intent. In letting go, one has to accept that stakeholders will also have an incomplete world view and will make mistakes. Therefore as an architect, how about architecting not just the SharePoint platform, but architecting the conditions by which SharePoint is delivered.

An obvious condition is one of real collaboration among stakeholders (which when you think about it, is kind of important when putting in collaborative systems!) Another condition that should be there is one that allows people to fail forward. Assume that mistakes will be made, take away the blame and architect SharePoint to be resilient in the face of change instead of making it brittle. Create the environment conducive to co-creation by painting part of the picture and allow participants to fill it in. After all, the learning that occurs via the journey is often just as important as the result achieved.

My confession is that I often say to my SharePoint clients that it is inherently more efficient for me to transfer my knowledge of SharePoint to them, than for them to transfer their deep knowledge of their organisation to me. To do the latter would be highly inefficient for both my clients and me, and my clients would not have the same opportunity to build their own SharePoint competencies and adaptive capacity. At the end of the day, they architect a lot of the solutions. Sure… I might offer suggestions here and there, and I might nudge them when I feel they need to be nudged, but more often than not, I lay some core foundations and they are the ones who do a lot of the legwork.

So to conclude, while I agree with everything Bjørn said in his post, I think the real key to being a good SharePoint architect is to architect the conditions by which SharePoint is delivered, just as much as SharePoint itself. While being a midwife may not be as glamorous as being a doctor, the solutions delivered will have more staying power.

Thanks for reading

Paul Culmsee

Hi all

Just a quick note for those of you who are of the academic persuasion or who have an interest in research and academic literature. Kailash and I wrote a paper for the International Journal for Managing Projects in Business. The article is called “Towards a holding environment: building shared understanding and commitment in projects”. The paper is about how to improve shared understanding on projects – particularly at the early stages where ambiguity around objectives tends to be at its highest. While it covers a similar territory to the Heretics Guide, it covers some literature that we did not use for the book. Plus it is peer reviewed of course.

This paper presents a viewpoint on how to build a shared understanding of project goals and a shared commitment to achieving them. One of the ways to achieve shared understanding is through open dialogue, free from political and other constraints. In this paper (and in the Heretics Book) we flesh out what it takes for this to happen and call an environment which fosters such dialogue a holding environment. We illustrate, via a case study:

1. How an alliance-based approach to projects can foster a holding environment.
2. The use of argument visualisation tools such as IBIS (Issue-Based Information System) to clarify different points of view and options within such an environment.

This was my first experience with the peer review process of writing a journal paper. I have to say that, despite the odd bit of teeth gnashing, the review process did make this paper much better than it originally was. Of course, none of this would have even happened without Kailash. This was definitely his baby, and this paper would not exist without his intellect and wide-ranging knowledge.

Thanks for reading

Paul Culmsee

www.hereticsguidebooks.com

Hi all

Just a quick note to mention that I’m off travelling again, this time swapping 39 degree Celsius summer weather of Perth for somewhere between –6 to 5 degrees of Canada. I’ll be spending a week in Canada running two classes – one public and one private. The first class is a public SharePoint Governance and Information Architecture class running in Vancouver. MVP Michal Pisarek of SharePointAnalystHQ fame will be there and it should be a terrific two days of learning how to think a little differently to govern SharePoint strategy and deployment. You will learn a bunch of new skills, techniques and perspectives. Best of all, the skills learnt are applicable for many other types of complex projects.

The class flyer is here: http://www.sevensigma.com.au/wp-content/uploads/downloads/2011/02/SPIA.pdf

The registration site is here: http://spiavancouver.eventbrite.com/

In terms of course coverage and content it is worth noting the research performed by the Eventful group (who run the Share conferences). According to them, the hot topic areas for SharePoint are governance, user adoption, change management, information architecture and user empowerment. These sort of topics are the sort where plenty of people tell you what the issues are, but are typically lighter on what to do about them. This class covers why this is, as well as dealing with all of these areas and presents detailed strategies, tools and methods to address them. Furthermore, aside from the 500+ page manual of meaty governance goodness, as a take home, we supply a CD for attendees with a sample performance framework, governance plan, SharePoint ROI calculator and sample mind maps of Information Architecture.

At last count there were 5 places left for the Vancouver class, so if you have been pondering if it is a worthwhile class, check out some of the feedback from the class web site. Also, if you know anybody who might be interested in attending, please pass the course flyer and registration site details to them. We always end up with people who tell us “Ah – if only I knew about the class!!”

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

www.hereticsguidebooks.com

Hi all

This is the second post in a quick series that attempts to use IBIS to analyse an online discussion. Strange as it may sound, but I believe that issue mapping and IBIS is one of the most pure forms of information architecture you can do. This is because a mapper, you are creating a navigable mental model of speech as it is uttered live. This post is semi representative of this. I am creating an IBIS based issue map, but I’m not interacting live with participants. nevertheless, imagine if you will, you sitting in a room with a group of stakeholders answering the question on why users cannot find what they are looking for on the intranet. Can you see its utility in creating shared understanding of a multifaceted issue?

Where we left off…

We finished the previous discussion with a summary map that identified several reasons why it is hard to find information on intranets. In this post we will continue our examination of this topic. What you will notice in this post is that the number of nodes that I capture are significantly less than in part 1. This is because some topics start to become saturated and people’s contributions are the same as what is already captured. In Part 1, I captured 55 nodes from the first 11 replies to the question. In this post, I capture an additional 33 nodes from the next 15 replies.

So without further adieu, lets get into it!

Suzanne Thornley • Just another few to add (sorry 5 not 3 :-):
1. Search engine is not set up correctly or used to full potential
2. Old content is not deleted and therefore too many results/documents returned
3. Documents have no naming convention and therefore it is impossible to clearly identify what they are and if they are current.
4. Not just a lack of metadata but also a lack of governance/training around metadata/meta tagging so that less relevant content may surface because the tagging and metadata is better.
5. Poor and/or low cost search engine is deployed in the mistaken belief that users will be happy/capable of finding content by navigating through a complex intranet structure.

Suzanne offered 5 additional ideas to the original map from where we last left off. She was also straight to the point too, which always makes a mappers job of expressing it in IBIS easier. You might notice that I reversed “Old content is not deleted and therefore too many results/documents returned” in the resulting map. This is because I felt that old content not being deleted was one of a number arguments supporting why too many results are returned.

My first map refactor

With the addition of Suzanne’s contributions, I felt that it was a good time to take stock and adjust the map. First up, I felt that a lot of topics were starting to revolve around the notion of information architecture, governance and user experience design. So I grouped the themes of vocabulary, lack of metadata, excessive results and issues around structure of data as part of a meta theme of “information architecture”. I similarly grouped a bunch of answers into “governance” and “user experience design”. These for me, seemed to be the three meta-themes that were emerging so far…

For the trainspotters, Suzanne’s comment about document naming conventions was added to the “Vocabulary and labelling issues” sub-map. You can’t see it here because I collapsed the detailed so you can see the full picture of themes as they are at this point.

Patrik Bergman • Several of you mention the importance of adding good metadata. Since this doesn’t come natural to all employees, and the wording they use can differ – how do you establish a baseline for all regarding how to use metadata consistently? I have seen this in a KM product from Layer 2 for example, but it can of course be managed without this too, but maybe to a higher cost, or?

Patrick’s comment was a little hard to map. I captured his point that metadata does not come natural to employees as a pro, supporting the idea that lack of metadata is an example of poor information architecture. The other points I opted to leave off, because they were not really related to the core question on why people can’t find stuff on the intranet.

Luc de Ruijter • @Patrik. Metadata are crucial. I’ve been using them since 2005 (Tridion at that time).You can build a lot of functionality with it. And it requires standardisation. If everyone adds his own meta, this will not enable you to create solutions. You can standardize anything in any CMS. So use your CMS to include metadata. If you have a DMS the same applies. (DMS are a more logical tool for intranets, as most enterprise content exists as documenst. Software such as LiveLink can facilitate adding meta in the save as process. You just have to tick some fields before you can save a document on to the intranet.)
@Suzanne. There’s been a lot of buzz about governance. You don’t need governance over meta, you just need a sound metastructure (and a dept of function to manage it – such as library of information management). Basically a lot of ‘governance’ can be automated instead of being discussed all the time :-).

Like Patricks comment, much of what Luc said here wasn’t really related to the question at hand or has been captured already. But I did acknowledge his contribution to the governance debate, and he specifically argued against Suzanne’s point about lack of governance around metadata tagging.

Next we have a series of answers, but you will notice that most of the points are re-iterating points that have already been made.

Patrik Bergman • Thanks Luc. It seems SharePoint gives us some basic metadata handling, but perhaps we need something strong in addition to SharePoint later.

Simon Evans • My top three?
1) The information being searched does not actually exist or exists only in an unrecognisable form and therefore cannot be found!
2) As Karen says above, info is organised by departmental function rather than focussed on end to end business process.
3) Lack of metadata as above

Mahmood Ahmad • @Simon evan. I want to also add Poor Information Structure in the list. Therefore Information Management should be an important factor.

Luc de Ruijter • @Patrik. Sharepoint 2010 is the first version that does something with it. Ms is a bit slow in pushing the possibilities with it.
@Simon @Mahmood Let’s say that information structure is the foundation for an intranet (or any website), and that a lack of metadata is only a symptom of a bad foundation?

Patrik Bergman • Good thing we use the 2010 version then 😀 I will see how good it handles it, and see if we need additional software.

Erin Dammen • I believe 1) lack of robust metadata, resulting in poor search results; 2) structure is not tailored to the way the user thinks; 3) lack of motivation on the part of contributors to make their information easy to use (we have a big problem with people just PDFing EVERYTHING instead of posting HTML pages.) I like that in SP 2010, users have the power to add their own keywords and flag pages as "I like it." Let your community do some of the legwork, I think it helps!

Simon’s first point that the information searched may not exist or may not be in the right format was new, so that was captured under governance. (After all, its hard to architect information when its not there!).

I also added Erin’s third point about lack of motivation on the part of contributors. I mulled over this and decided it was a new theme, so I added it to the root question, rather than trying to make it fit into information architecture, governance or user experience design. I also captured her point on letting the community do the legwork through user tagging (known as folksonomy).

Luc de Ruijter • @all. The list of root causes remains small. This is not surprising (it would be really worrying if the list of causes would be a long list). And it is good to learn that we encounter the same (few but not so easy to solve) issues.
Still, in our line of work these root causes lack overall attention. What could be the reason for that? 🙂
@Erin Motivation is not the issue, I think; and facilitation is. If it is easier to PDF everything, than everyone will do so. And apparently everyone has the tools to do so. (If you don’t want people to PDF stuff, don’t offer them the quick fix.)
If another method of sharing documents is easier, then people will migrate. How easy is it to find PDF’s through search? How easy is it to add metadata to PDF’s? And are colleagues explained why consistent(!) meta is so relevant? Can employees add their own meta keywords? How do you maintain the quality and integrity of your keywords?
Of course it depends on your professional usergroup whether professionals will use "I like" buttons. Its a bit on the Facebook consumer edge if you’d ask me. Very en vogue perhaps, but in my view not so business ‘like’.

Luc, who is playing the devils advocate role as this discussion progresses, provides three counter arguments to Erin’s argument around user motivation. They are all captured as con’s.

Steven Osborne • 1) Its not there and never was
2) Its there but inactive so can no longer be accessed
3) Its not where someone thought it would be or should be or its not called what they thought it was called or should be called.

Marcus Hamilton-Mills • 1) The main navigation is poor
2) The content is titled poorly (e.g internal branding, uncommon wording, not easy to differentiate from other content etc.)
3) Search can’t find it due to poor meta data

patrick c walsh • 1) Navigation breaks down because there’s too much stuff
2) There’s too much crap content hidden away because there’s just too much stuff
and
3) er…there’s just too much stuff

Mark Smith • 1. Poor navigation, information architecture and content sign-posting
2. Lack of content governance, meta-data and inconsistent taxonomy, resulting in poor search capability.
3. The content they are trying to find is out of date, cannot be trusted or isn’t even available on the intranet

Luc de Ruijter • @Steven Had a bit of a laugh there
@all Am I right in making the connection between
– the huge amount of content is an issue
– that internal branding causes confusion (in labeling and titles).
and
the fact that – in most cases – these causes can be back tracked to the owners of intranet, the comms department? They produce most content clutter.
Or am I too quick in drawing that conclusion?

Now the conversation is really starting to saturate. Most of the contributions above are captured already in the map as it is, so I only added two nodes: Patrick’s point about navigation (an information architecture issue) and too much information.

Where are we at now?

We will end part 2 with a summary below. Like the first post, you can click here to see the maps exported in more detail. In part 3, the conversation got richer again, so the maps will change once again.

Until then, thanks for reading

Paul Culmsee

www.sevensigma.com.au

Hi

There was an interesting discussion on the Intranet Professionals group on LinkedIn recently where Luc De Ruijter asked the question:

What are the main three reasons users cannot find the content they were looking for on intranet?

As you can imagine there were a lot of responses, and a lot more than three answers. As I read through them, I thought it might be a good exercise to use IBIS (the language behind issue mapping) to map the discussion and see what the collective wisdom of the group has to say. So in these posts, I will illustrate the utility of IBIS and Issue mapping for this work, and make some comments about the way the conversation progressed.

So what is IBIS and Issue/Dialogue Mapping?

Issue Mapping captures the rationale behind a conversation or dialogue—the emergent ideas and solutions that naturally arise from robust debate. This rationale is graphically represented using a simple, but powerful, visual structure called IBIS (Issue Based Information System). This allows all elements and rationale of a conversation, and subsequent decisions, to be captured in a manner that can be easily reflected upon.

The elements of the IBIS grammar are below. Questions give rise to ideas, or potential answers. Ideas have pros or cons arguing for or against those ideas.

Dialogue Mapping is essentially Issue Mapping a conversation live, where the mapper is also a facilitator. When it is done live it is powerful stuff. As participants discuss a problem, they watch the IBIS map unfold on the screen. This allows participants to build shared context, identify patterns in the dialogue and move from analysis to synthesis in complex situations. What makes this form of mappingcompelling is that everything is captured. No idea, pro or con is ignored. In a group scenario, this is an extremely efficient way of meeting what social psychologist Hugh Mackay says is the first of the ten human desires which drives us – this being the desire to be taken seriously. Once an idea is mapped, the idea and the person who put it forth are taken seriously. This process significantly reduces “wheel spinning” in meetings where groups get caught up in a frustrating tangled mess of going over the same old ground. It also allows the dialogue to move more effectively to decision points (commitments) around a shared understanding.

In this case though, this was a long discussion on a LinkedIn group so we do not get the benefit of being able to map live. So in this case I will create a map to represent the conversation as it progresses and make some comments here and there…

So let’s kick off with the first reply from Bob Meier.

Bob Meier • Don’t know if these are top 3, but they’re pretty common find-ability issues:
1. Lack of metadata. If there are 2000 documents called “agenda and minutes” then a search engine, fancy intranet, or integrated social tool won’t help.
2. Inconsistent vocabulary and acronyms. If you’ve branded the expense report system with some unintuitive name (e.g. a vendor name like Concur) then I’ll scan right past a link looking for “expense reports” or some variation.
3. Easier alternatives. If it’s easier for me to use phone/email/etc. to find what I want, then I won’t take the time to learn how to use the intranet tools. Do grade schools still teach library search skills? I don’t think many companies do…

In IBIS this was fairly straightforward. Bob listed his three answers with some supporting arguments. I reworded his supporting argument of point 2, but otherwise it pretty much reflects what was said…

Nigel Williams (LION) • I agree with Bob but I’d add to point two not speaking our user base’s language. How many companies offer a failure to find for example (i.e.if you fail to find something in a search you submit a brief form which pops up automatically stating what you were looking for and where you expected to find it? Lots of comms and intranet teams are great at telling people and assuming we help them to learn but don’t listen and learn from all levels of the business.
If I make that number 1 I’ll also add:
2) Adopting social media because everyone else is, not because our business or users need it. This then ostracises the technophobics and concerns some of our less confident regular users. They then form clans of anti-intranetters and revert to tried and tested methods pre-intranet (instant messaging, shared drives, email etc.)
3) Not making the search box available enough. I’m amazed how many users in user testing say they’ve never noticed search hidden in the top right of the banner – “ebay has their’s in the middle of the screen, so does Google. Where’s ours?” is a typical response. If you have a user group at your mercy ask them to search for an item on on Google, then eBay, then Amazon, then finally your intranet. Note whether they search in the first three and then use navigation (left hand side or top menu) when in your intranet.

Nigel’s starts out by supporting Bob’s answer and I therefore add them as pros in the map. Having done this though, I can already see some future conversational patterns. Bob’s two supporting arguments for “not using the vocabulary of users”, actually are two related issues. One is about user experience and the other is about user engagement/governance. Nevertheless, I have mapped it as he stated it at this point and we see what happens.

Luc de Ruijter • @Bob. I recognise your first 2 points. The third however might be a symptom or result, not a cause. Or is it information skills you are refering to?
How come metadata are not used? Clearly there is a rationale to put some effort in this?
@Nigel. Is the situation in which Comm. depts don’t really listen to users a reason for not finding stuff? Or would it be a lack of rapport with users before and while building intranets? Is the cause concepetual, rather than editorial for instance?
(I’m really looking for root causes, the symptoms we all know from daily experience).
Adding more media is something we’ve seen for years indeed. Media tend to create silo’s.
Is your third point about search or about usability/design?

In following sections I will not reproduce the entire map in the blog post – just relevant sections.

In this part of the conversation, Luc doesn’t add any new answers to the root question, but queries three that have been put forward thus far. Also note at this point I believe one of Luc’s answers is for a different question. Bob’s “easier alternatives” point was never around metadata. But Luc asks “how come metadata is not used?”. I have added it to the map here, changing the framing from a rhetorical question to an action. Having said that, if I was facilitating this conversation, I would have clarified that point before committing it to the map.

Luc also indicates that the issue around communications and intranet teams not listening might be due to a lack of rapport.

Finally, he adds an additional argument why social media may not be the utopia it is made out to be, by arguing that adding more media channels creates more information silos. He also argues against the entire notion on the grounds that this is a usability issue, rather than a search issue.

Nigel Williams (LION) • Hi Luc, I think regarding Comms not listening that it is two way. If people are expecting to find something with a certain title or keyword and comms aren’t recognising this (or not providing adequate navigation to find it) then the item is unlikely to be found.
Similarly my third point is again both, it is an issue of usability but if that stops users conducting searches then it would impact daily search patterns and usage.

I interpret this reply as Nigel arguing against Luc’s assertion around lack of rapport being the reason behind intranet and comms teams not listening and learning from all levels of the user base.

Nigel finishes by arguing that even if social media issues are usability issues, they might still impede search and the idea is therefore valid.

Bob Meier • I really like Nigel’s point about the importance of feedback loops on Intranets, and without those it’s hard to build a system that’s continually improving. I don’t have any data on it, but I suspect most companies don’t regularly review their search analytics even if they have them enabled. Browse-type searching is harder to measure/quantify, but I’d argue that periodic usability testing can be used in place of path analysis.
I also agree with Luc – my comment on users gravitating from the Intranet to easier alternatives could be a symptom rather than a cause. However, I think it’s a self-reinforcing symptom. When you eliminate other options for finding information, then the business is forced to improve the preferred system, and in some cases that can mean user training. Not seeing a search box is a great example of something that could be fixed with a 5-minute Intranet orientation.
If I were to replace my third reason, I’d point at ambiguous or mis-placed Intranet ownership . Luc mentions Communications departments, but in my experience many of those are staffed for distributing executive announcements rather than facilitating collective publishing and consumption. I’ve seen many companies where IT or HR own the Intranet, and I think the “right” department varies by company. Communications could be the right place depending on how their role is defined.

Bob makes quite a number of points in this answer, right across various elements of the unfolding discussion. Firstly, he makes a point about analytics and the fact that a lack of feedback loops makes it hard to build a system that continually improves.

In term of the discussion around easier alternatives, Bob offers some strategies to mitigate the issue. He notes that there are training implications when eliminating the easier alternatives.

Finally, Bob identifies issues around the ownership of the intranet as another answer to the original question of people not being able to find stuff on the intranet. He also lists a couple of common examples.

Karen Glynn • I think the third one listed by Bob is an effect not a cause.
Another cause could be data being structured in ways that employees don’t understand – that might be when it is structured by departments, so that users need to know who does what before they can find it, or when it is structured by processes that employees don’t know about or understand. Don’t forget intranet navigations trends are the opposite to the web – 80% of people will try and navigate first rather than searching the intranet.

In this answer, Karen’s starts by agreeing with the point Luc made about “easier alternatives” being a symptom rather than a cause, so there is no need to add it to the map as it is already there. However she provides a new answer to the original question: the structure of information (this by the way is called top-down information architecture – and it was bound to come out of this discussion eventually). She also makes a claim that 80% of people will navigate prior to search on the intranet. I wonder if you can tell what will happen next?

Luc de Ruijter • @Nigel Are (customer) keywords the real cause for not finding stuff? In my opinion this limits the chalenge (of building effective intranet/websites) to building understandable navigation patters. But is navigation the complete story? Where do navigation paths lead users to?
@Bob Doesn’t an investiment in training in order to have colleagues use the search function sound a bit like attacking the symptom? Why is search not easy to locate in the first place? I’d argue you’re looking at a (functional) design flaw (cause) for which the (where is the search?) training is a mere remedy, but not a solution.
@Karen You mention data. How does data relate to what we conventionally call content, when we need to bring structure in it?
Where did you read the 80% intranet-users navigate before searching?

Okay, so this is the first time thus far where I do a little bit of map restructuring. In the discussion so far, we had two ideas offered around the common notion of vocabulary. In this reply, Luc states “Are (customer) keywords the real cause for not finding stuff?” I wasn’t sure which vocabulary issue he was referring to, so this prompted me to create a “meta idea” called “Vocabulary and labelling issues”, of which there are two examples cited thus far. This allowed me to capture the essence of Luc’s comment as a con against the core idea of issues around vocabulary and labelling.

Luc then calls into question Bob’s suggestion of training and eliminating the easier alternatives. Prior to Luc’s counter arguments, I had structured Bob’s argument like this:

To capture Luc’s argument effectively, I restructured the original argument and made a consolidated idea to “eliminate other options and provide training”. This allowed me to capture Luc’s counter argument as shown below.

Finally, Luc asked Karen for the source of her contention that 80% of users navigate intranets, rather than use the search engine first up.

In this final bit of banter for now, the next three conversations did not add too many nodes to the map, so I have grouped them below…

Karen Glynn • Luc, the info came from the Neilsen group.

Helen Bowers • @Karen Do you know if the Neilsen info is available for anyone to look at?

Karen Glynn • I don’t know to be honest – it was in one of the ‘paid for’ reports if I remember correctly.

Luc de Ruijter • @Karen. OK in that case, could you provide us with the title and page reference of the source? Than it can become usable as a footnote (in a policy for instance).Thanks
Reasons so far for not finding stuff:
1. Lack of metadata (lack of content structure).
2. Inconsistent vocabulary and acronyms (customer care words).
3. Adopting social media from a hype-driven motivation (lack of coherence)
4. Bad functional design (having to search for the search box)
5. Lack of measuring and feedback on (quality, performance of) the intranet
6. Silo’s. Site structures suiting senders instead of users

So for all that Banter, here is what I added to what has already been captured.

Where are we at?

At this point, let’s take a breath and summarise what has been discussed so far. Below is the summary map with core answers to the question so far. I have deliberately tucked away the detail into sub maps so you can see what is emerging. Please note I have not synthesised this map yet (well … not too much anyway). I’ll do that in the next post.

If you want to take a look at the entire map as it currently stands, take a look at the final image at the very bottom of this post. (click to enlarge). I have also exported the entire map so far for you to view things in more context. Please note that the map will change significantly as we continue to capture and synthesise the rationale, so as we continue to unpack the discussion, expect this map to change quite a bit..

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

I was surprised to see the recent SharePoint Fatigue Syndrome post got some traction in the interweb. As it happened, that particular post was kicking around in an unfinished state for months. The thing is, its not the only “home truth” type of post that I have sitting in my “drafts” folder. I also have one on the state of the SharePoint training market. Given that I have a training announcement to make, I thought that I would combine them.

A day in the life…

We recently worked on a SharePoint upgrade project, where the previous developers did an excellent job overall. That is…if you judge them on the SharePoint governance metrics of writing clean and maintainable code, packaging it up properly, not hacking away at system files and actually writing documentation.

Unfortunately, although they did an excellent job through that lens, the actual solution, when judged on whether users found that it made their life easier, it was an epic fail. Users hated it with passion and like many solution that users hate, the system was soon relegated to being a little-used legacy platform where the maintenance costs now outweighed the benefits. The organisation had invested a couple-hundred thousand dollars on this solution and saw very little value for that money. Accordingly, they took their business elsewhere…to us. After a workshop, the client had one of those inverse “aha” moments when they realised that if they had taken a little more time to understand SharePoint, the custom solution would have never been developed in the first place.

This sort of example, to me, highlights where SharePoint governance goes so wrong. The care and diligence the developers exercised was necessary, but clearly not sufficient. No matter what the quality of the code, the unit testing regime and its packaging, at the end of the day a blueberry pie was baked and the client wanted an apple pie. The problem was not in the ingredients or the baking. The problem was that by the time they delivered the pie, it was clear that the wrong recipe was used. In the above case, the developer had omitted a whole raft of critical considerations in creating the solution – none of which were covered in developer training.

Necessary but not sufficient…

When you think about it, the current approach to SharePoint training seems not to be about recipes, but all about ingredients. Trainees get shipped off to “boot camps” for an indoctrination of all of the ingredients in the cupboard (and SharePoint is a bloody big cupboard!). SharePoint features and components are examined in individual detail, usually with an accompanying exercise or lab to demonstrate competency in that particular component. Graduates then return with a huge list of ingredients, but still no skills in how to develop the right recipes.

What exacerbates this problem is that training is siloed across disciplines. As an example: An “IT Pro” bootcamp will go into meticulous detail about performance, scalability and design aspects. Any considerations around development, information architecture and user engagement are seen through the lens of the infrastructure nerd. (Ah – who am I kidding… user engagement in an IT pro bootcamp has never happened. )

Now consider for a second, how we design SharePoint sites. These days, it is common for people to actively discourage designing SharePoint solutions based on organisational departmental boundaries. (By organisational departmental boundaries I mean Marketing, HR, IT etc.) Why is this design approach frowned upon? Proponents claim that it tends to perpetuate  the problem of information silos and doesn’t stand the test of time, given that organisations tend to restructure just when your information architecture masterpiece is ready for prime time. In fact, the research organisation Jackob Neilsen did a study and found that task based structures (characterised by “My…” and “I need to…”) endured better than organisational based structures. Quoting from them:

In our study, task-based structures often endured better than intranets organized departmentally. In our user testing of intranets, we’ve also found that task-based navigation tends to facilitate ease-of-learning. Thus, the benefits for IA durability are just one more argument in favor of adopting a task-based structure for your intranet.

So what I find ironically funny is the second sentence of the Jackob Neilsen quote: “Ease-of-learning.” I wonder what sort of learning they are talking about? Presumably something other than delivering a failed solution with some really nice programming governance behind it! Yet the way SharePoint training is designed and marketed actually compartmentalises SharePoint training into similar silos. The result? Students get a rose coloured view of the SharePoint world, based on their discipline. This is because, as Ackoff brilliantly put it,  “complexity is in the eye of the beholder – the other persons job always looks simple”.

By the way, what I am highlighting is not the fault of the trainers because at the end of the day, they respond to what they think the market wants. Sadly, what the market thinks it wants is often not what it needs.

I feel that the missing link – and most critical aspect of SharePoint training for practitioners – is not about how many ingredients you know, but how you go about creating those recipes. Yet SharePoint training overly focuses on what each ingredient does in isolation – whether a job discipline or a particular component. Whilst I fully accept that knowing the ingredients is a necessity, it is clearly not sufficient. This is an airbrushed version of reality, without due consideration of how ingredients combine in unique scenarios. Accordingly, this training does nothing to teach how to achieve shared understanding between practitioner and the eventual users who have to live with the legacy of what is delivered.

When you think about it, shared understanding is what makes or breaks SharePoint success because it is the pre-requisite to shared commitment to a solution. As demonstrated by the example of great code underpinning a crap solution, lack of shared understanding and commitment will always trump any other good work performed.

What to do about it…

SharePoint is a product that often requires adaptive change on the part of users. Learning the capabilities of the product is one thing – changing entrenched collaborative practice is another altogether. In case you haven’t noticed before, users tend not to be charmed by new, shiny features if they cannot see how it will make their jobs easier. (Nerdy knowledge workers like you and me easily get seduced by shiny things but our world view is seriously skewed compared to those who live on the coal face of organisations). Thus, the skills required to facilitate change and align various roles, require a different type of training course: one that integrates rather than compartmentalises. One that teaches how to synthesise the whole, rather than reductionise into the parts.

For such a course, no virtual machines are needed because there are no labs to demonstrate competence in some SharePoint component that will be out of date by SharePoint vNext. Instead, such a course needs to focus on the concepts, patterns and practices that are typically not seen in the IT practitioners toolkit (and for that matter, not seen in many complex mainstream IT/PM methodologies). The added bonus for such a course is that the skills and learning’s it provides are applicable beyond SharePoint and even beyond IT itself. While a typical SharePoint might give you mileage for the current version, a course like what I describe will give you tools that you can use anywhere, irrespective of the technology and project.

Does such a class exist? (Is that the longest post you have ever read to get to such a rhetorical question? )

Of course it exists – I’ve been running it around the world for a couple of years now. It’s called the SharePoint Governance and Information Architecture Class (#SPGovIA) and it was a year in the making and comes with lots of goodies, such as a CD with a sample performance framework, governance plan, SharePoint ROI calculator (spreadsheet) and sample mind maps of Information Architecture. The class was originally designed for Microsoft New Zealand, on behalf of 3Grow for the Elite program that used to certify gold partners for serious SharePoint competence. Since then its been run in the UK, Netherlands, US, Australia and New Zealand. Next month I will run classes in Singapore and Hong Kong.

For my US readers, early next year I will be taking the course on the road, specifically Canada and the USA in Feb 2012. This course is not run often, because for me the US is a damn long way to travel and my time is tight these days! So I sincerely hope that if this sort of class sounds interesting to you, then you will consider being part of it. Michal Pisarek has already made an announcement for classes in Vancouver, and more details will be forthcoming for one or two US cities. I only have time for 2 classes in North America, so which city should it be?

For more detail on the class, head on over to www.spgovia.com. While there, click the Media link and watch the first half hour of the class. I look forward to seeing you there.

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

Hiya

I have been wrong about many things – I am happy to admit that. In SharePoint land, one of my bigger naive assumptions was that in early 2007, I figured I’d have maybe a 6 month head start before the rest of the industry began to learn from its initial SharePoint deployment mistakes and start delivering SharePoint “properly.” I thought that I’d better make hay while the sun shines, so to speak, as the market would tighten up as more players entered it.

Yet here we are, heading to the latter half of 2011 – some five years later. As I continue to go into organisations, whether in a SharePoint remedial capacity, or a training/architect capacity, I am still seeing the legacy of really poor SharePoint outcomes. Furthermore I am seeing other, frankly disturbing trends that leave me both concerned and pessimistic. I now have a label for this concern: “SharePoint Fatigue Syndrome.” SharePoint Fatigue Syndrome is hard to define, yet its effects are there for all to see. I suffer from it at times, and I am certain others do too. As an example, recently on the Perth SharePoint User Group on LinkedIn the following topic for discussion was raised:

Hi folks, as you already know we have a worrying skills shortage in SharePoint Development / Architecture in Perth and things are getting worse. It’s getting to the stage where companies have to suspend or worse still abandon their SharePoint projects due to lack of available talent. As the core of the SharePoint community in Perth your suggestions are vital towards finding real solutions to this growing problem. What can be done?

Now I know that this problem is not just limited to Perth. There are consistently reports online that speak of SharePoint people being in demand. So you would think that in a “hot” sector like SharePoint, where the industry is crying out for talent, that the rate of attrition would not outpace the uptake of new talent. After all – money talks, right? If you are a .NET developer with half a brain, there is serious money to be made in SharePoint development land. On top of that, there is the collective realisation in the marketplace that actually talking to people about how SharePoint could make their lives easier, leads to better outcomes. Hence the emergence of this notion of a “SharePoint Architect” with a more varied skill-set that just tech or dev. This role has further been legitimised by entire conferences now just catering to the business this end of the market (I am thinking the Share conferences here).

So, we have all of this newfound collective wisdom spreading through the community via various channels, in terms of the skills and roles required in SharePoint circa 2011 and beyond. We have the fat pay-packets being commanded as a result of demand for these skills. So, with that in mind, why is the attrition rate growing?

As an example, I know personally, several exceptional SharePoint practitioners who are no longer in SharePoint. I’ve also had various quiet conversations with many SharePoint practitioners, right up to SharePoint MCM’s, who vent their various frustrations on how difficult it is to get truly lasting SharePoint solutions in their clients and organisations. I’ve reflected on the various reasons I have come to the conclusion that SharePoint is just plain tiring. As a result, people are burning themselves out.

7 causes of SharePoint Fatigue Syndrome…

Burnout, in case you are not aware, is actually a lack of emotional attachment to what you are doing.  Quoting about.com:

The term “burnout” is a relatively new term, first coined in 1974 by Herbert Freudenberger, in his book, “Burnout: The High Cost of High Achievement.” He originally defined ‘burnout’ as “the extinction of motivation or incentive, especially where one’s devotion to a cause or relationship fails to produce the desired results.

SharePoint Fatigue Syndrome is SharePoint manifested burnout. The symptoms include feeling physically and emotionally drained, difficulty maintaining optimism and energy levels, feeling that you have less to give as the burden of work seems overwhelming. Sound familiar?

So why does SharePoint work run this risk? I see 7 major reasons.

1: Cost pressure leading to overwork

First up, the lure of the big dollar is a double edged sword. Not long ago I shared a beer with a SharePoint developer who’s work I respect greatly, yet I can’t afford to hire. This is because the percentage of chargeable hours he would need to work just so I can break even, is very high. This puts me (the employer) under pressure and at risk. As a result, I need to ensure that my newly minted SharePoint employee is productive from day 1 and I need him to work a lot of hours. But here is the irony. When I had my beer with this developer, the conversation started with him lamenting to me that he is already pulling ridiculous hours (60 to 80 per week). He was looking for a job with less hours and yet more money. This is simply not sustainable, both for employer and employee. The more you chase one (work hours vs. money), the more you lose the other it seems.

2: Structures that force an inappropriate problem solving paradigm (and wicked problems of course)

Then there is the broader problem where structure influences behaviour. As a basic example: from the developers’ perspective, they have to put up with sales guys who promise the world, and project managers who then make their life hell and force them to cut corners delivering the impossible. Project managers find out that their beloved work breakdown structure gets chopped and changed when their pain-in-the-ass developers whine that they can’t make the schedule. As I have stated many times previously, SharePoint project are likely to have wicked problem aspects to them. The structures that work well to deliver tame problems, such as Exchange, a VOIP system or a network upgrade, are much less effective for SharePoint projects. While organisations persist with approaches that consistently fail to deliver good outcomes, and don’t look at the structural issues, the attrition rate will continue. There is only so much that someone can take putting up with these sorts of stresses.

3: Technical complexity

SharePoint’s technical complexity plays a part too. No-one person understands the product in its entirety. The closest person I know is Spence and ages ago on twitter he remarked that even within Microsoft no-one understood it all. As a result, it is simply too easy to make a costly mistake via an untested assumption. (I thought the user profile service was tough – until I did federated claims authentication and multitenancy that is). The utter myriad of features, design options and their even greater number of caveats, mean that one can make a simple design mistake that causes the entire logical edifice of an information architecture to come crashing down. Many have experienced the feeling of having to tell someone that the project time and cost is about to blow out because nobody realised that, say,  Managed Metadata has a bunch of issues that precludes its use in many circumstances. Accordingly, SharePoint architects learn pretty quickly that it is hard to answer a definite “yes” to many questions, because to do so would require a question worded like a contractual clause, to ensure it is framed with appropriate caveats. Even then, consultants would know that lingering feeling in the back of their mind that they might have missed an assumption. This brings me onto…

4: Pace of change

This is BIG…and becoming more acute. Remember the saying ‘The only certainties in life are death and taxes?’ Outside of that, the future is always unpredictable.

In between SharePoint 2003 and SharePoint 2007, the wave of Web 2.0 and social networking broke, forever changing how we collaborate and work with information online (and some of those effects are still to be felt). Microsoft, like any smart organisation, responds to the sentiment of its client base. Microsoft also, like most mature organisations, tends to hedge its bets in terms of marketplace strategy in which it tries to get in on the act with the cool kids, yet tries not to kill the goose that laid the golden egg. Just look at Windows 8’s new interface, tablets, app stores and the cloud.

But that is one facet. Change happens in many forms and at many scales. For example, at a project level, it may mean a key team member leaves the organisation suddenly (SharePoint fatigue no doubt). At a global and organisational level, events like the odd global financial crisis force organisations to change strategic focus very quickly indeed.

I don’t know about you, but when Windows 8 was announced recently I was not excited (in fact I was not excited by SharePoint 2010 either). I thought to myself “So soon? I am still figuring out the current platform!”

As an example of the effect of pace of change, consider all the Government 2.0 initiatives around the world. Collaboration is in-vogue baby, so information should be free and government agencies should engage with the community. While that’s nice and all, there is the world of compliance, security and records management that takes a very different view. So, we end up with market forces that push against each other in combination with vendors hedging strategy of being all things to all people. It’s little wonder that SharePoint projects become very complex very fast.

By the way, it is worthwhile checking out what Bill Brantley in this post sums up the whole government 2.0 issue when he said:

What exactly is the nature of the Gov 2.0 challenge? This question was inspired by Andrew Krzmarzick’s post (What Gov 2.0 Needs Now: Managers, Money and Models) and Christina Morrison’s post (What is Gov 2.0? A survey of Government IT pros) on the recent GovLoop survey about Gov 2.0. As Andrew and Christina argued, the survey demonstrates many differing perspectives on Gov 2.0 in terms of what it actually means and how to implement Gov 2.0. To me, this suggests that Gov 2.0 is the classic wicked problem

5: SharePoint Entropy

One of my clients (who you will meet in my book when it’s published), once said to me “All good ideas eventually deteriorate into hard work.” This is a nice way to lead into the concept of SharePoint entropy, which in some ways is the inevitable outcome from the first four symptoms. The easiest way to understand entropy is to watch this awesome TV series called the “Wonders of The Universe.” In that show, the concept of entropy was discussed and for me made a lot of intrinsic sense. Without getting into the detail, entropy is the notion that over time things move from an organised to less organised state. Rather than have me waste your time trying to explain it in prose, let’s listen to the show in question. (Don’t skip the video – this is important!)

Now what does this has to do with SharePoint fatigue? Gordon Whyte saw what I am getting at with his post on entropy within organisations, especially in relation to change management.

For example, when we build a car we take raw materials such as metal, leather, plastic and glass and arrange them in a highly organised way to make a car. But if we then leave that car for long enough the metal will rust, the glass will become brittle and break and the leather will dry out and turn to dust. If the car is left for a very long time it will eventually disappear altogether. This thought left me wondering about the nature of organisations. If a progression from order to chaos is the natural order of the universe, then is this same pressure present in organisations and, perhaps more importantly, what is the optimum position for an organisation between the extremes of rigid inflexibility (low entropy) and complete chaos (high entropy)? This question is not as crazy as it might at first appear”

Gordon has nailed the issue in his post. Any SharePoint solution that has a low entropic nature requires more energy and effort to maintain that order and control. Complex SharePoint solutions often have complex governance wrapped around them. Governance that is process and structure centric by definition, has low entropy and accordingly, needs higher effort to maintain over time. In fact, if you do not maintain that effort and energy, then any SharePoint solution will usually disintegrate back into the sort of information management chaos that gave rise to SharePoint in the first place!  Rather like the sandcastle in the video.

By the way, I feel that email and file shares are high entropy solutions – all failed SharePoint projects lead back to these tools because they require less structure to maintain (in the short term).

In short, if SharePoint is implemented with low entropy, more energy is needed to maintain it. Remove the energy and very quickly, things become chaotic again. Governance approaches that are not cognisant of this will never stand the test of time. The question then becomes whether people feel that the end in mind is worth the perceived extra effort that is being asked of them.

6. Social complexity

Social complexity is also somewhat of a result of the first five symptoms. Most organisations have a blame culture. If they didn’t, then people wouldn’t spend so much time trying to position themselves for blame avoidance. Social complexity is the result of turf wars, ideological smackdowns and all of the other sort of things that result in the cliché of “the silos” where people are not talking to each-other in organisations. SharePoint exacerbates social complexity for two main reasons.

Firstly, because it is a collaboration tool, it actually requires some collaboration to put it in! This is often easier said than done. Secondly, because it is a pervasive and disruptive technology, it almost always clashes with an established tool, process or practice where proponents aren’t willing to change. In fact, they may not even recognise that there is a problem to solve – especially when SharePoint has been thrust upon them. (In an old post, I wrote about the notion of memeplexes and the ideological immune mechanisms that they create and why it is so hard to get shared understanding across departmental boundaries in organisations. Memetic smackdowns are the result).

The long and the short of social complexity is that there is only so much stress people can take. We all seem to have a pathological need to seek order and safety, rather then remain in a stressful situation. Once social complexity bites, the merry-go-round of staff attrition really starts to bite…

7. Meaning over motivation…

Now if I haven’t completely depressed you, let me offer you a perverse glimmer of light. For those of us who understand the preceding 6 fatigue symptoms, recognise them for what they are and take steps to mitigating them, there is one other symptom that contributes to SharePoint Fatigue Syndrome. This is the trickiest of all – and I am a somewhat willing victim of it.

I have spent a lot of time learning techniques to help address the symptoms I outlined here and as it turns out, these skills are universally applicable, whether in SharePoint, IT or beyond IT. For years now, I have metaphorically had one foot out of the SharePoint world door and the other foot into the world of construction, health and management sectors. Hell…I have written what I think is the first business book ever by a SharePoint person that is a non SharePoint and non IT. I also have clients with SharePoint deployments who do not know me as a SharePoint person at all, but only as a sensemaker (and for that I am grateful.)

The point is this: While the investment in these skills enables me to counter the effects of SharePoint fatigue syndrome, it is also inexorably pulling me away from SharePoint work. It seems that once you crack this nut a little, your skills are in demand across the entire problem solving spectrum. Right now this is my coping mechanism for SharePoint Fatigue Syndrome – I get to step away from SharePoint for periods and work on something else. Eventually…inevitably…I will also be one of those attrition statistics.

Conclusion:

The problem is that SharePoint Fatigue Syndrome is a negatively reinforcing cycle. As evidenced by the SharePoint attrition rate, money isn’t that great a motivator. If it was, then the void of skilled resources would have been filled by now. Paying more money might give you a short term gain, but in the long term is not going to address my seven causes of SharePoint Fatigue Syndrome.

I will leave this admittedly negative sounding post with the key to breaking this cycle. While you can attend my SharePoint Governance and Information Architecture class or Issue Mapping Class to learn many ways, the video below says it all. I encourage you to watch and reflect on it, because it’s the same key point to understanding how to do effective user engagement.

Thanks for reading

Paul Culmsee

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

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

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

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

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

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

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

So why are there lots of sites?

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

Users don’t know any better.

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

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

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

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

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

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

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

What about legacy?

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

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

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

So I ask you the question:

Was this a successful project?

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

Why?

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

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

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

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

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

People remember legacy, not scope

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

Yet…

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

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

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

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

And that’s just tragic.

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

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

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

www.spgovia.com

Hi all

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

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

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

See you soon!

Paul