Quản lý và thực hiện các dự án Microsoft SharePoint 2010 - p 6 pptx

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

how users search for data. This is called “gathering user requirements.”
•
Plan your deployment carefully.
•
Educate and demonstrate. This fosters client adoption.
Chapter.2
Negotiate an Appropriate Scope. 27
Successful SharePoint 2010 implementations can be guaranteed to have quite a few of the
following attributes:
•
They have a good proposal.
•
They start with a good work plan and assume minor changes will occur.
•
They are structured into smaller projects for the timeframe and ensure that the scope
of the project does not blow out of proportion.
•
They make the SharePoint 2010 project sound like fun.
•
They have a resourceful SharePoint 2010 architect.
•
They strike a balance between planning and doing.
•
They have contingency plans and plan for the worst case in performing critical tasks.
•
The team members are clear about objectives and their terms of reference.
The SharePoint 2010 implementation realizes and addresses three areas of productivity:
•
Organizational Productivity Addresses process automation, information access,
and roles

•
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

document management features from SharePoint 2010 Enterprise edition. When asked for
the scope, the client states it is to “Build and deliver a SharePoint 2010 instance.”
Clearly that is not a good scope. To correct this as project manager, you need to create that
SharePoint 2010 project mantra and to get the client to review the scope. What is missing is
the Quality Plan, which describes the how and why of the project. This is a direct output of
the SharePoint 2010 project mantra.
There are three critical parts to quality planning that relate directly to the work you are
expected to do, and these are contained in the Quality Plan that management will sign off
on. The Quality Plan defines the product scope. For example, a product scope for Share-
Point 2010 to the organization would be similar to the following statement:
A collaborative technology that enables people to easily create and manage their own
Web sites.
Note
Creating an appropriate project scope ensures that the client understands what they
are going to get and why they are using SharePoint 2010 to solve the myriad issues
that have been stated. You should try to showcase successful SharePoint 2010 imple-
mentations and review Microsoft case studies as part of the project scope. You will find
many examples at />Chapter.2
Deciding What Not to Do Is As Important As Deciding What to Do. 29
Deciding.What.Not.to.Do.Is.As.Important.As.Deciding.
What.to.Do
A famous quote regarding SharePoint 2010 is, “If you need to have something happen in
SharePoint 2010, the answer is never ‘No.’ The question is, ‘Do you have money to spend if
you get to a No situation?’.” Here’s an example of how this observation might play out:
Company A wants to adopt a feature to enhance People Search in SharePoint so that when
someone searches for an individual, the results display a small list of recent documents that
person has created. The reason the company wants this particular search behavior is that it
likes to have open access to documents created and to be transparent with regard to who
has authored the documents. The company doesn’t have any internal developers familiar
with SharePoint, and the budget is tight. However, the client is adamant about having this

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

the trap of discovering lots of interesting and fun things to do.
For example, suppose that as project manager you must provide the ability for informa-
tion from the user directory to be available in SharePoint 2010. You think, “OK, that’s an
easy one. I’ll focus on the User Profiles section of SharePoint 2010.” Be careful—there’s a lot
going on in that area, more than just putting in some fancy user properties and working
with user metadata. Before long, you’ll find yourself falling into the following traps:
•
Working extremely long hours
•
Running into a brick wall because some customization is required
•
Charging out for developers
These actions add increased costs to the project and increase project timeframe. And you
might be tempted to justify this to the client as exceeding the scope. But remember, that
the objective of the project manager is to deliver what the client wants on time and at the
lowest possible cost. You can do this by keeping the following guidelines in mind:
•
Pace yourself Don’t get stressed and don’t overwork. Doing that will lead to
fatigue, which doesn’t make for an effective SharePoint 2010 evangelist!
•
If you are in trouble, renegotiate the deadline Tell the client what is going
on. Ensure that they know what you need and why you need it. The client will
understand.
•
You are not the god or goddess of your SharePoint 2010 implementation
clan There are enormous areas to work with in SharePoint 2010. If you are in trou-
ble, get help. Don’t attempt to sort it out yourself because that might only increase
the project timeframe. Don’t gloss over an obstacle by believing that you will get to
it later. If you do that, you are not even following a schedule. If you don’t delegate
tasks and manage them, it will just cause you more stress!

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.

You explain to the client that the hardware might not be up to the challenge and that it
might be necessary to take one or more of the following actions before the desired func-
tionality can be implemented:
•
The hardware must be sufficiently upgraded (which requires more money and more
configuration time).
•
A third-party product must be procured and connected to SharePoint 2010 at a later
stage. (This doesn’t directly affect immediate implementation of some functions, but
it does introduce additional support issues, costs, and most likely implementing a
separate product.)
Chapter.2
32. Chapter 2 SharePoint 2010 Project Mantra
•
Commit to the client request, but have the client agree to accept the risks to the
hardware.
•
Omit the feature or features that result in extra costs (time or money), and push those
features into a category of items to be investigated at a later date.
What you have just done is carried out a quick evaluation and weighted the outcomes of
each alternative. The key thing here is that the client is involved and has a say in which of
the alternatives is satisfactory. This is an example of renegotiating the scope, and it should
be done for every key aspect of the implementation plan.
Let’s analyze a few other reasons you might need to renegotiate the project scope:
•
Hardware The existing hardware might be a reason to renegotiate scope if the
SharePoint 2010 implementation is going to be a medium farm (more than one
front-end server, application server, and attached to an SQL cluster) and you find that
there is simply not enough capacity in the infrastructure (meaning not enough serv-
ers are available or the available servers are not up to the job).

•
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.


Scope 2: Design a physical site framework and taxonomy, and build relevant
SharePoint 2010 portal sites.
•
Stage 3: Portal Pilot SharePoint 2010 is installed; the solution is implemented and
tested in the environment.

Scope 3: Provide training and awareness sessions to users and support teams.
•
Stage 4: The SharePoint 2010 portal is operational.

Scope 4: Provide best practices for management and governance.
Even though there are scopes at every stage of this implementation, it is important to state
clearly and without ambiguity the absolute lowest level of what you can achieve. For exam-
ple, consider the scope of Stage 1 of a SharePoint 2010 implementation which is somewhat
nebulous:
“Develop a hierarchy that facilitates information management and solves information
challenges.”
We need to examine that scope closely. The real meaning of that scope is the you’re an
investigation of the current work processes of the organization (that is, an understanding
of how the client personnel communicate and collaborate with content). Based on under-
standing these processes, your stated scope identifies how SharePoint 2010 will be imple-
mented to solve the client’s information challenges.
For example, suppose that the client needs to get SharePoint 2010 up and running as
quickly as possible. Because of the time constraints, the client suggests removing the Stage
1 scope. If this scope is removed, there is a serious risk that SharePoint 2010 will not be
implemented around any well-planned design or in a way that aligns with any client work
processes. Without this scope, the scopes for stages 2, 3, and 4 become either redundant
or meaningless. Scope 2 (technically design and implement SharePoint 2010) would then
Chapter.2
34. Chapter 2 SharePoint 2010 Project Mantra

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

Chapter 2
Your Best Project Tool Is Your Plan 35
centralize, share, and manage all aspects of your project. This functionality can be show-
cased to your client as you work together on the project.
Remember that your SharePoint 2010 Project Plan defines the what, when, and why on the
project. In Chapter 3, “Content of Your SharePoint Project Plan,” I will describe the elements
of your plan and how you can place your SharePoint 2010 Project Plan on an Implementa-
tion site, managing it using SharePoint 2010 features and functionality.
SharePoint 2010 provides you with tools that ensure your project can be managed effec-
tively. SharePoint 2010 helps you accomplish this in the following ways:
•
By centralizing your project documents and project communication You can
easily create document libraries to store key project items such as the Business Case,
Project Quality Plans, Risk Management Lists, and Configuration Management Plans.
In fact, every form and procedure in this book can be created as a list of information.
•
By integrating existing project management tools (for example, Project Pro-
fessional 2010) SharePoint 2010 integrates with Project Professional 2010 so that
working on a Work Breakdown Schedule (WBS) is easy.
Note
Project Professional 2010 is designed to assist project managers in developing
plans, assigning resources to tasks, tracking progress, managing budgets and
analyzing workloads. The application creates critical path schedules, although
critical chain and event chain methodology third-party add-ons are available.
Schedules can be resource leveled, and chains are visualized in a Gantt chart.
Additionally, it can recognize different classes of users. These different classes of
users can have differing access levels to projects, views, and other data. Custom
objects such as calendars, views, tables, filters and fields are stored in an enter-
prise global which is shared by all users.
•

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.