Help
from Chapter 1
Project Planning in SharePoint
Microsoft SharePoint 2010 is a strategic technology that allows people to seamlessly connect with each other in terms of centralized content management. As a collaborative tool, SharePoint can be used by anyone, and it can be installed and configured quickly—usually to meet a ‘specific requirement’. And this “specific requirement” is typically based on one person’s perception that installing technology will solve a client request to get a product that allows teams to work closer together. But installation is not implementation.
Implementation of a product follows a plan. And that plan means pulling in resources to do that plan. You will need people, hardware, and software. You will need to define how SharePoint should be used by mapping it to user requirements, design its physical structure, and then implement SharePoint so that it will match user requirements.
To do this, you will need not only a strategy for planning, designing, building, and deploying SharePoint. That means you need a standardized method so that all SharePoint implementations follow the same route. Going down the route of installing SharePoint with little planning will produce a SharePoint platform that is ineffective, unreliable with low user acceptance.
The purpose of this book is to help you create a standardized approach for implementing SharePoint 2010, not directly from a technical perspective, but by explaining the phases required, the people required, the resources required, and wrapping this using typical project management methods. Generally, technical people shy away because they want the nuts and bolts. Business people shy away because they want productivity. This book brings them both together to understand how to meet the common goal: true implementation of SharePoint.
Here is an example, of how going down the route of providing SharePoint without planning courts disaster. I was working in a team whose purpose was to implement a content management system; this team was a mixture of IT professionals and technical staff. A meeting was held to choose the system of choice. A lot of administrators were there—server admins, Active Directory admins, Microsoft Exchange admins—a lot of egos in one room. (Strangely but not surprisingly, no one from the business attended.) The meeting kicked off with gusto.
One member of the technical team—a Microsoft Windows Server admin—stood up and in a loud voice stated the following:
“Hey! We got SharePoint! It has got blogs, wikis, workspaces, team sites, and search—let us have all of that. We don't need anyone to help us. It is easy to set up, and we’ll just learn as we use it. We only need a site or two to store the documents in. If the users want in, we’ll give them some sites to play with.”
Does that sound OK? Well, what I explained was that the vast majority of SharePoint implementations have been based on exactly the scenario depicted by the admin’s comments: project planning in a vacuum
What’s wrong with that? To best explain it, let’s take that scenario and add a couple of months to it:
“Hey! We have 20 sites now. Lots of content. Not sure what we are doing. Not sure how it all connects together. We think we know how to manage it, though we don’t know how big it will get. And we also can’t control how big it gets because we are not entirely sure who is using it and why.”
Adopting Project Governance in SharePoint Is Vital
Before I state why it is important that you have project governance, it is best to describe the key premise of project governance and the hurdles you must get over in implementing it. The first hurdle is that you must engage the stakeholders (the person or group in organization affected or that has a direct interest in the project—also known as the client) on the topic. There is absolutely no point in explaining the wonderful aspects of SharePoint (and how it will sort out all of the company’s woes by sharing data and establishing a framework for effective communication) unless the stakeholders have a grasp of what it means to have project governance. Stakeholder buy-in is the biggest factor concerning the adoption of SharePoint (or, in fact, any new technology).
Why is stakeholder buy-in important? All stakeholders need to know what’s happening, when it’s happening, and why it is happening. They will need clear about who is involved, the stages of SharePoint implementation and what they entail, what needs to be achieved along the way, and how you’ll reach key decisions and outcomes. It is crucial to remember the aims and objectives, protect the special qualities of the design, and hold on to the “golden thread” that will make the project successful and matches the client’s vision of SharePoint.
Some SharePoint project managers I have met are afraid to approach their clients to explain the concept of project governance; they feel the client will not want to implement SharePoint if doing so will alter the way people do things. Interestingly, it is not the implementation of SharePoint that invokes project governance, it is the implementation of SharePoint that allows people to work more productively.
A company called me up stating that they had been given SharePoint but had no idea how they got it or what to do with it. They were now having a nightmare controlling the management of the platform, especially since they wanted to rationalize their desktop technologies. I visited the company and found that technicians had decided to install it for a part of the organization where the users were not SharePoint trained, and now the entire organization had some use of SharePoint but that use was not quantified. Several weeks ensued of discussing how it is important to engage with the organization in terms of gathering requirements first so that they are clear on who does what and why, and on what equipment and where, for a SharePoint implementation. Had this been done at the beginning (meaning the technicians had engaged with the organization) things would have been much better.
How Does SharePoint 2010 Help Project Management?
Effective SharePoint project management will work only if the client’s aspirations map to the Project or Program Manager’s (PM) understanding of their aspirations.
Through the use of project data management (using SharePoint 2010 features and tools such as reporting tools, data relevance, security, auditing, traceability, and centralization of data), the organization will be able to use SharePoint 2010 to increase team collaboration, create a standardized process, and ensure that the PMs’ project mantra is intact. (We’ll have a look at Project Mantra later.)
SharePoint 2010 allows project managers and their teams to create sites that serve as a Project Management Office (PMO). This provides for the centralization of data and can be a massive win scenario for the client. Documents and other information in a PMO can be centrally stored and maintained, effectively standardizing and streamlining communications. Project managers can use document and list repositories to create a streamlined, one-stop shop for SharePoint documentation and communications.. The goal is to carry out a good SharePoint implementation is through a repeatable and standardized method of documentation control bound to project processes concerning document management. SharePoint 2010 is also directly integrated with Microsoft Office 2010 applications such as Microsoft Word, Excel, PowerPoint, Outlook, Access, Visio, and more. It is also directly integrated with the Windows operating system and with popular Web tools and technologies.
SharePoint 2010 has finely tuned access levels so that access to data can be limited. Permissions have been enhanced beyond the levels provided by SharePoint 2007 (for example, more out-of-the-box ”permissioning,” as well as an easier way to define and customize those permissions to suit the content being provided).
One of the most compelling aspects of SharePoint 2010 is the unified infrastructure approach, which entails having one platform with multiple solutions. This unified infrastructure results in easier integration and enhanced connectivity to multiple device and browser types.
What Is Project Governance in Relation to Content Management Systems?
Content management systems rely on project governance to deliver, support, and manage the platform. As a content management system, SharePoint makes project governance even more crucial because SharePoint is an enterprise system. It provides a technology platform that enables the organization to integrate and coordinate their business processes. It will provide a single system that is central to the organization and ensure that information can be shared across all functional levels and management hierarchies. It connects to all manner of Microsoft technologies and components. Additionally, these connected technologies and components could have their own project plans for implementation; they can also run on their own schedules that have been created and managed by their support and implementation teams.
Project governance techniques adopted in large organizations often use methodologies such as PRINCE, Agile, or PMBOK (Project Management Body of Knowledge). Unfortunately, when governance is applied to SharePoint, there is no standard methodology because SharePoint is based largely on the organization’s understanding and application of the product. Companies rarely look (or will not take the time to look) for a standard method of deploying a product such as SharePoint, and they might often look to external consultants and project managers to provide governance.
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 outputs of project governance probably will be meaningless, not clearly understood, not continually applied to the implemented 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, configured, 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:
- Research the Market for SharePoint People
- Get the SharePoint People
- Purchase Vanilla Ice Cream
- 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 covering Investigation and Design, 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? Here are four main reasons.
Accountability
There are people who need to be assigned responsibility for actions, decisions, and policies 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; and project management helps this by defining the what, when, why, and where of this implementation.
Sustainability
While preserving the integrity of the platform delivered to the organization, the platform must meet present needs, but also future organizational requirements. SharePoint 2010 needs to be managed and governed to grow. Project management helps by providing methods so that issues concerning SharePoint’s economic (user requirements in terms of added features or products), social (the ability to enhance and connect people), and environment (the infrastructure of SharePoint can be scaled, for example) are protected and managed.
Resiliency
A SharePoint implementation needs to be robust to survive. SharePoint must have the ability to provide and maintain an acceptable level of service in the face of faults and challenges to normal operation. Project management provides processes such as configuration management, planning for backup, disaster recovery, monitoring, and performance levels.
Supportability
SharePoint needs to be looked after. Project management defines the quality-control measures to be enacted by the team that is responsible for the SharePoint implementation.
As a Project Manager you need to ensure that when describing the four above elements to the client that they understand there is a timeline to put in SharePoint. You cannot let the client put together the timeline themselves, because they will start by reasoning that anything they don’t do is easy to do. Designing a SharePoint platform for worldwide operations cannot be completed in two weeks, for example.
I had a client who insisted that they wanted SharePoint in one week—yes, one week—for a team of 20 people in the company. I asked if any of the 20 people had ever seen SharePoint. No. I asked if any of the 20 people worked together on the same information as a team. No. I asked who would look after SharePoint when it was built. They said they would. I asked a bunch more questions. I think that the killer question was this one: Who is going to manage SharePoint? Now, it’s not to say you can’t install SharePoint in a week, not to 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 put 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, educate the client, put together a plan, agree on the plan—its feasibility--through to implementation? 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.
Learn more about this topic from Managing and Implementing Microsoft® SharePoint® 2010 Projects.
With this practical guide, you’ll gain project management best practices for implementing SharePoint 2010 in your organization, and learn expert techniques for tuning your system to match the communication and collaboration needs of your users.
