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!

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!

**************

Missed the other posts in this series?

SharePoint Saturday Houston Throwdown: Whither the Squeaky Wheel?
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

Get Notified! Scroll to the bottom of the page to get notified when new posts are added to the site!

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.

I have a quote in my Change Management 101 presentation, “In situations where there are strong pressures to conform, lone dissenters can have a major effect” (Scott Plous, Psychology of Judgment and Decision Making). In my experience as a change management consultant, the squeaky wheel is typically a laggard on the technology adoption lifecycle. When I go into an organization, I am not surprised to see that the majority of their technology support effort is being spent on an audience that is resistant to change. My strategy differs from Jim’s in that I see a higher success rate in moving the squeaky wheels into technology silos. If they don’t want to change, I find it’s much better not to force them into it right away. It’s simply not in their nature to jump on board with the latest and greatest. I find that they are a better ally when I allow them to lag behind. At the same time, I let them know that the consequence of lagging is that they will no longer be supported by our support organization. It’s the same thing Microsoft does when it ends the lifecycle of a product. IT governance needs to be able to retire outdated systems as part of an overall health strategy. By explaining this approach and giving them a deadline to get into compliance, I am putting the ball back in their court. They understand that I need to free up my resources to go and get success stories from the innovators and early adopters in an organization and they appreciate that they don’t have to go first.

Jim was saying that he invites his lone dissenter to be a member of the SharePoint governance committee. While I certainly agree in theory with the idea that differing interests and opinions need to be represented in any committee, I am simply saying that I think his time and energy as a consultant and advocate could have been more profitable if he’d been working with departments who wanted the change and embraced the new tool set. Many times on committees a consensus has to be reached. You might as well call it a unanimous vote because my experience on committees is that once you give a squeaky wheel the power to stop technology change, they become a wrench in the works. I don’t invite anyone who doesn’t adhere to a set of core governing IT principles. If that squeaky wheel wants to keep a legacy system for 20 years, I don’t want them on my governance committee.

In addition, I believe that oiling the wheel sets a bad change management precedent for our clients. Technology change is never going to stop. I believe it is our responsibility to teach people how to self sooth during these times of transition and to let them know that if they are not on a path to get into compliance with our IT Standards, then we are not going to respond to their temper tantrums. They can learn to support themselves if they don’t want to comply.

Centralizing governance is not for the faint of heart. I believe that Jim’s approach with this particular client continued to reinforce the bad behavior she had learned through the years. By continuing to tell this story in the organization, it sets a precedent that all users will be handheld through any uncomfortable situation. The problem with IT being considered a services organization is that people confuse that with it being a customer service organization. It’s not. It is a governing body. My challenge for large companies is to move away from the labor-intensive and cost inefficiency of hand holding. It goes along with my favorite quote from this therapy session. Jim said something along the lines of (I’m paraphrasing), “If you don’t trust the people you’ve hired to do a job then that’s an HR problem; not a SharePoint security issue.” At the end of the day, Jim’s example is referencing a person who was creating her own problems and then insisting that IT fix them. She was used to being ignored and dismissed. Jim took it upon himself to make her an ally. I applaud him for that. I really do. I just disagree with the approach as an overall governance principle. If you haven’t hired people who are willing to update business processes and technology to keep the company more profitable, then that’s not my IT problem.

I do think that it is important for IT to understand the business and I do agree that I have seen the needs of a lot of business units ignored when developing technology strategy. I’m not suggesting we continue to ignore the business and roll out irrelevant solutions. I am saying that it is our responsibility to make our users less dependent on IT when they are whining and crying about a software upgrade. Instead, let’s design intuitive solutions that meet real business needs. Let’s oil the wheels of our enemies by making self-service and user-centered development a part of our governance plan. The first step to user adoption in my opinion is to stop making change an option. And governance is a tool we can use to fix that very real problem. A squeaky wheel is the result of bad governance. You don’t fix that by throwing customer service at it.

Tiffany is a SharePoint subject-matter expert working on enterprise records management projects. She blogs while running on a human-sized hamster wheel that squeaks constantly.

Twitter – http://twitter.com/officeovereasy
LinkedIn – http://www.linkedin.com/in/tiffanysongvilay
Website – http://officeovereasy.com/

Comments on theis post are turned off. Go to Your Turn to weigh in on the debate!

Missed the other posts in this series?

SharePoint Saturday Houston Throwdown: Whither the Squeaky Wheel?
Keep Your Friends Close, Keep Your Enemies Closer, by Jim Adcock
The Great Debate: Your Turn!

She had apparently learned from some previous situation that if she didn’t do this, she would be ignored or dismissed. I managed her by disregarding e-mail as a response mechanism and not responding defensively to cover myself with my manager (though I did meet privately with my manager and let her know what I was doing), instead dealing with it by calling her directly, taking her concerns seriously, and addressing he problem while never making her feel like I was treating her as if she were stupid, and never blaming her for the problem while showing her what to differently next time to prevent the problem. Doing this, I weaned her from he past behavior (which I’m sure the managers involved appreciated), and turned her into an evangelist for the system, from their biggest critic and complainer into the biggest booster. All it took was making her understand that her issues were being heard and responded to with respect, and quickly and efficiently solving the problem. Which is really all that most complainers want – to be taken seriously, treated respectfully, and for their problem to be solved quickly.

This experience informed my opinion on bringing the most vocal “squeaky wheels” into the governance process. They know what doesn’t work for them, what issues need to be addressed by the governance plan. When their pain is caused by governance or other restrictions, they can help you find workarounds (or help you find the workarounds you want to prevent to keep your users from side-stepping those restrictions), and they can learn why those restrictions exist, and what pain having those restrictions prevents. When they buy into governance, you prevent them from poisoning the well and sowing discontent among the users.

But Tiffany had a case for treating difficult end-users differently.

Comments on this post are turned off. Go to Your Turn to weigh in on the debate!

Missed the other posts in this series?

SharePoint Saturday Houston Throwdown: Whither the Squeaky Wheel?
Keep Your Friends Close, Keep Your Enemies Far Far Away, guest post by Tiffany Songvilay
The Great Debate: Your Turn!

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
Your Turn!

Comments on this post are turned off. Go to Your Turn to weigh in on the debate!

Once again, I’ll be presenting SharePoint Group Therapy – A SharePoint Governance Workshop.

Bring your SharePoint governance issues and questions, we’ll work as a group to resolve your issues and help you gain control and drive user adoption.

Business alignment can be seen as the marriage of IT and business objectives. Every marriage has its rocky moments, and sometimes a therapist is needed to resolve those issues. Perhaps your marriage could benefit from a little SharePoint Group Therapy?

See you in Houston!

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.

In a smaller organization, you as the SharePoint Administrator are likely to be more familiar with the pains your organization is having around finding, modifying, preserving, and distributing information, or, at the very least, more familiar with the power players in each of the departments.  In a larger organization responding to user issues is likely to be divided up among several people, and you are less likely to interact with people outside your department on a regular basis.

In a smaller organization, you may have a smaller governance board, though that won’t always be the case, as you will still want representation for each job type, regardless of the size of the organization.

You mention that there is no legal department. There are still legal regulations that your organization operates under, and someone is responsible for making sure that those regulations are adhered to, and that those rules are known to the people doing the work. Whoever has that responsibility, whether it is management, Human Resources (for HR-related issues), or outside legal counsel, should be consulted to make sure that your governance plan complies with applicable legal requirements – document retention, HR regulations, discovery, etc. Usually this should be pretty straightforward, assuming your organization has its legal obligations documented. Build on your existing regulatory compliance infrastructure, and keep in mind that the choices you make in your governance plan can have legal implications.

Smaller organizations may have an advantage in their governance plans, in that it may be easier to get information and direct feedback from a larger portion of the population than would be practical for a larger organization.  This can help you define your governance to be more in tune with your users’ needs.

As I have said before, find out what the pain points are.  Find out how SharePoint aligns with your organization’s objectives – which means finding out what those objectives are, which means getting your organization to define those objectives (if they aren’t defined already), getting them to think about those objectives when considering what SharePoint in your organization is for.

Remember to use the tools built into SharePoint, regardless of the size of your organization –

• survey your users using SharePoint surveys
• organize meetings with meeting workspaces
• save your working documents and lists to a governance site
• consider writing an internal company blog talking about the issues and payoffs

Hopefully these tips will help you create an effective, living governance plan for your smaller organization.

Get Notified! Scroll to the bottom of the page to get notified when new posts are added to the site!

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:

First, SharePoint had already been implemented in other parts of the organization.  This provides an opportunity to have a discussion around what features this department had heard about from the rest of the organization that had convinced them they needed SharePoint too. Finding that out will be a pretty accurate guide to what they need and the challenges they face.

Second, he could have stakeholders meet with him for a “features review”, to go over the things that SharePoint can do for them, and use that to determine what things they wanted and discuss the configuration and maintenance needed to achieve those goals.

Third, find out who their in-house SharePoint talent is. Anyone in the organization who has some experience with SharePoint may shed light on the actual requirements, and may have some leverage to get management to understand the complexity of their needs. Meeting with them and determining their competency level may also provide insight to how much help (if any) they will need once SharePoint has been set up. If they are going to be over their heads, preparing them to know when outside assistance will need to be called in might be a good tactic.

A fourth option occurred to me today – a meeting to define success metrics. The business side tends to like words like “metrics”, and it may make them more amenable to discussing and defining requirements and coming to an understanding about the resources needed to fill those requirements.

All of these approaches are just different tactics to get to the same information, ways to get past the barriers in the minds of the stakeholders, preventing them from seeing and addressing what it is going to take to achieve success.

Have you ever worked with an organization that wanted you to “just set it up”, without providing clear requirements and probably lacking a clear understanding of just what they are asking for? How did you handle it?

Get Notified! Scroll to the bottom of the page to get notified when new posts are added to the site!

“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.

Things that can be created in production, without going through the defined testing and promotion process:

• New pages.
• New documents and list items.
• Modification to pages involving addition, reorganization and removal of web parts, or the editing of content.
• Changes using approved templates, such as lists, libraries and sites.

Things that are required to go through the defined process:

• Modification of pages involving JavaScript, jQuery, CAML queries, and other scripting options.
• New web parts.
• Custom development.
• Changes to master pages, CSS and other design elements.
• Changes to templates.
• Patches to operating system and SharePoint.

The Defined Testing and Promotion Process:

1. Changes are made to a development environment.
   1. If the development environment is a single-server farm (for instance, a local virtual machine) and the ecosystem also had a multi-server development farm, the developer must push the changes to the multi-server development farm and verify the solution before given approval to promote to the Staging Farm.
2. Approved changes in the development environment are promoted to the staging farm for User Acceptance Testing
3. Approved changes in the staging farm are promoted to the production farm in a manner consistent with minimizing impact to users.

Does your environment have a defined testing and promotion process? Do you allow some of the things I have identified as “development” to occur in your production environment? Are you more restrictive than the guidelines I have set? Do you even have a production environment?

What is your experience?

Get Notified! Scroll to the bottom of the page to get notified when new posts are added to the site!

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:

1. Content access controls are different
2. Content ownership is different from that of existing sites
3. Intent of the content is significantly different from existing sites
4. 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

Other Considerations
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!