xx.
Chapter.6:.Building.the.Resources.for.Implementation:.
SharePoint.Components.and.Sssociated.Pieces
Key components are required to deliver SharePoint, and this chapter describes what they
are and why they are required. Chapter 6 also describes the role of members of the team
in collating this data and how the data should be used.
Chapter.7:.The.Business.of.SharePoint.Architecture
Chapter 7 describes the concept of architecture and how it is applied to SharePoint. The
principles of hardware, software, and information architecture are discussed in this chapter.
Software architecture looks at the components of IIS, ASP.NET, Virtual Directories and how
logically they are defined. Hardware architecture considers capacity, isolation, and sharing
and looks at how the requirements for these can be defined. However, information archi-
tecture is discussed in detail since this is the foundation of providing the key requirements
of hardware architecture planning and how software is then applied to it. The implementa-
tion of all of this is then listed as tasks and are slotted into the work breakdown schedule,
including reasonings and how architecture agreements on Sharepoint also provides risk
management detail.
Chapter.8:.SharePoint.Customization
This chapter details the ”when and why” of SharePoint customization—the development
and branding the priorities placed on implementation of SharePoint. It describes what
the requirements are to carry out customization of the platform in terms of people and
equipment; what the process is for ensuring that there is a split between development and
production environments; the importantance of having a functional environment over its
”look”; and when you should go for development and the responsibilities of the project
manager to ensure that it is provided in a proper environment.
Chapter.9:.SharePoint.Governance
Extremely important to a successful implementation of SharePoint is its governance, by
which we mean the strategy, rules, and support process provided to the user base. This
chapter describes what SharePoint governance needs to be implemented from the outset,
and how by having a structured environment, it can be continually maintained, monitored,
standardized, and enhanced.

xxii.
Chapter.14:.Releasing.SharePoint.to.the.Client
This chapter addresses key areas relevant to building the SharePoint development, test,
stage, and production platforms. It includes information on testing and training the users.
Chapter.15:.SharePoint.Is.Implemented,.Now.What?
This final chapter covers what it takes to ensure that SharePoint, once implemented,
becomes part of the organizational lifecycle. This chapter describes the wrap-up procedures
concerning archiving of project data and goes into detail concerning responsibilities of the
team members and what they need to do to ensure that full handover is completed. The
chapter concludes by discussing the importance of ensuring resources, governance, and
other business-as-usual activities have been handed over satisfactorily.
Where.to.Find.Additional.Information.and.Updates.
I started off my website way back in 2003, and since then, it’s grown and I’ve tried to keep
pace with the times. The current site runs on SharePoint 2010 Foundation, and it’s great
fun. Of course, there is a mountain of blogs that are relevant to this book—and quite a
few of the links in this book point to blogs on the site. You will also find articles, links, and
downloads related to SharePoint 2010, 2007 and 2003.
This site is:

As for updates, just keep an eye on my website as I aim to publish more articles on Share-
Point implementation, and of course, I welcome any input you might have. Please feel free
to contact me using the contacts sheet on that site.
I do hope you enjoy my book.
xxiii
Conventions and Features Used in This Book
This book uses special text and design conventions to make it easer for you to find the
information you need.
Text Conventions
Convention Feature
Abbreviated menu

going on with the software—inside information on why a feature works the way it
does. You’ll also find handy workarounds to different software problems.
troubleshooting
This statement illustrates an example of a “Troubleshooting” problem
statement.
Look for these sidebars to find solutions to common problems you might encounter.
Troubleshooting sidebars appear next to related information in the chapters. You can
also use the Troubleshooting Topics index at the back of the book to look up problems
by topic.
Sidebar
T
he sidebars sprinkled throughout these chapters provide ancillary information on
the topic being discussed. Go to sidebars to learn more about the technology or a
feature.
1
Chapter 1
Introduction
Project Planning in SharePoint . . . . . . . . . . . . . . . . . . . . . . . .1
A Historical Perspective on Project Governance
with SharePoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
What This Book Is About. . . . . . . . . . . . . . . . . . . . . . . . . . . 11
What This Book Is Not About. . . . . . . . . . . . . . . . . . . . . . . 11
Project Planning in SharePoint
M
icrosoft SharePoint 2010 is a strategic technology that allows people to seam-
lessly connect with each other in terms of centralized content management. As a
collaborative tool, SharePoint can be used by anyone, and it can be installed and
configured quickly—usually to meet a “specific requirement.” And this “specific require-
ment” is typically based on one person’s perception that installing technology will solve a

it. We only need a site or two to store the documents in. If the users want in, we’ll give them
some sites to play with.”
Does that sound okay? Well, what I explained was that the vast majority of SharePoint
implementations have been based on exactly the scenario depicted by the admin’s com-
ments: project planning in a vacuum.
What’s wrong with that? To best explain it, let’s take that scenario and add a couple of
months to it:
“Hey! We have 20 sites now. Lots of content. Not sure what we are doing. Not sure how it
all connects together. We think we know how to manage it, though we don’t know how big
it will get. And we also can’t control how big it gets because we are not entirely sure who is
using it and why.”
What’s the Situation?
T
he situation described is that the technology is adopted without any analysis
(known as information architecture) to define the requirements for using the tech-
nology within the organization and without future-proofing the technology.

Information Architecture is the study of how information, organizational structure,
information flow, process flow and more are connected to user requirements. With-
out it, SharePoint is not defined to meet the client requirements, since Information
Architecture leads to SharePoint user strategy in terms of content management. Infor-
mation Architecture is further discussed in Chapter 7, “The Business of SharePoint
Architecture.” Future-proofing describes the exclusive process of trying to anticipate
future developments, so that action can be taken to minimize possible negative conse-
quences, and to seize opportunities. For example, you may want to make the platform
easy to grow (to scale) so you add capacity to the system to accommodate it. You may
want SharePoint to be easy to support, so you add more monitoring, performance tun-
ing, even more people to look after the product as part of the implementation.
Chapter.1
Project Planning in SharePoint. 3

nal person. Chaos ensues because there is no documentation found concerning the
original, or the added server installation.
Adopting.Project.Governance.in.SharePoint.Is.Vital
Before I state why it is important that you have project governance, it is best to describe
the key premise of project governance and the hurdles you must get over in implement-
ing it. The first hurdle is that you must engage the stakeholders (the person or group in the
organization affected or that has a direct interest in the project—also known as the client)
on the topic. There is absolutely no point in explaining the wonderful aspects of Share-
Point (and how it will sort out all of the company’s woes by sharing data and establishing
Chapter.1
4. Chapter 1 Introduction
a framework for effective communication) unless the stakeholders have a grasp of what it
means to have project governance. Stakeholder buy-in is the biggest factor concerning the
adoption of SharePoint (or, in fact, any new technology).
Why is stakeholder buy-in important? All stakeholders need to know what’s happening,
when it’s happening, and why it is happening. They need to be clear about who is involved,
the stages of SharePoint implementation and what they entail, what needs to be achieved
along the way, and how you’ll reach key decisions and outcomes. It is crucial to remem-
ber the aims and objectives, protect the special qualities of the design, and hold on to
the “golden thread” that will make the project successful and match the client’s vision of
SharePoint.
Some SharePoint project managers I have met are afraid to approach their clients to explain
the concept of project governance; they feel the client will not want to implement Share-
Point if doing so will alter the way people do things. Interestingly, it is not the implementa-
tion of SharePoint that invokes project governance, it is the implementation of SharePoint
that allows people to work more productively.
A company called me up stating that they had been given SharePoint but had no idea
how they got it or what to do with it. They were now having a nightmare controlling the
management of the platform, especially since they wanted to rationalize their desktop
technologies. I visited the company and found that technicians had decided to install it for

more out-of-the-box security permissioning, as well as an easier way to define and custom-
ize those permissions to suit the content being provided).
One of the most compelling aspects of SharePoint 2010 is the unified infrastructure
approach, which entails having one platform with multiple solutions. This unified infra-
structure results in easier integration and enhanced connectivity to multiple device and
browser types.
What.Is.Project.Governance.in.Relation.to.Content.
Management.Systems?
Content management systems rely on project governance to deliver, support, and manage
the platform. As a content management system, SharePoint makes project governance even
more crucial because SharePoint is an enterprise system. It provides a technology platform
that enables the organization to integrate and coordinate their business processes. It will
provide a single system that is central to the organization and ensure that information can
be shared across all functional levels and management hierarchies. It connects to all man-
ner of Microsoft technologies and components. Additionally, these connected technologies
and components could have their own project plans for implementation; they can also run
on their own schedules that have been created and managed by their support and imple-
mentation teams.
Project governance techniques adopted in large organizations often use methodologies
such as PRINCE, Agile, or Project Management Body of Knowledge (PMBOK). Unfortunately,
when governance is applied to SharePoint, there is no standard methodology because
SharePoint is based largely on the organization’s understanding and application of the
product. Companies rarely look (or will not take the time to look) for a standard method of
deploying a product such as SharePoint, and they might often turn to external consultants
and project managers to provide governance.