Paul is a well-known SharePoint expert in the areas of governance and information architecture, is a sensemaking practitioner (a mapping technique for business problems) and facilitator for large scale complex projects, and is a popular blogger at Clever Workarounds.
How Planning Occurs in Most Businesses
Paul began his presentation discussing the sometimes subversive nature of how planning happens, with management often requiring SharePoint to be deployed quickly and inexpensively, without considering the implications of many of the features, platform limitations, or actual business needs.
The path forward is usually build the plan around execution, then add assumptions as you go -- which means the plan contains no substance. As people lose faith in the plan, they begin to distance themselves from the project, and communications channels shut down. Ensuring a project has adequate time for planning and feedback from all stakeholders is essential to keeping the entire organization engaged in the project.
One of the more impactful examples Paul shared was around the idea of governance. There are many definitions out there, but he described it as "a means to an end" that helps you understand the what, why, who and how of the project.
Paul questioned the audience "If you define the goal of your project to 'Deploy SharePoint,' how do you know you've succeeded with your project?" and challenged the audience to dig deeper to reveal the actual business issues that SharePoint seeks to solve.
SharePoint is not the goal of the project: SharePoint is the means by which you will solve your business problems. The ultimate goal of governance, then, is to align the goals of the many different requirements with specific business outcomes.
Paul then described 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 because while it can do a lot of things, and solve many business problems, it requires proper planning and architecture to successfully meet the needs of current and future business needs -- and to ensure that people will actually use it.
Deciphering SharePoint Platitudes
One of the concepts Paul is well-known for is the problem of platitudes. Most 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 isprecursor 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.
Paul walked through two methods -- Sensemaking, and what he calls the Kapitola Pathway technique. Both methods are very inclusive, allowing people to start from what they know, slowly uncovering the key performance indicators (KPIs) that will measure the success of the project, and helping people come to a shared understanding of the true business goals of the project.
The key benefit of using these mapping methods, aside from providing context and details to how the project is to be measured, is that they provide an end-to-end view of how SharePoint fits into broader organizational strategies.
Paul's closing point was 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).
Three Rules to Guide Your SharePoint Projects
At the end of his session, Paul summarized his points 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 experiences with sensemaking and other 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).
Title Image courtesy of Mark Carrel (Shutterstock).
Editor's Note: You may also be interested in reading: