En la pagina del Sharepoint Magazine encontre este articulo interesante sobre los 10 pasos para una implementacion exitosa segun esta publicacion realizada por el muy famoso Joel Olsen.
Les copio una parte del articulo para que puedan leerla.
A common word that keeps popping up around SharePoint deployments is “Governance,” as if it will help you avoid chaos and have a more successful deployment. The answer is, when executed properly, it can. Governance consists of rules and guidelines for designing a service offering. Its goals aren’t to shut down a deployment and make it take forever, but, rather, to find balance in user flexibility while providing for IT oversight. Here are 10 key steps to help you be successful in designing your SharePoint deployment.
1. Confront Reality
Understanding where your company is in its maturity of SharePoint can better help you understand the next steps, as well as the challenges your corporate culture will face. Confronting reality is something that can be done at any time during a deployment. Often, it isn’t a greenfield deployment; there is already something in place, and that current solution may or may not be working. Why?
An assessment of your Intranet, collaborative platforms, file sharing platforms and usage scenarios will help you understand where to begin. It’s time to wake up and see that there are better ways to do things, and you may need resources to accomplish this.
You will find that making any changes will affect the balance of empowerment for the business, and give up some control from IT. It may feel unnatural at first. Doing this with the out-of-the-box deployment often is where companies start with SharePoint. They find that giving the business site collections to create projects, workspaces and team sites makes them very happy.
The balance can get out of control when the business is left with a default install. The default install has faults. There are no quotas enabled, and all data goes into one content database that continues to grow until it fills the drive. Auditing is off, versions aren’t enabled and chaos can reign quite easily without some forethought about the answers to these questions. The newbie mistake is to decide to figure out many of these things later. Later comes too late, when the environment is down or, worse, never backed up. Again, it’s something that by default isn’t automatically configured. Backing up the drives isn’t good enough. The data is in databases, and the binaries and development assets are on the disks, while the configuration is spread across the system. This might seem obvious to those running the system for awhile, but unfortunately it is a common mistake.
2. Create a Governance Plan
Before we can create a governance plan, we need to understand what governance is. I’m a fan of the definition from the Burton Group: “Governance uses people, process, technology, and policies to define a service, resolve ambiguity, and mitigate conflict within an organization.” The governance plan does just that—it defines the service, roles, team, technology and the policies.
People – Think virtual teams. The roles for a SharePoint environment can be as simple as a Portal Admin and an IT Infrastructure Admin. This provides some level of delegation and empowerment for the business, while maintaining patch levels and optimizing administrative tasks by someone who has the appropriate skill set. The larger the enterprise, the more these tasks become divided into roles stemming from a development lifecycle. It may be an SDLC (Software Development Lifecycle) or an Operations framework like MOF 4.0, where a framework is laid out with staged deployment involving different roles— the Dev team, the Test team, the Ops team, the Engineering team and the Service Manager, along with the Project Management Office. A support desk, along with communication functions and release management, can provide these teams with simple to highly-structured support, based on the requirements and complexity of the application and organization.
Process – The process for this service most often determines how the site or site collections live and die—it’s about the lifecycle management of the unit of provisioning. Exchange supports mailboxes and SharePoint supports Site Collection as its most scalable unit, but, in some cases, the unit of provisioning actually is a site. The process is the system set up to support the provisioning process. Imagine it as a workflow from creation all the way through to the archive and deletion process. Who can create sites? Who approves them? How are they managed?
A great way to achieve stability and address cultural issues is to include Site Admin training as a prerequisite to owning a site or site collection. In the training session, you could include HR policies on security and risk associated with your information policies. Your SharePoint community will be happy they were told the rules ahead of time.
Technology – The technology is the platform. It’s also what I like to call the “Buzzwords.” In nearly every SharePoint marketing deck, you will find the SharePoint pie. This pie consists of buzzwords from Portals, web content management, records management, BI and others. The SharePoint Platform is plastic, so mold it to support the service you envision.
Policies – Customization policies will keep you out of trouble. Security policies are right up there, as well. You need to establish the rules of the game and learn how to enforce them. A customization policy might define who can use SharePoint designer, or, it might determine how you support custom development assets and how they are evaluated even before reaching your dev boxes.
Service – The service is what you’re building. It’s what helps you be consistent and achieve scale. The service definition will give you, in black and white, what everyone agreed that you would build and support.
People – Think virtual teams. The roles for a SharePoint environment can be as simple as a Portal Admin and an IT Infrastructure Admin. This provides some level of delegation and empowerment for the business, while maintaining patch levels and optimizing administrative tasks by someone who has the appropriate skill set. The larger the enterprise, the more these tasks become divided into roles stemming from a development lifecycle. It may be an SDLC (Software Development Lifecycle) or an Operations framework like MOF 4.0, where a framework is laid out with staged deployment involving different roles— the Dev team, the Test team, the Ops team, the Engineering team and the Service Manager, along with the Project Management Office. A support desk, along with communication functions and release management, can provide these teams with simple to highly-structured support, based on the requirements and complexity of the application and organization.
Process – The process for this service most often determines how the site or site collections live and die—it’s about the lifecycle management of the unit of provisioning. Exchange supports mailboxes and SharePoint supports Site Collection as its most scalable unit, but, in some cases, the unit of provisioning actually is a site. The process is the system set up to support the provisioning process. Imagine it as a workflow from creation all the way through to the archive and deletion process. Who can create sites? Who approves them? How are they managed?
A great way to achieve stability and address cultural issues is to include Site Admin training as a prerequisite to owning a site or site collection. In the training session, you could include HR policies on security and risk associated with your information policies. Your SharePoint community will be happy they were told the rules ahead of time.
Technology – The technology is the platform. It’s also what I like to call the “Buzzwords.” In nearly every SharePoint marketing deck, you will find the SharePoint pie. This pie consists of buzzwords from Portals, web content management, records management, BI and others. The SharePoint Platform is plastic, so mold it to support the service you envision.
Policies – Customization policies will keep you out of trouble. Security policies are right up there, as well. You need to establish the rules of the game and learn how to enforce them. A customization policy might define who can use SharePoint designer, or, it might determine how you support custom development assets and how they are evaluated even before reaching your dev boxes.
Service – The service is what you’re building. It’s what helps you be consistent and achieve scale. The service definition will give you, in black and white, what everyone agreed that you would build and support.
3. Get an Exec Sponsor
Without a stakeholder who has a budget, your deployment is doomed from the start. You need the visibility and support of the business. At Microsoft, they are called shadow apps. The key stakeholder might be the director of HR, Marketing or Communications. It isn’t always the CEO, or even a C-level executive. While it is great to be on their radar—and have the awesome visibility that goes with a spot on the radar screen, the day-to-day details are rarely discussed in the board room. The CIO’s vision for information management and the ability to support the growth of the business is critical. The platform the CMO chooses to push the marketing message can either hurt or embrace your service. Vision is a key word.
4. Create the Dream Team You don’t need to hire an army.
You can find people with the right skill sets right in your corporation. It also is extremely helpful to have the guidance of someone who has performed previous SharePoint deployments. Microsoft’s SharePoint Deployment Planning Services provide the option of working with a skilled partner to get your service scoped. I can’t over-emphasize the importance of training by a skilled SharePoint instructor, especially one who is a SharePoint MVP. There are many out there who have built instruction based on their deployment experience. While Microsoft’s Official curriculum training may help you learn how to install, the insight of the instructor will provide the core lessons.
5. Build Services not Stuff
While a lot of Microsoft applications come with a simple wizard-based install, you would never just install Active Directory or Exchange and then hand over the keys to someone. It’s the same with SharePoint—you need to design a service around it. You need to decide what you’re providing and how you’re providing it. This service-based approach will help you to scale, and set the expectations of the business. It’s an approach that is mandatory to achieve the core requirements of the business and IT. Balance is essential to success, and the only way to achieve it is to scope the service and roll it out in a phased approach as the service delivery team can handle the rate of change.
Los puntos del 5 al 10 pueden revisarlos en el link al articulo
Entradas
