Chapter.1
6. Chapter 1 Introduction
The only problem with this approach is that if the company does not understand the nature
of project management and its application to SharePoint, the output of project governance
probably will be meaningless, not clearly understood, not continually applied to the imple-
mented product—or all three. And when that happens, the implemented product becomes
a white elephant.
Content management systems such as SharePoint need to be designed, installed, config-
ured, delivered, and managed. (Indeed, delivery and management may run in life cycles of
their very own.) The project management methods of plan, control, risk, implementation,
and signoff need to be cycled around these systems.
SharePoint Project Planning is a fine art. SharePoint projects are created by those who
understand SharePoint. There is no point designing projects that look like this:
Phase 1:
1. Research the Market for SharePoint People
2. Get the SharePoint People
3. Purchase Vanilla Ice Cream
4. Install SharePoint
Those who do not understand SharePoint may even assume that the third step (Purchase
Vanilla Ice Cream) “fits.” A SharePoint project manager will demand not only the removal
of that step, but also describe why it’s wrong and ensure there are proper phases cover-
ing Investigation and Design, and Build and Deploy. In this book, we also describe who
is required on a SharePoint implementation team, their roles, and typically what skills are
required.
Project.Management.of.SharePoint.Provides.Project.
Governance
Why is project management so important for SharePoint? Following are four main reasons.
Accountability
There are people who need to be assigned responsibility for actions, decisions, and poli-
cies concerning the management of the implementation and governance, all within the
scope of their role within the project. In other words, someone puts SharePoint in place;

say that in the same week you could try to teach the very basics of SharePoint. But in terms
of accountability, supportability, resiliency, and sustainability, you can’t get that in a week.
Those are continual processes, and to make sure you can apply those means planning
through to implementation. How did I resolve that situation, review current process, edu-
cate the client, put together a plan, agree on the plan—its feasibility—through to imple-
mentation? The client got their SharePoint in one month and now, three years on, have
scaled it to handle over 1000 people and manage their platform well.
Chapter.1
8. Chapter 1 Introduction
A.Historical.Perspective.on.Project.Governance.
with.SharePoint
I’ve had some successes (and some failures) in gathering information concerning how proj-
ects historically implement SharePoint. SharePoint project planning is seen as time-consuming
or as a nuisance, or it is just not generally understood or discussed. For a product that is
so important to the growth of an organization in terms of communication and productiv-
ity, one would think it is very likely that project planning had been investigated or put into
place.
Let’s take a look at how SharePoint has been implemented thus far. By the way, this isn’t just
based on some techie talk such as “Hey, I downloaded it and installed it on a server.” And it
has little to do with the version implemented. Even though SharePoint 2003 has less func-
tionality and fewer features than SharePoint 2007, which in turn has less functionality and
fewer features than SharePoint 2010, a successful implementation of SharePoint is based on
whether the planning through investigation and designing, building and then deploying
was carried out correctly.
Failed.Scenarios:.When.SharePoint.Isn’t.Implemented.
Properly
Let’s take a quick look at some scenarios where SharePoint is poorly implemented. Note
that all of these implementations are examples of failures except for number 5.
1:.By.the.Back.Door
Someone in an organization downloads a copy of a beta version of SharePoint from Micro-

SharePoint and start using it.
Perspectives of Project Governance: What Is Wrong with
Scenarios 1 Through 4
Let’s examine the reasons that scenarios 1 through 4 lead to a poorly executed implemen-
tation of SharePoint.
1: By the Back Door
If SharePoint is implemented without governance from the outset, attempting to design
and implement governance will take time and be more difficult because the users are
accustomed to the Wild West approach. The culture will be one of “governance slows me
down” and “the problems of SharePoint in the organization will sort themselves out.” The
back-door approach is usually the fastest method of getting the product, and the IT help
desk is generally not involved.
Chapter 1
10 Chapter 1 Introduction
2: By Stealth
If one department puts in SharePoint, the governance adopted will be based on the rules
and processes in the department that first installed it. The governance will have noth-
ing to do with a centralized approach by the company; hence, project governance in this
approach will be stifled.
3: By a “You Get It, I Got It” Approach
In this scenario, the poor help desk is left to try to understand and support SharePoint.
They are technicians and therefore are not suited to provide management rules, let alone
review and audit them. Therefore, governance is very low on the priority list and seen as a
nuisance—it gets in the way of trying to sort out a user issue—however, that’s the problem.
Because the help desk does not implement governance, it is highly unlikely the organiza-
tion as a whole will, because they see the IT help desk as owners—after all, the organization
was never directly involved with managing the product. There is no quality control.
4: By an “Our Technology Is Old; We Want New Stuff, But We’re Not
Sure What. IT Help Desk, Please Help Us” Approach
Aha! The organization speaks out and asks for new technology. The organization does it

•
To be a source of forms and procedures that will help your SharePoint 2010 project
meet and exceed customer expectations and requirements
•
To provide a project management implementation method that is repeatable and
standardized for SharePoint 2010
•
To logically connect business requirements to key SharePoint features
What.This.Book.Is.Not.About
This book is not:
•
A technical “How Do I” guide to building SharePoint physical server environments or
connecting SharePoint to other environments
•
A cookbook of development or third-party recipes
•
A technical guide to fixing problems with SharePoint
•
A statement that there is only a single, de facto method of implementing SharePoint

13
Chapter 2
SharePoint 2010 Project Mantra
What Is the SharePoint 2010 Project Mantra? . . . . . . . . . 13
Your First Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Know Your SharePoint 2010 Features . . . . . . . . . . . . . . . . 17
Engage the Right People . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Ask the Right Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
How to Perform an Effective SharePoint 2010
Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

cost. To do that requires combining the resources of both the business side of the organiza-
tion and its technology department. Business resources are members of the organization
who will provide details concerning the client vision; the information they provide is crucial
to the format of SharePoint 2010. For example, they will determine how sites look, what the
taxonomy is, and what metadata is associated with content. Technical resources refers to
the equipment required: hardware (servers under which SharePoint 2010 operates and that
it communicates with) and software (SharePoint 2010, Office 2010, and associated compo-
nents and technologies), including third-party products. There will be business challenges,
Chapter 2
14 Chapter 2 SharePoint 2010 Project Mantra
such as those brought about by changes in organizational structure, by the clients’ vision,
and by the clients’ processes. There will be external challenges too—for example, those
brought about by legal and economic issues.
Whatever these challenges, your SharePoint 2010 project mantra is critical. The project
mantra shows how the project will evolve and align with your client’s aspirations. It shows
your enthusiasm about SharePoint 2010; your stakeholder group will likely feed off of that
enthusiasm.
Note
A SharePoint project mantra is the combination of an enthusiastic and evangelistic
approach to implementing SharePoint combined with a sound project approach that
is repeatable, and gives the client confidence that the SharePoint implementation will
succeed and meet their expectations. Your project mantra increases in accordance with
the knowledge you have gained of what the client wants (their vision). Additionally, as
the client’s understanding of SharePoint grows in terms of how SharePoint will benefit
their organization, the mantra increases.
A key part of making the mantra meaningful is adopting an evangelistic and realistic
approach to implementing SharePoint 2010. Therefore, as project manager, you don’t
just need the typical organizational and scheduling skills (say, from a methodology such
as Prince). You need to have an enthusiastic approach and appear to your peers and col-
leagues as having high-level skills in defining a collaborative environment that’s responsive

SharePoint 2010 based on the client’s requirements. (This is discussed further in Chapter 5,
“Building Your SharePoint 2010 Team.”) To build your team, you not only need to have an
understanding of planning and controlling a SharePoint 2010 project, but an understanding
of the client’s organization.
By gaining this understanding, you are preparing both yourself and the client. Preparing
yourself allows you to carry out investigations and build your team. Preparing the client
allows you to understand their knowledge so that you both can define your collective
expectations of SharePoint 2010.
For example, you need to determine whether your client has used SharePoint 2010 in the
past or whether they are currently using SharePoint 2010. The answer to this question is
critical, because it will give the project/program manager an immediate indication of the
top-level project scope; therefore, the answer to this key question (and related questions)
must be gathered at your first meeting with the client.