Whatever you do, do not ignore legacy
On the twitterverse recently, someone stated that because of a problem of excessive SharePoint site sprawl, they were going to institute a new site approval process. On the surface this remedy seems to be perfectly reasonable. After all, there is a clear problem that has emerged and in the name of governance, we have taken steps to address it via this new process.
There is only one small problem with this. It’s probably the wrong thing to do or at best, a minor facet of what to do.
Before I explain why, consider another scenario that I am sure all of us have experienced. You have a problem so you call your bank, ISP or some other provider of services that you have paid for. You encounter an operator or customer service representative who seems hell-bent on closing your call at all costs, whether you think the problem is solved or not. Common examples of how this plays out is the oft used “well I will close this call and you can call back and log a new one if there is still an issue” line. A more subtle, yet equally frustrating one that even Microsoft have used on me is the “well you logged the problem as X, but in reality its Y. So you will need to close this call and re-log a new call for problem Y”.
The underlying reason for this is very likely that the performance of the person on the other end of the line is judged on time spent handling your call. The logic would be that the speedier a call is closed, means the less time users have spent on tech support, which indicates good outcomes for customers.
Alas, if only that were true. Anybody who has been on the receiving end of this sort of treatment knows full well that the opposite happens. As a customer, you get frustrated and pissed off. More dangerously for the organization, this sort of indicator conveys a warped representation of reality. Essentially the operator has altered their behaviour to maximise their performance according to this measure of “effectiveness”. Customers who are paying the money are not necessarily satisfied. In fact they are more often than not dissatisfied. Therefore, the notion that length of support calls somehow lead to happier customers is a fallacy. In the longer term, customers will tire of crappy outcomes and take their business elsewhere.
This success indicator is a mirage, and in actual fact contributes to the nastier, longer term problems of customers ending up with competitors.
So with that said, lets go back to our Sharepoint site sprawl issue. Before instituting such a policy, I ask the following simple question.
So why are there lots of sites?
Now there will be various reasons, but the most common answer I get back from this is:
Users don’t know any better.
This assertion is pretty easy to test too. Take a look at the sites in the wild west of a chaotic SharePoint install. Since most site templates in SharePoint have a single document library, it is common to see many hundreds of sites with a single document library in them. Clearly, people simply aren’t aware that they can do things like add more libraries or lists to a site or they are unwilling or unable to do so. I have experienced users telling me that if they had have known, they would have never created a site for a particular collaborative activity.
Side Note: SharePoint’s own attempts to be “intuitive” is the problem here. For a start, sites build navigation by default so people get duped into using sites to create navigational structure when its wholly inappropriate. Secondly, creating a new site is inferred as the right thing to do. To see why, go to the site actions menu and what is a default action there? You guessed it – create a site. SharePoint out of the box actually contributes to users forming this mental model of how SharePoint hangs together).
So clearly, many instances of excess site sprawl is symptomatic of something deeper. Users do not know that there are potentially better alternatives. This leads us to a somewhat rhetorical, yet critical question:
What does an approval process do about users not knowing any better?
Many times such approval processes shift the burden of creating the site to an authorised party like IT, after a requestor’s boss has given it the go ahead. Naturally, people will have to do more paperwork to get approval and it might take longer. Furthermore, maybe their request will be rejected under certain circumstances. But at what point will they learn that there is more to life than sub sites? Even after instituting the approval process, we still may end up with a heap of sites with a single document library in them. Have we really addressed the real issue?
Do you see the parallel? The sort of thinking that decided an approval policy is the answer to site sprawl is the same sort of thinking that decided that call times are a reliable indicator of customer outcomes being met. Both treat the superficial, visible symptoms of a problem, not the underlying cause. Furthermore, both end up leaving stakeholders with crappy outcomes in the longer term. Your support calls are still frustrating and you are still using SharePoint in a sub optimal fashion.
More scarily though is that we have deluded ourselves into thinking we have dealt with the problem. SharePoint governance is often built around this sort of superficial thinking. If a governance plan weighs as much as a door stop, and gets about as much attention as a door stop, then you might be making this mistake.
What about legacy?
This problem is more common than you think. There is a more systematic pattern of delusion that can happen in project management. Check out the diagram below.
Seen this diagram before? It is very common on project management books and presentations. We have a pyramid that implying that to have quality, we have to have time, cost and scope balanced and understood. Like the site approval policy, this seems perfectly reasonable on the surface. But unfortunately, by its very nature can cloud us to what is really important.
Below is an example of a project output – the Sydney Opera House. During my classes, everyone recognises it and there is always someone who has been there. In fact people come to Sydney just to see it. In term of economic significance to Sydney, it is priceless and irreplaceable. the architect who designed it, Jørn Utzon, was awarded the Pritzker Prize (architecture’s highest honour) for it in 2003.
So I ask you the question:
Was this a successful project?
I ask this question to people all around the world and the answer is always a great big Yes. But if we look at this project through the lens of our quality triangle above, the view changes.
Why?
Well, here are a few fun filled facts about the Sydney Opera House.
- The Opera House was formally completed in 1973, having cost $102 million.
- The original cost estimate in 1957 was $7 million.
- The original completion date set by the government was 1963.
- Thus, the project was completed ten years late and over-budget by more than fourteen times.
- Ultzon, the designer of the opera house never lived to set foot in it, having left Australia in disgust, swearing never to come back.
“Utzon soon found himself in conflict with the new Minister. Attempting to rein in the escalating cost of the project, Hughes began questioning Utzon’s capability, his designs, schedules and cost estimates. Hughes eventually stopped payments to Utzon. Unable to pay his staff, Utzon was forced to resign as chief architect in February 1966 and left the country never to return. Utzon has never seen the completed work that brought him international renown”
Harsh huh? Clearly, when judged through the “quality” lens of time, cost and scope, this project was a unmitigated epic fail that makes SharePoint look like a walk in the park.
The example of the Sydney Opera House serves to remind us that when all is said and done, we judge quality across something deeper than time, cost and scope alone. That something is legacy.
People remember legacy, not scope
So when you look at the Opera house through the lens of the quality triangle, you are making the same mistake as the call-center KPI and the well intentioned site creation policy. You are taking a superficial view of things and in doing so, missing more subtle, but ultimately important factors. In fact you are treating symptoms and not looking for the “story beneath the story” that caused the visible symptoms in the first place.
Yet…
Why do we go to the time, effort and cost to put in tools like SharePoint? It is because we see that it can take us to a better place than we are now. After all, if we didn’t believe this fundamental truth, then we wouldn’t spend the that time and money working on it. This notion of a “better place” implies that we are trying to escape a legacy of the past – such as poor information management practices, inefficient process, silo organisations and so forth.
As illustrated by the Opera House example, people do not remember time, cost and scope. What they do remember acutely however is legacy.
So what is a more reliable indicator of quality? Who visits the Opera house and takes a photo of it because it was such a breathtakingly bad example of project management 101? No, they take their photo because it is unique, has value and people want to experience it for themselves. Its the legacy that they remember, cherish and want to be a part of.
As a result, there is a critical lesson here for all SharePoint practitioners (from the nerdiest of nerds to the hippiest of web 2.0 pundits). Ask yourself, “what legacy is my governance actions going to leave”, because if you fail to consider the legacy of your approaches to SharePoint delivery, you are probably dooming your organisation to the very same legacy you wanted to escape in the first place!
And that’s just tragic.
So I think that PM 101 diagram needs to be redrawn because it misleads – especially for complex, adaptive or wicked problems. To me, considering time, cost and scope without legacy is delusional and plain dumb. Legacy informs time, cost and scope and challenges us to look beyond the visible symptoms of what we perceive as the problem to what’s really going on.
When I get time, I will post several examples of how I was able to utilise this sort of thinking in a future post, but I hope this gives you some food for thought.
Thanks for reading
Paul Culmsee
Great post Paul.
Lots of SharePoint implementations seem to have ‘approval’ mechanisms to avoid sprawl. I agree that this is far from the right answer. In fact worst case I’ve seen people look for other external systems to store information as the process is too slow or they have little confidence in having a new site approved.
When ‘onboarding’ new groups to a system we use the bookshelf comparison to explain that using many libraries ‘shelves’ is the right way to maximise use of each site location. We equate the site to a room. People seem to have reasonable success is using this approach to structure the information without adding lots of SP bits to create structure.
Hi Wes
Excellent metaphor for onboarding and excellent point about the side effects of poor process. Another example is the one where the hard core records manager puts in a hard to use, counter intuitive records management system as the collaborative document management system in an attempt to be more “compliant”, only to find that the very act of doing so, creates less compliance via the same avoidance mechanism you describe.
I just finished reading the Fifth Discipline, which is the most accessible introduction to systems thinking I have seen. The pattern you describe, and the records manager example is called the “Shifting the burden” archetype. It’s interesting stuff indeed and a book well worth grabbing.
regards
Paul
This is an outstanding analysis of project management in the SharePoint environment.
Legacy is an interesting dimension on the the concept of value over time. When applied to policies, however, I question the real impact of legacy. Governance policies in the SharePoint world (at least the one you describe), impact the friction required to get something done and, ultimately, influence the project outcomes by applying friction and oversight in certain places along a project lifecycle. The idea is that, with an approval process either 1) the approver is able to apply enough friction (cost) to the process to influence the proliferation of sites by decreasing it or 2) by improving the outcomes by providing oversight and influence to the outcome (e.g., instead of adding another site, why not just add another document library).
In number 1, the friction is intentional. It is meant to increase the cost of the project because, in most case, in terms of the project, the overhead of a SharePoint site is 0. The overhead is an externality. That is, it is not included in the scope of the project. Although it does so inefficiently, in my opinion, adding an approval process that creates friction, does add cost to the project. A better alternative would be to charge the true cost of the site overhead when measuring it’s ROI and overall feasibility.
Number 2 is a clear recognition of lack of proper user and site owner education. The people who have the power to create new sites don’t always understand the features and functionality of SharePoint in such a way that would allow them to accomplish the same thing (or something better) with less cost. An oversight and governance process introduces a supposed third party that can help guide implementations towards cost effective solutions.
Reality is that an approval process is, as is described in the article, a short-sighted quick fix that doesn’t necessarily accomplish what an organization wants. I would argue that it is for different reasons than cited in the article, though. Properly scoped, a project always considers all costs and benefits associated with the project. SharePoint sites are all too easy to create once the infrastructure is in place and overhead is usually not charged back to individual projects. So, rather than create an artificial impediment through an approval process, the best approach would be to charge back the overhead associated with the cost of running a SharePoint site (which is admittedly a difficult task at best). Second, we need to educate project managers and other site users on how best to leverage SharePoint cost efficiently.
Thanks for your thoughtful comments Doug
In relation to your reply, “Properly scoped, a project always considers all costs and benefits associated with the project”. What I would state is that scope is illusive on problems that require shared learning on the change of participants or behavioural change.
I would draw your attention to issue of adaptive or wicked problems. “Properly scoped”, assumes a shared understanding of the problem by participants. When you don’t have this, the visible symptoms are scope creep and vague requirements. In a wicked problem, nailing scope can be very difficult indeed. Take a read of my “One best practice” series for a case study and some insights here:
http://www.cleverworkarounds.com/2009/02/12/the-one-best-practice-to-rule-them-all-part-1/
I would also suggest having a look at my talk at http://spgovia.com in the media section.
regards
Paul
I read the series that you linked and listened to the talk and am blown away by how utterly helpful, enlightening, applicable…those were to exactly what I am doing and encounter in my SharePoint projects. Fantastic.
I hadn’t considered the (now obvious to me) idea of an illusive scope. This article makes a lot more sense to me after reading those. Thank you.
Excellent post Paul. Such an important message that I have not seen articulated so succinctly anywhere else before.
Cheers, Shim.
It’s a natural response to want to assert control over a situation where we feel we have lost all control. It’s why most governments tend to follow mistakes in scope through legislation. We repeat these mistakes in SharePoint by locking it all down – for the sake of organization and control, without thinking about the legacy of these decisions. But like a stream of water temporarily diverted by a child’s makeshift dam, people will find a way to subvert these controls to get their works done. Unfortunately, they may do this by going outside of SharePoint. The more controls you put in place, the less likely people are to use the technology.
Enter the role of the Business Analyst. I was reading some of your older posts on the role of the BA, and in my experience this is where having a BA dig into the problem and both understand the scope fo the issue and – working with the dev team, the end users, management, and the PM – identify and articulate one or more possible solutions to the problem. More controls may be the answer, but more likely it is either a process issue or a training issue that leads to SharePoint sprawl.
Hey Christian
I have no problem with the BA as such as its just a role name. What I would argue though that the facilitator paradigm is the showstopper as, by definition, people would be brought together to widen their respective lenses.
http://www.cleverworkarounds.com/2010/12/02/sharepoint-analystsstop-analysing/
I agree that legacy cannot be ignored as people forget its cost, scope and time of the project. The legacy matters most in case of any project.