Chapter 2
26 Chapter 2 SharePoint 2010 Project Mantra
Ask the Right Questions
In asking the right questions concerning what the client wants for the SharePoint 2010
implementation, you are setting the scope for the top-level part of project, refining the
project plan, recording key user requirements, and scoping the infrastructure.
The kind of questions you ask are based on the client’s organizational objectives, the con-
tent they carry, the applications they use, and how searching for content is carried out. You
also need to look at how content is formatted and how information is structured.
This is further discussed in Chapter 11, “Making Sure SharePoint 2010 Meets User Require-
ments,” to help you gauge and identify SharePoint 2010 features that can solve specific
challenges.
How to Perform an Effective SharePoint 2010
Implementation
An effective SharePoint 2010 implementation has a quality plan, a project plan, a configura-
tion plan, testing, validation, and scope details. All of these elements describe to the client
(both business and technical) what the SharePoint 2010 implementation is and what has
been agreed and signed off on by all parties addressed in the implementation plan.
The implementation plan has a number of facets, described in Chapter 3, “Content of Your
SharePoint 2010 Plan.”
In essence, all the relevant procedures associated with the SharePoint 2010 installation are
known or adhered to. In addition, as the project manager, you need to sell SharePoint 2010,
and to do that you need to do the following:
•
Find SharePoint 2010 case studies.
•
Identify the client’s Microsoft licensing model.
•
Engage with the client, carry out reviews of the organization, find out what the client
wants to achieve with SharePoint, ascertain the technical infrastructure, find out how
the client’s users collaborate, find out how users work with Web content, and find out

•
Personal and Team Productivity Addresses user enablement, user adoption, and
ease of use
•
Infrastructure Productivity Addresses responsiveness, reduced complexity, and
cost reduction
Negotiate.an.Appropriate.Scope
When I say “scope” here, I am not talking about a SharePoint 2010 technical term. This
book concentrates on the setting up of SharePoint 2010 from a business perspective; there-
fore, don’t expect that the word “scope” is about searching scopes in the SharePoint 2010
Search Crawling feature!
A SharePoint 2010 project scope can be described as follows:
The work that has to be carried out in order to deliver SharePoint 2010, its services, and
specified features and functions; it is the definition of what the project is to accomplish as
well as the budget (time and money) that has been created to achieve the objectives.
Chapter 2
28 Chapter 2 SharePoint 2010 Project Mantra
A good scope needs to be clear and concise. The project name is a good place to begin.
Lack of planning in SharePoint 2010 often results in a failed implementation, and that lack
of planning is often due to a poorly designed project scope.
An effective SharePoint 2010 project name that reads something like “Create a SharePoint
2010 environment to enhance collaborative working in Company XYZ” is much better than
“SharePoint 2010 Environment Project.” More concise is not always more clear. The aim of
the SharePoint 2010 project name is to document the project so that everyone is aware of
what is expected during the life of the project. It also helps provide a vision of where the
project is headed and is the projection of your project mantra.
Here’s the scenario: you get a requirement to provide SharePoint 2010 to a company, and
you have just been appointed to be the SharePoint 2010 project manager. The client has
already looked at the product, but they don’t really know what they want. They are sure
they want a branded My Site, an extranet, and an intranet, and they think they will want

feature in place.
This functionality isn’t available out of the box. You must do some investigating to find
out how best to implement this new feature. You should start by examining the company’s
technological resources to find out whether there’s a way it can be done in house—of
course, that’s not possible in this case. So you need to move on to the second option:
determine whether it’s possible to bring in a developer.
But wait a minute.
By doing this, you are already passing the point of project planning!
Here’s another example.
Company B has hired a SharePoint team to implement SharePoint 2010. That team has a
connection to a third-party development company that will build numerous features for
the product to meet a specific client requirement.
While building the tool, the development company adds additional features that are not
required by the client. It did this because the team wanted to prove they could do it and go
beyond client expectations. Unfortunately, in doing this, they created a bigger collection of
user documentation to cover the unneeded features and the additional training and sup-
port requirements that go along with them.
This scenario is infamously known as feature-scope creep. It means one or more features
not originally contemplated by the client have been added in. The preceding scenario is a
combination of two types of feature-scope creep—customer-pleasing and gold-plating—
Chapter.2
30. Chapter 2 SharePoint 2010 Project Mantra
because there is a desire to please or impress the customer by adding product features
beyond what was requested.
Avoid.Biting.Off.More.Than.You.Can.Chew
The SharePoint 2010 feature set is so large that failing to carefully manage the scope can
easily push you to your limits as a project manager. There are so many interesting things
to do in SharePoint 2010 while working on a particular problem that it’s easy to become
distracted. As well, solutions you put in place in a SharePoint 2010 implementation might
require you to work in maybe three or four areas of the platform. One can easily fall into

Chapter.2
Renegotiate the Scope If Necessary. 31
•
Regroup This book describes procedures that ensure you schedule time to find out
where you are while you are running your SharePoint 2010 project. A well-structured
SharePoint 2010 has a regroup day, once per week. On this day, the project team
takes a rest from implementation, and as such, you take a rest. Use this time to reas-
sess the workload and adjust the schedule.
Renegotiate.the.Scope.If.Necessary
You might find that renegotiating the scope is required for the following reasons:
•
You are in trouble because you have bitten off more than you can chew (as men-
tioned in the previous section).
•
A particular client requirement, while possible to accomplish, might require purchas-
ing a third-party product or developing a feature, which would push the implemen-
tation over budget.
•
Similar to the preceding point,acheiving a particular client requirement might not be
possible within the timeframe established for the product going live.
•
Delivering a particular client requirement might introduce unwarranted risks into the
implementation.
To give you a picture of how you might end up in one of these situations, let’s look at an
example that illustrates the final point in the list.
Client A has requested that the SharePoint 2010 implementation include a record to show
views to sites, documents, lists, and any additions or deletions made. As a SharePoint 2010
practitioner, you suggest using either the SharePoint 2010 auditing feature or the analytics
feature in SharePoint 2010 at the site level. The only problem is that the available hardware
is a single server with a single SQL box without much hard disk space.

•
People The proposal to install SharePoint 2010 includes managing the implementa-
tion going forward. If you find that the people assigned to the task are not capable
of managing a SharePoint 2010 implementation, you need to ensure that the project
scope addresses this shortcoming.
•
Budget Your project is underway. Your SharePoint 2010 implementation is taking
shape. The farm is in place, and some development efforts are underway. The client
indicates there is a change in the budget for the project. In this case, the scope must
be re-evaluated to ensure that the project goals are aligned with the new budget.
Avoid.Having.to.Whittle.Your.Scope.Down.to.Nothing
The scope of your project to implement SharePoint 2010 is crucial. It states the agreement
between you and the client.
The one, overriding scope we’re discussing here is the one for implementing SharePoint
2010 according to the client’s requirements; however, most projects have more than one
scope because there are at least four stages to implementing SharePoint 2010:
Chapter.2
Avoid Having to Whittle Your Scope Down to Nothing. 33
•
Stage 1: Content Assessment and Architecture Review An assessment is con-
ducted of the way the organization works with data and how individuals work
together.

Scope 1: Develop a hierarchy that facilitates information management and
solves information challenges.
•
Stage 2: SharePoint 2010 Site Development A basic SharePoint 2010 site struc-
ture is developed that provides a practical foundation to address the business and
technology issues identified during the content assessment and architecture review.


have to be revisited because the processes of the client are unknown. If the client performs
a large amount of Excel reporting and uses external services through SQL, and Scope 1
is ignored, how will you know that you should install Excel Services and investigate and
implement Business Connectivity Services to enhance the use of SQL data connectivity?
Be careful not to heavily whittle down or eliminate your scopes. At the same time, ensure
that the scopes you do put in place are fully understood by the client.
Your.Best.Project.Tool.Is.Your.Plan
Installing SharePoint 2010 requires a skilled and multifaceted technical team. From a busi-
ness perspective, SharePoint requires careful implementation for a client new to content
collaboration and sharing. It is therefore important that you have a plan that reflects all
the aspects of the installation so that the client understands what is being done, when it is
being done, who is doing it, and how much it costs.
There is little point in assuming there is a project plan when installing SharePoint 2010 and
the client asks “Hey, how is the SharePoint 2010 installation going?”
And the reply is “No problem. It is all in my head.”
Amazing as it might sound, I’ve seen that happen.
There’s good project engineering and bad project engineering. Good project engineering
leads to tangible progress. Bad project engineering hinders progress.
In the past, project managers have generally used e-mail as the top collaborative tool. So
you were likely to hear conversations like the following:
“Where is that business case?”
“Check my e-mail.”
“What about those project risks?”
“Ahh, let’s check my e-mail.”
“Can you give me your status report on the project, please?”
“No problem. Let me check my e-mail.”
That approach can work, I suppose. However, if you are running a project team where
information needs to be updated, collated, and reviewed by more than one person, that is
not a great way to run your project. So ensure that you have the necessary tools available
for proper communication. SharePoint 2010 is perfect for this because it enables you to

By providing tools to automate project management processes For example,
you can create a Risk And Issues log and have automated alert processing for it. In
this case, when a project member submits a risk it can be automatically e-mailed to
the project manager for action and then routed as part of the Quality Plan document
in a document library. Risk items in a SharePoint 2010 list can be connected to physi-
cal data in a document library.
•
By providing project reporting using dashboards SharePoint 2010 provides rich
and detailed information by graphically reporting content information using built-in
charts.