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.

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

                      

Technorati Tags: Book, Beyond Best Practices

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

                      

No Tags

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.

Why do they do this? At the end of the day, implementing a quality framework and therefore developing a culture within the organisation to *think* quality has obvious bottom line benefits. Profit improves through internal efficiency gain, customer satisfaction and happy employees.

Now that is all well and good, but how do you as a customer differentiate an organisation with a commitment to quality from one that has not made the effort?

That’s where the logo comes in.

Organisations that put a quality management system in place are then subject to regular audits to ensure they are compliant. This is supposed to give you, the customer, assurance (dang there is that word assurance again), that the organisation has a commitment to quality that has been independently audited. That’s what the logo is for and is seen on the marketing materials of many an organization.

Quality for the rest of us

My initial naive impression of quality initiatives that I was involved in was a lot of documentation for no tangible gain. (Mind you, I am wiser now and the same can be said for many SharePoint governance plans – teehee). I still think this attitude is actually valid for many quality initiatives because anything that requires discipline and rigour tends to fall off after the initial interest fades and requires constant communication, reminders, incentives and inducements.

But for geeks reading this who are frustrated with say, the security awareness/posture of the organisation, or if they are asked to do something that they are uncomfortable with (such as installing unlicensed software), or they simply can see that something is risky or problematic but they are getting no traction in getting the problem addressed, then ISO9001 is for you!

In short, ISO9001 kung fu is well worth learning.

Recon first…

Here is the whole “kids, please do not try this at home” warning. Now before you undertake your own evil plan, you need to think carefully. Like all evil plans (such as implementing SharePoint), you need to lay your foundation. Armies don’t rush blindly into battle – they always do a bit of reconnaissance first. You have to know your enemy.

There are two types of companies that implement an ISO9001 quality management system.

• Those that have a genuine interest in managing, improving and committing to quality in their organisation
• Those who want the logo on their marketing material

The latter is obviously an easier target in relation to the fireworks that will ensue, but sometimes “genuine interest” only goes so far as well.

If you work in a registered ISO9001 company, you need to be aware of what has been done to achieve this. Here are your recon steps.

1. First up, someone will have written a quality policy. This will typically be one of those documents that no-one has read – even the CEO who signed it off. But the first step of your recon is to find and read this document. It will set the scope and aspirational principles of what the quality management system is supposed to achieve. From an evil plan point of view, the bigger, more touchy-feely and more idealistic it is, the better for you
2. The quality policy should refer to a bunch of quality goals. These will be measurable goals defined by the organisation and this is one of the things that quality auditors look at when they perform their regular compliance assessment. A typical quality goal is reducing the number of non-conformances over a period of time, or how many of the incidents of non-conformance has been addressed. You need to find out what these goals are and understand them.
3. Next comes the bulk of the QMS – the procedures, work instructions that document processes. Although the majority of procedures and work instructions will likely not be relevant to you, you still need to check if there are any. To execute your evil plan means that you might be going up against someone who also knows ISO9001 kung-fu. So to prevent being sprung by your own trap, ensure that you are aware of any procedures and work instructions that relate to you or your department.

So armed with these three weapons, you now need to understand the parts of ISO9001 that will allow you to achieve your ends.

Now the next thing that you need to be aware of is one of the requirements for ISO9001 is management must demonstrate that not only has the above steps been done, but that they are continually monitored and improved upon in a verifiable way. There should be data collected about how the QMS has performed, and that management review meetings have been held to review the QMS, examine opportunities for improvement and needs for changes to be made.

So although there is a lot more to ISO9001 than what I have outlined above, it should be enough for you to get an idea of the whole point of it all. Now we get to the good bit!

Product Realization and non conformance

Basically, “product realisation” in ISO9001 says the organisation needs to ensure that a product which does not conform to product requirements is IDENTIFIED, and CONTROLLED TO PREVENT ITS MISUSE OR DELIVERY. Responsibilities for dealing with the product must be defined in a procedure (see number 3 above showing the role of procedures in a quality policy).

Now do not be mislead by the word “product” either. A product is the output of a process. Thus, products can be tangible or intangible.

For reference, ISO 9000 lists four generic product categories: services, software, hardware, and processed materials.

ISO is very specific about how product defects are handled. Section 8 of ISO9001 is called “Measurement, Analysis and Improvement” and the goodies that you need to arm yourself with are here:

8.3 Control of a nonconforming product
8.5.2 Corrective Action
8.5.3 Preventative Action

Nonconformity, according to Praxiom, refers to a “failure to comply with requirements. A requirement is a need, expectation, or obligation which can stated or implied by an organization, its customers, or other interested parties. There are many types of requirements. Some of these include quality requirements, customer requirements, management requirements, product requirements, and legal requirements.”

Remember! As far as ISO9001 is concerned (and therefore the auditors examining compliance of it), whenever your organization fails to meet one of these requirements, a nonconformity occurs.

Executing your evil plan…

So if I have managed to do a decent job of explaining everything above, you should now start to see the kind of weapon that you are wielding. Just like SharePoint itself, when used properly with a bit of forethought, ISO9001 can be your friend.

So, if you come across a problem that concerns you greatly (let’s say – poor or negligent SharePoint governance/planning and you see major risk), raise a nonconformance via the QMS! There will be a form to fill in, of course, and that’s where all of your reconnaissance efforts come in. If you know the quality policy and the quality goals that the organisation aspires to, you can be a major fly in the ointment, all in the name of quality!

Remember, part of implementing the quality management system and remaining compliant is to identify, control and track issues of nonconformance and their corrective/preventative actions! By raising it via the Quality Management System, you, by definition, give it visibility and now the organization must deal with it. Unlike the usual office politics, where it is easy to find creative ways to ignore a problem, within the framework of the QMS, the decision to ignore has to be justified. Not only that, an independent auditor will eventually be examining this nonconformance as well.

Visibility and transparency tend to change the way in which the problems are handled in organisations.

The inevitable blowback

Now you have to be careful when playing the QMS nonconformance card. You are basically pulling the rug off the usual office politics that thrives in a world of ‘off the record’ conversation, meetings that were not meetings, doublespeak and the like. In this type of organisational environment, visibility and transparency are in short supply. Raising a quality issue via the QMS is not likely to get you sacked, but the blowback from executing an action like this, is that you may well make yourself an enemy for life in the process. – But that’s okay half the time because if you are raising a previously swept under the carpet issue, chances are you don’t like the offender anyway!)

But remember, the same weapon can be used against you, so like any good politician, you’d better be squeaky clean yourself. Don’t go whining about a process not followed if you don’t follow them yourself! If you manage to avoid being hit by retaliatory fire, you also have to watch out for this one – one common way to lob the grenade back your way by politically savvy management is to say “That’s a great suggestion, Paul. I authorise *you* to fix it. Please write us a detailed report…”

What is more telling, however, from an organizational point of view is the reaction of the QA or Senior Management. After all, they put this system into place to create an organisation with a shared commitment to quality so if they get mad at you, then it tells you a lot of about how they view a QMS.

One final note – in honour of the typical organisational politics that we often find ourselves a part of, you never heard any of this from me!

Thanks for reading

Paul Culmsee

                      

No Tags