One of the proposals I make in Step 3 in the white paper is that in order to encourage people to intuitively understand how make use of SharePoint, that you should provide a “sandbox” environment where they are free to try things out. Given the breadth of capability available in SharePoint, I feel that it is important for people to be able to “play” with the tools in an informal setting and before they are asked to use the tools for important and mission critical business projects. As a “sandbox”, the environment is separate from the full production SharePoint installation, and there should be (a) freedom for people to use different SharePoint templates to set things up, (b) clear user interface constructs to indicate that this is a non-production playground, and (c) some default rules and policies.

During the Q&A session in Wellington, Bruce asked this question:

If we set up a sandbox environment don’t we run the risk of encouraging too much usage and adoption? And in particular, won’t people use the sandbox as a default production site, thus routing around official processes for getting a SharePoint site or application set up?

I personally don’t have a problem with the first half of the question, given the assumption that the usage and adoption in question is monitored by IT. If people are learning how to use SharePoint features effectively, are learning about how to include others in their efforts, and are pushing the boundaries of what can be done with SharePoint, I think it’s fine.

However, the second part of Bruce’s question is problematic and warrants some thought. I’m glad he asked it. My take is that there needs to be a clear process for taking ideas and concepts that are developed in the sandbox across to the production environment, and that there needs to be clarity around the triggers for doing so.

Some triggers for shifting a site from the sandbox to the production environment are:

• Wider Appeal … If a SharePoint site has been developed in the sandbox and is proving valuable to the people that created it, and it is apparent that other groups/teams could experience value from it directly or from a new template based on it, then shift it across.
• More Regular Backup Required … Let’s assume that the sandbox environment is only backed up weekly, and so if the environment fails, people will lose up to a week’s worth of data. On the other hand, the production site is backed up very regularly … multiple times a day even. Thus when a group/team starts to be worried that their sandbox efforts may get lost, that’s a clear trigger that it should be shifted into production.
• Integration with Other Systems … Aside from integration with Active Directory, once the team/group starts talking about integration with other core infrastructure elements–Project Server, Live Meeting, Office Communications Server, and other bespoke applications–then it is clearly time to move it across.
• More Experienced Development Required … When the development effort required to do cool things in the site goes beyond the capabilities of everyday users (eg, writing code), then shift it across to production and get a SharePoint developer involved with the team in scoping what needs to be done and delivering those enhancements.

What’s the process for shifting? From IT, common courtesies should prevail–clear communication across whatever triggers are in place for your organization, clear communication about when it will be shifted, and clear communication about how the shift will impact the team/group. From the team/group/person … there is going to need to be some recognition that some things will change and become more structured once the shift has been accomplished, eg, changes will be less ad hoc and subject to a more formal change control process. Such things need to be made clear upfront when the sandbox goes live.

Do you think this approach would work at your place? Why or why not? What would you do differently?

Comments
From Marnix Catteeuw,

“To make a clear distinction between sandbox and production environment, I would add an extra rule that everything in the sandbox is by default temporary. This also allows you to easily monitor the new users/groups during their start up phase.“