GESTIÓN DE PROYECTOS DE VOZ

INTRODUCCION

La mayoría de las veces, como ingenieros de soporte o de proyectos, estamos involucrados en proyectos, y muchas veces, para la mayoría la gestión de proyectos es desconocida.

EL PMI (Project Managment Institute), durante decadas, ha tratado el tema, por lo que es el estándar de común aceptación para la mayoría de los países y organizaciones. Pero no voy a volver a tratar este tema extenso en este blog, sino darles algunos TIPS que me han facilitado en mi vida laboral.

No voy a hablar en un orden determinado sino de temas que al azar o por cuestiones de mi trabajo me ha tocado enfrentar en un momento determinado.




Muchos quizás  recuerdan esta imagen,  de hecho si alguna vez les han hablado sobre proyectos , esta es la imagen que en ninguna presentación puede faltar.

Si fijan en la imagen sobre estas lineas, la documentación del proyecto esta vacia, no hay nada. Y eso es la triste realidad, cuando los ingenieros se encargan de la labor de implementar o ejecutar un proyecto, yo diria que es mas bien un problema de cultura organizacional.

Algo importante a resaltar sobre todas las metodologias, las de PMI, ITIL, COBIT, ISO, etc, es que todas te dicen el QUE, pero nunca el dicen el como.  Es ahi donde la experiencia juega un papel importante.


DOCUMENTACION



Yo he llegado a organizaciones donde no había documentación de nada y me ha tocado levantarla desde ceros, aparte de cumplir con mis demás funciones, y como es una labor, secundaria, para la mayoría de las personas, por esto, no se hace o se deja para lo ultimo, porque claro es mas importante cumplir, con los resultados que exige el proyecto.

Bueno y que pasa cuando un cliente te solicita, al final del proyecto un manual, o la documentacion del proyecto, cuando te enfrentas a un cliente que trabaja con la metodologia del PMI, y en tu organizacion, eso es completamente, desconocido (haces caras :S), y te toca salir corriendo a buscar en el mar de correos que se han cruzado, si acaso encuentras la orden de compra, una factura, y pare de contar.

Como disciplina personal, cada proyecto que realizo lo voy documentando a medida que lo voy realizando, y así no me lo exija el cliente, así la empresa donde trabaje, no le interesa o no le importa, tengo esa documentación  para mi referencia personal y que muchas veces la he utilizado en tiempos posteriores si tengo que manejar un proyecto similar.  Esto es lo que llamamos *BASE DEL CONOCIMIENTO*.

ACTAS

La metodología exige actas, para casi la mayoria de las actividades de tipo administrativo del proyecto.
Pero las importantes, por ahora voy a mencionar:

ACTA DE INICIO DEL PROYECTO
ACTA DE CIERRE DEL PROYECTO CON LA FIRMA DEL CLIENTE ACEPTANDO
o recibiendo a satisfacción *esto nos puede ahorrar muchos dolores de cabeza, en el futuro.


CRONOGRAMA

El lo minimo que un PM (Project Manager) debe realizar, es el cronograma del trabajo.


PRESUPUESTO

Aunque mayoría oria de los ingenieros, no manejamos como tal el presupuesto o la plata del proyecto, si es un buen ejercicio, aprender, a diseñar , y controlar un presupuesto.


PLAN DE COMUNICACIONES




WTF?, que es eso, dirían mucho, bueno les cuento, es simplemente un plan, donde plasmas como se van a desarrollar las comunicaciones del proyecto, y de este plan nacen planes como el de CAPACITACIÓN  que también esta ASOCIADO al de la Gestión de RRHH.


Hablemos de algo, que muchos organizaciones pueden incluir o no, la GESTIÓN DE CAMBIOS:

Dentro de la documentacion de un proyecto deberia haber un plan de sensibilizacion sobre el proyecto y los cambios que acarrea, y existir un documento que plasme como se va a tratar este aspecto, se habla mucho, se exige, que se maneje el cambio, y la mayoria de las personas, creen que gestionar la resitencia al cambio es simplemente con dar las charlas informativas, y las reuniones que se dan en el proyecto como tal.


Pero no seria muy util, que el PM, saliera, con un documento, y una serie de estrategias para afrontar el cambio?


Doy unos tips, para crear dicho documento:

  • establecer los objetivos estratégicos,
  • determinar la audiencia destinataria,
  • utilizar la investigación en la formulación de un mensaje efectivo, teniendo en cuenta también la investigación previa, y
  • elaborar un programa de comunicación.

Parece fácil  y en realidad, lo es y lo interesante del cuento es que ese plan lo puedes tener de plantilla para tus demás proyectos.


Por ejemplo:

Creas, dispositivas, videos, imagenes, que impacten a las personas, y les avise del cambio.
Hablas de los aspectos positivos que tiene el cambio
Hablas de como el cambio que vas a realziar, beneficia a la organizacion
Finalmente explicas las ventajas que tu cambio hara para la empresa.

Esto se puede hacer, en los casos que el proyecto impacte a toda la organización  implique una migración tecnológica y cambie la forma de trabajo de los empleados.






ANTES DE EMPEZAR:


Debes tener lo siguiente:


Inventario del sistema telefónico:  


  • lo mas detallado posibles, topologia del cableado interno de la red
  • Tipos de puertos del sistema (FXO, FXS,E1, IP, etc)
  • Listado de los usuarios y sus perfiles
  • Plan de numeración
  • Interconexion con otros sistema telefónicos
  • Conexión a la PSTN
  • Se tiene una red de datos dedicada entre sedes?
  • Se requiere QoS?
  • Que servicios se van a definir
  • Se ha considerado mejorar la red de la empresa?
  • Se va a migrar a IP?
  • Se van a tener usuarios remotos? (se van a usar softphones?)
  • Se cuenta con un Call Center?
  • Cuantos usuarios exixten?
Cronograma:

Describir las actividades de planeacion del sistema, realizar pruebas y verificaciones,  realizar pruebas de todos los servicios ofrecidos.

Se puede convivir antes de migrar con el sistema anterior?

Existe la opción de rollback?


Documentación:

Detallada del sistema su funcionamiento y operación, manuales de usuario final, administradores del sistema y FAQs.










No hay comentarios:

Publicar un comentario