Las dos aproximaciones a un proyecto SharePoint (con una inversión muy distinta)

Una perspectiva muy poco técnica y muy poco de Project Management puede ayudar a visualizar dos aproximaciones  muy diferentes de un proyecto SharePoint, a la gente de negocio como yo.
A saber:

• Proyecto de despliegue SharePoint
• Proyecto de SharePoint profundo.

Esta no es una diferenciación oficial, ni siquiera oficiosa, sino una forma de entenderlas yo que quería compartir y contrastar con la comunidad (asumiendo que no gustará a los más ortodoxos, por supuesto).

Proyecto de despliegue SharePoint

Llamo a este tipo de proyectos a los que están más orientados a explotar SharePoint out-of-the-box, en donde el mayor esfuerzo se concentra en el análisis de cómo sacarle provecho a la plataforma dentro de la organización, la configuración de la plataforma y la gestión del cambio en la empresa(formación, nuevos procedimientos, soporte al uso, etc.).

Este tipo de proyectos tienen un clarísimo quickwin, porque SharePoint es un entorno muy conectado con nuestro Desktop y nuestro entorno Office, con una funcionalidad muy rica disponible para el usuario (adecuadamente capacitado) y así es casi inmediato obtener valor de la plataforma.


Me refiero, por ejemplo, a crear una biblioteca de documentos para un departamento con sus distintos atributos y metadatos, asignarla a un grupo de compañeros y vinculársela cada uno de ellos como un directorio local con OneDrive for Business. Además sacaremos provecho de las búsquedas, las alertas y el control de versiones...Realizando una pequeña configuración y orquestando el cambio entre los compañeros involucrados, la operación puede resolverse en una o dos jornadas, y el valor de negocio es super-elevado.

Posibilidades funcionales como estas hay decenas para cualquier Organización en distintos ámbitos de SharePoint:








Si la Organización está dispuesta a utilizar SharePoint conforme es "natural" y como está facilitado por la propia plataforma, y se conforma con cubrir el 80% típico y clave de sus necesidades según ya lo hace SharePoint correctamente configurado, entonces, estamos hablando de un proyecto temporal, técnica y económicamente muy ligero.

Con este proyecto SharePoint de DESPLIEGUE (ANALISIS, DISEÑO DE LA SOLUCIÓN, CONFIGURACIÓN, CUSTOMIZACIÓN LIGERA Y GESTION DEL CAMBIO), en un único entorno de trabajo (solo tenemos Producción), es como si SharePoint se entendiera como una herramienta más del Desktop, y tiene sobre todo sentido utilizarlo en entornos Office365.

No hablaríamos de un proyecto técnico, sino sobre todo de un proyecto de Consultoría.

Proyecto de SharePoint profundo.

Si por el contrario, lo que queremos es o una solución muy customizada a mis procesos, o a mi diseño gráfico, o integrada con mis otros sistemas, o con requisitos de seguridad/fiabilidad/escalabilidad críticos, o con un ciclo ALM formal y respetando entornos de Desarrollo/Test/Integración/Producción o una solución muy específica o con movilidad real de la solución (SharePoint Everyware) o de publicación web, o realmente el 20% no cubierto por SharePoint es clave para mi negocio... entonces necesitamos un proyecto de SharePoint PROFUNDO.




Estos proyectos, más típicos del mundo SharePoint  on-premises (o preferiblemente sobre una granja de SharePoint en Azure), requieren de un proyecto más profundo de análisis, arquitectura y diseño técnico, diseño de UX, y muchas horas de construcción y deployment. Son proyectos más complejos, largos y costosos, y son pocas las consultoras capacitadas para llevarlos a éxito, pues el conocimiento, metodología y herramientas necesarias son de un alto nivel de exigencia.

Conclusiones de negocio sobre SharePoint en modo DESPLIEGUE o PROFUNDO

Como todo en la vida, nada es blanco o negro, sino que hay una gama enorme de grises. Lo mismo aquí:
No siempre es posible acometer una solución de forma completamente "SharePoint Despliegue"  o necesariamente "SharePoint Profundo", pero es importante que usuario clave de la plataforma (y consultora que lo acomete) sepa diferenciar pros y contras para acometer el proyecto (y balancear costes, plazos, infraestructuras subyacentes necearias, cualificación del equipo, etc.).

El consejo sería, en la medida de lo posible, valorar siempre la posibilidad del proyecto tipo SharePoint DESPLIEGUE, y tener claro a TODO lo que se renuncia con él, y solo si no encaja en nuestras necesidades de negocio (y esto es muy habitual en medianas y grandes empresas), entonces acabar en el proyecto de SharePoint PROFUNDO (y asumir su coste, en todas sus dimensiones, necesario).