Category Archives: Governance

SharePoint: Surf’s Up – Your Governance Visualised


You may also be interested in: SharePoint Conference.ORG 2013


 

Editor’s note: Contributor Ant Clay is the Founder, CEO & Tummeler of Soulsailor Consulting. Follow him @soulsailor

Over the past few weeks we’ve published excerpts from Ant’s new book “The SharePoint Governance Manifesto:

Why are SharePoint projects so complex?
SharePoint: Beware of Governance snake-oil
SharePoint: Surf’s Up – Your Governance Visualised

Grab your ebook discount code here: http://www.soulsailorconsulting.com/euspbookoffer:

Picture this:

  • Your SharePoint team is the water
  • Your Organisation is the wind
  • Your SharePoint platform/project is the energy in the water
  • Your SharePoint Vision is a paradise island
  • The aim of the game is to make progress by transferring the energy (SharePoint) to the island (your vision)
  • Progress can be tracked by a cool surfboard or some random flotsam riding ‘The 7 Waves of Governance’.

It should be clear from the analogy or personal experience, that there needs to be significant engagement and creative friction between the wind (your organisation) and the water (your SharePoint team) to generate the energy required to create the Governance waves we need to make progress towards our goal.

The effort (friction of wind against water) required to create the energy and hence the waves is directly proportional to what your vision is and how far away you are from it, so you really need to get a grip on these things, now!

So now we have identified some [Governance] waves, seven to be precise if we are to be effective. Now our goal in the SharePoint team (we will talk about the SharePoint team in more detail later in the book), is to help that energy (our SharePoint project / platform) travel from wherever we started, towards the vision as effectively as possible.

The progress (surfer or flotsam) is never going to be a straight-line, remember the water in each of the waves is moving in a circular motion around a relatively fixed point, so the surfer can ‘ride each wave’ until they’re ready to move on…

That may be a weird explanation for something as dull as Governance, but this is what it looks like, in my mind, my whiteboard and occasionally on a client’s wall:

2013-05-01-SharePointSurfsUp-01.png

My approach to Governance covers 7 specific areas (waves) and is defined as, in no particular order as:

  • Business Alignment
  • IT Assurance
  • Project Governance
  • Information Governance
  • Change Management and Adoption
  • Social Business
  • Kaizen (Continuous Improvement).

It is these areas that I focus all my governance thinking, workshops, documentation and on-going activities on.

SharePoint: Beware of Governance snake-oil

 

Editor’s note: Contributor Ant Clay is the Founder, CEO & Tummeler of Soulsailor Consulting. Follow him @soulsailor

Over the next few weeks we’ll be publishing excerpts from Ant’s new book “The SharePoint Governance Manifesto Grab your ebook discount code here: http://www.soulsailorconsulting.com/euspbookoffer

Why does SharePoint Governance deserve my focus for this manifesto?

It is because I think that SharePoint Governance is completely screwed!

Maybe that’s a little strong, but basically everyone has an opinion about what Governance means and how you should apply it, including:

  • Your IT department
  • Microsoft
  • Tool vendors
  • SharePoint MVP’s
  • Your boss
  • Microsoft Partners
  • Consultants
  • Business stakeholders
  • And of course you!

Yes, when it comes down to it, anyone that has anything to do with SharePoint is probably selling some kind of Governance snake-oil (opinion, tools, frameworks etc.) to yourself, your team or worse to the business stakeholders in your organisation, looking for answers.

The challenge is that I honestly think you and the rest of them are all just a little bit wrong…

Yes that is very bold statement, but there is very little convergent thinking around Governance at the moment and most of what I see and hear in organisations has some serious flaws.

Perhaps I am being too harsh, but that’s just the way I see it based on my experiences.

The challenge is that:

  • Microsoft is selling their technology
  • Microsoft Partners are selling their consulting
  • Tool vendors are selling their tools
  • And so on.

All these groups of people have valid insights into Governance, but they are also falling foul of their company’s world-views and KPI’s (Key Performance Indicators), which are always grounded on selling more of their stuff.

I truly believe that individuals across the SharePoint community and wider collaboration, knowledge management and sensemaking spaces have a huge amount to offer in terms of governance thinking and frameworks, but we need to more explicitly anchor these thoughts with business Governance ideals.

If my thinking and bold statements don’t sit well with you, then let me know why. SharePoint will never be confined to just one person, it’s a team sport, its community supported and dare I say it, collaborative. It’s my hope that we can be on the same page and together change SharePoint Governance forever in a positive way!

How do we achieve this?

Well a starting point will be for us all to share our Governance experiences with the community. Both the wider SharePoint community and the community that I hope will form around this book.

If you experience change (hopefully positive) and value from approaching SharePoint Governance differently, based on the ideals and approaches articulated within this book, then please share.

All feedback is welcomed, embraced and will quite probably be the basis for future Governance work and publications!

Let us not forget that SharePoint Governance needs to be collaborative!

This book is not Governance snake-oil, this is a new way of Governance thinking…

Why are SharePoint projects so complex?


You may also be interested in: SharePoint Conference.ORG 2013


 

Editor’s note: Contributor Ant Clay is the Founder, CEO & Tummeler of Soulsailor Consulting. Follow him @soulsailor

Over the next few weeks we’ll be publishing excerpts from Ant’s new book “The SharePoint Governance Manifesto Grab your ebook discount code here: http://www.soulsailorconsulting.com/euspbookoffer

My experience, over the last decade is that in way too many instances, SharePoint projects fail to deliver true business value. They’re delivered as though they are just another Microsoft Office productivity solution, implemented as a technology project with a huge and catastrophic assumption that "If you build it, they will come" (Field of Dreams, 1989).

Dave Snowden’s ‘Cynefin Framework’ (Snowden, 2012, http://bit.ly/Cynefin) is immensely useful in sensemaking the complexity of delivering collaborative and social solutions, such as SharePoint, to my clients. I apply the Cynefin Framework to demonstrate why we can’t just assume that a technology solution on its own will deliver value and solve our organisations business problems.

2013-04-11-SharePointProjects-01.png

Originally developed in the context of knowledge management and organisational strategy, Cynefin, a welsh word, literally translated to mean ‘habitat, or place of multiple belongings’, is now applied in many diverse ways, including complex adaptive systems, decision making, cultural change, organisational strategy and community dynamics.

As you can see we have a typical four quadrant diagram, with each quadrant sensemaking particular scenarios, one of which I feel is most appropriate to SharePoint and collaborative or knowledge management projects.

In the Simple quadrant, life is very much cause and effect. As you can see by the character, every time they drop the ball it falls to the ground, that action is infinitely repeatable with the same predictable effect. Have you ever implemented a SharePoint solution that you could repeat in any team, company, or sector that would always have the same repeatable and predictable cause and effect? Nope, I didn’t think so! So SharePoint, collaboration and knowledge management solutions don’t live here in this quadrant.

Also, you know all the focus in SharePoint land on ‘Best Practice’? It’s an oxymoron.

Moving up to the Complicated quadrant, this is where the previously simple and repeatable relationship between cause and effect requires investigation, analysis or the application of expert knowledge in order to be effective. Here we can see from our characters that an expert is analysing the situation, the consultant character is reading about that knowledge and implementing a solution influenced by that thinking. The result being the end user character is walking away happily. Now we may see this kind of behaviour in more infrastructure based projects such as Microsoft Exchange, but not for collaboration, knowledge management and SharePoint scenarios. True, most technology projects are implemented as ‘good practice’ or even worse perhaps using ‘best practice’, but if we analyse those projects we will see that the projects are deemed failures because they do not deliver the outcomes required by the business.

What I have found, in my experience, is that projects delivered with the assumption that the business problem they are solving is in the ‘Complicated’ or ‘Simple’ domain, although outwardly they do fail, they do make some positive steps towards the goal. The challenge is that the implementers, very often do not see things with a perspective of learning and continuous improvement and therefore the one-shot project cannot hope to capitalise on the value that has already been delivered.

Now things get interesting in the Complex quadrant. As you can see from the characters, we have music playing in the background and we have two emergent behaviours:

  • The first person is dancing
  • The second person is listening intently.

Both characters are happy and are deriving value from the music in different ways, perhaps ways we had not imagined or expected. From a Cynefin perspective the relationship between cause and effect is only perceived in retrospect, never in advance. For our characters, that implies that depending on whom they are, what they are doing and even their mood, different behaviours will emerge from the same music playing.

In terms of our work around SharePoint Governance, this fits nicely with what we experience every day. We implement a solution based on what the business stakeholders state their requirements are, they use it for some period of time and then we start to hear about the users’ unrest:

  • It doesn’t quite work right
  • A particular team "doesn’t work like that"
  • When I said I wanted this I meant that
  • Can you move the search box over there?
  • But in this situation, we want it to work like this…

Does that sound all too familiar?

Is that what tends to happen to your SharePoint projects?

What we are seeing are emergent requirements, emergent behaviours and emergent use-cases. Implementing the solution based on what they think they want helps the user community to further evolve their understanding of the problem or goal. It is through continuous improvement that we can work with them to evolve the solution to meet their goals.

Finally, for completeness, although a little out of the remit for this book, is the Chaotic quadrant. There is no relationship here between cause and effect at a systems level, so behaviour is unpredictable and although at times that may feel true of our SharePoint user community it isn’t the reality!

So let us remember, SharePoint projects are people projects and people projects are emergent and therefore they are most definitely not a one shot solution.

Confession of a (post) SharePoint architect… “Thou shalt NOT”


You may also be interested in: SharePoint Portals in minutes by SharePoint Implemented


 

Editor’s note: Contributor Paul Culmsee is an IT and business consultant with 21 years experience. Follow him @paulculmsee

Confessions of a (post) SharePoint Architect Series:

Hi all

*sigh*

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

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

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

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

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

What is the opposite of governance?

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

Ouch! Really?

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

2013-03-04-Confessions-Part09-01.png

“Thou shalt not…”

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

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

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

2013-03-04-Confessions-Part09-02.png

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

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

Let’s examine each one in turn…

Pace of change

2013-03-04-Confessions-Part09-03.png

Remember the saying “The only certainty in life are death and taxes”? Outside of that, the future is always unpredictable. In between SharePoint 2003 and SharePoint 2007, the wave of web 2.0 and social networking broke, forever changing how we collaborate and work with information online. In between SharePoint 2010 and SharePoint 2013, the wave of cloud computing broke, which is slowly but surely changing the way organisations view their IT assets (both systems and people). The implications of this are huge and Microsoft have to align their product to tap into these opportunities. Net result? We all have a heap of new learning to do.

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

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

Problem “Wickedness”

2013-03-04-Confessions-Part09-04.png

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

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

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

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

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

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

Technical Complexity

2013-03-04-Confessions-Part09-05.png

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

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

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

Social Complexity

2013-03-04-Confessions-Part09-06.png

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

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

However, there is an inherent paradox here:

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

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

Key takeaways…

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

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

2013-03-04-Confessions-Part09-07.png

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

Thanks for reading

Paul Culmsee

Define a SharePoint IT Strategy – Part 2


You may also be interested in: SharePoint Portals in minutes by SharePoint Implemented


 

Editor’s note: Contributor Peter Ward is a SharePoint Solution architect. Follow him @peter_1020

2013-01-23-ITStrategy-Part01-01.jpg Q: Who needs to be involved with the process?

A: A variety of organizational personnel will be involved in the development, execution, and analysis of any IT strategy at different times. The key to success is the input from IT and business management who have the ability and authority to assign resources to the project, and to authorize business initiatives as they relate to SharePoint.

Because a strategy is not a single project, there generally is not a single business sponsor, but rather senior members from both the IT and business sides of the organization. To increase the chances of success, these individuals should be involved from the beginning of the strategy defining process. The business sponsor is responsible for communicating the overall objectives they seek to accomplish with the assistance of IT. During this dialogue, the IT sponsor is responsible for understanding the high-level feasibility and risk as well as the desired functionality; this is the Risk Registry. Once these items are understood, the IT sponsor will need to come back with the proposed IT strategy to meet these goals. It is the IT sponsor’s responsibility to understand the resources required to ensure successful execution of the IT strategy. Initial resources to consider may include IT personnel, operational personnel, and helpdesk personnel.

Your advocates may come from various disciplines. A good place to start would be the management teams of those individuals most likely to benefit from the prioritized list. However, do not forget resources that help to drive the adoption and solicit feedback once your solution is live. If you work in the IT department, you may witness continuous requests for IT resources or initiatives with the SharePoint platform for business users. This is good, because they see you or your department as a strategic asset that can help them solve problems. If this is the case, then some of these requestors should attend the SharePoint workshop or at least see the post-workshop findings.

If you work in the IT department and the business community in your organization does not make requests, then there is a chance your department is not viewed as a strategic asset and you may be even viewed as an operational cost. If this is the case, the workshop is an opportunity to bring perceived value to the business.

Q: Do I need to get the CEO involved?

A: A typical IT strategy does not require the CEO’s hands-on involvement. However, an IT strategy, at the end of the day, truly serves only the corporate strategy. Ultimately, there is really only one true strategic player in the organization: the CEO and his or her counterparts on the board. All the other officers of the corporation must use their respective departments to help the CEO execute the company’s strategy. Most business units align their activities to the corporate strategy and similarly, IT must wrap its strategy around the business’s. Therefore, by all means, share your finding with the CEO to demonstrate that your department is supporting the corporate strategy. Most CEOs care about dominating a market or increasing sales and not necessarily whether or not you have a deployment plan for any product. So the last thing you really want is a non-technical person being very influential with an IT strategy that they don’t understand.

Q: Why is a SharePoint strategy different than other IT products?

A: It is because SharePoint is a platform. It can be difficult to define the functionality that has or could have been deployed to the business, so the milestones/endpoints are different than those for a typical application such as a CRM system. Also for a SharePoint strategy to become a deployment reality, there are several dependent technologies that SharePoint relies on, which need to be in place and set up correctly for the initiatives to work. For example, user profile synchronization needs to be configured appropriately with Active Directory in order for the organization chart in My Sites to work.

You will read "SharePoint is a platform" endlessly throughout this book. So what does this mean? A platform has multiple functionality that can be applied to different applications such as search, workflow, document management and content management, and .NET development, which takes time to configure and deploy within an organization.

An application is like Microsoft Word, a program that is very clearly defined for the single purpose of writing documentation. As stated many times in this book, SharePoint is a platform for web applications to be developed on. This is why SharePoint can be difficult to define and describe to people. Another term you will hear is that it is the Swiss Army knife of Microsoft’s web offerings, because the tool has many blades. Microsoft will often explain SharePoint with the pin wheel.

Given SharePoint’s broad functionality and its potential to be used by any employee in an organization, defining a strategy can be a challenge. This is unlike a Customer Relationship application where generally only the sales and marketing departments are involved and processes are already defined.

Another reason why defining a SharePoint strategy is unique is because employees may have had an experience with SharePoint at a previous job, and want to repeat this experience again. What they often do not realize is that their previous experience may have consisted of a customized SharePoint environment, or one augmented with third-party components. These employees end up surprised and disappointed when their expectations don’t comply with the current deployment.

It is essential to educate the user community about SharePoint if you really want to leverage its functionality. It is important to gauge the level of interest and time that business users have and are willing to spend on SharePoint awareness.

Q: Why do we really need an IT strategy?

A: In short, the strategy will help prioritize IT efforts to support the business requests. The key aspect of an IT strategy is to manage expectations of both the business and IT department so that both parties know what to expect and when.

In the first figure of the article, there is a clear roadmap of SharePoint deliverables for the business so budgets can be defined and resources allocated. The details of how this is done do not necessarily need to be agreed upon in the strategy meeting. In fact, given that the budget is not defined at the workshop, some initiatives may not be feasible.

By having an IT strategy for SharePoint, return on investment can be identified with some effort and initiatives being approved and prioritized.

Without a strategy, there is normally a passive approach to a SharePoint deployment, where initiatives are not coordinated among departments and low value processes are used with SharePoint, such as fancier and more expensive set of shared drives rather than a usable ECM system with findable information assets.

Research by AIIM stated that half of SharePoint implementations proceed without a clear business case (which shows lack of direction from the start); only 22 percent of the organizations provide users with any guidance on corporate classification and use of content types and columns; one third of the organizations have no plans as to how to use SharePoint, while one fourth of the organizations say IT is driving it with= no input from information management professionals.

Q: Any final words of advice on this?

A: Rushing off to "the next big thing" after completing a phase or a project of the first phase of the strategy road map is a bad idea. But even in the most successful projects, there are usually items still remaining. Additionally, after a few weeks or months "in the wild," the people using the fruits of your labor may have some great and often simple-to-implement ideas for improvement. However, the project is complete, deployed to the specified scope, and your resources are working on another project.

This problem often happens with SharePoint projects, when phase II functionality is urgently required to meet business expectations and perhaps prevent an initiative stalling, yet the additional resources and perhaps an already large investment of time and money is allocated to other projects.

This is typical of SharePoint projects partly because the end user actually knows what they really want, once they realize that they have to use SharePoint and experience what they requested.

In short, a small additional effort can have dramatic effects, accelerating and amplifying results. Therefore, you may want to factor in a six-month revisit on projects and should not be afraid to move projects out of phases, or even eliminate them if the business value will be trumped by a phase II project.

This article is an extract from the book: Microsoft SharePoint for Business Executives: Q&A Handbook co- written by Peter Ward. Read the previous extract here.

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


You may also be interested in: SharePoint Smart Notifications by KWizCom


 

Editor’s note: Contributor Paul Culmsee is an IT and business consultant with 21 years experience. Follow him @paulculmsee

Confessions of a (post) SharePoint Architect Series:

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

Confessions of a (post) SharePoint architect: The dangers of dial tone governance…


You may also be interested in: SharePoint Portals in minutes by SharePoint Implemented


 

Editor’s note: Contributor Paul Culmsee is an IT and business consultant with 21 years experience. Follow him @paulculmsee

Confessions of a (post) SharePoint Architect Series:

Hi all and welcome to the next exciting instalment of my confessions from my work as a SharePoint architect and beyond. This is the eighth post so I will get straight into it.

To recap, along the way we have examined 5 f-laws and learned that:

Now, as a preamble to today’s mini-rant, I need to ‘fess up. I know this might come as a shock, but there was once a time when I was not the sweet, kind hearted, gentle soul who pens these articles. In my younger days, I used to judge my self-worth on my level of technical knowledge. As a result of this, I knew my stuff, but was completely oblivious to how much of a pain in the ass I was to everyone but geeks who judged themselves similarly. Met anyone like that in IT?2013-01-23-Confessions-Part08-01.png

This brings me onto my next SharePoint governance f-law – one that highlights a common blind spot that many IT people have in their approach to SharePoint governance.

F-Law 6: Geeks are far less important than they think they are

All disciplines and organisational departments have a particular slant on reality that is based on them at the centre of that reality. If this was not true, then departments would not spend so much time bitching about other departments and I would have no Dialogue Mapping work. The IT department is no better or worse in this regard than any other department, except that the effects of their particular slant of reality can be more pronounced and far reaching on everyone else. Why? Because the IT slant of reality sometimes looks like a version of Neo from the Matrix. Many, if not most people in IT, have a little Neo inside of them.

2013-01-23-Confessions-Part08-02.png

We all know Neo – an uber hero. He is wise, blessed with super powers, can manipulate your very reality and is a master of all domains of knowledge. Neo is also your last hope because if he goes down, we all go down. Therefore, everything Neo does – no matter how over the top or what the consequences are – is necessary to save the world from evil.

All of the little Neos in IT have a few things in common with bullet stopping big Neo above. Firstly, little Neo has also been entrusted with ensuring that the environment is safe from the forces of evil. Secondly, Little Neo can manipulate the reality that everybody else experiences. And finally, little Neo is often the last hope when things go bad. But that is where the similarities end because big Neo has two massive advantages over little Neo. First, big Neo was a master of a lot of domains of knowledge because he had the convenience of being able to learn any new subject by downloading it into his brain. Little Neo does not have this convenience, yet many little Neos still think they are all-knowing and wise. Secondly, big Neo was never mentally scarred from a really bad tequila bender…

Bad tequila bender? What the…

Never again…

Years ago when I was young and dumb, I was at a party drinking some tequila using the lemon and salt method. My brother-in-law thought it would be hilarious to switch my tequila shots with vodka double shots. Unfortunately for me, I didn’t notice because the lemon and salt masked the taste. I downed a heap of vodkas and the net result for me was not pretty at all. Although I wasn’t quite as unfortunate as the guy in the picture below I wasn’t that far off. As a result, to this day I cannot bring myself to drink tequila or vodka and the smell of it makes me feel sick with painful memories best left supressed.

2013-01-23-Confessions-Part08-03.png

I’m sure many readers can relate to a story like this. Most people have had a similar experience from an alcohol bender, eating a dodgy oyster or accidentally drinking tap water in a place like Bali. So take a moment to reflect on your absolute worst experience until you feel clammy and queasy. Feeling nauseous? Well guess what – there is something even worse…

Anyone who has ever worked in a system administrator role or any sort of infrastructure support will know the feeling of utter dread when the after hours pager goes off, alerting you to some sort of problem with the IT infrastructure on which the business depends. Like many, I have lived through disaster recovery scenarios and let me tell you – they are not fun. Everyone turns to little Neo to save the day. It is high pressure and stressful trying to get things back on track, with your boss breathing down your neck, knowing that the entire company is severely degraded until you to get things back online.

Now while that is bad enough, the absolute nightmare scenario for every little Neo in IT is having to pick up the pieces of something not of their doing in the first place. In other words, somehow a non-production system morphed into production and nobody bothered to tell Little Neo. In this situation, not only is there the pressure to get things back as quickly as possible, but Little Neo has no background knowledge of the system being recovered, has no documentation on what to do, never backed it up properly and yet the business expects it back pronto.

So what do you expect will happen in the aftermath of a situation like the one I described above? Like my aversion to tequila, Little Neo will develop a pathological desire to avoid reliving that sort of pain and stress. It will be an all-consuming focus, overriding or trivialising other considerations. Governance for little Neo is all about avoiding risk and just like Big Neo, any actions – no matter how over the top or what the consequences are – will be deemed as necessary to ensure that risk is mitigated. Consequently, a common characteristic of lots of little Neos is the classic conservative IT department who defaults to “No” to pretty much any question that involves introducing something new. Accordingly, governance material will abound with service delivery aspects such as lovingly documented physical and logical architecture, performance testing regimes, defining universal site templates, defining security permissions/policies, allowed columns, content types and branding/styling standards.

Now all of this is nice and needs to be done. But there is a teeny problem. This quest to reduce risk has the opposite effect. It actually increases it because little Neo’s notion of governance is just one piece of the puzzle. It is the “dial tone” of SharePoint governance.

The thing about dial tone…

What is the first thing you hear when you pick up the phone to make a call? The answer of course is dial tone.

Years ago, Ruven Gotz asked me if I had ever picked up the phone, heard dial tone and thought “Ah, dial tone… Those engineers down at the phone company are doing a great job. I ought to bake them a cake to thank them.” Of course, my answer was “No” and if anyone ever answered “Yes” then I suspect they have issues.

This highlights an oft-overlooked issue that afflicts all Neos. Being a hero is a thankless job. The reality is that the vast majority of the world could not care less that there is dial tone because it is expected to be there – a minimum condition of satisfaction that underpins everything else. In fact, the only time they notice dial tone is when it’s not there.

Yet, when you look at the vast majority of SharePoint governance material online, it could easily be described as “dial tone governance.” It places the majority of focus on the dial tone (service delivery) aspects of SharePoint and as a result, de-emphasises much more important factors of governance. Little Neo, unfortunately, has a governance bias that is skewed towards dial tone.

Keen eyed readers might be thinking that dial tone governance is more along the lines of what quality assurance is trying to do. I agree. Remember in part 2 of this series, I explained that the word ‘govern’ means to steer. We aim to steer the energy and resources available for the greatest benefit to all. Assurance, according to the ISO9000 family of standards for quality management, provides confidence in a product’s suitability for its intended purpose. It is a set of activities intended to ensure that requirements are satisfied in a systematic, reliable fashion. Dial tone governance is all about assurance, but the key word for me in the previous sentence is “intended purpose.”

Dial tone governance is silent on “intended purpose” which provides opportunities for platitudes to fetser and governance becoming a self fulfilling prophecy.

and finally for 2012…

So, all of this leads to a really important question. If most people do not care about dial tone governance, then what do they care about?

As it happens, I’m in a reasonable position to be able to answer that question as I’ve had around 200 people around the world do it for me. This is because in my SharePoint Governance and Information Architecture Class, the first question I ask participants is “What is the hardest thing about SharePoint delivery?”

The question makes a lot of sense when you consider that the hardest bits of SharePoint usually translate to the highest risk areas for SharePoint. Accordingly, governance efforts should be focused in those areas. So in the next post in this series, I will take you through all the answers I have received to this question. This is made easier because I dialogue mapped the discussions, so I have built up a nice corpus of knowledge that we can go through and unpack the key issues. What is interesting about the answers is that no matter where I go, or whatever the version of SharePoint, the answers I get have remained extremely consistent over the years I have run the class.

Thanks for reading…

Paul Culmsee

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


You may also be interested in: O’Reilly – SharePoint 2010 at Work


 

Editor’s note: Contributor Paul Culmsee is an IT and business consultant with 21 years experience. Follow him @paulculmsee

Confessions of a (post) SharePoint Architect Series:

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.

2013-01-15-Confessions-Part07-01a.png

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?2013-01-15-Confessions-Part07-09.gif

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.

2013-01-15-Confessions-Part07-03.png

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?

2013-01-15-Confessions-Part07-04.png

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…

2013-01-15-Confessions-Part07-05.png

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…

2013-01-15-Confessions-Part07-06.png

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?2013-01-15-Confessions-Part07-07.png

2013-01-15-Confessions-Part07-08.png

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!2013-01-15-Confessions-Part07-09.gifIn fact what you are doing here is penalising people for their learning – something I warned against doing in part three.

2013-01-15-Confessions-Part07-10.png

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

Confessions of a (post) SharePoint architect: Black belt platitude kung-fu


You may also be interested in: SPTechCon 2013 – San Francisco


 

Editor’s note: Contributor Paul Culmsee is an IT and business consultant with 21 years experience. Follow him @paulculmsee

Confessions of a (post) SharePoint Architect Series:

Hello kung-fu students and thanks for dropping by to complete your platitude training. If you have been dutifully following the prior 5 articles so far in this series, you will have now earned your yellow belt in platitude kung-fu and should be able to spot a platitude a mile away. Of course, yellow belt is entry level – like what a Padwan is to a Jedi. In this post, you can earn your black-belt by delving further into the mystic arts of the (post) SharePoint architect and develop simple but effective methods to neutralise the hidden danger of platitudes on SharePoint projects.

If this is your first time reading this series, then STOP NOW! Go back and (ideally) read the other articles that have led to here. Now in reality I know full well that you will not actually do that so read the previous post before proceeding. Of course, I know you will not do that either, so therefore I need to fill you in a little. This series of articles outline much of what I have learnt about successful SharePoint delivery, strongly influenced from my career in sensemaking. I have been using Russell Ackoff’s concept of f-laws – truth bombs about the way people behave in organisations – to outline all of the common mistakes and issues that plague organisations trying to deliver great SharePoint outcomes.

So far in this series we have explored four f-laws, namely:

In the last post, we took a look at the danger of conflating a superlative (like biggest, best, improved and efficient) with a buzzword like (search, portal, collaboration, social). The minute you combine these and dupe yourself into thinking that you now have a goal, you will find that your project starts to become become complex, which in turn results in over-engineered solutions solving everything and anything, and finally your project will eventually collapse under its own weight after consuming far too many financial (and emotional) resources.

This is because the goal you are chasing looks seductively simple, but ultimately is an illusion. All of your stakeholders might use the same words, but have very different interpretations of what the goal actually looks like to them. The diagram that shows the problem with this is below. On the left is the mirage and to the right is the reality behind the mirage. Essentially your fuzzy goal actually is a proxy for a whole heap of unaligned and often unarticulated goals from all of your stakeholders.

2013-01-09-Confessions-Part06-01.png2013-01-09-Confessions-Part06-02.png

Now in theory, you have read the last post and now have a newly calibrated platitude radar. You will sit at a table and hear platitudes come in thick and fast because you will be using Ackoff’s approach of inverting a goal and seeing if a) the opposite makes any logical sense and b) could be measured in any meaningful way. As an example, here are three real-world strategic objectives that I have seen adorning some wordy strategic plans. All three set off my platitude radar big time…

“Collaboration will be encouraged”

“A best-practice collaboration platform”

“It’s a SharePoint project”2013-01-09-Confessions-Part06-03.png

I look at the first statement and think “so… would you discourage collaboration? Of course not.” Ackoff would take a statement like that and say “Stop telling me what you need to do to survive, and tell me what you need to do to thrive”.

What do you mean by?

So if I asked you how to unpack a platitude into reality, what might you do?

For many, it might seem logical to ask people what they really mean by the platitude. It might seem equally logical to come up with a universal definition to bring people to a common understanding of the platitude. Unfortunately, both are about as productive as a well-meaning Business Analyst asking users “So, what are your requirements?”

With the “what do you mean by [insert platitude here]” question, the person likely won’t be able to articulate what they mean particularly well. That is precisely why they are unconsciously using the platitude in the first place! Remember that a platitude is a mental shortcut that we often make because it saves us the cognitive effort of making sense of something. This might sound strange that we would do this, but in the rush to get things done in organisations, it is unsurprising. How often do you feel a sense of guilt when you are reflecting on something because it doesn’t feel like progress? Put a whole bunch of people feeling that way into a meeting room and of course people will latch into a platitude.

By the way, the “mental shortcut” that makes a platitude feel good seems to be a part of being human and sometimes it can work for us. When it works, it is called a heuristic, When it doesn’t its called a cognitive bias. Consult chapter 2 in my book for more information on this.

Okay, so asking what someone means by their platitude has obvious issues. Thus, it might seem logical that we should develop a universal definition for everyone to fall in behind. If we can all go with that then we would have less diversity in viewpoints. Unfortunately this has its issues too – only they are a little more subtle. As we discovered in part 2 of this series appropriately entitled “don’t define governance”, definitions tend to have a limited shelf life. Additionally, like best-practice standards, there are always lots of them to choose from and they actually have an affect of blinding people to what really matters.

So is there a better way?

It’s all in the question and its framing…

If there is one thing I have learnt above all else, is that project teams often do not ask the right question of themselves. Yet asking the right question is one of the most critical aspects to helping organisations solve their problems. The right question has the ability to cast the problem in a completely different light and change the cognitive process that people are using when answering it. In other words, the old saying is true: ask a silly question, get a silly answer.

Let me give you a real life example: Chris Tomich is a co-owner of Seven Sigma and was working with some stakeholders to understand the rationale for how content had been structured in a knowledge management portal. Chris is a dialogue mapper like me – and he’s extremely good at it. One thing Dialogue Mapping teaches you is to recognise different question types and listen for hidden questions. The breakthrough question in this case when he got some face time with a key stakeholder and asked:

  • What was your intent when you designed this structure for your content?

The answer he got?

  • “Well, we only did it that way because search was so useless”
  • “So if I am hearing you, you are saying that if search was up to scratch you would not have done it that way”
  • “Definitely not”

Neat huh? By asking a question that took the stakeholder back to the original outcome sought for taking a certain course of action, we learnt that poor search was such a constraint they compensated by altering page template design. Up until that point, the organisation itself did not realise how much of an impact a crappy search experience had made. So guess where Chris focused most of his time?

In a similar fashion, my platitude defeater question is this:

So if we had [insert platitude here], how would things be different to now?

Can you see the difference in framing compared to “what do you mean by [insert platitude here]?”. Like Chris with his “What was your intent”, we are getting people to shift from the platitude, to the difference it would make if we achieved the platitude. No definitions required in this case, and the answer you will get almost by definition has to be measurable. This is because asking what difference something would make involves a transition of some kind and people will likely answer with “increased this” or “decreased that”.

Now be warned – a hard core middle manager might serve you up another platitude as an answer to the above question. To handle this, just ask the question again and use the new platitude instead. For example:

  • Me: Okay so if you had improved collaboration, how would things be different to now?
  • Them: We would have increased adoption
  • Me: And what difference would that make to things?

I call this the KPI question because if you keep on prodding, you will find themes start to emerge and you will get a strong sense of potential Key Performance Indicators. This doesn’t mean they are the right ones, but now people are thinking about the difference that SharePoint will make, as opposed to arguing over a definition. Trust me – its a much more productive conversation.

Now to validate that these emerging KPI’s are good ones, I ask another question, similarly framed to elicit the sort of response I am looking for…

What aspects should we consider with this initiative to [insert platitude here]?

This question is deliberately framed as neutral is possible. I am not asking for issues, opportunities or risks, but just aspects. By using the term aspects I open the question up to a wider variety of inputs. Like the KPI question above, it does not take long for themes to emerge from the resulting conversation. I call this the key focus area question, because as these themes coalesce, you will be able to ensure your emerging KPI’s link to them. You can also find gaps where there is a focus area with no KPI to cover it. As an added bonus, you often get some emergent guiding principles out of a question like this too.

The thing to note is that rather than follow up with “what are the risks?” and “what should our guiding principles be?”, I try and get participants to synthesize those from the answers I capture. I can do this because I use visual tools to collect and display collective group wisdom. In other words, rather than ask those questions directly, I get people to sort the answers into risks, opportunities and principles. This synthesis is a great way to develop a shared understanding among participants of the problem space they are tackling.

If we were unconstrained, how would we solve this problem?

This is the purpose question and is designed to find the true purpose of a project or solution to a problem. I don’t always need to use this one for SharePoint, but I certainly use it a lot in non IT projects. This question asks people to put aside all of the aspects captured by the previous question and give the ideal solution assuming that there were no constraints to worry about. The reason this question is very handy is that in exploring these “pie in the sky” solutions, people can have new insights about the present course of action. This permits consideration of aspects that would not otherwise be considered and sometimes this is just the tonic required. As an example, I vividly recall doing some strategic planning work with the environmental division of a mining company where we asked this exact question. In answering the question, the participants had a major ‘aha’ moment which in turn, altered the strategy they were undertaking significantly.

Note: If you want some homework, then check Ackoff’s notion of idealised design and the Breakthrough Thinking principle called the purpose principle. Both espouse this sort of framed question.

Sharpening the saw…

Via the use of the above questions, you will have a better sense of purpose, emergent focus areas and potential measures. That platitude that was causing so much wheel spinning should be starting to get more meaty and real for your stakeholders. For some scenarios, this is enough to start developing a governance structure for a solution and formulating your tactical approaches to making it happen. But often there is a need to sharpen the saw a bit and prioritise the good stuff from the chaff. Here are the sort of questions that allow you to do that:

No matter what happens, what else do we need to be aware of?

This question is called the criterial question and I learnt it when I was learning the art of Dialogue Mapping. When Dialogue Mapping you are taught to listen for the “no matter what…” preamble because it surfaces assumptions and unarticulated criteria that can be critical to the conversation and will apply to whatever the governance approach taken. Thus I will often ask this question in sessions, towards the end and it is amazing what else falls out of the conversation.

What are the things that keep you up at night?

I picked this up from reading Sue Hanley’s excellent whitepaper a while back and listening to hear speak at Share2012 in Melbourne reminded me why it is so useful. This question is very cleverly framed and is so much better than asking “What are your issues?”. It pushes the emotive buttons of stakeholders more and gets to the aspects that really matter to them at an gut level rather than purely at a rational level. (I plan to test out dialogue mapping a workshop with this as the core question sometime and will report on how it goes)

What is the intent behind [some blocker]?

This is the constraint buster question and is also one of my personal favourites. If say, someone is using a standard or process to block you with no explanation except that “we cannot do that because it violates the standards”, ask them what is the intent of the standard. When you think about it, this is like the platitude buster question above. It requires the person to tell you the difference the standard makes, rather than focus on the standard itself. As I demonstrated with my colleague Chris earlier, the intent question is also particularly useful for understanding previous context by asking users to outline the gap between previous expectation and reality.

Conclusion…

To there you go – a black belt has been awarded. Now you should be armed with the necessary kung-fu skills required to deflect, disarm and defeat a platitude.

Of course, knowing the right questions to ask and the framing of them is one thing. Capturing the answers in an efficient way is another. For years now, I have advocated the use of visual tools like mind mapping, dialogue mapping and causal mapping tools as they all allow you to visually represent a complex problem. So as we move through this series, I will introduce some of the tools I use to augment the questions above.

Thanks for reading

Paul Culmsee

Confessions of a (post) SharePoint architect: Yellow belt platitude kung-fu


You may also be interested in: O’Reilly – SharePoint 2010 at Work


 

Editor’s note: Contributor Paul Culmsee is an IT and business consultant with 21 years experience. Follow him @paulculmsee

Confessions of a (post) SharePoint Architect Series:

Hi all. It’s been a while I know, but it is time to continue along my journey of confessions of a post SharePoint architect. As I write this, the SharePoint community is in Vegas, soaking up the love of the biggest SharePoint conference yet. For the other twelve SharePoint professionals who are not there, I know your pain.

If this is your first foray into this series of articles, consider it the closest I will ever get to a SharePoint governance book. Since all new knowledge is gained through the lens of existing knowledge, it is important to note that my world view has been shaped by the increasing amount of non IT work I do in various complex problem solving areas. Essentially this work has had a major effect on the lens that I view SharePoint projects and the approaches I use to steer them. When developing a class on the topic of SharePoint Governance and Information Architecture, I found a fun yet effective way to put coherence around things via Russell Ackoff’s concept of f-laws. These are simple home truths about the way people behave in organisations than explain much more than the complex ones proposed by theorists of various persuasions.

So far in this series we have explored three f-laws, namely:

The next f-law is straight from Ackoff himself and is a universal truth in any project, but absolutely chronic in SharePoint projects as well as many SharePoint slide decks:

F-Law 4: Most SharePoint governance objectives are platitudes. They say nothing but hide behind words

Most people in the IT industry (with the obvious exclusion of sales guys, Office365 MVP’s and Google employees) tend to inwardly cringe or outrightly roll their eyes when the word “cloud” is uttered during conversation. This is because people instinctively know that what follows is either:

  • Gushing hyperbole squarely aimed at getting you to part with some cash
  • Gushing hyperbole squarely aimed at convincing you that they know what they are talking about
  • Gushing hyperbole in the form of FUD laden counter-arguments from server hugging sysadmins who reject “cloud” outright because they fear irrelevance

These reactions in such conversations result from the term “Cloud” being used in a platitudinal sense. In case you were not aware, a platitude is referred to as “a trite, meaningless, biased, or prosaic statement, often presented as if it were significant and original”. Platitudes are everywhere and usually unavoidable since many people use them unconsciously – especially politicians, senior executives and the aforementioned sales guys. Want proof? Just look on the wall behind the reception area of your office – chances are there is a mission statement there somewhere that would read something like:

- “We are dedicated to ensuring a long-term commitment to stakeholder value from performance and improved returns at all levels.”

Does a mission like that sound familiar? What if I told you the line above was generated from a website that generates mission statements like a poker machine. Just pull the lever and within a few seconds, a random assortment of small quotes are mashed together to create a cool sounding sentence. If you enter your company name into it, you can even print a certificate. I generated this one for the Heretic’s Guide book. Neat, huh?

2012-12-21-Confessions-Part05-01.jpg

The problem, of course, with a platitude is that while it sounds significant, it doesn’t actually tell you much at all. So this f-law states that most SharePoint governance objectives are platitudes. One of the core reasons for this is a side effect of Microsoft’s marketing approach. Consider Microsoft’s SharePoint marketing material as it has evolved. Take a look at how many words survived the transition from Microsoft’s SharePoint pie of 2007, the Frisbee of 2010 and now the square of 2013. Do you see a pattern? What is the average shelf life of a word in each of these diagrams?

2012-12-21-Confessions-Part05-02.png

2012-12-21-Confessions-Part05-03.png

Now, let me start out by stating that I have no problems with any of these diagrams. Microsoft is perfectly entitled to develop the message it wants to convey in whatever means it sees fit. The biggest travesty is when people frame the above words as deliverables. They take a superlative word like “improved”, “best practice” or “effective” and then add one of the above words to it. This combination inevitably forms the basis for the justification of putting SharePoint in.

The classic example that still pervades SharePoint projects to this day is the perennial mirage of “Improved Collaboration.” If we return to the “here” and “there” diagrams of the previous posts, it looks like this… note the aspiration goal has a happy smiley on it!

2012-12-21-Confessions-Part05-04.png

Platitude detection 101

So the first thing you have to do as a SharePoint architect or practitioner is to develop a finely tuned platitude radar. The thing to be aware of is that platitudes come in many forms – some which are obvious and some much more subtle. Thus we will start your platitude radar calibration via a quick and easy method that Ackoff came up with. Years ago, Russel Ackoff critically examined mission statements and said that a mission statement that merely restates the obvious does not say anything that is truly aspirational. To quote from Ackoff:

- They often formulate necessities as objectives: For example, ‘to achieve sufficient profit’. This is like a person saying his mission is to breathe sufficiently.

Ackoff’s test to judge the quality of a mission statement was to inverse the statement and see it still made logical sense. If you could not reasonably disagree with this negative version, then the original statement was a platitude. As an example, consider this mission statement from a well-known global organisation:

- … our mission and values are to help people and businesses throughout the world realize their full potential.

So, our inverse here is that we are working to hinder people and businesses to realise their full potential. Who in the hell would ever do that? Well – given this is Microsoft’s mission statement, suddenly Windows Vista is finally starting to make sense to me.2012-12-21-Confessions-Part05-05.png

Now, go and take any word from the 3 diagrams above and put a superlative like “biggest”, “best”, “optimum” or “improved” in front. If I use my example – “Improved Collaboration” – Ackoff’s inversion approach results in “Worse Collaboration” and is therefore a platitude. I mean – aside from the odd command and control boss, would anybody seriously want to make collaboration less effective?

So, to put it simply – stop stating the bloody obvious! If your SharePoint goal doesn’t satisfy Ackoff’s simple platitude test, you have a problem.

The seeds of doom are sown at the start…

Now that I have wired up your platitude detector via Ackoff’s inversion test, you will start to notice how utterly pervasive they are in SharePoint projects and beyond. As Kailash and I state in the Heretics Guide book:

- A platitude is a mental shortcut we take, a deceptively quick way to cut through uncertainty. We clump our unclear, unarticulated aspirations in a bunch of platitudes. It is easy to do and it gives us a sense of achievement. But it is a mirage because the objective is not clear and we cannot define sensible measurements of success if the goal is fuzzy. It never fails to amaze us that many organisational endeavours are given the go-ahead on the basis of platitudinous goals. Mind-boggling, isn’t it?

What is really amazing and sad at the same time is how badly the platitude problem is misattributed. One of my students at a recent SPGovIA class said that with SharePoint projects “the seeds of doom are sown at the very beginning”. He’s right too…project teams will commit significant time and money into a project that is chasing a platitude, and when things inevitably go haywire, will blame the process, methodology, people… everything but the mirage at the root of it all.

The seduction of a platitude is strong. Many have been entranced by some nice sounding desirable future state incorporating some superlative like “Improved quality” or “Best practice collaboration”. But the key point is this: The platitude becomes a sort of proxy for the end in mind rather than the real end. We have no shared understanding of what where we want to get to. Empty words preclude a shared understanding because they mean nothing at all.

The image below illustrates the effect of a platitude being confused with the actual desired state. We do not have an aspirational future state at all. Instead, we have many possible, fuzzily-defined future states.

2012-12-21-Confessions-Part05-06.png

If you look really closely, the future state is a sad smiley. This is because the visible symptoms of a project with a divergent understanding among participants are well documented. Scope creep and vague requirements mean that the project will start to unravel, yet the platitude-driven journey towards the mirage will continue. The project will lurch from crisis to crisis, with scope blowing out, tensions and frustrations rising. This is accompanied by classic blame-shift or hind-covering moves that people make when they realise that their ship’s taking water.

How to defeat a platitude…

I am going to conclude this post at this point because it is starting to get too long. But I will leave you with a teaser about the next post…

One of the most important things about dealing with a platitude is knowing what *not* to do. I know that what I am about to say may sound counter intuitive to many readers, but trust me when I tell you that there are two things you should avoid doing.

  1. Never, never, never ask someone what they mean when they use a platitude
  2. Never try and come up with a definition for a platitude

In the next post, I will elaborate on these two contentions and provide you with a much better way to get past the seductive danger of platitudes, so you can find out what really matters to your stakeholders.

Until then, thanks for reading…

Paul Culmsee