Q: Governance for Smaller Organizations

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.
Continue reading

Q: They Want SharePoint To Solve All of Their Problems

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:

Continue reading

What Counts As SharePoint Development?

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.
Continue reading