I’m excited to be going to Microsoft’s Ignite conference in Chicago next week. If it bears any resemblance to the SharePoint conferences I have attended, this is going to be an awesome experience.
I’ve decided to try an experiment at Ignite.
If you have SharePoint governance issues that you would like some help with, an outside opinion, or just a shoulder to cry on (we’ve all been there), I’d like to help
I’m offering free SharePoint Governance counseling to anyone who asks.
This is brief therapy – we’ll discuss your issue and I’ll try to help you brainstorm solutions and offer you advice based on my experience.
Feel free to reach out to me at my email address (you can find that on my LinkedIn profile and on my résumé), or you can contact me on Twitter (I use @SPointTherapist for governance issues, but I’ll happily reply at my more unfocused general account @dlairman as well) so we can schedule a time.
I say “free”, but there is one thing that I will require. I will be using the issues brought to me on this blog (with names changed to protect the innocent and guilty alike). If you’re open for that, I’ll be glad to help!
One thing that I can see that Tiffany didn’t mention in favor of her approach, is that when you give the compliant children the cool new toys, and keep them out of the hands of the resistant ones, eventually the resistant ones will want to play with th cool new toys too, because they keep hearing from everyone else how they are missing out.
Tiffany and I do recognize that we may not be talking about the same people. Is it possible that there are different sorts of squeaky wheels? Ones that are laggards, who are forever asking “Who moved my cheese?”, and others that have legitimate issues that need to be addressed?
It is your turn to weigh in on the debate.
What is your experience? Am I off the mark? Is my example an edge case? Is Tiffany’s point of view more valid in your experience? Or should you indeed keep your “enemies” closer? Are there different kinds of squeaky wheels? If so, how can you tell them apart?
Are we both missing the point?
Weigh in below!
Guest Post by Tiffany Songvilay
I had a great time in Jim Adcock’s SharePoint Group Therapy governance session at SharePoint Saturday Houston. He tells a story about how he embraced a squeaky wheel and turned her into one of the biggest fans of the project. On an Enterprise scale, I disagree with this approach.
My recommendation comes from my personal experience, as does Tiffany’s rejection of it.
One of my favorite things about my SharePoint Group Therapy governance session is when someone disagrees with me.
Unlike most sessions, where the presenter stands up in front of an audience and provides little room for disagreement, my session encourages a free-flowing discussion among the audience as well as questions directed to me, and this allows plenty of room for disagreement.
As long as all sides are unwilling to become entrenched in their point of view, out of that disagreement can come a deeper understanding of the issues and the options for resolving them.
Case in point, this past weekend’s SharePoint Saturday Houston, which I felt was the best version of my session I have ever had. Sitting in the back row, Tiffany Songvilay had a few choice words when I suggested that you invite some of your more difficult users into your governance committee, a tactic I have suggested before.
For the benefit of those who were unable to attend the event, I present to you the Great Debate: What to do about squeaky wheels?
Once you have read both sides, it will be your turn to weigh in on the debate!
Keep Your Friends Close, Keep Your Enemies Closer, by Jim Adcock
Keep Your Friends Close, Keep Your Enemies Far Far Away, guest post by Tiffany Songvilay
Comments on this post are turned off. Go to Your Turn to weigh in on the debate!
Some of the advice you are offering would likely work best for a large organization. What about a small one with less than 4 IT/IM staff, less than 200 SharePoint users and no legal department? – T.
In a small organization, it may seem like you don’t need as much governance. You surely don’t need all of the sample governance plan by Joel Oleson, as it lays out a potential plan for a multi-national organization with multiple SharePoint administration roles, and a team of developers.
But, on a smaller scale at least, the same considerations need to be addressed. Who is responsible for what? If you don’t have a separate Database Administrator (for example), then it is possible that the SharePoint Administrator would be responsible for backing up the database, and restoring it in the event of a system failure. Or maybe it is the Network Administrator, depending on how roles are divided. In any case, formalizing the roles of who is responsible for what is one of the basic tasks of defining your governance plan, regardless of the size of the organization.
I got a call from a friend who was working with a client.
The client wanted him to set up SharePoint. Unfortunately, they didn’t have anything more specific than that as a requirement. He got the impression from the client that they expected SharePoint to just work, to do things just by virtue of having been installed, with little thought to the fact that configuration would be required for SharePoint to actually do much of anything, and that there would be ongoing need for administration. They had so far been dismissive of his attempts to convince them that “Just set it up” wasn’t an adequate strategy for deploying SharePoint successfully.
His question –
How can I help them understand that what they are asking for is likely to end in failure, if they don’t take configuration and ongoing administration into consideration?
I was able to provide a few pieces of advice on approaches to getting the needed information:
At the recent SharePoint Saturday Austin, I spoke with a peer who was working with a client that didn’t have a development environment, only a production environment.
“No,” I said. “If they don’t have a separate development environment from their production environment, they don’t have a production environment, there is only a development environment.”
A very common way to design a SharePoint ecosystem that protects end users from harmful alterations or interruptions to access to their data is to have three SharePoint farms – Development, Staging and Production. Changes are made to the development environment, moved into the staging for validation to make sure it won’t cause problems before ever being allowed into the production environment. Another common configuration has only two farms, with both development and testing in one farm, and production in another. This requires less maintenance and hardware, but can result in a testing environment that may be a poor match for the production environment (though it beats not having a production environment!).
But the nature of SharePoint is a collaboration platform. This means that changes are being made to production environment by end users. End users often have the rights to change page layouts, add and remove web parts, and do many other things that make alterations to the production environment. While there are built-in features to provide data stability, such as document versioning, approval workflows, and publishing processes, it does point up the slippery slope of what counts as “development” and what doesn’t.
Here is one of the approaches I have used to keep some control of the kinds of changes that can be made directly in production without prior validation, and what needs to go through a defined testing and promotion process.
During a recent SharePoint governance discussion, we talked about the process for responding to requests for new sites.
One thing I brought with me from my last job was an understanding of just how bad site sprawl can get. I knew going into the meeting that management only had a vague idea about sites, the reasons for creating them, and the reasons for NOT creating them.
So I came prepared with a handout with a few brief sentences that management could understand and buy into. With this plus a description of the out-of-control scenario of site sprawl, I got my buy-in.
What is a site?
A site is a collection of lists, libraries and pages with similar ownership, access rights, and intent.
When should a site be created?
Consider creating a site when:
- Content access controls are different
- Content ownership is different from that of existing sites
- Intent of the content is significantly different from existing sites
- Content is of significant complexity and volume (for example, if a group needs its own calendar, document library and lists with multiple content types and tags specific to that group)
When should you consider other options?
- If the content is minimal (only a few documents)
- If the ownership or purpose matches an existing site
Sites should have clear ownership (both a sponsor and a content manager).
What do you think?
Get Notified! Scroll to the bottom of the page to get notified when new posts are added to the site!
In case you haven’t heard, I’ve joined the panelists on SharePoint ShopTalk, a weekly webconference where you can interact with panelists, ask your questions and share your thoughts and opinions too!
On the Thursday, June 28 edition of SharePoint ShopTalk, I’ll be leading SharePoint Group Therapy (A SharePoint Governance Workshop), a session formatted as an open discussion where I talk about some of the governance challenges I have faced, and ask everyone else to share their challenges as well, Together, in the style of group therapy, we’ll discuss everyone’s SharePoint problems and work together to provide solutions and approaches to managing your SharePoint governance issues.
This session will be reprising the successful format of sessions run at SharePoint Saturday Austin in January, and SharePoint Saturday Houston in April of this year.
Every SharePoint implementation is unique, as they each live in in their own environment of users, business objectives, requirements, and organizational cultures. The workshop format allows us to tailor solutions to the problems in your environment. But despite the uniqueness of your implementation, the pains you feel are a lot like the pains felt by others, so (at the very least) you’ll be discussing your SharePoint problems with a sympathetic group.
Sign up to attend next week’s SharePoint Group Therapy on SharePoint ShopTalk!