How To Use Site Definitions in SharePoint

One of the questions that often comes up in SharePoint engagements is the question of
whether you should create your own site definition or whether you should use the out-of-
the-box definitions and use features to control how they appear. It is in fact a topic of
some discussion between SharePoint consultants. My hope here is to illuminate the
primary reasons that you should be creating site definitions -- and what reasons you
shouldn't create them. Let's start our discussions about using features to modify a site
definition.

Features and Site Definitions

In version 2 of the product you had to create site definitions to work around the behaviors
in the out-of-the-box site definitions. There wasn't a mechanism for adding to or
removing functionality from a site definition once it was created. However, in version 3
that changed. The addition of SharePoint features allows you to add and remove
functionality at will. There's virtually nothing that can't be managed through the addition
of a feature especially when coupled with feature receivers.

Features can deploy pages, add menu items, remove menu items, and even do more
advanced things with the use of feature receivers that allows you to run any code you
want when a feature is activated on a site. Features can even be stapled so that they are
automatically added to new sites that are created.

As a point of fact, most of the out of the box functionality was moved into features. The
site definitions reference features that are automatically added to the created site through
feature dependencies in the site definition. One of the reasons that you should use
features in SharePoint is because you can change and redeploy features, however, once
you've created the first site from the site definition you shouldn't modify that site
definition for any reason.

Making the argument for the Site Definition

If features are so great with their ability to address virtually every menu item, the ability
to add new pages, and so on why wouldn't someone build everything as features and
leverage the existing site definitions. There are two answers: Cleanliness and
differentiation.

Cleanliness

If you've had a chance to look at the output of SharePoint using one of the out of the box
site definitions you may have noticed that they're not the cleanest HTML output. You'll
notice all sorts of extra stuff in the templates that isn't going to add much value. In fact it
may make your job of branding your site more difficult -- and it will certainly make
getting an accessible site more difficult. What does this have to do with the site
definitions? Well the site definition is where the master page, web part pages, and in
MOSS, where the content pages come from. If you don't like the output of the HTML
you're going to be redoing these pages anyway.

Sure you can do that from a feature, however, then you have to consider the possibility
that someone may accidentally reactivate one of the out of the box features and overwrite
your hard work to make the page branding work or to make the page more accessible.

By creating your own site definition you have less chances for issues related to user
deactivating features that they shouldn't.

Differentiation

One of the challenges with working with large numbers of sites in SharePoint is just
determining what the site is supposed to be from code. Sure the user can quickly tell the
difference between a Six Sigma site and a budgeting site, but how do you determine
which type of site it is from code?

If you're using site definitions for the major categories of sites in your organization you
can easily determine what kind of a site an instance is by just reviewing the
SPWeb.WebTemplate or SPWeb.WebTemplateId properties. These fields allow you to
see which site definition a site was created from.

There is no other named property that allows you to differentiate the type of site. These
properties can be used to clearly identify which sites are your special sites -- ones with
special code or special rules -- and which ones are out of the box collaboration sites.

It should be noted that it's possible, without implementing a site definition, to

differentiate sites from one another. Each site has a property bag associated with it. It is
possible to insert an entry into this property bag about what the site is supposed to be. In
fact, I've used this strategy in certain circumstances, however, if you're using properties a
lot you'll find that it's inconvenient to have such an important system property stored
along with user supplied information.

Implementing Site Definitions

In an organization it makes sense to develop a minimal site definition that contains all of
the basic elements that are required and make copies of this base site definition for every
type of site that you wish to differentiate. This minimizes the work that must be done for
each site definition while simultaneously supporting a clean solution.

Creating your own site definition isn't that difficult. You can start with the Minimal
Publishing Site which is available from the Features project on Codeplex or download the
code from Andrew Connell's book Professional SharePoint 2007 Web Content
Management Development: Building Publishing Sites with Office SharePoint Server
2007. (The Download is at http://www.wrox.com/WileyCDA/WroxTitle/productCd-
0470224754,descCd-DOWNLOAD.html)
It's true that both of these examples are publishing examples, but those are the most
technically challenging to create and thus are the ones that samples are most needed for.

Making Sense of it All

If you take a step back and look at the problem you'll find that you'll likely start with
using features to make your modifications. You'll deploy your branding through master
pages, web part pages, and page layouts. When you need to differentiate between
different kinds of sites. What this means for a governance plan is that you'll likely want to
offer an instance of a standard site definition -- one that has the branding and core
features baked in -- to key projects in the organization so it's easy and consistent to
identify which sites belong to each project.

An Introduction to Microsoft SharePoint Portal

Server
As the volume of intranet content grows, administrators and users are increasingly looking for
ways to manage the volume of information. Just as Netscape aggregated the then-growing
internet content into a manageable framework (called a portal), application vendors have created
many packages that allow their customers to aggregate their intranet content into corporate
portals.

This series of articles will discuss Microsoft's portal product — SharePoint Portal Server. I hope to
provide some value to the readers of Intranet Journal regarding the capabilities (and limitations)
of SharePoint. Your feedback is encouraged, and will help me to cover topics that you find
relevant.

Introduction to SharePoint

Like most portal products, SharePoint allows visitors to create custom views of the Web site. This
customization can be very simple or very complex, depending on the type and version of the
product that is installed. In addition, SharePoint has a powerful collaboration model that is tightly
integrated with the Office 2003 suite.

The current version of SharePoint is its third (despite its name). Like most Microsoft software,
(Windows in particular) version 3 is gaining rapid adoption. A recent article in The Register
indicated that SharePoint Portal Server is Microsoft's fastest growing product, with 30 million
licenses.

Have questions about Microsoft SharePoint? Have a story idea for Paul's series? Visit the
Intranet Journal Discussion Forum.

History of SharePoint

Microsoft's first portal application was called Digital Dashboard. This product introduced the
concept of Web parts — boxes of information on a page that represented a summary or overview
of information. (Other vendors referred to these items as "portlets.") By assembling multiple parts
on a page, each user could customize his view of the portal to contain the information that
pertained to them. In theory, every visitor of the site could have different content at the same
URL. However, the technology behind the Digital Dashboard was not up to the task, and it never
made it out of the beta stage.

At the same time, Microsoft's Office group was working toward a collaboration solution. The need
for many people to contribute to a single document or worksheet was growing. And, these people
were not necessarily working at the same location. The result was SharePoint Team Services
(STS), a Web-based solution that allowed shared access to information and documents. STS
also allowed end-users to make changes to the site via a Web browser instead of requiring a
development-oriented application.

The merging of the collaboration and aggregation functions lead to SharePoint Portal Server
2001. Portal Server has been upgraded to run on the .Net framework and is now referred to as
SharePoint Products and Technologies. The "Product" is SharePoint Portal Server 2003 (SPS)
and the "Technologies" are Windows SharePoint Services (WSS). A significant point about these
two is that WSS is included with the Windows Server 2003 license. Any organization that is
licensed for Windows Server 2003 can also host Websites that are based on WSS.

Features of SharePoint

In general, SharePoint contains all of the features you would expect from a portal or collaboration
tool:

• Browser-based customization of page

• Browser-based content administration
• Aggregation capabilities
• Document Repository
• Message board
• Ad-hoc data storage
• E-mail notifications
• Announcements, event calendar and contact list.

A complete feature matrix that also indicates whether the feature is part of WSS or SPS can be
found in the whitepaper Implementing Rich Collaboration Infrastructure Using Windows
SharePoint Services and SharePoint Portal Server 2003 on Microsoft's Web site
(http://www.microsoft.com/sharepoint/evaluationoverview.asp).

Uses for SharePoint

In addition to being the default intranet portal, there are many additional uses for SharePoint.
Microsoft has included pre-defined templates for Web sites to facilitate meetings, manage
projects and create documents. Combined with the "self-service" site creating feature, teams can
create and use a Web site with minimal assistance from the Information Technology department.

The Document Workspace template will allow a group to work on a document. The template
combines a document repository with a task list and a links list. While using Word 2003, a user
can have the document open and at the same time view the task or links list. Changes made to
the task list are immediately visible to site visitors. And the document library allows versioning, so
edits are not lost.

The Meeting Workspace template combines the agenda, attendee list and Outlook's calendar
function. When sending a meeting request in Outlook 2003, a user can create a workspace on
the server. The URL of the workspace is automatically included in the message and the
attendees are added to the site. The materials required for the meeting can be centrally located,
which is preferable for attendees who travel frequently.

The browser-based customization feature, combined with the ability to create ad-hoc lists allows
an advanced user to create a site for almost any purpose. A user group could host its meeting
schedule, complete handouts. A youth sport organization can post its schedule and roster. An
individual can host a blog. The possibilities are endless.

About this series

This series of articles on SharePoint is intended to help you understand the capabilities of the
product, as well as provide tips and tricks, development ideas, information from Microsoft,
information from the community, and perhaps some samples. Like many other series on
IntranetJournal.com, I plan to include how-to articles that can help you with your deployments —
ways to customize a page; deployment scenarios; content management; etc. With such a diverse
product, there is no lack of topics for this series of articles. What would you like to read?

About the author

Paul Schaeflein is a developer with over twenty years experience. Paul has been developing
dynamic and interactive Web sites since 1996. Paul has worked on all of the versions of
SharePoint and has worked with the .Net framework since its debut. You can reach Paul through
his blog at http://www.schaeflein.net/blog/.

Managing the Code When Customizing SharePoint

Robert Bogue

6/9/2008

One of the most common problems that organizations that are customizing SharePoint
have is how do they manage the code deployment process. Organizations typically have
configuration management guidelines that help them regulate how code makes it into
production whether that's internally developed code or are patches that are applied to the
operating system and products being leveraged.

The problem is that SharePoint doesn't fit a nice clean model. Because so much of
SharePoint is configuration and data driven, code that works in development or a test
environment may not work in Prod because things are configured differently or there's
different data to operate on.

So how do you manage a situation where you've got configuration information that needs
to meet up with code to create a complete solution? In this article I'll tackle this problem,
a generic approach, and talk about a few of the sharp edges on the strategy that you'll
have to educate everyone on.

A Simple View of Environments

In order to facilitate a discussion, let's assume that we have three formal environments:
 Development -- A system integration environment where developers have (or
potentially have) access to the servers and to the administrative controls. Some
organizations call this environment the "Wild West" because it is only lightly under
configuration management. This actually a systems integration environment where all
code is forced to live together with test data before moving forward.
 Quality Assurance (QA)/Test -- The Quality Assurance (QA) or Test environment is
where the code from development and the content or a subset of the content from
production comes together. This is the place where final signoffs are received prior to
going into production. There might be multiple QA environments in an organization but
for our purposes here they can be considered as once since they all live in the same space
of configuration management. This environment is generally well controlled and follows
a change management process - however, typically with fewer sign offs than the
production environment.
 Production --The tightly controlled production environment where the tightest
restrictions on access are and where availability, reliability, and scalability are of
paramount importance. This is the final resting place for code and in at least some
environments is the origin for all content.
Certainly it's possible to have more environments or a more complex scenario; however,
this simple model will make it easy to talk about the concepts. The one assumption that's
not listed as a formal environment in the above is that developers will have their own
environments locally which aren't formalized. Their initial development work will take
place on their local machines or dedicated development machines - not in the
development environment.

Content and Configuration Never Moves To Production, Only Away From It

One of the challenging, and powerful aspects of SharePoint is that the configuration of
the system and the content for the system are comingled into a single content database.
Because of that it's difficult to extract either the content or the configuration without
bringing along the other. As a result, it's too easy to accidentally overwrite production
content if you try to pull up content or configuration from another environment. As a
result, the hard and fast rule is that content and configuration always move from Prod
backwards through the environments to QA and if necessary to Development.

This isn't all that different conceptually from how organizations approach QA
environments for other systems. It's common place to migrate production data, or parts of
the production data, back into a QA environment to test changes to an application and run
validation suites. The key difference is that with SharePoint the code and the content can
be more tightly coupled than is common for most traditional systems. This always move
from production approach isn't without its limitations not the least of which is what
content to migrate backwards and what to do about required configuration information
which is covered in the following sections.

Partial Migration
Depending upon the environment size, the amount of testing resources, the type of
content, and the sensitivity of the content, it may be impractical or impossible to migrate
all of the production data back to QA. However, in other environments QA must
precisely mirror the production environment all the way down to the data that's in use.
Whether you choose to do a partial migration or a full migration doesn't impact the
approach of migrating from production to QA - and potentially even back to
Development if the information isn't sensitive. The rule is primarily that nothing moves
to production. If you want to allow your QA environment to get out of sync with
production data you can do that.

Required Configuration

Once of the most vocal arguments against this strategy is the problem of code and
configuration aligning. Say for instance that I have code that requires that there be a new
field in a list in SharePoint. The argument becomes how you get that new field in the
SharePoint list and how does that meet up with the code. In most cases, the configuration
can be made in production in advance of the code getting there. In other words, the new
field can be added into production, but perhaps not have it visible to most users. A new
list can be created with permissions so only the site administrators can see it. A whole
new site can be created and hidden from the users if necessary. There are a variety of
options that are all workable ways to get the configuration into production without
impacting the look and feel of production for the users.

What's more tools can be developed to make these configuration changes. Whether they
take the form of an additional feature with a feature receiver or are a command line tool
that the infrastructure team runs, you don't have to configure things via the user interface
just because you can. These tools can then be run in the development environment, again
in QA, and when the time comes in production as well.

Initial Load

There's one possible exception to the rule of always copying content back from
production. That is, the initial load of the system. While it's still not recommended that
you roll forward the content database from development, a roll forward of the QA
environment to production for the initial load can make sense if you've been treating QA
as a pseudo production while the production environment has been being built or
converted.

Code Always Moves from Development through QA to Production

To someone who's been doing configuration management the idea of moving code from
development to QA and then once approved to production may seem like an obvious
approach, it's not necessarily that obvious to someone that hasn't done configuration
management - or has been loose in their practices. In addition to a semi-rigid approval
process for code which requires a stop in QA and sign off that the code is ready for
production, I generally recommend that all code be delivered as a SharePoint Solution
package. The SharePoint Solution package, with a .WSP extension, can be atomically
deployed to an entire web farm which makes it ideal for the identical delivery of code to
QA and to production. There are only two steps for deploying code with a WSP - adding
it to the solution store and scheduling the deployment. The ability to avoid a large
number of manual steps means that there is less chance for error when moving to
production and that's a good thing.

What is Code?

Code is all of the things that you can't do from the user interface or SharePoint designer.
Developing web parts is obvious, as are the development of SharePoint Features.
However, there are some situations where you'll convert content into code so that it can
be universally applied across site collections in the farm. For instance, master pages,
content types, and page layouts used for publishing are generally published via a Feature
so they're code -- even if they're initially created in the user interface. Here's a list of
examples that are always code:

 Workflow Templates (the kind created in Visual Studio 2005)

 Event Handlers
 Navigation Providers
 Web Services
 Site Definitions
 List Definitions
 Web Parts
 Features
 SharePoint Solution Files (WSPs) What is Content?

Some content is easy to identify. Documents, web pages, and list items are clearly
content and should therefore be rolled back from production to other environments.
However, what about list instances, lists schemas, web sites, etc? In short, yes, that's
content. If you can create it in a web browser or in SharePoint Designer - it's content. It
needs to roll backwards from production to QA and possibly to Development. Here's a
list of things that are always content:

 Site Collections
 Web Sites (Sites/Webs)
 List and Library Instances including both the schema and the items in it
 Web Content Management Pages
 Workflow Associations (the relationship between a template and a list or content
type)
 Workflow Instances (The instance of a workflow template running on an item)
 Workflows created in SharePoint Designer
 User permissions
 Site Templates
 List Templates
Determining the Difference Between Code and ContentYou may have noticed that the
list of code items and the list of content items don't represent everything that is in
SharePoint. There are some major gaps between the two. It's already been mentioned that
some items may start out as content and then be converted into code to allow them to be
more easily deployed in a consistent manor. Let's take a look at that list:

 Master Pages
 Content Types
 Page Layouts
 Themes
 Web Part Pages
 Navigation
Generally speaking it's a good idea to deploy master pages via Solutions and Features.
Content Types -- particularly those used for Web Content Management should also be
deployed via Solutions and Features. Page Layouts which are designed for cross site use
fall into the category for deployment -- and thus should be treated as code -- as well.
Similarly Themes are good candidates for Solution deployment since the point of a theme
is a consistent experience between sites.

It does get a bit sticker when we start to talk about Web Part Pages because sometimes
you just need another page in the database. In other cases you want the page to appear on
a whole set of sites. If it's a one off, the page can certainly stay in the content database as
content, however, if it's a part of a solution that already includes code, it might be best to
wrap the web part page up into the Solution and Feature and to use that for deployment.

Navigation is the final difficult to classify component of the SharePoint configuration

landscape. In many ways, Navigation is built up from the data that's in SharePoint so it's
a function of the content. However, it is possible to deploy some navigation via code.
Again this would typically happen when you're already deploying code solutions and the
objective is to add that code solution to the navigation tree. However, because it's
bundled with a new application it's unlikely that anyone would misconstrue one type of
navigation for another.

Smashing Code and Content Together

By viewing the problem from the perspective that content rolls backwards from
production and code rolls forward from development you have the ability to smash code
and content together in a QA environment so you can perform real-world testing before
you get into the critical production environment. Being able to find issues in QA will lead
to a more stable production environment and fewer emergency deployments of new code.

Creating your SharePoint Governance Plan

One of the most common questions that I get from prospects as I'm talking to them about
the creation of a governance plan and process is what does it look like. In other words,
there are materials available which describe what should be in a governance plan but
there isn't a ton of guidance on what the process of creating a governance plan and
process are.

Unlike a few years ago you now have sample governance plans you can look at, there are
articles describing the kinds of things that you need to make sure are in a governance
document, and a governance resource center on TechNet.

The goal of this article is something slightly different. The other resources available
describe what to create, in this article I'll focus on the process for creating the plan based
on the engagements I've been a part of. Rather than a specific step-by-step process, what
appears here is a rough framework that you can and should tailor to your unique situation.
In the following you'll also find some insight as to the psychology of putting a plan
together as well as the aspects of how we as humans learn and process information.

The underlying assumption to this process is that you have an expert available. Whether
you're contracting that expert yourself or using one of the Microsoft programs like
SharePoint Deployment and Planning Services (SDPS) to get the resource, it's assumed
that the time estimates below are your time with an expert.

Phase I: Orientation

The first phase of a typical governance project is an orientation phase. This is, generally
speaking, a single day for a mid-sized organization but can be broken into multiple two
half day sessions which are spaced close together (within one-two days). There are three
major objectives for this phase:

 Verify a clear definition and objective for the governance

 Educate the consultant on the organization, industry, and special factors which may
be working on the organization.
 Educate the client on some of the features of SharePoint which may be appropriate to
consider as a part of the governance process.
 Walk through the high level decisions related to governance.
The key to any successful project is to clearly understand what the objective is. Generally
we start the day with a conversation about what governance means including some
alternative thinking on what governance is, and reaching agreement on what definition
we're going to use for governance as well as what we'll define as success for a
governance process.

Ultimately the goal is to collaborate on the creation of a governance process and plan. In
order to do this there are two different sets of domain knowledge that need to be
transferred. First, the consultant needs to get from the client information about the
organization including background on the industry in general (if the consultant isn't
familiar with the industry) and any special factors for the organization that may make the
governance process and plan difficult, different, or "interesting."
Second, the consultant needs to educate the client on the parts of SharePoint that are
applicable to their situation. For instance, the quintessential feature is the Quotas feature.
This is a part of nearly every governance plan. However, conversely, the SharePoint
Single Sign On feature rarely is a part of a governance plan. The consultant will tailor the
information communicated about SharePoint to those parts of the product which are most
necessary to reach an agreement.

The final step is to walk through a high level discussion of governance. The objective is
to review a set of questions that are useful for the creation of the plan. Frequently these
questions are based on the two SharePoint Governance articles at IntranetJournal.com
[Part 1 and Part 2] or the SharePoint Deployment Guide and Checklists. The goal is to
sort the questions into three piles: definitely govern, don't govern, and discuss. We don't
generally discuss the "discuss" items during this day because there isn't time. The good
news is that the items that end up in the definitely govern category are relatively easy to
develop guidance on and can be started without outside help -- although there are often
cases where a review of these is appropriate.

Generally this process more than consumes a day's worth of time and really just starts the
process rolling. It doesn't in itself create a governance plan and in some cases it stirs up
more questions than it seems to answer. This is normal. The objective of the day is to get
the process started and get the right questions being asked.

Phase II: Initial Plan Generation

The next phase of the process which generally takes one-to-two days is to work through
the issues associated with creating a plan. Ideally this should happen no sooner than two
days after phase I and no later than 2 weeks after phase I. The reasoning is because
people need to have an opportunity to think through the materials and discussions from
Phase I. In organizations with a dedicated team working on SharePoint with the time to
dedicate to the process two days seems to be appropriate. For organizations where the
resources aren't dedicated it seems like 1-2 weeks is optimal. More than two weeks
doesn't provide enough urgency and generally too much time is spent reviewing what was
covered in Phase I.

In general the process for Phase II looks like this:

 Level set including explaining the impact of governance on adoption and engagement
and how governance should be approached in order to balance the need to evangelize the
platform and control risks.
 Work through the list of "discuss" items from phase I.
 Discuss other successes and failures with different governance approaches.
Before we start the process of writing the initial plan we review what a plan should look
like. This is approached from the thinking that should be in the mind of the authors
(Governance or Guidance), the specific language definitions that should be used so
everyone is clear on how flexible the governance is, and keeping the size of the document
down (Generate development documentation with the inclusion by reference method).
We also cover the idea that Governance is a process and not just a plan. There are two
aspects of this. First, is the aspect that there will be continuing requirements to execute
the plan like solution reviews, and change control. There's also a second order effect to
the creation of the plan itself. By creating the plan you've improved your understanding
of the situation. That improved understanding is often more important than the plan itself.
(See "Creating artifacts -- what you don't know.") By developing the plan you'll not only
understand the end guidance but also the thinking that went behind it.

The next step is to start working through the "discuss" items from Phase I. This generally
alternates between a discussion of the organization's unique needs and situations and how
SharePoint works and what has worked at other organizations.

It's important to note that the one-to-two days of time mentioned above is the time to
meet and discuss with the expert. This doesn't include any time for creating the plan
document or routing that document for approval.

At the end of this phase it's possible to deliver an initial plan that should cover the core
needs of the organization. As we'll see there will be another phase to kick start the
governance process for revising and enhancing the plan.

Phase III: Information Architecture, Taxonomy, and Navigation

One of the closely related topics to governance is the topic of the organization of the
information that will be added to the platform. Whether this topic is identified as
taxonomy or Information Architecture (IA), the guidance on how to organize information
in the platform is generally closely related to the governance of the platform. However,
where governance is about creating a set of guidelines, creating an information
architecture is about analyzing the information to be managed and providing a
categorization structure that can facilitate findability of information in the organization.
The information architecture discussion generally takes one to two days to get started.
The conversation consists of:
 Definition Review including a buzzword to English translation guide
 Review of SharePoint features related to search, taxonomy, and organization
 Exploration of the impact that search has on findability and metadata
 Discussion of the difference between storage and retrieval of information -- said
differently organizing for the creator vs. organizing for the consumer.
 A Card Sorting or similar organization exercise
Just as governance isn't just a plan it's a process, so too must you expect that your
information architecture will evolve over time. Because of that the objective is to expose
the team to the key concepts in information architecture and to walk through exercises
designed to illuminate key approaches to organizing information that may be useful in the
organization.
The definition review part of this phase is designed to link the terminology used in the
industry, such as taxonomy, to concrete topics that make sense to everyone like creating a
filing system. We'll connect metadata to the sticker that might be found on the tab or on
the outside of a folder. Instead of vague concepts you'll be able to connect with concepts
you already inherently know.
The SharePoint feature review is similar to what happened in Phase I where specific
features were reviewed as they applied to how you would govern the platform. Here,
however, the focus is on information management so tools like site directories, navigation
components, site columns, and content types will be reviewed.
Next is a discussion about what all of this means. Once you understand the objectives (to
find information) in detail and you understand the tools that SharePoint offers to you it's
time to see how those tools may shape your design. This discussion includes the
limitations of leveraging search to find information (the delay between creation and
index) as well as other issues such as distinction. This discussion also generally includes
how to leverage search to bring common types of documents together such as providing a
consolidated view of forms.
With the objective, tools, and techniques behind you it's time to learn more about
different organizational structures. We're all familiar with the dewy decimal system and
how library card catalogs work. We'll look at how this system works as well as the
balance between making items easy to store vs. making them easy to retrieve. Finally, it's
typically to run through a couple of techniques, such as card sorting to show effective
ways to elicit feedback about how to organize content from an audience that may not be
able to clearly articulate the ways that they organize information.

Phase IV: Systematizing the Process

I'm careful to make the distinction between a static document which sets upon a shelf and
a living process which grows and evolves over time. Governance planning cannot be just
the governance plan. It cannot be a once and done type of project. Governance is a
process that at some organizations will need to be reviewed quarterly. At other
organizations it may need to be reviewed annually. Using the information from the
process of developing the plan it's possible to create a roadmap for how frequently the
plan should be revisited as well as the type and frequency of meetings for the various
groups.

The final phase is generally establishing these schedules and identifying what situations
or events should cause the roadmap to be redesigned. The process generally takes a day
or two and involves mapping out the intervals, project pipeline, and organizational needs.

Summary

In most organizations a governance plan -- including a basic information architecture -

shouldn't take man-months of effort. If you realize that the objective isn't to create a huge
document that no one will read but is instead to create a plan and process that's minimally
sufficient for managing the organization's risk with the platform. By carefully walking
through a process you can create a plan with one-to-two weeks of outside assistance and
a few weeks of internal time to document the plan.