1.0.1.1.P1

 

Una de las características de un proyecto es que tiene fecha de inicio y fecha de terminación. Esto parece muy simple hasta que empezamos a definir exactamente el significado de estas fechas. No existen estándares universales que se recomienden para ninguna de las dos fechas. En muchos respectos, depende de cada organización y de si existen implicaciones por elegir una alternativa en vez de otra. A continuación presentamos algunas opciones para identificar la fecha de inicio del proyecto.

 

·         Generación de la idea. Este punto lleva a la fecha de inicio a un punto previo mucho antes de que el inicio del proyecto haya sido formalizado, además en su superficie esta definición puede no ser coherente. Sin embargo, hay que recordar que la definición elegida puede depender de  que implicaciones tenemos. Podemos elegir esta definición si nuestra compañía esta tratando de enfocarse en el tiempo que toma entre cuando una idea es generada y el momento en que dicha idea es cristalizada en el proyecto. El problema que podemos tener es que tome mucho tiempo el implementar las buenas ideas. Si la compañía desea minimizar el tiempo total que se lleva entre la idea y su cristalización, podemos consultar un proyecto previo y revisar si la definición de fecha de inicio es como la de nuestro proyecto.

·         El presupuesto es aprobado. Esta definición es un poco más concreta que la idea anterior. En esta definición, una idea ha sido generada y la idea es lo suficientemente buena como para satisfacer la declaración de costo / beneficio que haya sido preparada. El proyecto también satisface el proceso de priorización y el presupuesto real aprobado. Hay que tener en mente que el presupuesto puede haber sido aprobado durante el proceso de planificación del año de negocios anterior. El trabajo real puede no empezar hasta el siguiente año. Por lo tanto, esta definición puede también poner en marcha el reloj prematuramente para muchas organizaciones.

·         Asignación del gerente de proyecto. Esto es más común. Puede ser difícil decir que un proyecto ha iniciado antes de que el gerente de proyecto sea asignado. Cuando el gerente de proyecto es asignado, la planificación y definición del proyecto inician y la base del proyecto empieza. Esta es la definición general de la fecha de inicio del proyecto que se utiliza en el Proceso TenStep.

·         El Acta del proyecto es aprobada por el patrocinador. En algunas organizaciones el proyecto oficialmente inicia cuando el cliente aprueba el Acta del proyecto. Algunas compañías requieren un Acta del proyecto y cronograma aprobados antes de que el equipo de proyecto pueda ser asignado. Esto se hace para asegurar que el acuerdo anticipado es correcto antes de que el trabajo del proyecto inicie.  

·         La reunión arranque del proyecto se lleva a cabo. Usando esta definición, el trabajo de planificación y definición son considerados como el trabajo “pre-proyecto”. Todos los proyectos inician con una reunión formal de arranque con el cliente y el equipo de proyecto. Para cuando la reunión de arranque se lleva a cabo, la planificación ha sido completada, el cliente ha aprobado iniciar los trabajos y el equipo de proyecto ha sido asignado. La reunión de arranque es el momento de decirles a todos que el proyecto está listo para iniciar. Debido al trabajo previo, la mayoría de las organizaciones consideran que la reunión de arranque es un momento tardío para definir la fecha de inicio del proyecto.

 

1.0.1.1. P2 ¿Por qué la fecha de inicio es importante?

 

En cierta medida, podemos pensar que realmente no tiene importancia cuando inicie el proyecto. El no tener bien definida la fecha de inicio no elimina el hecho del trabajo implicado en el proyecto. Es obvio que el proyecto inició en un momento dado, ya que hubo un momento en que el trabajo no se estaba llevando a cabo y un momento en que el trabajo se llevó a cabo. De esta forma, el proyecto en algún momento de hecho “inició”.

 

La razón por la que es importante saber la fecha de inicio es que puede haber consecuencias e incentivos con base en el tiempo que toma completar el proyecto. A continuación se presentan ejemplos de dichas consecuencias.

 

·         Responsabilidad del equipo de proyecto. Es difícil hacer responsable a las personas por cosas que no se hallan bajo su control. Por esta razón, es conveniente que el gerente de proyecto sea el responsable del proyecto a partir del momento en que es asignado. Si el reloj del proyecto inicia antes de que sea asignado, es posible que algunas decisiones hayan ya sido tomadas y que algunos recursos hayan sido ya utilizados y por lo tanto son aspectos que no han estado bajo el control total del gerente de proyecto. De la misma forma, si los miembros del equipo son considerados responsables de completar el proyecto dentro del presupuesto y cronograma, es difícil hacerlos responsables del trabajo y de las decisiones que se llevan a cabo antes de que hayan sido asignados. Por esta razón, quizás el proyecto debe iniciar oficialmente cuando el gerente de proyecto sea asignado, mientras que los miembros del equipo son responsables de los que suceda después de que el Acta del proyecto y cronograma sean aprobados, o después de que la reunión de arranque del proyecto se lleve a cabo.

·         Proceso de mejora. Muchas compañías llevan un registro de la duración total de los proyectos y de los intentos de disminuir su duración promedio. Es importante que todos los elementos que están dentro de la compañía utilicen un punto común de inicio y fin. De otra forma las estadísticas de la duración del proyecto no serán significativas.

·         Finanzas / contabilidad. Muchos proyectos tienen gastos de capital desde un punto de vista contable (en oposición al gasto contable). El definir con precisión cuando inicia un proyecto tiene consecuencias en términos del trabajo que puede ser capitalizado y el trabajo que necesita ser gastado.

·         Comparaciones con otras compañías. Si comparamos cuanto tiempo toma a la organización entregar proyectos contra el tiempo que tardan otras organizaciones o compañías, tenemos que asegurarnos que tenemos una definición común de fecha de inicio y de término. Si nuestra compañía considera que un proyecto inicia cuando el gerente de proyecto es asignado y otras compañías inician el reloj en la reunión de arranque, va a aparecer que nuestra compañía toma más tiempo para entregar los proyectos.

 

1.0.1.1. P3 Fecha de término del proyecto

 

De la misma forma, existen varios eventos potenciales que pueden determinar la fecha de término del proyecto. Con frecuencia tenemos dos definiciones:

Primero, la reunión de finalización del proyecto puede significar que el proyecto este oficialmente concluido. Aunque el finalizar el proyecto en la reunión de finalización nos es un poco útil, no es la respuesta a la pregunta fundamental, ya que todavía necesitamos decidir cuando programar la reunión. Podemos llevar a cabo la reunión después de que varios eventos han ocurrido, por ejemplo después de entrar en productivo o 30 días después de entrar en productivo. Sin embargo, la definición final de finalización no se resuelve con esta respuesta.

 

La segunda definición es que el proyecto termina cuando el dinero se acaba. Aunque en muchos proyectos esto sucede realmente, el finalizar a proyecto cuando el presupuesto se acaba es una respuesta financiera altamente arbitraria. Esto no responde la pregunta fundamental de la Dirección del Proyecto de cómo definir la finalización de un proyecto.

 

Existen varios eventos que pueden determinar que un proyecto finalice. Sin embargo, algunas opciones de fecha de finalización pueden no ser convenientes para ciertos tipos de proyecto. Por ejemplo, si nuestro proyecto da como resultado la creación de un documento, sería conveniente que el proyecto finalice cuando el entregable sea aprobado. En este caso, no sería conveniente decir que vamos a entrar en producción en 30 días.

·         Cierre de proyecto. Quizás la fecha más temprana para que se termine el proyecto es cuando el cliente o el patrocinador formalmente aprueba los entregables. Esta definición es probablemente válida para casi todos los proyectos. Estamos construyendo entregables para un tercero. Es conveniente que el proyecto no termine hasta que las personas que solicitaron el trabajo estén satisfechas. Esto puede implicar el presentar el entregable para su aprobación y llevar a cabo el re trabajo con base en su retroalimentación. Sin embargo, para que el proyecto termine exitosamente, los entregables deben ser aprobados. El proyecto podría también terminar si los entregables finales fueron rechazados y ya no se planeó más trabajo.

·         Implantación. Muchos proyectos dan como resultado la implantación de un producto o servicio. Los proyectos de tecnología de la información normalmente son de esta naturaleza. En la mayoría de los casos necesitamos que el patrocinador cierre de proyecto antes de que podamos llevar a cabo una implantación de manera que éste evento se lleve a cabo en una fecha posterior. La implantación puede ser un evento individual o puede ser un conjunto complejo de actividades. El proyecto no termina cuando inicia la implantación, sino cuando la implantación termina. Por ejemplo, si estamos implementando una solución en ubicaciones múltiples con proximidad cercana, el proyecto podría terminar cuando todas las ubicaciones estén exitosamente implementadas. Para muchos proyectos de tecnología de la información, esta es la fecha de término oficial común.

·         Avance a “soporte”. Si nuestro proyecto construye una solución que tiene una vida útil de mayor duración, en algún momento los entregables van a ir de estar en “desarrollo” a estar en “soporte”. Algunas veces este cambio de estatus también significa que hay un cambio en la organización responsable de la solución. Si nuestra solución de proyecto se convierte en una solución de soporte en la organización, este sería asimismo el momento típico en que debemos considerar que el proyecto original ha sido completado. Aún si no tenemos una organización separada involucrada, si llegamos a un punto en que es claro que la solución se encuentra en situación de apoyo, en ese momento el proyecto va oficialmente a terminar.

·         La implantación más un ciclo de producción. Si nuestra solución tiene un ciclo de producción, muchas veces necesita ser ejecutada en producción antes de que el proyecto sea considerado completo. Por ejemplo, si la solución tiene transacciones que se procesan diariamente y un ciclo de cierre mensual, la solución puede necesitar ser implementada y entonces recibir el soporte del equipo de proyecto por al menos un mes. Esto es lógico ya que el equipo de proyecto conoce la mejor solución y puede responder lo más rápido posible si ocurren problemas iniciales. Esto también es útil para asegurarnos que la solución es estable antes de que pase al equipo de soporte. 

·         Implantación más el primer año de producción. Esta condición normalmente se basa en el ciclo de presupuesto más que en la definición de la gestión de proyecto. Pueden haber algunas razones contables de por qué un proyecto necesita existir hasta el final del año fiscal. Cuando llega el nuevo año fiscal, el proyecto termina y el soporte inicia. De nuevo vemos que esto no responde a la pregunta básica desde la perspectiva de la Dirección de Proyectos, pero puede ser la forma en que se defina la fecha de terminación del proyecto. Esta definición puede ser particularmente aplicable a proyectos grandes.

La pregunta de cuando inicia y termina formalmente un proyecto es una de las cosas que la mayoría de las personas da por hecho. Sin embargo, no hay una respuesta fácil para cada organización. Existen probablemente una o dos respuestas que son las más lógicas desde el punto de vista de la gestión de proyecto, pero pueden haber factores culturales o financieros que causen que nuestra organización defina las fronteras del proyecto de manera diferente. Si estamos tratando de comparar proyectos dentro nuestra compañía, o si estamos compartiendo comparándonos con compañías externas, es vital que todos usemos los mismos eventos como puntos de inicio y finalización. Sin embargo, si no estamos tomando como referencia comparaciones, en cierta medida estas fechas solo necesitan ser entendidas con anticipación y acordadas para cada proyecto por la mayoría de los grupos de interés. Este acuerdo nos va a permitir el no estar en la posición en que declaremos victoria y nos demos cuenta que otros piensan que hay todavía más trabajo por hacer.