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 (www.cleverworkarounds.com), 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 platitude detector).

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 "complex" category.

• 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 commitment.

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.

Christian Buckley was a speaker at the European SharePoint Conference 2011. Check out his conference presentation by  clicking here>>

Stay tuned for more content by joining our community or by following us on twitter or facebook