Érase una vez… ¡Un SharePoint!

Así empiezan muchos cuentos…… y muchos proyectos.

Como en los cuentos, lo que todos nos preguntamos es si los proyectos tendrán un “happy end”, y qué podemos hacer para conseguirlo.

Y en concreto, para proyectos de SharePoint, ¿existen claves específicas para que los proyectos tengan éxito?

Sobre esta duda y alrededor de ella reflexionamos en el pasado SharePoint Saturday (http://www.spsevents.org/city/Barcelona/Barcelona2015) (por cierto, gran evento organizado por SUG.CAT).

Desde mi visión, las claves para ayudar a conseguir el éxito en una proyecto de SharePoint no distan excesivamente de los elementos clave a tener en cuenta en el desarrollo de una proyecto de software cualquiera, al margen de la tecnología.

Pero desde mi experiencia, todos los puntos comentados a continuación son más relevantes si cabe aún para el éxito en un proyecto de SharePoint

Gestión de expectativas

Habitualmente los proyectos de SharePoint son llevados desde IT, quizá por la complejidad técnica y por la importante dependencia de elementos técnicos y de arquitectura propios de la plataforma.

Así mismo, los usuarios finales de los proyectos de SharePoint acostumbran a ser usuarios de negocio o de las distintas áreas de la organización.

SharePoint es una plataforma muy amplia, con una gran flexibilidad y permite la integración y desarrollo de muchas funcionalidades.

Estos usuarios, durante el ciclo de vida del proyecto acostumbran a iniciar el contacto con la herramienta en un kickoff inicial donde se les muestran las potencialidades de la plataforma y su siguiente punto de control en muchos casos son ya las pruebas finales previas al Golive de producción.

Así pues durante este tiempo los usuarios se han generado unas expectativas muy altas que pueden no corresponderse con la solución final ofrecida.

Eso conlleva una sensación de fracaso del  proyecto por parte del usuario que no es necesariamente real.

Este puede haberse acometido cumpliendo los objetivos y requerimientos establecidos manteniendo costes y planificación prevista pero aún así pueden existir distancias importantes con las expectativas generadas.

La gestión de expectativas es importante en cualquier proyecto, sobre todo en proyectos de desarrollo desde cero pero aún más en proyectos de SharePoint, donde la plataforma ofrece tantas posibilidades que es aún más fácil que el usuario se cree unas expectativas propias respecto al resultado final que pueden no estar alineadas con el desarrollo del proyecto.

Por tanto es necesario establecer el alcance del proyecto e involucrar de las distintas áreas en las diferentes fases del mismo.

Gobernanza en SharePoint

Una de las principales razones para no alcanzar el éxito en un proyecto SharePoint, según estadísticas, es la falta de impulso desde dirección del mismo.

Debe incluirse en el proyecto tareas propias para la definición de políticas de gobernanza de la plataforma validadas e impulsadas por la dirección:

• Identificar un equipo de gobierno inclusivo: Identificar los roles y responsabilidades del equipo de gobierno.
• Es este equipo el que define las normas / políticas a aplicar y sobre qué elementos aplicarlas.
• Implementación del programa de colaboración
  • Establecer la propiedad de los elementos.
  • Organizar los usuarios de negocio para gestionar los flujos de aprobación de esos elementos.

La falta de apoyo y liderazgo desde dirección conlleva dificultades para alinear los objetivos del proyecto con las estrategias de la compañía así como para asegurar el cumplimiento de los mismos.

El apoyo y liderazgo de la dirección es necesario tanto durante la implementación del software específico del proyecto como en las fases posteriores para asegurar el asentamiento y éxito de la nueva plataforma de trabajo.

Tras implementar y asegurar el seguimiento de estas políticas estaremos en disposición de impulsar/ promover el uso de SharePoint en toda la organización, definiendo el adecuado proceso de la gestión del cambio.

Gestión del cambio

Esta es una actividad que aunque parezca propia de la fase de post-implantación realmente debe trabajarse y desarrollarse a lo largo de todo él.

Pero para definir correctamente las actividades necesarias para la gestión del cambio en un proyecto SharePoint  debemos realizarnos 2 preguntas:

• ¿De qué tipo de proyecto SharePoint se trata?
• ¿Qué tipo de usuarios trabajarán en la plataforma?

Primero, ¿de qué tipo de proyecto SharePoint se trata?

¿Se trata de un proyecto de instalación y configuración de SharePoint “menor” cuyos objetivos son:

• Disponer de una herramienta de soporte a la gestión de documentación
• Crear diferentes sites de colaboración interna
• Disponer de una plataforma para la publicación de dashboards o informes sencillos?

En estos proyectos la gestión del cambio es “sencilla”,

Se trata de conocer cuáles son los elementos de trabajo, flujos, pero si venimos de usuarios de Office, ya acostumbrados a la plataforma las necesidades se simplifican.

En cambio si hablamos de proyectos donde existen

• Desarrollos a medida
• Inclusiones de nuevos procesos de negocio
• Uso de nuevas herramientas

El cambio no implica sólo el uso de una nueva plataforma sino también implica cambios en los flujos de trabajo, cambios en la organización del mismo, nuevas herramientas…así pues la capacitación necesaria es mayor y más amplia.

Si además estamos ante usuarios que quizá vienen de otras plataformas (escritorio) y el proyecto además implica un cambio al mundo web es necesario diseñar una gestión del cambio específica que tengan en cuenta todas estas circunstancias.

Así pues según el tipo de proyecto (complejidad)  y usuarios (competencias)  se nos dibujan diversas tipologías (celdas) para cada una de las cuales deberemos definir procesos de gestión del cambio adecuados.

Gestión de la configuración 

¿Cuántos servidores se necesitan?¿ De qué versión se dispone? ¿Con qué nivel de Servicepack? ¿Qué tolerancia de fallos tenemos? ¿Queremos redundancia? ¿Alta disponibilidad? ¿Qué cargas vamos a soportar? ¿Con qué otro software nos vamos a integrar? ¿De qué versión?

Todas estas preguntas tan necesarias y tan evidentes en muchos casos pueden suponer la diferencia entre el éxito y el fracaso si no se gestiona esta información correctamente durante el proyecto.

SharePoint es un producto amplio y complejo, la forma de instalación y configuración de sus componentes pueden implicar consecuencias en explotación y uso posterior.

Así pues esto es necesario tenerlo cuenta no sólo desde el punto de configuración y despliegue de entornos sino también durante el desarrollo y la definición de la arquitectura de la solución.

¿Cuántas veces hacemos pruebas de concepto, en un entorno parecido al escenario definido  pero luego al testear en el entorno final aquella solución que en la POC funcionaba y era operativa ahora no es viable por rendimiento, escalabilidad, o configuración final de otros elementos externos o internos?

La gestión de la configuración, pues, no por obvia deja de ser un riesgo a seguir en el proyecto si no se gestiona correctamente.

El equipo

No por ser el último punto es el menos importante, sino al revés.

Acometer un proyecto de SharePoint con un equipo altamente competente en este entorno es garantía de éxito, ya que de base todo equipo competente y con experiencia en SharePoint tendrá en cuenta los elementos comentados anteriormente y muchos otros necesarios para el buen desarrollo del mismo.

¿Pero cómo se consigue un equipo competente de SharePoint?

Analizando las peticiones abiertas durante el mes de Septiembre respecto a perfiles SharePoint, las palabras clave que más aparecen son:

SharePoint es un producto muy extenso con una curva de aprendizaje lenta.

La extensión y complejidad del producto hace que la experiencia sea un elemento clave para disponer de un equipo que permita cumplir los requisitos según los esfuerzos y plazos previstos. Y así se refleja en las demandas de perfiles .

La falta de experiencia del equipo puede conllevar implementaciones deficientes que suponen el fracaso del mismo.

Desde el punto de vista organizativo y bajando a un nivel de conocimiento más técnico, los perfiles y roles requeridos para un proyecto de SharePoint podrían resumirse en la siguiente tabla:

Así pues, teniendo en cuenta los elementos anteriores y contando con un equipo competente como el de SOGETI podemos asegurar el éxito del proyecto y conseguir el anhelado “happy end».

Descubre cómo SOGETI puede ayudarte en el desarrollo de proyectos de SharePoint, visitando nuestra web.

Anna Almuni es licenciada en Matemáticas por la Universidad de Barcelona. Ha cursado postgrados en desarrollo de aplicaciones en .NET e implementación de soluciones BI. Trabajando en el sector IT desde 2003 en proyectos para diferentes organizaciones del sector público y privado, se incorpora a SOGETI en 2010 como jefe de proyecto. Actualmente como Delivery Manager de la unidad de Microsoft, es la responsable de la supervisión del Delivery de la unidad de soluciones Microsoft en Barcelona, así como de dar soporte a las acciones de preventa.