The best part of my job as an evangelist is that I am able to
connect and talk with some of the brightest minds in the SharePoint
community, tapping into their extensive backgrounds to better
understand their unique perspectives to some of the more difficult
business problems facing SharePoint teams. One of the more common
problems -- which sounds simple, and yet it sits at the core of the
majority of failed enterprise application deployments -- is the
failure of the organization to have a shared understanding of what
is to be accomplished.
I was in Perth, Australia this past month where I met with
partners and customers, conducted a roundtable event at the local
Microsoft offices, and presented to the
Perth SPUG (SharePoint User Group). The issue identified itself
a number of times: people shared frustrations with trying to get
different teams working together to agree to requirements, or, more
commonly, people wanted to know how to "convince" management that
activities such as building a robust taxonomy or mapping out a
governance strategy are important to the overall health and success
of SharePoint. The majority of questions I was asked focused not on
problems with the technology, but on best practices for building a
shared commitment aground SharePoint.
Following the SPUG, I spent a few hours with my good friend Paul
Culmsee (@paulculmsee), a
well-known SharePoint and dialogue mapping expert, popular blogger
and author of the new book The Heretics Guide to Best
Practices. Paul has spent a good portion of his career talking
about (and consulting around) the need for consensus and shared
understanding around the business problems for which SharePoint is
being deployed. Over dinner, we spent a good deal talking about the
questions and comments from the roundtable and SPUG events, which
all came back to one common thread: the purpose of a SharePoint
deployment is not to roll out SharePoint, but to solve a business
problem (well, a set of business problems). SharePoint is not the
end state, but a means to the end. More importantly, Paul points
out, is that you can't measure success if you don't have a clear
definition of what it is you're trying to accomplish.
One of Paul's favourite topics is to delve into the differences
between "complicated" problems and "complex" problems. Complicated
problems are issues that have a clear goal in mind, but have many
steps. You know what you need to do to succeed, but it is
difficult. Complex systems, on the other hand, are those for which
you cannot readily define success. You know you have a problem to
solve, but it cannot be answered definitively. If you cannot state
definitively that people will use your solution after delivering
it, it is a complex problem.
SharePoint falls into the complex definition. While it can do a
lot of things, and solve many business problems, it requires proper
resources and planning and architecture and alignment to
successfully meet the needs of current and future business needs --
and to ensure that people will actually use it.
One of the concepts Paul is well-known for is the problem of
platitudes. Most stated SharePoint project objectives are
platitudes. They say nothing, hiding behind words. A great example
in my own experience is asking an audience "What are you trying to
accomplish with SharePoint?" The most common answers include 'To
collaborate more' or 'To build out a document repository.' While
these statements are certainly true, they don't provide any detail
that allows a project to be well-defined and successfully executed.
As Paul points out, if you cannot reasonably disagree with an
objective or measure it, then it is a platitude.
SharePoint is the means to the end. The hard part is defining
that end. The point of the project is not to deploy SharePoint, the
point is to deploy SharePoint to achieve your business objectives.
One way to cut through the platitudes is to ensure a shared
understanding of the problem among all participants. Paul
referenced his mentor and issue and dialog mapping instructor Dr.
Jeff Conklin (Director of
CogNexus Institute) , "the 'Holy Grail' of effective
collaboration is creating shared understanding, which is
precursor to shared commitment."
One of the tools for breaking through the platitudes and helping
a team to reach a shared understanding of the business problems and
possible solutions is dialogue
mapping. The concept is simple enough: map out the problem to
help people understand why a problem is to be solved, and how it is
to be solved, identifying all inputs and allowing all stakeholders
to participate. Dialogue mapping provides context and details to
how the project is to be measured, as well as helps to provide an
end-to-end view of how SharePoint fits into broader organizational
strategies. Paul's contention is that by making the effort to map
out the many different facets of a project and truly understand the
shared goals, the process helps validate broader strategic plans by
testing them against projects and initiatives (and is a great
Paul summarized his problem-solving approach down to three
critical planning rules:
• Understand the difference between "complicated"
and "complex" problems.
My interpretation: It's important to understand the complexity
of your business issues, and what measurements will help you track
and, ultimately, determine success. If SharePoint is a major
component of your solution, it will automatically fall into the
• Do not allow platitudes to fester.
Platitudes, if left standing, will skew perspectives of
SharePoint as expectations can quickly get out of hand. Two
stakeholders using the same platitudes to define their business
goal could be thinking of two very different business outcomes,
which can seriously impact long-term SharePoint adoption and
project success. Dialogue and issue mapping is one way to get to
the heart of the business issues, and to be very prescriptive on
how to resolve them.
• Shared understanding leads to shared
When people share understanding of a problem and the proposed
solution, they are also able to more quickly determine their own
roles and responsibilities -- as well as hold others accountable
for their areas of ownership. Successful planning required a shared
understanding of the problem, the proposed outcome, and the
measurements of success along the way.
For those interested in learning more about dialogue mapping to
improve SharePoint planning and, specifically, to read more about
Paul's mapping and business analysis techniques, you can pick up
his recently published book The Heretics Guide to
Best Practices (recently recognized as a Medalist for the Axiom
Business Book Awards 2012). You can also reach out to SharePoint
MVP Andrew Woodward (@andrewwoody) and
business partner Ant Clay (@soulsailor) fromwww.21Apps.com, who partner with
Paul and teach master classes based on Paul's content.
was a speaker at the European SharePoint Conference 2011. Check out
his conference presentation by
Stay tuned for more content by joining our community or by
following us on twitter or facebook