Confessions of a (post) SharePoint Architect: A pink box called chaos…

Hi all and welcome back to my ever growing series which attempts to codify a lot of learning over a long period of time into something that I hope is readable, rigorous and is useful to anyone tasked with successful SharePoint project delivery. This is the 7th post in a what is turning out to be a large series. It is large for a good reason: SharePoint is complex and the problems it attempts to solve (collaboration) are complex as well. If this is your first article, I super-strongly suggest you take it from the beginning as these articles build on each-other.

My motivation for getting this stuff out there is to tap into the shift I now sense in how organisations approach the SharePoint platform. Through a combination of organisations living through SharePoint project failure, practitioners experiencing SharePoint fatigue syndrome, as well as the strength and congruence of the messages of many wise people in the SharePoint community, organisations now realise that SharePoint is a “different” kind of project.  This realisation represents the first stage of any form of learning where people have moved from unconscious incompetence to conscious incompetence.  These terms sound rather confronting but are common in training-speak…

• Unconscious incompetence refers to people who do not realise they lack certain skills and therefore don’t realise they need training to address the gap. That explains pretty much every IT centric SharePoint deployment based on the “built it and they will come” delivery model (and we all know how much fun those projects are).
• Conscious incompetence means that people now see the gap between their knowledge and know they need help. Much of my company’s work is in this area – as is our close friends at Dynamic Owl and 21apps. Aside from our own clients, all of us are often sought out by other Microsoft partners who have learnt the hard way that the classic model of sales guy, project manager, business analyst and developer doesn’t always crack the SharePoint nut.

So newfound realisation among clients and consultants is there and that’s all well and good. Now the issue is to get past the cover story and take it to the next level. We have to go beyond the oft-used hippie clichés like “It’s all about the business, man” and make the art of SharePoint delivery real, pragmatic, rigorous and tangible. This series aims to be my attempt to do just that, complimenting leaders like Andrew Woodward, Ruven Gotz, Michal Pisarek and Sue Hanley. To that end, as I continue writing the series I hope that you:

• laugh at the various truths behind the various SharePoint governance f-laws;
• smile knowingly at the folly of some of the elaborate project and governance rituals you have to do now;
• have your own biases challenged as you either cringe in embarrassment or think “he has gone too far with *that* comment”; and
• have enough solid ammo to get through to influence other key stakeholders in your organisation

Allrighty then! Let’s get down to business. Our f-law for today’s article comes from Woody Allen. I have never actually watched one of his movies, but I have to give him credit for this pearl of wisdom…

F-Law 5: Confidence is the feeling you have until you understand the problem

Most projects start with a honeymoon phase. A newly formed team gets to deliver some new technology that is high profile and bolster their CV’s while “taking the business to the next level” (platitude black belts take note!) Morale is high and the team feel the sort of excitement one feels when going on a first date. Like a bad first date however, it doesn’t take long for the slow but relentless imposition of reality to take hold. Accordingly, as understanding of the problem grows, uncertainty grows commensurately. This in turn tests the initial project assumptions which an optimistic budget was likely pinned to. Most people can’t handle this sort of uncertainty because it confers risk of blame – something we all seek to avoid if we can. Thus on a complex project where the problem has elements of wickedness, blame avoidance results in things becoming quite dysfunctional and often project teams lose confidence that they can solve the problem.

There is an underlying phenomenon at work here that seems to be part of the human condition. Check out these two diagrams below as both of them show the same pattern. The left image is by Gartner and is their famous hype cycle that they pin technology fads to. The other won a Nobel prize for the originators and refers to a phenomenon called the Dunning-Kruger effect.

   

The diagrams should be self explanatory as both are a representation of increasing ones understanding of a problem over time. Both diagrams powerfully illustrate that as understanding grows, one never regains the same level of confidence that one had at the start! Take a look at the red line which reflects level of understanding of a problem. In both cases, the red line never reaches the same peak as it did at the very start when confidence was high and understanding was low. In other words, as your understanding grows and you become more informed about a problem, you will never be as certain as you would like to be.

Now in my mind, anyone who tries to argue against truth of the above patterns have fallen victim to the pattern. Furthermore, if you are dealing with someone who fits that level of optimistic naivety like a command-and-control project manager or CIO, just tell them that this has Nobel prize winning backing. For those CIO types who get all of their gospel from Gartner, use the hype cycle instead. After all, what would those Nobel dudes know eh? 🙂

So here is a tip. Next time you are kicking off a SharePoint project and need to assess risk, try this: First up, explain platitudes as described in the last two posts. Then draw one of the above diagrams on a whiteboard and ask your stakeholders to place an X on the above diagrams where they see the project team, themselves and where they see others! I guarantee much fun and frivolity will ensue…

Divergence and Convergence

Now if you work for an organisation where the idea of ranking ones naivety is a bit confronting, let me offer you something gentler. This alternate way of looking uncertainty over time is similarly powerful to the images above. I first saw this diagram used by Jeff Conklin, who got it from a book by Sam Kaner called the Facilitator’s Guide to Participatory Decision-Making. My diagram below was modified from Kaner for my own purposes.

Like the Gartner and Dunning-Kruger diagrams above, the X axis represents time, with a problem at one end and the solution on the other. The Y-axis represents the level of uncertainty and it illustrates that project teams typically go through a cycle of divergent thinking, followed by a period of convergent thinking as the team becomes more aligned and the problem is better understood. What is interesting to note is that the point where divergence ends and convergence starts is never clear. No-one ever stops and pronounces “Okay guys, I think we have sufficiently diverged. Let’s converge now.”

To converge, one has to cross over the ‘hump’ of divergence. Imagine climbing a mountain and there are thick clouds that obscure the peak. For all you know, the peak might be a couple hundred feet further, but equally so, you might only be halfway up. For this reason I draw a box in the middle rather than connect the arrows. it is important to note that when I draw the box in the middle, I make a point of asking people to tell me the sort of words they would use to convey what they are feeling during this time. Without fail, I always get negative responses like “confusion,” “irritability,” “stress” and “uncertainty.”

Now consider this: Some projects tend to diverge sharply and convergence seems almost impossible. No attempts to reign things in by asserting control seem to work. In fact, they usually make things worse. Accordingly, SharePoint projects commonly look like the figure below. They are highly divergent with little convergence as a result of the varied implicit assumptions that stakeholders have about SharePoint that have not been aired and reconciled. The power of those pesky platitudes, eh?

When I show this version of the diagram to people, I always ask a simple question:

• If you do not have governance for SharePoint, what do you have?

The answer I get is always “Chaos,” which I write in the box as you can see above. My next question to the group is this:

• “So by definition, to understand SharePoint governance, we all have to metaphorically open this box we have labelled “Chaos” to understand the forces that create the divergence?

So far, nobody has disagreed with that logic. So I then I hit people with the punch line…

• “So how can you tell me that your governance approach is addressing the forces of divergence if you don’t know what’s in the box?“

That is usually the great silence moment… Despite the logic of my argument, most organisations never open the damn box and then approach SharePoint project delivery in a manner that is very likely to exacerbate the problem, rather than address it.

False convergence…

Check out the figure below. It is a variation of the divergence/convergence figure and represents a common approach to rein in SharePoint going haywire. If you look closely, you can see that an attempt has been made to force convergence. This manifests in different ways, but is most often the scenario when a sponsor or key stakeholder starts to make key decisions on behalf of others. In the short term, this approach tends to feel good because there is a sense of momentum and something is “being done” to get things under control. Project managers stop palpitating for a time because their Gantt charts start to see some progress…

After explaining this diagram, I then ask my audience. “So has this dealt with divergence?”. To this day, not a single person I have ever asked has said yes. In fact, everyone implicitly seems to realise that this is a false convergence and the underlying divergent forces have not truly been addressed at all. There is usually a short term feeling that things are getting back on track, but it doesn’t last long because it is actually little better than an illusion and things starts to get fishy – both on the project and in my diagram as shown below…

So eventually we will be smacked by the chaos baseball bat whether we like it or not. Despite this, many organisations will persist with the forced convergence approach many times (with a different set of consultants each time) and of course continue to get crappy results. Eventually though, the attrition of this approach will exceed the commitment of stakeholders and something gives. It is at this point where some organisations react by doing another dumbass thing…

Overly constraining divergence…

Once there is a realisation that an elite coterie (like the IT department or a single champion in the business) cannot solve the information management problems for the entire organisation via false convergence approaches, the next approach seems to artificially constrain the divergence via controlling the terms of reference – aka lock the crap out of the scope. This is seductively tempting since scope creep is the quintessential symptom of stakeholders who are still in divergent thinking.

While I have no problem with determining an appropriate scope, as we all operate within time, people and budgetary limits. But it has to be done for the right reasons and constraining divergence is not a good reason. Why? Because it means that stakeholders have very little shared understanding at the point scope is decided. This is a problem because ideally, divergent thinking should be reconciled to be able to decide on scope. From a diagrammatic point of view, this is like putting clamps around the level of allowable uncertainty. The classic example of this approach is when an organisation opts for the installation and deployment of SharePoint itself as phase 1 of the project. Ever done that before?

Like the previous example, I ask my audience whether this approach deals with divergence. Also like the first example, the answer is a universal no. The underlying divergent forces have not truly been addressed at all and things are still fishy – although on the diagram below it is a difference species of fish! 🙂 In fact what you are doing here is penalising people for their learning – something I warned against doing in part three.

Key takeaways

I hope that you find these diagrams useful when discussing SharePoint delivery with your own stakeholders. By explaining SharePoint delivery in terms of divergence, convergence and a pink box labelled “chaos” we are able to provide a frame to show why artificially constraining divergence often has the opposite effect of what is intended. It is also worth pointing out that both of the above approaches are not particularly collaborative either – which tends to go against what one is trying to do with SharePoint in the first place.

Many SharePoint projects proceed on the assumption that the problem is well understood – that divergence has peaked and we are heading down the slope of convergence. If this is indeed the case, then the SharePoint project should go reasonably well since all of the tools for managing and delivering projects are convergence tools and do a good job in assisting this process. When this is not the case however, those same approaches have a bad habit of getting in the way by precluding the sort of learning and exploration needed for stakeholders to align around a problem. Returning to my mountain climbing metaphor I used earlier, these tools are like gravity assist to help you get down the mountain, but they weight a lot when you are trudging up a steep mountain and when clouds are obscuring the peak.

My takeaway for f-law 5 is not to jump straight to convergence. It might give you an initial sense of certainty and momentum, but only for a short time. I have said it many times and I will say it again. While there is a lack of shared understanding among participants of a problem, you will never get the shared commitment you need to see a solution through. Shared commitment is critical because without it, projects lose their energy and momentum to be seen to conclusion. Persistent divergence is a sign of a lack of shared understanding so the trick of course, is to harness divergence and turn it into something positive. Create the conditions that allows for some uncertainty, reduce the blame culture and tolerate mistakes. Invest in tools and methods that allow collective sensemaking and give people safety and structure to raise and reconcile their concerns.

Achieving shared understanding of the problem is for me the essence of SharePoint governance. In the doctors vs. midwives post in this series I explained how the goal of an architect is to create the right conditions for SharePoint success. The conditions to manage and harness divergence is a critical skill.

If you can achieve this end you should be bloody proud of yourself – as you have done 80% of the work of SharePoint delivery already.

Thanks for reading

Paul Culmsee

www.hereticsguidebooks.com