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

Chapter 2
36 Chapter 2 SharePoint 2010 Project Mantra
Note
A dashboard is an executive information system user interface that (similar
to an automobile’s dashboard) is designed to present information in an easy-
to-read format. For example, SharePoint can obtain information from one or
more applications that may be running, and from one or more remote sites
on the Web and present it as though it all came from the same source on a
SharePoint site. SharePoint can provide Business Intelligence Dashboards and
Key Performance Indicators using internal data from lists, or from Excel Spread-
sheets, Access, Visio, SQL Reporting Services, and much more. For more infor-
mation, see this screencast: />Using-Microsoft-Office-SharePoint-Server-to-Create-BI-Dashboards-and-KPIs/.
All of these tools improve team collaboration (which is the heart of SharePoint 2010). Later
in this book, I’ll show you the methods by which these tools can be used in your SharePoint
2010 one-stop shop.
Summary
The SharePoint 2010 project mantra is about knowing the product, knowing what your client
vision is, knowing how the organization operates, and being enthusiastic and evangelistic
in your approach to providing the platform. Your client feeds off this mantra, and from it
you will both have a shared vision of how SharePoint 2010 will look, feel, and work in the
organization.
A well-planned project includes an appropriate scope. This scope defines the implementa-
tion, and a good implementation comes from proper planning. Planning is the key element—
I’ll revisit the topic in more detail later in the book. For now, here are a few planning tips:
•
Come up with an accurate and detailed plan (one that includes tasks and
Gantt chart).
•
Review your plan weekly. Use your Gantt chart to gauge your long-term progress.
•
Revise and rewrite your plan on a weekly basis in the form of a to-do list.

•
State your plan as a high-level WBS, and then group it into several tasks per grouped
area.
•
Use your to-do list to manage your week-to-week activities.
•
Assess your progress weekly, even if only to measure what you haven’t done.
37
Chapter 3
Content of Your SharePoint 2010
Project Plan
Before You Get Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Create the SharePoint 2010 Quality Plan . . . . . . . . . . . . . 40
Introducing the SharePoint Project Plan . . . . . . . . . . . . . 51
The Plan Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
The Build Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
The Operate Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Program Schedules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Resource Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Before You Get Started
Y
ou need to understand the concept of a SharePoint Implementation Plan. A Share-
Point Quality Plan and SharePoint Project Plan make up a SharePoint Implementation
Plan. The Quality Plan and Project Plan are separate documents, and this chapter will
explain the contents of each and how they are connected. The combined output of these
creates a SharePoint Implementation Plan. The Quality Plan details the who and how of a
SharePoint 2010 implementation. The Project Plan details the what and when. You cannot
have a Project Plan without a Quality Plan, because the Quality Plan describes, at the very
least, the people who will be carrying out the project tasks detailed in the Project Plan.

The project manager must be aware of the procedures that are included in the life cycle of
a SharePoint 2010 implementation project and of the forms that need to be collated and
managed. Figure 3-1 shows the procedures and how they are connected.
This chapter concentrates on the production of the various plans and the administrative
activities related to those plans. By the end of this chapter, you should have a thorough
understanding of the content of a SharePoint 2010 Implementation Plan and the proce-
dures, forms, and tools required to support it.
To support your adventure through these procedures, you need to create two key forms:
the Project Startup Checklist and the Project Closure Checklist. Figure 3-2 illustrates the
Project Startup Checklist.
Chapter.3
38. Chapter 3 Content of Your SharePoint 2010 Project Plan
Production of Plans:
SharePoint Project Plan
SharePoint Quality Plan
Administration Activities:
File Referencing System
(e.g., a SharePoint Project Site)
Procurement Procedure
Contract Hire Staff
Support Activities:
Document and Data Controll
Configuration Management
Software Build Definition
Technical Reviewing
Control of Test Equipment
Control of Software Tools
Controls of Nonconforming Items
Requirement and System
Specification Verification

• Risk Management Plan
• Configuration Management Plan
• Subcontract Management Plan
• Verification and Validation Plan
The following can be separated or part
of the SharePoint Quality Plan
Implementation Plan
Control of Technical Records
Delivery Documentation
Project Archiving
Project Closure
Project Planning and Control
Contract Review
Project Startup
SharePoint Installation Plan
Control of SharePoint Testing – Software
and Hardware Inspection of Software
and Hardware Items
Figure.3-1. SharePoint 2010 Project planning and control life cycle.
Chapter.3
Before You Get Started. 39
Considerations
Review Contract Requirements
Have the commercial aspects been addressed?
Have the technical aspects been addressed?
Have the quality aspects been addressed?
Has the client acknowledged the contract receipt?
Is the client familiar with the contract requirements?
Appointment of Staff
Have the “technical authority” individual(s) been identified?

Has the Project Team been recruited?
Have the “Terms of Reference” been generated for the project team?
Have the approval and authorization authorities been identified?
Have the resource requirements been identified?
Establish Project Interfaces
Have the commercial and purchasing procedures been identified?
Are the computer facilities for the project team established?
Has the project documentation policy been created?
Has the filing policy (document and data control) been established?
Produce Plans
Has the SharePoint Quality plan been produced?
Has the SharePoint Project plan been produced?
Has the Subcontractor Management plan been produced?
Has the Risk Management plan been produced?
Has the Configuration Management plan been produced?
Verify and Validate
Have technical reviews and internal testing plans been identified?
Are the subcontractor SharePoint deliverables acceptable?
Has the client accepted the SharePoint deliverables?
SharePoint Project Startup Checklist
SharePoint Project Title Project Number
Project Manager Name Date
Y N N/A Reference
Figure.3-2. Project Startup Checklist.
Chapter.3
40. Chapter 3 Content of Your SharePoint 2010 Project Plan
As you can see, each section of this checklist relates to the plan you are drawing up and is
used as a guide to ensure you are ready to carry out the work. The checklist also informs
the client what pieces of work have been done, have not been done, and do not need to
be done. The Project Closure Checklist will be detailed in Chapter 15, “SharePoint 2010 Is

Implemented, Now What?”
Create.the.SharePoint.2010.Quality.Plan
The SharePoint 2010 Project Plan (which we will examine in detail in the section “Introduc-
ing the SharePoint Project Plan,” on page 51) should ensure that the contractual require-
ments of the project are completely fulfilled. On a large project, a project plan might be
produced for each identified subsystem that is part of the overall product.
The SharePoint 2010 Project Plan complements the SharePoint 2010 Quality Plan and
duplication of information or instructions from one plan to the other should be avoided.
In simple terms, the SharePoint 2010 Project Plan details the what, why, where, and when
aspects. The Quality Plan determines the project policies and the aspects of who and how.
During your initial meetings with the client, you should identify the client’s requirements.
These requirements are then used to produce the SharePoint 2010 Quality Plan. This
plan details the business requirements and specifies how the project will deliver these
requirements.
Here’s a real-life example of the importance of a Quality Plan. I was called to fix a Share-
Point implementation project where the project manager (who was no longer with the
company) decided that the only thing required was a couple of technicians, a list of instruc-
tions on how to install SharePoint, and someone to sign off on the installation. Because no
scoping of the project was done to find out how SharePoint should be used, how it would
grow with the organization, how it should be controlled, or what should be done if there
were problems in meeting future client requirements, the SharePoint delivery failed to
perform as the client felt it should and the users did not accept it. They blamed SharePoint
for virtually every problem because it was an easy target—no one liked it. I was successful
in fixing the implementation, but it was a slow and painful process for the organization.
The users had to re-engage with SharePoint, but through the process of gathering user
requirements, they felt more empowered. Stressing the need for a Quality Plan to bolster
a carefully defined Project Plan that includes design tasks (for example, gathering user
requirements) is key to a successful SharePoint implementation. The SharePoint 2010
Quality Plan includes the following:
Chapter.3

Create the SharePoint 2010 Quality Plan. 41
•
Project organization and responsibilities
•
Risk management
•
Subcontract management
•
Design and development life cycle
•
Configuration management
•
Verification and validation plans
•
Acceptance and delivery
You might be thinking, “OK, when I install SharePoint 2010, I can do all of that at the same
time or ignore it.” If you choose to proceed this way, you will be responsible for signing off
on all the implementation to the client’s satisfaction, or you will be assuming the client does
not need to be satisfied. I think that’s a mistake. You would be very unlucky if you were
pushed to provide a companywide SharePoint 2010 solution and there’s no team currently
looking after the technology and no person who knows about it and how it was designed
in the first place. Things are not going to go very well if you adopt that method!
For example, an exasperated client once called me to help them properly engage with
a SharePoint installation. The installation was carried out by a SharePoint consultant who
delivered SharePoint to the company and then left the company without handing over
SharePoint to the company technical team. The technical team members had no training in
SharePoint and were very busy managing other technologies. Users were accessing the
SharePoint installation but were concerned about the lack of support. A Quality Plan
defines who will look after SharePoint and who will deliver it, and the Project Plan defines
when it will take place and who takes control of SharePoint in terms of support, including

training.
To build a SharePoint 2010 Quality Plan, you need to use the Project Startup Checklist (see
Figure 3-2). You can find the Quality Plan on the checklist in the section “Produce Plans.”
Once a Quality Plan draft is completed, you should indicate a Y (for “yes”) in the Y column
and give an identifier so that people can locate the Quality Plan in the reference column. So
continuing on from the headings given earlier, you would be able to create a Quality Plan.
Chapter.3
42. Chapter 3 Content of Your SharePoint 2010 Project Plan
Project.Organization.and.Responsibilities
The SharePoint 2010 Quality Plan needs to be clearly defined with the help of the business
stakeholders. To do this, you need to delineate the relevant areas of the business—first, you
identify who the key stakeholders are, and then identify who on the project team needs to
interface with the technical and business teams that will be supporting the product.
Technical teams include the people who administer SharePoint and manage the servers
that provide SharePoint services. Business teams are the people who support SharePoint
team sites and the content on those sites. These business and technical teams have the
responsibilities shown in the checklist. For example, one technical team could be called the
SQL Database Team. In this case, one of the specific responsibilities the team has related
to the SharePoint implementation is looking after the SharePoint SQL databases. Likewise,
business teams also have responsibilities. For example, you might have a business team
responsible for testing a SharePoint site or a SharePoint feature. Responsibilities create the
objectives (for example, in order for the business team to test SharePoint, team members
need SharePoint training). You should make a point of recording the responsibilities and
objectives of each member in the project organization. To formulate a work schedule, you
need to ensure that you know who is responsible for what in the business. For SharePoint
2010, there are two camps you must deal with. The first camp includes personnel who look
after and support the technical infrastructure—for example, Active Directory, Microsoft SQL
Server, Microsoft Exchange, the firewall and security elements, and so on. This is the techni-
cal camp. Then there is the business camp. The people in the business camp will shape your
SharePoint 2010 environment; they will tell you what needs to be in the environment, how

it will function, who will own the implementation, who will test it, and so on.
First let’s make a list of groups within those two camps, and then list the name of the per-
son accountable for a particular service in one of the groups, as well as their contact details.
This is the first step toward forming the Project Startup Checklist.
Table 3-1 is an example of a list you can compile if you need to ascertain who the stake-
holders are and who the business and technical leads are. You can also include (as I have
done) key people who have a stake in the back-end connectivity to SharePoint 2010 or
people who are good contacts to have. Note that you need to update this list regularly and
ensure that all parties listed know who is on this list. Once this list is created, you need to
use it in your Project Plan Work Breakdown Structure (which is where you list the tasks and
who should be assigned those tasks).
Chapter.3
Create the SharePoint 2010 Quality Plan. 43
Table.3-1. Project Title: SharePoint 2010 Implementation Project XYZ
Name Job.Title Responsibilities
Walter Harp Head of Company Stakeholder
Kim Akers Communications Stakeholder
David Pelton Technical Manager Decision Maker
Charlie Herb Business Manager Decision Maker
Katie Jordan SQL Lead Database
Kevin Kelly AD Lead Active Directory
Jerry Orman Messaging Lead Exchange
Howard Gonzalez Infrastructure Lead Servers
Once you have identified who is responsible for what in the company, it is time to start
involving your own team (meaning yourself, the architect, the business analyst, and oth-
ers). The Project Startup Checklist refers to your team-building efforts as the “Appointment
of Project Staff.” This information is used to construct the Project Responsibilities column
shown in Table 3-1.
Note that you do not need to list everyone on the technical team because it’s the respon-
sibility of the technical manager, as the decision maker, to identify who they are. For Share-

Point 2010, you must know who is currently responsible for the infrastructure (including
security), messaging, user data store, and database. And because we are talking about
SharePoint 2010, the infrastructure includes technologies such as SQL Server, Exchange
Server, Active Directory, and Forefront TMG.
After this exercise, your team list could look like Table 3-2.
Table.3-2. Project Title: SharePoint 2010 Implementation Project XYZ
Name Job.Title Responsibilities
Walter Harp Head of Company Stakeholder
Kim Akers Communications Stakeholder
David Pelton Technical Manager Decision Maker
Charlie Herb Business Manager Decision Maker
Katie Jordan SQL Lead Database
Kevin Kelly AD Lead Active Directory
Jerry Orman Messaging Lead Exchange
Howard Gonzalez Infrastructure Lead Servers
Your Name
Project Manager Project Team
Holly Dickson SharePoint 2010 Architect Project Team
Chapter.3
44. Chapter 3 Content of Your SharePoint 2010 Project Plan
Risk.Management
You need to systematically identify and assess the potential risks to the project. By this, I
mean risks to the entire project, not to some internal and technical component of Share-
Point 2010 (which is covered in the section “Configuration Management,” on page 48). Risks
to the implementation of the project are not the same as risks related to SharePoint Gover-
nance. For example, a lack of content audit compliancy or inadequate levels of SharePoint
content access are borne out of a lack of SharePoint Governance. Methods ensuring struc-
tured SharePoint Governance are discussed in detail in Chapter 9, “SharePoint Governance.”
As you might recall from the project mantra mentioned in Chapter 2, the client has a
vision of the SharePoint 2010 implementation as benefitting the organization by providing

a boost in productivity. If there is a risk that any of the following client benefits cannot be
attained, it must be communicated to everyone in the list of stakeholders (listed in the sec-
tion “Project Organization and Responsibilities” on page 42).
•
Operational Productivity Addresses process automation, information access, and
roles. This is a client-productivity goal—individuals in the organization should be able
to work more efficiently using SharePoint 2010.
Example: Individuals intend to automate several activities concerning document
retention and expiration. They want to be able to control access to documents and
set up permissions to access relevant documents. This is a key objective of the orga-
nization using SharePoint 2010. Without this in place, there is a serious risk to the
effectiveness of the platform and its usefulness.
•
Personal and Team Productivity Addresses user enablement, user adoption, and
ease of use. This is a client-productivity goal—individuals in the organization should
be able to quickly understand how to use SharePoint in meeting their information
objectives.
Example: Users have never seen SharePoint 2010. If the users are not trained in the
platform, there is a serious risk that they will not be able to easily manage their elec-
tronic data or sites holding that data.
•
Infrastructure Productivity Addresses responsiveness, reduced complexity, and
reduced Total Cost of Ownership (TCO). This is a client and technical authority pro-
ductivity goal. SharePoint as a platform should be responsive and resilient, and it
should reduce TCO—for example, reduce hardware and software (licensing) costs.
Example: The client expects a high level of performance concerning the SharePoint
infrastructure—for example, the client expects the percentage of users who can be
active on SharePoint is on target—as well as concurrency, and they expect that Share-
Point 2010 can handle an agreed-upon user load. If SharePoint does not perform to
the agreed-upon target, there is a question as to how effective the solution will be to

the organization.
Chapter 3
Create the SharePoint 2010 Quality Plan 45
In any organization where SharePoint 2010 is implemented, you need to adopt a risk man-
agement process, and a document stating that the process should be referenced in the
“Risk Management” section of the Quality Plan.
A risk management procedure for SharePoint 2010 is available at ffevelyn.
com.
The section of the SharePoint 2010 Quality Plan titled “Risk Management” details the top-
level risks and what strategy will be taken to mitigate these risks.
Subcontract Management
At some point in the implementation of SharePoint 2010, you might require third-party aid.
For example, you might want to bring in a developer team to customize SharePoint 2010,
or you might need to provide a third-party feature for backup tasks, restore functions, and
so forth.
Before going down this route, you need to ensure that there is a need to bring in a party
outside of the selected project team. Don’t get caught in the syndrome known as “devel-
oping beyond SharePoint 2010.” In any uncontrolled development, whether software or
hardware, falling prey to such a syndrome can have a serious negative impact on the pro-
ductivity of the platform, resulting in SharePoint 2010 implementation pain to the client.
The topic of SharePoint 2010 subcontracts is normally raised when it is considered, for whatever
reasons, more effective to place discrete packages of work relating to an existing SharePoint
2010 environment in the hands of a company outside of the organization. The Share-
Point 2010 Quality Plan needs to state that it will or will not advocate the use of these
services as part of the implementation. If the service is required, this section of the Quality
Plan needs to state the nature of the engagement with the subcontracts and specify that
the project manager will follow organizational principles and rules governing the hire of
such contracts.
You’ll find a blog article that discusses a Subcontract Management procedure that can be
applied to SharePoint at .

Design and Development Life Cycle
A number of factors can discourage the design and development of a SharePoint 2010
implementation: it costs money, it consumes the time of the most highly skilled people,
the time spent in producing the plan can delay the start of using it, the life cycle could
cause inflexibility in the implementation approach, and estimation of the life cycle is dif-
ficult. These objections should not detract from the importance of proper design and
development.