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.

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

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

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

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-

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

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.