Hi all

Once in a while, you can come across a case study that not only showcases innovative and brilliant solutions, but tells a much deeper story that both inspires and teaches. I am writing this post to tell you such a story – a story about genuine collaboration and what it can enable when the right conditions exist to foster it.

To explain this story, I first need to talk about the work of an academic named Richard Hackman. Here is a guy who spent most of his working life examining the factors that make teams work really well. Over the years he studied hundreds of high performing teams, trying to distil the magical ingredients that would lead to success for other teams. He would come up with theories, then create models that looked great on a whiteboard, but when applied to real teams in the real world, reality never fitted the models.

From causes to conditions…

After years of doing this, Hackman started to wonder whether he was leaning the ladder against the wrong wall. In other words, he wondered if trying to determine the causes of team efficacy by looking at successful teams retrospectively was the wrong approach. In the end, he changed his focus and asked himself a different question. What are the enabling conditions that need to exist that give rise to great teams?

He came up with six conditions arguing that irrespective of what else you did or what methodology you used, usually led to better results. I will give you a super brief summary below:

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

Now my interest in Hackman and his conditions stemmed from reviewing the published “models” for SharePoint governance. Whether it is the 7 “pillars”, the 5 “steps”, or the 6 “focus areas”, all are developed in a retrospective way – by looking at a mythically perfect SharePoint solution and then breaking it down into all the things that need to be done to enable it. You see, for a long time now, I have deliberately not started with one of the models up front and Hackman offered me a reason why. Instead I first strive to create the conditions that Hackman lists above and develop governance as it is needed, rather than follow a fixed model.

Meet Louis Zulli Jr and his students

Earlier this year, I met Louis Zulli Jnr – a teacher out of Florida who is part of a program called the Centre of Advanced Technologies. We were co-keynoting at a conference and he came on after I had droned on about common SharePoint governance mistakes. Louis then gave a talk that blew me away, and at the same time proved Hackman completely right. The majority of Lou’s presentation showcased a whole bunch of SharePoint powered solutions that his students had written. The solutions themselves were very impressive, as this was not just regular old SharePoint customisation in terms of a pretty looking site with a few clever web parts. Instead, we were treated to examples like:

• IOS, Android and Windows Phone  apps that leveraged SharePoint to display teacher’s assignments, school events and class times;
• Silverlight based application providing a virtual tour of the campus;
• Integration of SharePoint with Moodle;
• An Academic Planner web application allowing students to plan their classes, submit a schedule, have them reviewed, track of the credits of the classes selected and whether a student’s selections meet graduation requirements;
• An innovative campus Hall Pass system that leveraged jQuery, HTML5, CSS3, XML, JSON, REST, List Data Web Services and features integration with IOS, Windows 8 and swipe card hardware.

All of this and more was developed by 16 to 18 year olds and all at a level of quality that I know most SharePoint consultancies would be jealous of. To any of Lou’s students who read this – and I have consulted and delivered SharePoint since 2006, as well as speaking to people around the world on SharePoint – the work quality that I saw is world-class and you all have lucrative careers ahead of you in the SharePoint space and beyond.

So the demos themselves were impressive enough, but that is actually not what impressed me the most. In fact, what had me hooked was not on the slide deck. It was the anecdotes that Lou told about the dedication of his students to the task and how they went about getting things done. He spoke of students working during their various school breaks to get projects completed and how they leveraged each other’s various skills and other strengths. Lou’s final slide summed his talk up brilliantly, and really spoke to Hackman’s six conditions. The slide made the following points:

• Students want to make a difference! Give them the right project and they do incredible things.
• Make the project meaningful. Let it serve a purpose for the campus community.
• Learn to listen. If your students have a better way, do it. If they have an idea, let them explore it.
• Invest in success early. Make sure you have the infrastructure to guarantee uptime and have a development farm.
• Every situation is different but there is no harm in failure. “I have not failed. I’ve found 10,000 ways that won’t work” – Thomas A. Edison

If you look at the above 5 points and think about Hackman’s conditions of compelling direction, supportive context, real team and coaching in particular, you can see that Lou ensured those conditions were present. The results of course spoke for themselves.

About halfway through Lou’s talk, I decided that whether he liked it or not, he was coming out to Australia to tell this story. So we sat down together and talked for a long while and I asked him all sorts of questions about his students, the projects, how he coached his students and how his own teaching style developed. I ended up showing him Hackman’s six conditions for great teams performance and he said “that’s what we do”.

The real lesson…

So as I write this, Lou is on his long journey home after similarly blowing away the attendees of the Australian SharePoint conference with his story about what he and his students have done. His talk was the hit of the conference and I hope that the staff and students of Lakewood High School read this post because it’s important for them to know that their story and examples were the topic of much conversation amongst attendees and highly inspiring. I also hope that people in the SharePoint community read this because CAT shows precisely why SharePoint can be such an amazing enabler within organisations when the right conditions are in place for it. Governance models are great and all, but without these enabling conditions in place, cannot deliver great outcomes on their own.

This leads me onto one final cautionary point – directed at Lou’s students, but applicable to all readers who aspire to improve collaboration in their organisations and their projects.

There are plenty of clever people in this world – in fact most IT people from my experience are intellectually very clever (IQ), but some have all the emotional maturity (EQ) of a baseball bat. IQ is what you are born with, but EQ is caught and lived. What makes great SharePoint practitioners (and in fact great leaders) is EQ, not just IQ and the CAT program shows what happens when clever people are given discretionary freedom with supportive conditions in place. My advice is to never forget that it is the conditions in which a team or organisation finds itself that a strong predictor of outcome. Take the same clever people and change the conditions (for example, from a supportive educational institution to an organisation with a blame culture and silo based fiefdoms) and you will get very different outcomes indeed.

What students may not realise is that what the CAT program is really teaching them is the experience of living those enabling conditions and therefore teaching them EQ. These students will eventually move into organisations that do not necessarily have the same enabling conditions as what exists for them now. So look past the cool API’s, the development tools, technical whitepapers, the certifications, endless debates as to whether X vs Y is the best practice, and understand the conditions like Hackman did. Strive to (re)create those conditions in all your future work and you will go further than a SharePoint laden CV ever will.

This of course, took me around 18 years of working in IT before I figured it out and have been making amends ever since. So whatever you do, wise up earlier than I did!

Thanks for reading

Paul Culmsee

www.cleverworkarounds.com

www.hereticsguidebooks.com

Hi all

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

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

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

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

Hope to see you there!

Paul

Yup you heard right. I am particularly excited for the Melbourne SharePoint conference in June because I get to unleash “Dr Neil” onto the SharePoint world. Neil (who’s full name is Neil Preston) is an Organisational Psychologist who I have been working with for several years now in all sorts of novel and innovative projects. He’s not a SharePoint guy at  all – but that doesn’t matter for reasons that will soon become clear…

I spent January 2013 on holiday in New Zealand and caught up with Debbie Ireland in her home town of Tauranga. We talked about the state of SharePoint conferences around the world and mused about what we could do to raise the bar, particularly with the Melbourne SharePoint conference in June 2013. Both of us felt that over the last few years, the key SharePoint message of “It’s all about business outcomes” was now:

1. well understood by the SharePoint community; and
2. getting a little stale

So the challenge for Debbie and I – and for that matter, all of us in the SharePoint community – is how to go beyond the paradigm of “It’s not about SharePoint, it’s about the business”, and ask ourselves the new questions that might lead to new SharePoint powered innovations.

The theme that emerged from our conversation was collaboration. After all, one of the most common justifications for making an investment in SharePoint is improved collaboration within organisations. Of course, collaboration, like SharePoint itself, means different things to different people and is conflated in many different ways. So we thought that it is about time that we unpacked this phenomena of collaboration that everyone seeks but can’t define. This led to a conversation about what a SharePoint conference would look like if it had the theme of collaboration at its core. Who would ideal to speak at it and what should the topics be?

As Debbie and I started to think more about this theme, I realised that there was one person who absolutely had to speak at this event. Dr Neil Preston. Neil is a world expert on collaboration, and his many insights that have had a huge influence on me personally and shaped my approach to SharePoint delivery. If you like what you read on this blog, or in my book, then chances are that those ideas came from conversations with Neil.

Debbie then suggested that we get Neil to keynote the conference to which he graciously accepted. So I am absolutely stoked that attendees of the Melbourne SharePoint conference will have the opportunity to learn from Neil. I can guarantee you that no SharePoint conference in the world has ever had a keynote speaker with his particular set of skills. Thus, I urge anyone with more than a passing interest in developing a more collaborative culture in their organisations should come to the conference to learn from him.

Then, in one of those serendipitous moments, a few weeks later I was in the US and met an amazing schoolteacher named Louis Zulli Jnr who presented a case study on how he enabled 16-19 year old students to develop SharePoint solutions that would be the envy of many consultancies. As I listened to him speak, I realised that he was the living embodiment of the collaborative maturity stuff that Neil Preston preaches and I asked Debbie about bringing him to Melbourne to speak as well.

So there you have it. On June 11, you get to hear from one of the most brilliant people I have ever met who’s understanding of collaboration and collaborative maturity is second to none. You also get to hear an inspiring case study of what how the incredible potential of enthusiastic and engaged students can enable SharePoint to do amazing things.

That is not all either – we have Craig Brown (of betterprojects.net and LAST conference fame) introducing Innovation Games and we also have John Denegate from collaborative governance specialists Twyfords, speaking on the curse of the expert.

So don’t miss this event – I think it will be amazing. In the next blog post I will write about the 2 day post-conference workshops

Thanks for reading

Paul Culmsee

Hiya

I just recorded the second video on the topic of powerful questions. These powerful questions are the result of the years I’ve spent dialogue mapping many different groups of people on many different problems. As time has gone on, I’ve learnt a lot about collaborative problem solving, and concluded that some questions tend to lead to breakthrough more than others.

In the previous video, I introduced you to the platitude buster question. This time around, I have recorded a video on one of the best questions you can ask in any form of strategy development meeting – the key focus area question. For all you SharePoint types, I always use this question during SharePoint governance planning and when drawing up a project charter, but it is equally effective when working with an executive team who are working out their short and long term strategies.

Like the previous post, I suggest you watch this video in full screen. Enjoy!

Thanks for reading

Paul Culmsee

Hi there…

In a couple of weeks from now, I will be heading to the US for the only time this year – to participate in the Share conference in Atlanta. This will be my first US SharePoint conference since early 2011 and I’ll be delivering one of the keynote talks as well as a 1 day workshop.

The Share conference is always a great event, for both its focus (business users and key decision makers) and its execution (via the highly experienced eventful group). There is always a great line-up of speakers and this year, the key topic areas include user adoption, governance, envisioning and developing roadmaps, business process automation, information architecture, training, change management and upgrade planning.

My keynote is on Friday morning and is called SharePoint Governance Home Truths. The synopsis for the talk is:

You might think that after a decade of SharePoint deployments there would be a yellow brick road of best practices that we could follow that would lead to success. Yet for many organizations, SharePoint governance does not exist, or is enshrined in 100-page monster manuals that weigh as much as a door stop, and that no-one will ever read, let alone understand.

While we persist in methods that deliver sub-optimal results, we will continue to deliver those results! You can have all the documentation and process in the world, but will your users adopt your solution? If Information Architecture for SharePoint was as easy as putting together SharePoint building blocks the right way, then why doesn’t Microsoft publish the obvious best practices? Why is success so difficult to achieve, even if your system is rock-solid, stable, well-documented, and processes-defined?

The secret sauce to a successful SharePoint project is an area that governance documentation barely touches. In fact, documentation is rarely the answer, because SharePoint projects typically have certain characteristics that are different than most other IT projects. Therefore, to understand SharePoint governance, one has to understand the nature of the problems SharePoint is deployed to solve, why traditional delivery approaches often fail, and what to do about it.

Lessons:

• The top five reasons SharePoint governance efforts fail
• The reality of how we actually solve new or novel problems
• The one best practice you need before you consider any other SharePoint best practice

I am also really excited to be able to facilitate a pre conference workshop called Aligning SharePoint to Business Goals: Don’t Just Say It, Do It!. I have had a lot of requests to bring more classes to the US, but living in far flung Australia, makes this difficult. So this is your one chance to participate in one of my workshops in the US this year. The synopsis for this workshop is:

It is common to hear consultants wax lyrical about how we have to align SharePoint to business goals. While this and other popular cliches like ‘obtain executive support or ‘obtain user buy-in’ are easy to say, in practice they are much harder to do. After all, if this was not the case, then business goal alignment would not be near the top of the list of SharePoint challenges.

In this workshop, Paul will offer practical guidance, tools, and methods for taming this complex problem. This in-depth workshop will build upon the presentation on ‘SharePoint Governance Home Truths’ and provide a deeper, more detailed focus. Paul will demonstrate how to guarantee that all aspects of SharePoint delivery clearly align to organizational aspirations, ensuring all stakeholder needs are considered and at the same time, creating the understanding and commitment via an inclusive, collaborative approach.

• Why SharePoint belongs to a class of problems that are inherently hard to solve 
• Why aligning organizational goals is hard 
• What to do when organizational goals are unclear 
• How to avoid chasing platitudes 
• Tapping into the wisdom of crowds 
• Structuring and running a great goal alignment workshop 
• Creating a walking deck 
• Building on foundations – next steps

Now if that wasn’t enough to whet your appetite, then how about a discount! If you register for the conference online and use discount code DELEGATE10 to save $300!

Hope to see you there…

Paul

Hi

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

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

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

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

thanks for reading

Paul Culmsee

www.hereticsguidebooks.com

Hi all

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

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

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

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

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

Reflections…

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

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

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

Thanks for reading

Paul Culmsee

paul.culmssee@sevensigma.com.au

Most SharePoint blogs tend to tell you cool stuff that the author did. Sometimes telling the dumb stuff is worthwhile too. I am in touch with my inner Homer Simpson, so I will tell you a quick story about one of my recent stupider moments…

This is a story about anchoring bias – an issue that many of us can get tripped up by. In case you are not aware, Anchoring is the tendency to be over-reliant on the some information (the “anchor”) when making subsequent decisions. Once an anchor is set in place, subsequent judgments are made by interpreting other information around the anchor.

So I had just used content deployment, in combination with some PowerShell, to push a SharePoint environment from the development environment to the test environment and it had all gone well. I ran through test cases and was satisfied that all was cool. Then another team member brought to my attention that search was not returning the same results in test as in development. I took a look and sure enough, one of the search scopes was reporting way less results than I was expecting. The issue was confined to one pages library in particular, and I accessed the library and confirmed that the pages had successfully migrated and were rendering fine.

Now I had used a PowerShell script to export the exclusions, crawled/managed properties and best bets of the development farm search application, subsequently import into test. So given the reported issue was via search results, the anchor was well and truly set. The issue had to be search right? Maybe the script had a fault?

So as one would do, I checked the crawl logs and confirmed that some items in the affected library were being crawled OK. I then double checked the web app policy for the search crawl account and made sure it had the appropriate permissions. it was good. I removed the crawl exclusions just in case they were excluding more than what they reported to be and I also I removed any proxy configuration from the search crawl account as I have seen proxy issues with crawling before.

I re-crawled and the problem persisted… hmm

I logged into the affected site as the crawl account itself and examined this problematic library. I immediately noticed that I could not see a particular folder where significant content resided. This accounted for the search discrepancy, but checking permissions confirmed that this was not an issue. The library inherited its permissions. So I created another view on the library that was set to not show folders, and when I checked that view, I could see all the affected files and their state was set to “Approved”. Damn! This really threw me. Why the hell would search account not see a folder but see the files within it when I changed the view not to include folders?

Still well and truly affected by my anchoring bias towards search, I started to consider possibilities that defied rational logic in hindsight. I wondered if there was some weird issue with the crawl account, so I had another search crawl account created and retested the issue and still the problem persisted. Then I temporarily granted the search account site owner permission and was finally able to view the missing folder content when browsing to it, but I then attempted a full crawl and the results stubbornly refused to appear. I even reset the index in desperation.

Finally, I showed the behaviour of the library to a colleague, and he said “the folder is not approved”. (Massive clunk as the penny drops for me). Shit – how can I be so stupid?

For whatever reason, the folder in question was not approved, but the files were. The crawler was dutifully doing precisely what it was configured to do for an account that has read permission to the site. When I turned on the “no folder” view, of course I saw the files inside the folder because they were approved. Argh! So bloody obvious when you think about it. Approving the folder and running a crawl immediately made the problem go away.

What really bruised my tech guy ego even more was that I have previously sorted out this exact issue for others – many times in fact! Everybody knows that when content is visible for one party and not others, its usually approvals or publishing. So the fact that I got duped by the same issue I  have frequently advised on was a bit deflating…  except that this all happened on a Friday and as all geeks know, solving a problem on a Friday always trumps tech guy ego.

Thanks for reading

Paul Culmsee

Once upon a time there lived a rather round wizard named Hocklart who worked at the FogWorts school of witchcraft and wizardry. Hocklart was a very proud wizard, perhaps the proudest in all of FogWorts. His pride did not stem from being a great wizard or a great teacher; in reality, he was neither of those. In fact Hocklart was never much good at wizardry itself, but he knew a lot of people who were – and therein lay the reason for his pride. For what Hocklart lacked in magic ability, he more than made up for with his attention to detail, love of process and determination to rise to the top. From the day he arrived at FogWorts as one apprentice amongst many, he was the first to realise that the influential wizards liked to unwind on Friday nights with a cold ale at the Three and a Half Broomsticks Inn. Hocklart sacrificed many Friday nights at that pub, shouting rounds of frothy brew to thirsty senior wizards, befriending them all, listening to their stories and building up peerless knowledge of FogWorts organisational politics and juicy gossip.

This organisational knowledge brought just enough influence for Hocklart to climb the corporate ladder ahead of his more magically adept colleagues and presently he was very proud. As far as Hocklart was concerned, he had the most important job in all of FogWorts – Manager of the Department Responsible for the Integrity of Potions (or DRIP for short).

You see, in schools of witchcraft and wizardry, wizards and witches concoct all sorts of potions for all sorts of magical purposes. Potions of course require various ingredients in just the right amount and often prepared in just the right way. Some of these ingredients are highly dangerous and need to be handed with utmost care, while others might be harmless by themselves, but dangerous when mixed with something else or prepared incorrectly. Obviously one has to be careful in such a situation because a mix-up could be potentially life threatening or at the very least, turn you into some sort of rodent or small reptile.

The real reason why Hocklart was proud was because of his DRIP track record. You see, over the last six years, Hocklart had ensured that Fogwarts met all its statutory regulatory requirements as per the International Spell-casters Standards Organisation (ISSO). This included the “ISSO 9000 and a half” series of standards for quality management as well as the “ISSO 14000 and a sprinkle more” series for Environmental Management and Occupational Health and Safety. (Like all schools of witchcraft and wizardry, Fogwarts needed to maintain these standards to keep their license to operate current and in good standing).

When Hocklart became manager of DRIP, he signed himself up for a week-long training course to understand the family of ISSO standards in great detail. Enlightened by this training, he now appreciated the sort of things the ISSO auditors would likely audit FogWorts on. Accordingly, he engaged expensive consultants from an expensive consultancy to develop detailed management plans in accordance with wizardry best practices. To deliver this to the detail that Hocklart required, the consultants conjured a small army of business analysts, enterprise architects, system administrators, coordinators, admin assistants, documenters, quality engineers and asset managers who documented all relevant processes that were considered critical to safety and quality for potions.

Meticulous records were kept of all activities and these were sequestered in a secure filing room which was, among other things, guaranteed to be spell-proof. Hocklart was particularly fond of this secure filing room, with its rows and rows of neatly labelled, colour coded files that lovingly held Material Safety Data Sheets (MSDS) for each potion ingredient. These sheets provided wizards the procedures for handling or working with the ingredients in a safe manner, including information of interest to wizards such as fulmination point, spell potency, extra-magical strength, reversal spells as well as routine data such as boiling point, toxicity, health effects, first aid, reactivity, storage, disposal, protective equipment and spill-handling procedures. All potion ingredients themselves were stored in the laboratory in jars with colour coded lids that represented the level of hazard and spell-potency. Ever the perfectionist, Hocklart ensured that all jars had the labels perfectly aligned, facing the front. The system was truly was a thing of beauty and greatly admired by all and sundry, including past ISSO auditors, who were mesmerised by what they saw (especially the colour coded filing system and the symmetry of the labels of the jars).

And so it came to pass that for six years Hocklart, backup up by his various consultants and sub-contractors, saw off every ISSO auditor who ever came to audit things. All of them left FogWorts mightily impressed, telling awestruck tales of Hocklart’s quality of documentation, attention to detail and beautiful presentation. This made Hocklart feel good inside. He was a good wizard…nay, a great one: no one in the wizard-world had emerged from an ISSO audit unscathed more than twice in a row…

On the seventh year of his term as FogWarts head of DRIP, Hocklart’s seventh audit approached. Although eagerly waiting to impress the new auditor (as he did with all the previous auditors), Hocklart did not want to appear overly prepared, so he tried to look as nonchalant as possible by casually reviewing a draft memo he was working on as the hour approached. Only you and I, and of course Hocklart himself, knew that in the weeks prior to today, Hocklart was at his meticulous best in his preparation. He had reviewed all of the processes and documentation and made sure it was all up to date and watertight. There was no way fault could be found.

Presently, there was a rap on the open door, and in walked the auditor.

“Potter – Chris Potter,” the gentleman introduced himself. “Hocklart I presume?”

Hocklart had never met Potter before so as they shook hands he sized up his opponent. The first thing he noticed was that Potter wasn’t carrying anything – no bag, notebook and not even a copy of the ISSO standards. “Have you been doing this sort of work long?” he enquired.

“Long enough,” came the reply. “Let’s go for a walk…”

“Sure,” replied Hocklart. “Where would you like to go?”

For what seemed like an uncomfortably long time to Hocklart, Potter was silent. Then he replied, “Let’s go and have a look at the lab.”

Ha! Nice try, thought Hocklart as he led the auditor to the potion laboratory. Yesterday I had the lab professionally cleaned with a high potency Kleenit spell and we did a stocktake of the ingredients the week before.

Potter cast his sharp eyes around as they walked (as is common with auditors), but remained silent. Soon enough they arrived at a gleaming, most immaculate lab, with nothing out of place. Without a word, Potter surveyed the scene and walked to the shelves of jars that held the ingredients, complete with colour coded lids and perfectly aligned labels. He picked up one of the red labelled jars that contained Wobberworm mucus – a substance that, while not fatal, was known to cause damage if not handled with care. Holding the jar, he turned to Hocklart.

“You have a Materials Safety Data Sheet for this?”

Hocklart grinned. “Absolutely… would you like to see it?”

Potter did not answer. Instead he continued to examine the jar. After another uncomfortable silence, Potter looked up announcing, “I’ve just got this in my eyes.” His eyes fixed on Hocklart.

Hocklart looked at Potter in confusion. The Wobberworm mucus was certainly not in Potter’s eyes because the jar had not been opened.

“What?” he asked hesitantly.

Potter, eyes unwaveringly locked on Hocklart, remained silent. The silence seemed an eternity to Hocklart. A quick glance at his watch then Potter, holding up the jar in his hand, repeated more slowly, “I’ve just got this in my eyes.”

Hocklart’s heart rate began to rise. What is this guy playing at? He asked himself. Potter, meanwhile, looked at his watch again, looked back at Hocklart and sighed. “It’s been a minute now and my eye’s really starting to hurt. I risk permanent eye damage here… What should you be doing?”

A trickle of sweat rolled down Hocklart’s brow. He had not anticipated this at all.

Potter waited, sighed again and grated, “Where is the Materials Safety Data Sheet with the treatment procedure?”

A cog finally shifted in Hocklart’s mind as he realised what Potter was doing. Whilst he was mightily annoyed that Potter had caught him off guard (he would have to deal with that later), right now however he had to play Potter’s game and win.

“We have a secure room with all of that information,” he replied proudly. “I can’t have any of the other wizards messing with my great filing system, it’s my system…”

“Well,” Potter grated, “let’s get in there. My eye isn’t getting any better standing here.”

Hocklart gestured to a side door. “They are in there.” But as he said it his heart skipped a beat as a sense of dread came over him.

“It’s… “ he stammered then cleared his throat. “It’s locked.”

Potter looked straight into Hocklart with a stare that seemed to pierce his very soul. “Now I’m in agony,” he stated. “Where is the key?”

“I keep it in my office…” he replied.

“Well,” Potter said, “I now have permanent scarring on my eye and have lost partial sight. You better get it pronto…”

Hocklart continued to stare at Potter for a moment in disbelief, before turning and running out of the room as fast as his legs could carry his rotund body.

It is common knowledge that wizards are not known for being renowned athletes, and Hocklart was no exception. Nevertheless, he hurtled down corridors, up stairs and through open plan cubicles as if he was chased by a soulsucker. He steamed into his office, red faced and panting. Sweat poured from his brow as he flung a picture from the wall, revealing a safe. With shaking hands, he entered the combination and got it wrong twice before managing to open the safe door. He grabbed the key, turned and made for the lab as if his life depended on it.

Potter was standing exactly where he was, and said nothing as Hocklart surged into the room and straight to the door. He unlocked the door and burst into the secure room. Recalling the jar had a red lid, Hocklart made a beeline for the shelf of files with red labels, grabbed the one labelled with the letter W for Wobberworm and started to flick through it. To his dismay, there was no sign of a material safety data sheet for Wobberworm mucus.

“It’s…it’s not…it’s not here,” he stuttered weakly.

“Perhaps it was filed under “M” for mucus?” Potter offered.

“Yes that must be it”, cried Hocklart (who at this stage was ready to grasp at anything). He grabbed the file labelled M and flicked through each page. Sadly, once again there was no sign of Mucus or Wobberworm.

“Well,” said Potter looking at his watch again. “I’m now permanently blind in one eye… let’s see if we can save the other one eh? Perhaps there is a mismatch between the jar colour and the file?”

Under normal circumstances, Hocklart would snort in derision at such a suggestion, but with the clock ticking and one eye left to save, it seemed feasible.

“Dammit”, he exclaimed, “Someone must have mixed up the labels.” After all, while Wobberworm mucus was damaging, it was certainly not fatal and therefore did not warrant a red cap on the jar. This is why I can’t trust anyone with my system! he thought, as he grabbed two orange files (one labelled W for Wobberworm and one labelled M for mucus) and opened them side by side so he could scan them at the same time.

Eureka! On the fifth page of the file labelled M, he found the sheet for Wobberworm mucus. Elated, he showed the sheet to Potter, breathing a big sigh of relief. He had saved the other eye after all.

Potter took the sheet and studied it. “It has all the necessary information, is up to date – and the formatting is really nice I must say.” He handed the sheet back to Hocklart. “But your system is broken”

Hocklart was still panting from his sprint to his office and back and as you can imagine, was absolutely infuriated at this. How dare this so-called auditor call his system broken. It had been audited for six years until now, and Potter had pulled a nasty trick on him.

“My system is not broken”, he spat vehemently. “The information was there, it was current and properly maintained. I just forgot my key that’s all. Do you even know how much effort it takes to maintain this system to this level of quality?”

A brief wave of exasperation flickered across Potter’s face.

“You still don’t get it…” he countered. “What was my intent when I told you I spilt Wobberworm mucus in my eye?”

To damn well screw me over, thought Hocklart, before icily replying “I don’t care what your intent was, but it was grossly unfair what you did. You were just out to get me because we have passed ISSO audits for the last six years.”

“No,” replied Potter. “My intent was to see whether you have confused the system with the intent of the system.”

Potter gestured around the room to the files. “This is all great eye candy,” he said, “you have dotted the I’s, and crossed the T’s. In fact this is probably the most comprehensive system of documentation I have ever seen. But the entire purpose of this system is to keep people safe and I just demonstrated that it has failed.“

Hocklart was incredulous. “How can I demonstrate the system works when you deliberately entrapped me?”, he spat in rage.

Potter sighed. “No wizards can predict when they will have an accident you know,” he countered. “Then it wouldn’t be an accident would it? For you, this is all about the system and not about the outcome the system enables. It is all about keeping the paperwork up to date and putting it in the files… I’m sorry Hocklart, but you have lost sight of the fact the system is there to keep people safe. Your organisation is at significant risk and you are blind to that risk. You think you have mitigated it when in fact you have made it worse. For all the time, effort and cost, you have not met the intent of the ISSO standards.“

Hocklart’s left eye started to twitch as he struggled to stop himself from throwing red jars at Potter. “Get out of my sight,” he raged. “I will be reporting your misconduct to my and your superiors this afternoon. I don’t know how you can claim to be an auditor when you were clearly out to entrap me. I will not stand for it and I will see you disciplined for this!”

Potter did not answer. He turned from Hocklart, put the jar of Wobberworm mucus back on the shelf where he had found it and turned to leave.

“For pete’s sake”, Hocklart grated, “the least you could do is face the label to the front like the other jars!”

=========================

I wrote this parable after being told the real life version of a audit by a friend of mine… This is very much based on a true story. My Harry Potter obsessed daughter also helped me with some of the finer details. Thanks to Kailash and Mrs Cleverworkarounds for fine tuning…

.

Paul Culmsee

Hi all

*sigh*

This post comes to you during my reality check of returning to work after the bliss of 1 month of vacation in New Zealand. After walking on a glacier, racing around in jetboats and relaxing in volcanic hot springs, the thought of writing SharePoint blog posts isn’t exactly filling me with excitement right now. But nevertheless I am soldiering on, because as Ruven Gotz frequently tells his conference attendees – I do it because I love you all.

Now this is article ten (blimey!) in a series of posts about my insights of being a cross between a SharePoint architect and facilitator/sensemaker. In case this is your first time reading this series, I highly recommend that you go back to the beginning as we have covered a lot of ground to get to here. Inspired by the late, great Russell Ackoff, I used his notion of f-laws – sometimes inconvenient truths about what I think is critical for successful SharePoint delivery. At this point in proceedings, we have covered 6 f-laws across 9 articles.

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

The next f-law we are going to cover is a bit of a mouthful. Are you ready?

F-Law 7: The degree of governance strictness is inversely proportional to the understanding of the chaos its supposed to prevent

So to explain this f-law, here is a question I often ask clients and conference attendees alike…

What is the opposite of governance?

The answer that most people give to this question is “Chaos”. So what I am implying? Essentially that the stricter you are in terms of managing what you deem to be chaos, the less you actually understand the root causes of chaos in the first place.

Ouch! Really?

To explain, let’s revisit f-law 5, since this is not the first time the theme of chaos has come up in this series. If you recall f-law 5 stated that confidence is the feeling you have until you understand the problem. In that article, I drew the two diagrams below, both of them representing the divergence and convergence process that comes with most projects. The pink box labelled chaos illustrated that before a group can converge to a lasting solution, they have to cross the ‘peak’ of divergence. This is normally a period of some stress and uncertainty – even on quite straightforward projects. But commonly in SharePoint things can get quite chaotic with lots of divergence and very little convergence as shown by the rightmost diagram where there appears to be little convergence.

“Thou shalt not…”

There are clearly forces at play here… forces that push against convergence and manifest in things like scope creep, unreconciled stakeholder viewpoints and the stress of seeing the best laid plans messed with. The size and shape of the pink ‘chaos’ box reflects the strength of those underlying forces.

To manage this, many (if not most) SharePoint practitioners take a “thou shalt not” approach to SharePoint delivery in an attempt to head things off before they even happen. After the dissection in f-law 6 of how IT people channel Neo and focus on dial tone issues, it is understandable why this approach is taken. Common examples of this sort of thinking are “Thou shalt not use SharePoint Designer” or “Thou shalt use metadata and not folders” or “Thou shalt use the standard site template no matter what.”

These sort of commandments may be completely appropriate, but these is one really important thing to make sure you consider. If having no governance indeed results in chaos, then it stands to reason that we need to understand the underlying divergent forces behind chaos to mitigate chaos and better govern it. In other words, we need look inside pink box labelled chaos and see what the forces are that push against convergence. So lets modify the diagrams above and take a look inside the pink box.

For me, there are four forces that govern the amount of chaos in SharePoint projects, namely:

1. Pace of Change
2. Problem Wickedness
3. Technical Complexity
4. Social Complexity

Let’s examine each one in turn…

Pace of change

Remember the saying “The only certainty 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. In between SharePoint 2010 and SharePoint 2013, the wave of cloud computing broke, which is slowly but surely changing the way organisations view their IT assets (both systems and people). The implications of this are huge and Microsoft have to align their product to tap into these opportunities. Net result? We all have a heap of new learning to do.

If you read the last post, you might recall that pace of change was a recurring theme when people answered the question about what is hard with SharePoint. But let’s look beyond SharePoint for a second… change happens in many forms and at many scales. At a project level, it may mean a key team member leaves the organisation suddenly. At an organisational level, there might be a merger or departmental restructure. At a global level, events like the Global Financial Crisis forced organisations to change strategic focus very quickly indeed.

The point is that change breeds innovation yet it is relentless and brings about fatigue. Continual learning and relearning is required and even the best laid plans will inevitably be subject to changing circumstances. The key is not to fight change but accept that it will happen and work with it. In terms of SharePoint, this is best addressed by an iterative delivery model that has a high degree of key stakeholder involvement, recognises the learning nature of SharePoint and fosters meaningful collaboration.

Problem “Wickedness”

Some problems are notoriously hard to solve because they evoke a lot of diverse, often conflicting viewpoints and it can be difficult even agreeing on what the core problem actually is. F-law 1 examined how we sometimes fixate on the means of governance when the end goal of SharePoint is uncertain. Over-reliance on definitions is the result. F-law 2 looked at how users understanding of a problem changes over time and f-Law 4 looked at the folly in chasing platitudes. The underlying cause for all of these f-laws is often the very nature of the problem you are trying to solve.

You might have heard me talk about wicked problems or read about it in my blog or my book. In short, some problems are exceptionally tough to solve. Just trying to explain the problem can be hard, and analysis-paralysis is common because it seems that each time the problem is examined, a new facet appears which seemingly changes the whole concept of the problem. This phenomenon was named as a wicked problems by Horst Rittel in 1970. One of the most extreme examples right now of a wicked problem in the USA would be the gun control debate since depending on your values and ideology, you would describe the underlying problem in different ways and therefore, the potential solutions offered are equally varied and contentious.

While there are actually many different management gurus who have also come up with alternate names for this sort of complexity (“mess”, “adaptive problem”, “soft systems”), the term wicked problem has become widely used to describe these types of problems. I suspect this is because Rittel listed a bunch of symptoms that suggest when your problem has elements of wickedness. Here are some of the commonly cited ones:

1. There is no definitive formulation of a wicked problem (defining wicked problems is itself a wicked problem).
2. The problem is not understood until after the formulation of a solution.
3. There is no immediate and no ultimate test of a solution to a wicked problem.
4. Every solution to a wicked problem is a “one-shot operation”; because there is no opportunity to learn by trial and error, every attempt counts significantly.
5. Wicked problems do not have an enumerable (or an exhaustively describable) set of potential solutions, nor is there a well-described set of permissible operations that may be incorporated into the plan.
6. Every wicked problem is essentially unique.
7. Every wicked problem can be considered to be a symptom of another problem.
8. The existence of a discrepancy representing a wicked problem can be explained in numerous ways. The choice of explanation determines the nature of the problem’s resolution.
9. Stakeholders have radically different world views and different frames for understanding the problem.
10. The constraints that the problem is subject to and the resources needed to solve it change over time.
11. The problem is never solved definitively

Can you tick off some of those symptoms with SharePoint? I’ll bet you can… I’ll also bet that for other IT projects (say MS Exchange deployments) these symptoms are far less pronounced.

Guess what the implication is of wicked problems. They tend to resist the command-and-control approach of delivery and require meaningful collaboration to get them done. That is kind of funny when you think about it since SharePoint is touted as a collaboration tool yet falls victim to wicked elements. That suggests that there was not enough collaboration to deliver the collaboration platform!

Technical Complexity

Technical complexity involves difficulties in fact finding, technical information and the systematic identification and analysis of options and their likely consequences. It is an understatement to say that SharePoint is full of technical complexity. In fact, it is one of the most complex products that Microsoft has ever produced (and that’s before you get to dependencies like SQL Server, IIS, FIM, Federated authentication and the myriad of other things you need to know)

A typical characteristic of technical complexity is information overload in fact finding. There is far too much information to make sense of and as a result, no one person has the cognitive capacity to understand it all. Thus, stakeholders have to rely on each other and, on occasions, rely on outside experts to collaboratively work towards a solution. Technical complexity requires a lot of cognitive load to manage and it is easy to get caught up in the minute detail and lose the all important bigger picture.

Problems also arise when different technical experts come to opposite conclusions. This gives rise to the last and most insidious divergent force underlying SharePoint chaos and the governance that goes with it – social complexity.

Social Complexity

The first three symptoms tend to create a perfect storm of complexity, since we have a situation where there is a lot of uncertainty. Many people hate this because unknown unknowns creates fear if sufficient trust does not exist between all key parties. Developing trust is made all the harder because we are all a product of our experiences, with different values, cultural beliefs, personality styles and biases so reconciling different world views on various issues can be difficult. Then you have the issue that many organisations have a blame culture and people position themselves to avoid it. This my friends is social complexity and I know that all of you live this sort of stuff everyday.

Yet under the right circumstances, groups can be remarkably intelligent and are often smarter than the smartest people in group. Groups do not need to be dominated by exceptionally intelligent people in order to be smart – in fact diversity of group makeup is a much more important factor than individual IQ. Without this diversity, groups are less likely to arrive at a good answer to a given problem because they are likely to fall into groupthink. Groupthink is when highly cohesive groups make unsound decisions due to group pressures, ignoring possible alternatives. Every management team that only wants to hear the good news is likely to have fallen foul of groupthink. The same applies to dismissing all SharePoint governance except for the dial tone stuff.

However, there is an inherent paradox here:

• The more parties involved in a collaboration, the more socially complex;
• The more different these parties are, the more diverse, the more socially complex; and
• This creates tension, resentment and lack of communication and a strong desire to go back to business as usual

This paradox between diversity and harmony is the toughest aspect of the four forces to tackle.

Key takeaways…

Way back in the very first post I stated that a key job of a SharePoint architect is to architect the conditions by which SharePoint is delivered. By this I mean that the architect has to grease the gears of collaboration between stakeholders and provide an environment that has the safety and structure for people to raise their issues, speak their truths and not get penalised for improving their understanding of the problem.

To enable this to happen, we need to tackle all four of the forces behind chaos that we have covered here. In short, if you focus governance efforts only on one of the forces you will simply inflame the others. Accordingly, the final diagram illustrates the key takeaway from f-Law 7. Since the four forces behind chaos push out and create divergence, our governance efforts needs to push back. But the important thing to note is the direction of my arrows. It is not necessarily appropriate to provide a direct counterforce via the “thou shalt not” type of all-or-nothing approach. Governance always has to steer towards the solution. The end always drives the means and not the other way around! Arbitrarily imposing such restrictions is often done without due consideration of the end in mind and therefore gets in the way of the steering process. This is why my arrows point inwards, but always push toward the solution on the right.

In this context, it can be seen why envisioning, stakeholder and goal alignment is so critical. Without it, its too easy for governance to become a self fulfilling prophecy. So when you look at your own projects, draw my divergence/convergence diagram and estimate how big the pink box is. If you sense that there is divergence, then look at where your gaps are and make sure you create the conditions that help mitigate all of the forces and not just one one of them.

Thanks for reading

Paul Culmsee

www.hereticsguidebooks.com