A Very Potter Audit – A Best Practices Parable

Send to Kindle

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

HGBP_Cover-236x300

 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

Confession of a (post) SharePoint architect… What are you polishing?

This entry is part 9 of 10 in the series confessions
Send to Kindle

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

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

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

No matter how much you polish it…

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

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

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

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

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

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

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

The hardest thing…

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

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

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

Brisbane 2012 and Melbourne 2010

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

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

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

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

Some analysis…

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

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

Auckland 2011

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

Some more analysis…

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

The additional themes that I noted from this group were:

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

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

Singapore 2012

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

Final Analysis

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

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

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

Conclusions and takeaways

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

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

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

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

 

Thanks for reading

 

Paul Culmsee

www.hereticsguidebooks.com

 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

Why I’ve been quiet…

Send to Kindle

As you may have noticed, this blog has been a bit of a dead zone lately. There are several very good reasons for this – one being that a lot of my creative energy has been going into co-writing a book – and I thought it was time to come clean on it.

So first up, just because I get asked this all the time, the book is definitely *not* “A humble tribute to the leave form – The Book”! In fact, it’s not about SharePoint per se, but rather the deeper dark arts of team collaboration in the face of really complex or novel problems.

It was late 2006 when my own career journey took an interesting trajectory, as I started getting into sensemaking and acquiring the skills necessary to help groups deal with really complex, wicked problems. My original intent was to reduce the chances of SharePoint project failure but in learning these skills, now find myself performing facilitation, goal alignment and sensemaking in areas miles away from IT. In the process I have been involved with projects of considerable complexity and uniqueness that make IT look pretty easy by comparison. The other fringe benefit is being able to sit in a room and listen to the wisdom of some top experts in their chosen disciplines as they work together.

Through this work and the professional and personal learning that came with it, I now have some really good case studies that use unique (and I mean, unique) approaches to tackling complex problems. I have a keen desire to showcase these and explain why our approaches worked.

My leanings towards sensemaking and strategic issues would be apparent to regular readers of CleverWorkarounds. It is therefore no secret that this blog is not really much of a technical SharePoint blog these days. The articles on branding, ROI, and capacity planning were written in 2007, just before the mega explosion of interest in SharePoint. This time around, there are legions of excellent bloggers who are doing a tremendous job on giving readers a leg-up onto this new beast known as SharePoint 2010.

BBP (3)

So back to the book. Our tentative title is “Beyond Best Practices” and it’s an ambitious project, co-authored with Kailash Awati – the man behind the brilliant eight to late blog. I had been a fan of Kailash’s work for a long time now, and was always impressed at the depth of research and effort that he put into his writing. Kailash is a scarily smart guy with two PHD’s under his belt and to this day, I do not think I have ever mentioned a paper or author to him that he hasn’t read already. In fact, usually he has read it, checked out the citations and tells me to go and read three more books!

Kailash writes with the sort of rigour that I aspire to and will never achieve, thus when the opportunity of working with him on a book came up, I knew that I absolutely had to do it and that it would be a significant undertaking indeed.

To the left is a mock-up picture to try and convey where we are going with this book. See the guy on the right? Is he scratching his head in confusion, saluting or both? (note, this is our mockup and the real thing may look nothing like this)

This book dives into the seedy underbelly of organisational problem solving, and does so in a way that no other book has thus far attempted. We examine why the very notion of “best practices” often makes no sense and have such a high propensity to go wrong. We challenge some mainstream ideas by shining light on some obscure, but highly topical and interesting research that some may consider radical or heretical. To counter the somewhat dry nature of some of this research (the topics are really interesting but the style in which academics write can put insomniacs to sleep), we give it a bit of the cleverworkarounds style treatment and are writing in a conversational style that loses none of the rigour, but won’t have you nodding off on page 2. If you liked my posts where I use odd metaphors like boy bands to explain SharePoint site collections, the Simpsons to explain InfoPath or death metal to explain records versus collaborative document management, then you should enjoy our journey through the world of cognitive science, memetics, scientific management and Willy Wonka (yup – Willy Wonka!).

Rather than just bleat about what the problems with best-practices are, we will also tell you what you can do to address these issues. We back up this advice by presenting a series of practical case studies, each of which illustrates the techniques used to address the inadequacies of best practices in dealing with wicked problems. In the end, we hope to arm our readers with a bunch of tools and approaches that actually work when dealing with complex issues. Some of these case studies are world unique and I am very proud of them.

Now at this point in the writing, this is not just an idea with an outline and a catchy title. We have been at this for about six months, and the results thus far (some 60-70,000 words) have been very, very exciting. Initially, we really had no idea whether the combination of our writing styles would work – whether we could take the degree of depth and skill of Kailash with my low-brow humour and my quest for cheap laughs (I am just as likely to use a fart joke if it helps me get a key point across)…

… But signs so far are good so stay tuned 🙂

Thanks for reading

 

Paul Culmsee

www.sevensigma.com.au

 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

The one best practice to rule them all – Part 1

Send to Kindle

image

This is a post or three that I have really been looking forward to writing, and it is a long time in the making for various reasons. Some of you, after reading it, will no doubt wonder if I have been taking magic mushrooms or something similar, but if the feedback from the SharePoint Best Practices conference is anything to go by, then maybe a couple of readers will have the same sense of realisation and clarity that I had.

I am going to tell you the first best practice that you should master. If you master this, all of the other best practices will fall into place. It goes beyond SharePoint too. Failure to do this, and all of your other best practices may not necessarily save you. In fact they can actually work against you. Hence the “Lord of the Rings” inspired title of this post.

Before we begin, I have to make a confession. I am not a 100% full time SharePoint consultant anymore. Don’t get me wrong. I still do, and will continue to perform a *heck* of a lot of SharePoint advisory and pick through the wreckage of many a chaotic installation. But I have worked hard to develop a new skill over the last year that has proven to be particularly powerful and profound in my SharePoint practice. The response of those SharePoint clients with whom I have used this craft has been overwhelmingly positive. The thing is though, this craft has started to take on a life of its own and now I am being called on to use it outside the SharePoint realm – despite SharePoint being the whole reason I found it in the first place.

So to explain this craft I really need to explain how I came to find it.

“I don’t know what I am delivering anymore”

Back in  late 2006, I was the infrastructure architect at a mid sized MOSS early adopter. This organisation came from a place of pretty low maturity around their document, knowledge and information management practices. As I have subsequently come to understand and recognise, many organisations coming from this place have a tendency to try to boil the ocean, via a phenomena that I previously termed the “panacea effect“. At one level, a big ambitious SharePoint platform was brilliant learning for me personally because I got to put in a multi-server farm as well as the IBM SAN storage, clustered SQL, network load balanced web front end servers, extranet config, custom authentication, publishing and just about everything in between. All in all the perfect site for the tech geek to learn the guts of SharePoint infrastructure and develop an early instinct for governance at that level.

But that wasn’t the problem area – that was actually the *tame* part of the SharePoint project. This project started to unwind pretty quickly for other reasons. Under pressure and eager to produce, the Microsoft enamoured sponsor pushed hard. Each stakeholder had *radically* different world views of what we were doing, and pinning down scope and requirements was an exercise in futility, project time estimates were crashed by more than half because they were more than the sponsors original naive estimate that went to the board of directors. The thoroughly frustrated project manager said to me one day “I don’t know what I am delivering anymore”.

CleverWorkarounds’ Hindsight Rating: Stop now – just stop now.

Around this time I decided to have a chat with some of the major stakeholders because I was really worried about this project to the point that I was thinking of resigning. It seemed that the various stakeholders never actually spoke to each other, instead using the project manager as a kind of proxy. I thought that maybe a few one-on-one, more casual meetings might break a few deadlocks and frustrations.

So, sitting in a coffee place with one particular stakeholder, I was asked the question that was the catalyst for where I am today.

“Paul, can you tell me the difference between SharePoint and Skype?”

(When I told the audience this at the Best Practice conference, I was met with disbelieving laughter. I can tell you that at the time I didn’t laugh – I was so taken aback by the question I just about choked on my double-shot latte!). 

“Well”, he explained, “I can collaborate with anybody in the world using Skype for free, and even call regular land lines very cheaply. Why should I pay half a million bucks for SharePoint to collaborate?”

CleverWorkarounds’ Hindsight Rating: Project participants can hide a lack of understanding longer than you think. Have you ever been in a meeting where you are unsure or do not feel fully informed? It is very common for people to sit quietly rather than stop and say “Sorry, I don’t understand this.”

I spent a lot of time with this stakeholder after that, and little by little I was able to get across various SharePoint basics like libraries, lists, columns and views. What happened next though was that this stakeholder started to suggest we do things that were already in the project plan (he never read it originally because he didn’t understand it). Later he gave me a records based taxonomy from a company that he used to work for in the mid nineties. It was one of those library inspired, record centric taxonomies like what I described in the document management/death metal article. He had decided that all document libraries farm-wide should use 5 common site columns – no more.

He said another thing to me around this time which was also very influential.

“We have one shot to get this right. If we get this wrong, we are going to set the company back years”.

You will understand the significance of this comment soon enough…

Off to the cave…

I think I have told enough of this story that you already know the outcome. There were other stakeholders of course with their own peculiar views of the world, and there were various things we could have done better at all levels. But fundamentally, I was dealing with a guy who’s understanding of the problem clearly changed, the more he learned and the more he thought about the collaboration problem. All of the other stakeholders went through this thought/learning process as well.

This project was something that stuck in my mind for a long time after and I was determined to never ever let this happen again. I mean, we all know SharePoint is technically complex, but the “SharePoint vs Skype” conversation for me was a watershed moment. If I were the PM, how could I have seen this coming and mitigated it early? How could we have gotten into the implementation phase for someone to ask such a question? He sat in all the meetings with everyone else and he saw the famous SharePoint pie chart like everyone else. What was wrong with our processes? Did we need to use a best-practice methodology? Did I need to learn to train people better?

It was time to go off to the metaphorical cave and meditate for a while. (Jeremy Thake once called me the theory master – now you know why).

I dug out my PMBOK books. “Maybe the PMO was implemented too rigidly or with too much dogma?” I thought. But after re-reading that stuff I still couldn’t satisfactorily reconcile the Skype question. We spent days and days developing the project management plan – it was a good plan for its time and anticipated a lot of stuff. It was clear that at least one of the stakeholders never read it beyond a basic skim or perhaps the executive summary.

So I looked at COBiT as it was supposed to be about controls and oversight. I really liked COBiT, especially the RACI charts and the maturity model. To this day I think it is one of the best designed and most elegantly constructed standards out there, but it suffers from being *so* high level and abstract that is really only useful at CIO/board level. In fact COBiT really is an umbrella that sits across all of the other ones, so by itself I think it is next to useless. Thus, it really wasn’t going to be a practical help in dealing with this problem of stakeholder understanding.

What about ISO9001? I mean, it is all about quality right? Maybe we had a quality issue? Maybe some insights were to be found there? Would a quality management plan have helped? Maybe a little bit – I mean I learned the fun you can have with the non conformance clauses. But the issue was *not* what to do once I found a quality problem. The fact that it had become a quality issue means that by definition, something went unnoticed or ignored and then caused some unwanted event to occur. Thus, I needed to recognise it much, much earlier than when it becomes a quality issue.

(ISO9001, if you have not yet read it, will cure even the most hard-core insomniac – guaranteed).

Hmmm, perhaps the answer lies in process improvement? Maybe if we used a best-practice methodology to map out and understand our processes, it would have resulted in a more optimal information architecture exercise. I had watched teams argue over process and accountabilities when we started talking to them about metadata and workflows during the information architecture sessions. So I hit the books on process improvement and business process modelling methodologies – a very crowded space with many standards and theories.

Three things popped up here. IBM’s BPMN (Business Process Modelling Notation), the process improvement methodology Six Sigma (and its variants) and a great book by Geary Rummler called “Improving Performance: How to Manage the White Space in the Organization Chart (Jossey Bass Business and Management Series)“.

I became excited as this was definitely getting closer to what I was looking for. As I read more, I saw potential. BPMN was simply a method to create consistent, easy to understand process flow diagrams and in fact, one of my colleagues has become a master at this craft. But that didn’t address the ‘art’ of process improvement. I found that often when trying to map a process with a group, the group would often start to recognise flaws or flat out disagree on how the process ran within the organisation. Inevitably, as a process mapper, you would sit back and “process debates” would take over the meeting. Clearly there was a step missing.

I also liked the emphasis on data centric decision making of Six Sigma and the emphasis on measurement. I went very low-brow and bought Six Sigma for Dummies and devoured it. As I read it, I started to remember my old high school maths because Six Sigma is very analytical and data driven. Much of what Six Sigma teaches is very, very good from a philosophical standpoint, but it did seem so “epic” and seemed to be geared around “big bang” change.

All of process improvement methodologies were process-heavy and structure-heavy. I feared that the same dogma that I had seen derail the good intentions of PMBOK would affect Six Sigma in the sorts of organisations that I had involvement with. I read a great online document later that suggested Six Sigma in real life had more of a two sigma success rate which I found unsurprising.

I also looked at Lean/Kaizen and a zillion variants. In the end I started to get lost and frustrated. Process improvement (and by association, strategy theory) is an insanely crowded place and some other time, I will write about the various fads as they have come and gone.

The Eureka Moment

Okay so I read a lot of stuff (and now have forgotten most of it). All of the methodologies and practices that I studied had some excellent parts to them, and in fact, most *encourage* you to take the bits that make logical sense for you. As I wrote in Part 8 of the “SharePoint Project Failure…” series, I found it ironic that implementation of many of these methodologies fell victim to the same sorts of “people” issues that derail the original project. The whole ‘big bang’ style approach, whether it was a software project or a best-practice methodology seemed to suffer the same sort of hit-or-miss fate.

Then in one of those times when you randomly surf wikipedia (the fountain of all authoritive knowledge 😉 ), I came across the term “Wicked problems” and the work of Horst Rittel from the early 1970’s. In Rittel’s era, he was talking about a particular class of social policy and planning problems like “What shall we do about the global financial crisis” or “What should we do about global warming”, “What should we do to solve the Palistinian issue?”. Such problems are insanely tough to solve. But as I read about the *characteristics* of a wicked problem as described by Rittel, and subsequently by his student Conklin, I realised that both were describing *exactly* my first MOSS 2007 project.

While I am not suggesting a MOSS project is a wicked problem the way that Rittel or Conklin envision it to be, those “characteristics” or “properties” of wicked problems were so applicable to my experience that is was scary.

Phew!

Since I have been waffling on far too long, I’ll stop things now, and in the next post, I will delve into wicked problems in more detail, both Rittel and Conklin’s definitions, as well as my own definition, that I used at my Best Practices SharePoint Conference session.

 

Thanks for reading

Paul Culmsee

 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

(ab)using ISO9001 for fun and profit

Send to Kindle

I don’t know if you have ever read ISO9001, but it is about as exciting as getting a root canal or trying to listen to a Ricky Martin album with a straight face. But hey, if they were actually interesting, ISO compliance wouldn’t be such a billion dollar industry. Does anybody else use SharePoint for ISO compliance purposes? I’ve done several of them now.

First up, I’ll give you the Cleverworkarounds’ version of ISO9001 and then I’ll teach you how to use it to get your own way 🙂 .

ISO9001 is an internationally recognised standard that provides an organisation with the guiding principles, means and methods to improve their internal quality. If you are wondering what or which quality, then I can’t give you an answer because it depends on your organisation. So for example, Microsoft might use ISO9001 to improve their ability to release a desktop operating system that people actually like. McDonalds may use ISO9001 to ensure that your calorie-laden burger is *consistently* calorie-laden no matter which store you visit.

Continue reading

 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle