Material de Referencia - esi-sp.com · un acta de constitución y un documento de requisitos del...

© ESI International PMC:CPM:ESP:000 ver.2.0 R2-i

Inicio del Proyecto

Material de Referencia

Esta unidad trata sobre el inicio o lanzamiento del proyecto.

Aunque el inicio del proyecto es con frecuencia un proceso

independiente en el que el gestor del proyecto tiene a

menudo poca o nada de influencia, es importante que este

entienda lo que supone el proceso.

El siguiente índice es la referencia de la información incluida

en esta unidad.

Para información sobre— Ver página

Inicio del Proyecto .......................................................................... R2-1

Influencias en los Proyectos .......................................................... R2-1

Selección de Proyectos ................................................................. R2-7

Acta de Constitución del Proyecto .......................................... R2-13

El Comienzo Correcto .................................................................. R2-15

Documentación de los Requisitos .............................................. R2-20

Mensajes Clave ............................................................................ R2-21

Fórmula

Resumen de la Unidad

Índice

Leyenda

2

© ESI International PMC:CPM:ESP:000 ver.2.0 R2-1

Inicio del Proyecto

Inicio del Proyecto

Desde el punto de vista del gestor del proyecto, el inicio es a

menudo un proceso único del que él tiene poca o nada de

influencia. El inicio es frecuentemente algo que la alta

dirección ha hecho antes de que el gestor del proyecto se

incorpore. No obstante, el gestor de proyecto debe

entender el rol de la alta dirección en el proceso de

lanzamiento y en el éxito del proyecto, como los métodos

cuantitativos y cualitativos que ellos pueden aplicar para

seleccionar los proyectos.

El gestor de proyecto debe también dominar ciertas

capacidades para poder participar eficazmente en el

proceso de el inicio (participar lo máximo posible cuando se

le ofrece la oportunidad).

La primera capacidad es la habilidad de desarrollar

buenos objetivos de proyecto basados en la

valoración de las necesidades.

Una función muy relacionada con la anterior es la

habilidad de distinguir entre los requisitos funcionales

y técnicos y entender el papel de ambos.

El gestor de proyecto debe ser capaz de desarrollar

un acta de constitución y un documento de requisitos

del proyecto.

Y finalmente, analizar y evaluar los interesados del

proyecto con respecto a su poder e influencia y

poder manejar sus expectativas.

Influencias en los Proyectos

Varias influencias dejan su huella en el rendimiento y

resultado de la mayoría de proyectos. Estas influencias

pueden ser internas en forma de sistemas, estructuras y

cultura de la organización. El sponsor del proyecto es “la

persona o grupo que proporciona los recursos financieros, en

dinero o en especie, para el proyecto1”. Adicionalmente,

factores corporativos, empresariales o ambientales, así como

activos intangibles de la organización (procesos) también

1 Ward, J. LeRoy. Dictionary of Project Management Terms. 3rd ed. Arlington, Va.: ESI

International, 2008, p. 414.

Introducción al inicio del Proyecto

Influencias en los proyectos

4 2


juegan un papel importante en la vida el proyecto. Pueden

también ser externas como factores sociales, ambientales y

económicos. En todos los casos, un proyecto nunca

transcurre aislado en el vacío. Cuanto más profundamente

se analicen y más proactivamente se traten las influencias en

los proyectos, más exitosos serán.

Puesto que los proyectos se dan en organizaciones más

grandes (sean éstas de lucro o no, públicas o privadas),

existen siempre características de la organización que

influyen en el proyecto. Es esencial tener conciencia de

estas características. Los sistemas de una organización

determinarán como se han realizado las cosas

históricamente. Cómo se ha realizado la investigación, por

ejemplo, y cómo los costes han sido seguidos y asignados.

La estructura de la organización es una influencia interna de

mucha importancia.

La organización está estructurada según funciones

(ingeniería, marketing, etc.), por equipos de proyecto,

¿o por algún otro criterio?

¿Cómo encaja su proyecto dentro de la estructura

existente?

¿Dónde reside el poder y el control de la financiación,

en los gerentes funcionales o en los gestores de

proyectos?

¿Dónde se encuentra el control sobre los recursos

humanos? ¿Lo ejerce el gestor de proyecto o los jefes

de los departamentos?

Las respuestas a este tipo de preguntas pueden tener un

efecto dramático sobre cómo se cumplirá un proyecto.

La cultura y el estilo de una organización afectarán a sus

proyectos. ¿Es la organización jerárquica? Por ejemplo, ¿los

gestores de proyecto deben operar a través de los gerentes

funcionales para solicitar asistencia de otro departamento?

¿O se trata de una cultura más relajada en la que uno

puede ir a visitar o enviar un e-mail a cualquier persona

independientemente del nivel? El hecho de que algo

“siempre se ha hecho así” no debería dictar el futuro, pero

un gestor de proyectos sabio debe tener en cuenta las

prácticas dominantes.

Factores externos de naturaleza social, económica o

ambiental están siempre fuera del control del gestor y del

equipo del proyecto, sin embargo pueden ayudar o hacer

fracasar a un proyecto. La construcción de una fábrica en

otro país requerirá ajustes en las costumbres y prácticas

sociales y el sistema legal local. La conclusión de un

proyecto de desarrollo de un sistema de software

complicado allí donde existe poca oferta y mucha

demanda de programadores tendrá un efecto significativo


en los costes del proyecto. La construcción de una planta

nuclear en los Estados Unidos estará sujeta a inquietudes

medioambientales. Un buen gestor de proyectos debe

siempre ser capaz de ajustar la planificación y ejecución,

para que cuenten con factores externos como estos.

¿Qué entendemos con el término “interesados”? Los

interesados, son “personas o/y organizaciones que

participan de forma activa en el proyecto o cuyos intereses

pueden verse afectados [positiva o negativamente] como

resultado de la ejecución del proyecto o de su conclusión.2”

Los “interesados” pueden influir sobre los objetivos y

resultados del proyecto.” Algunos ejemplos comunes de

interesados incluirían—

Los dirigentes de la organización (por ejemplo, el

responsable de un departamento que espera

beneficiarse de un proyecto interno)

El Cliente (por ejemplo, el banco que ha fichado una

empresa de desarrollo de software para diseñar e

implementar un sistema bancario on-line).

Los usuarios finales del producto (por ejemplo, los

clientes del banco que utilizarán el sistema bancario

on-line tras su puesta en marcha)

Socios en el cumplimiento del proyecto (por ejemplo

los vendedores y subcontratados que están

trabajando para un primer contratista sobre cualquier

tipo de proyecto)

Grupos de un interés especial (por ejemplo, expertos

de medio ambiente que se preocupan sobre cómo

un nuevo edificio puede afectar a la tierra, o minorías

interesadas en el reparto de contratos)

Agencias reguladoras (por ejemplo, la distribución de

alimentación y bebidas en relación con un proyecto

farmacéutico, o el Ministerio de Transportes en

relación con un proyecto de infraestructuras de

carreteras)

Como se ve en la lista anterior, los interesados incluyen

algunas categorías bastante obvias, como también mucha

más gente dentro y fuera de la organización que

implementan el proyecto. El gestor del proyecto debería

tener la mente bastante abierta para considerar a los

interesados de un proyecto y sus intereses, porque es mejor

“sobre-identificar” a los interesados que dejar algunos fuera.

Las mejores prácticas sugieren por lo menos los siguientes:

Personas muy influyentes



Interesados en el Proyecto


Equipo de gestión de proyecto

Oficina de gestión de proyectos

Patrocinador (sponsor)

Usuario

Organización que ejecuta el proyecto

Agencias reguladoras

Se pueden utilizar varios criterios para determinar quiénes son

los interesados en un proyecto. Pensad en los siguientes:

¿Quién recibe los resultados del proyecto?

¿Quién provee la información de entrada al equipo

del proyecto?

¿Quién tiene la responsabilidad de supervisión?

¿Quién tiene otras responsabilidades relacionadas?

¿Quién disfruta de los beneficios?

¿Quién sufre las penalizaciones?

Tras identificar quiénes son los interesados, pónganse en su

lugar y háganse la siguiente pregunta “¿Qué puedo ganar

yo con esto?”. Luego encuentren la respuesta y

compártanla con ellos, porque para ganar el apoyo de la

gente necesitan demostrarles cómo ellos se beneficiarán

ayudándole. Si fallan en tomar este paso fundamental, están

tomando el riesgo de someter el proyecto a un “veto

unitario”. En otras palabras, cada interesado — sea

poderoso o aparentemente poco importante — puede

aplicar veto a su proyecto, algunos completamente y otros

sólo temporalmente.

Por ejemplo, un gerente funcional probablemente puede

conseguir cancelar su proyecto si no tiene su aceptación y

apoyo, mientras un administrativo de aprovisionamientos lo

puede retrasar durante una semana o más, por no encargar

el material que necesiten con suficiente tiempo.

Existe una cierta jerarquía en un proyecto. El gestor de

proyecto, el equipo de gestión de proyecto y el equipo de

proyecto. El gestor de proyecto es “la persona responsable

de dirigir todo el proyecto y sus entregables.3”. El equipo de

proyecto es el grupo que realiza el trabajo del proyecto,

pero puedo no estar involucrado en la gestión.

Adicionalmente, la mayoría de los gestores de proyectos

necesitarán nombrar un equipo núcleo del proyecto que

consistirá en todos los miembros clave del proyecto y que

participará intensamente en la planificación y gestión del

trabajo. En proyectos pequeños, sin embargo, estos pueden

ser todos los miembros del equipo del proyecto. Lo



El personal del Proyecto


importante es que cuanto más grande es un proyecto, más

probable será que su organización de personal se parezca a

una estructura de gestión jerárquica e incluya miembros que

no participen en la planificación y gestión del esfuerzo.

La “alta dirección” normalmente es la que inicia los

proyectos. Distintas organizaciones tienen distintas maneras

para determinar quienes forman la “alta dirección” y qué

autoridad y poderes tienen. Básicamente, son los llamados

jefes, tanto si les llaman gerentes de programa, directores de

departamento, o directivos en general. Como los altos

directivos son unos interesados clave en cada proyecto, es

importante recordar que la estructura y la cultura de la

organización afectan las relaciones del gestor de proyecto

con la alta dirección. Estas relaciones pueden ser muy

formales y jerárquicas, o muy informales, o en un punto

intermedio. Una relación clave para el gestor de proyecto es

la del patrocinador del proyecto (sponsor) que es el que

proporciona los recursos financieros, en dinero o en especie,

para el proyecto.

Independientemente de cómo se puede definir y llamar a la

alta dirección en su organización, necesitan entender y

utilizar esta información a su favor. Como gestor de

proyectos, pregúntense lo siguiente:

1. ¿Qué necesitan ellos de mí?

2. ¿Qué necesito yo de ellos?

3. ¿Cómo quieren que yo gestione el proyecto? ¿Con

qué reglas de gobierno?

4. ¿Cómo se escalan y resuelven problemas?

5. ¿Cómo está alineado mi proyecto con la estrategia

de la organización? ¿Cómo contribuye?

Tras que el proyecto haya sido aceptado y usted haya sido

nombrado gestor de proyecto, la “alta dirección” es

normalmente su jefe o el jefe de su jefe, formará parte de la

vida del proyecto. Tal vez necesitarán aprobar el plan del

proyecto, o serán los que acudirán a otros departamentos

para ayudarle a conseguir recursos, etc. Necesitan estar al

corriente del estado del proyecto y saber que pueden

confiar en que usted cumplirá con el trabajo. Como muchos

jefes dicen, “no me gustan las sorpresas.”

La alta dirección utiliza un nivel más abstracto de gestión

(más filosófico) sobre los proyectos que caen bajo su

responsabilidad. El “Gobierno” son las reglas, contexto,

recomendaciones, según las cuales se medirá el proyecto

Entender el papel de la alta dirección


en esa organización. Las reglas de gobierno serán de gran

utilidad para saber lo que la Alta Dirección espera del

proyecto. El gestor de proyecto debe de estar familiarizado

con las reglas de gobierno de los proyectos. Si su

organización no las tiene, no se preocupe, simplemente

trabaje en conjunto con su patrocinador para responder a

las preguntas anteriores.

El inicio de un proyecto se justifica normalmente por una

necesidad de negocio o por la detección de una

oportunidad. La alta dirección decide emprender proyectos

por muchas razones. Algunos de los factores generales que

generan un nuevo proyecto incluyen—

Obsolescencia (Tenemos software que necesita una

actualización)

Fuerzas competitivas (Nuestros competidores están

construyendo un nuevo hipermercado y necesitamos

seguir el ritmo)

Requisitos del Cliente (Participamos en una oferta y

ganamos)

Sugerencias de empleados (Un empleado tiene una

idea para producir mejores máquinas)

Otras fuentes (El propietario de la compañía tiene una

visión de un robot que podrá batir huevos)

Aunque existen siempre excepciones a la regla, el gestor del

proyecto normalmente no participa en esta decisión. No

obstante, él debería entender el porqué se está lanzando el

proyecto para asegurar que los resultados que entregará

cumplen las necesidades para las que se inició.

Necesidades de

negocio y

oportunidades


Selección de Proyectos

Antes del inicio de cada proyecto, los iniciadores deben

decidir si el proyecto debería o no ser emprendido. Esto

supone que muchas veces se debe elegir entre más de un

potencial proyecto, debido a la escasez de recursos a la

que se enfrentan muchas organizaciones. Las prácticas de

selección de proyectos son únicas en cada organización.

Ésta es otra buena razón por la que los gestores de proyectos

deben conocer la cultura de su propia organización y la de

sus clientes. De esta manera, si se le ofrece la oportunidad

de participar en la selección del proyecto, puede aportar

información y opinión valiosa a la alta dirección en el

momento de decisión.

Las mejores prácticas en selección de proyectos apuestan

por la objetividad, pero la selección es pocas veces

puramente cuantitativa. Ser equitativo y claro al elegir entre

todos los proyectos potenciales es crítico, pero hay cosas

que simplemente no son cuantitativas por naturaleza y

necesitan ser definidas más relajada. Aunque la subjetividad

y los prejuicios nunca se eliminarán del todo, cuanto más lo

puedan reconocer los gestores de proyecto e intentar

minimizarlo a través de análisis de hechos, mejores serán las

selecciones de sus organizaciones. Si se les asigna un

proyecto tras la conclusión de la fase de selección, intenten

saber si las decisiones fueron objetivas y cómo esto va a

influir sus propias decisiones en el recorrido del proyecto.

Independientemente de cómo se realiza, la selección de un

proyecto debería ser acorde con el enfoque estratégico de

la organización. Si un fabricante de acero necesita

diversificar sus productos para sobrevivir, la selección de

hacer pequeñas modificaciones en sus procesos antiguos,

probablemente no será una buena decisión de selección de

proyectos. Sería mejor enfocar su esfuerzo en el desarrollo de

una nueva línea de negocio.

Los factores de selección pueden ser tanto cuantitativos

como cualitativos.

Los factores cuantitativos incluyen los siguientes:

Ratio de beneficio-coste (BCR)

Valor actual (PV)

Valor actual neto(NPV)

Período de recuperación de la inversión (PayBack)

Introducción a la

selección de proyectos

Herramientas de selección


Los factores cualitativos incluyen los siguientes:

Predisposición de los interesados

Encaje organizativo

Análisis de riesgos

Modelos de toma de decisiones

Estos métodos los utiliza la alta dirección para seleccionar

proyectos, y el gestor de proyectos también los utiliza en la

planificación del proyecto y la selección de subcontratistas.

Existen muchos métodos de selección, pero están fuera del

alcance de esta visión general de la gestión de proyectos.

Consciente o inconscientemente, la alta dirección casi

siempre considerará las predisposiciones, preferencias o

reticencias de los interesados más importantes como

clientes, accionistas, empleados y los mismos directivos. Eso

es difícil de evitar, por lo tanto debe considerarse.

El encaje organizativo se refiere a la cuestión de si el

proyecto encaja dentro de lo que la organización necesita

lograr, lo que la organización es capaz de emprender, y si el

proyecto expandirá la misión estratégica de la organización.

Un ejemplo sería una organización sin ánimo de lucro que

rechaza grandes donaciones si estas suponen proyectos

inconsistentes con el núcleo de su misión. Otro sería una

empresa de informática que ofrece servicio de base de

datos a un hospital local, rechazando una solicitud para

gestionar un proyecto de actualización de la red para el

hospital porque su negocio consiste sólo en servicios de

software. Esto no significa que cada variación en el negocio

normal deba evitarse, sino que la alta dirección ha

considerado (o debería considerar) el encaje organizativo

en el momento de tomar su decisión. Muchas organizaciones

han fracasado por desviarse demasiado de su negocio

principal.

El análisis de riesgos es otro concepto importante en la

selección de proyectos. En este punto basta con decir que

la organización debe realizar una identificación y análisis de

riesgos previo, para decidir si el proyecto debería

emprenderse a pesar de los riesgos relacionados y gestionar

los riesgos que alto nivel que se generan en caso de que el

proyecto no se realice.

Factores cualitativos


El BCR compara los beneficios con los costes dividiendo el

primero por el segundo y determinando el ratio.

BCR = Beneficio / Coste

Cuanto más alto sea el ratio lo más preferible será. Por

ejemplo, supongamos que tenemos dos maneras

alternativas para realizar un conjunto de tareas que valen

€200.000 en pagos del cliente. El uso de empleados de la

propia empresa costará unos €50,000 pero un subcontratado

está dispuesto a hacer el mismo trabajo por €40,000. En el

primer caso, el BCR es 4:1. El segundo caso es mejor negocio

porque el BCR es 5:1.

Como toda fórmula matemática, el BCR tiene sus

limitaciones. Es importante recordar que como el margen de

beneficios, el BCR solamente se enfoca en un ratio y no en el

volumen del trabajo involucrado. Consecuentemente no

dice nada sobre el valor del entregable. Una gran cadena

de mercados de productos de descuento puede tener un

margen de beneficio (o BCR) mucho más bajo que una

tienda exclusiva, pero puede ganar más dinero debido al

volumen de su negocio. Como la mayoría de las fórmulas, el

BCR también ignora unas consideraciones que son más

difíciles de cuantificar en términos de coste. ¿Cuál es el valor

monetario de gastar un poco de tiempo adicional para

asegurar que un cliente es feliz con su producto? El BCR tiene

limitaciones de cara al sentido cuantitativo, también en el

sentido de que normalmente se calcula de una manera que

no considera el valor del dinero en relación con el tiempo. El

valor actual y el valor actual neto son los cálculos que se

deben aplicar para conseguir esto.

Enfrentados con la selección entre recibir €1,000 hoy y €1,000

dentro de un año, todos veríamos que sería preferible recibir

€1,000 ahora, asumiendo que no hay influencia en el pago

de impuestos. Eso es porque podríamos invertir los €1,000

durante un año y recibir el beneficio de tener lo que hemos

comprado: un año de diversión si hubiésemos comprado

una bicicleta de montaña, interés si hubiésemos comprado

un bono del Tesoro, beneficios si hubiéramos comprado

acciones, o rentabilidad si lo hubiéramos invertido en nuestro

propio negocio. Utilizando un ejemplo sencillo, este “valor del

dinero en relación con el tiempo” es fácil de entender, pero

la gente a menudo lo olvida o tienen problemas en

concebirlo en situaciones más complejas.

La fórmula para el valor actual lo convierte en un proceso

sencillo y nos indica el valor de hoy de los flujos de dinero

futuros. Se calcula como PV = FV / (1 + i)n donde—

Ratio de beneficio coste (BCR)

Valor actual (PV)


PV = valor actual (Present Value)

FV = valor futuro (Future Value)

i = tipo de interés o ratio (tasa) de descuento interno

en la medida de tiempo que utilizamos (como un tipo

de interés anual para el dinero recibido dentro de un

número de años concreto o un tipo de interés

mensual para dinero recibido dentro de un número

concreto de meses).

n = número de períodos de tiempo desde hoy

(basado en la misma medida de tiempo que se utilizó

para determinar el i)

Ésta fórmula puede parecer complicada, pero es un cálculo

que los gestores de proyectos utilizan muy a menudo.

Simplemente cuantifica lo que todos sabemos por intuición.

Cuanto más pronto se traiga dinero dentro de la

organización, más valor tendrá. Cuando más tarde se puede

gastar, menos coste tendrá.

Supongamos que tenemos un cliente que quiere pagar su

factura de €1,000 de aquí a 2 años y pagarnos una

compensación de retraso de €250, en un total de €1,250.

¿Será un trato justo? La respuesta depende del ratio de

devolución o el interés que pagamos para nuestros propios

préstamos. Imaginamos que ganaríamos un 15% anualmente

por el dinero que recibimos. El cálculo correspondiente sería

el siguiente con i igual a 15 por ciento por año (0.15) y n igual

a 2 años:

PV = FV / (1 + i)n

PV = €1,250 / (1 + 0.15)2

PV = 1,250 / (1.15)2 = 1,250 / 1.3225

PV = €945

Aunque recibimos unos €250 adicionales más tarde, con

este acuerdo perdemos €55 en valor actual. De este modo

no vale la pena esperar dado el tipo actual.

El valor real del flujo del dinero (flujo de caja) en un proyecto

depende de la cantidad y el tiempo de las transferencias

para ambos gastos e ingresos. La lógica del valor actual

neto considera ambos flujos de dinero entrante y saliente a

través del tiempo.

La fórmula básica es NPV = PV ingresos – PV gastos (ambos a

través del tiempo)

Se utiliza para comparar los ingresos con los gastos llegando

al valor de un proyecto o de un componente de proyecto,

pero también se puede utilizar para comparar el valor actual

de cualquier pareja de proyecciones de flujo de caja. Por

ejemplo, durante el proceso de selección de proyectos, la

Valor actual neto (VAN)


alta dirección puede comparar el valor de dos proyectos

distintos, y durante el proceso de aprovisionamiento, el

gestor del proyecto puede comparar los costes de dos

distintos vendedores.

Consideremos el caso donde estamos comparando dos

empresas de software para un proyecto de tecnología

informática de seis meses. La compañía Paquete Standard

S.A., ofrece un producto estandarizado por €11,000 con casi

todo el coste de soporte excepto una porción pequeña

cobrada de entrada. La empresa Programadores S.A.,

propone desarrollar un nuevo sistema por €12,000, pero está

dispuesto a aceptar pagos fijos durante la vida del proyecto.

Nuestra empresa recibe préstamos con un tipo de interés de

1.5% mensual. Los calendarios de pagos están resumidos en

la siguiente tabla, y la pregunta es si la oportunidad de diferir

el pago utilizando la empresa de Programadores S.A.

compensa el precio superior de este proveedor.

Mes

Calendario de

pagos de

Paquete ST,

SA

Calendario de

pagos de

Programa. SA.

0 €8,000 €2,000

1 €2,000 €2,000

2 €2,000

3 €2,000

4 €2,000

5 €1,000 €2,000

Precio total €11,000 €12,000

Para responder a la pregunta, necesitamos determinar el

valor actual del flujo de caja propuesto por cada proveedor

y luego calcular la diferencia entre los dos. Los valores

actuales del calendario de pagos de cada vendedor se

calculan en la siguiente tabla, basándose en el tipo de

interés de 1,5 por ciento mensual y usando la fórmula

PV = FV / (1.015)n para hallar el valor actual de cada uno de

los futuros pagos.


Mes Valor actual

Paquete ST

Valor actual

Programa S.A.

0 €8,000 €2,000

1 €1,970 €1,970

2 €1,941

3 €1,913

4 €1,884

5 €928 €1,857

Precio Total €10,898 €11,565

Los cálculos demuestran que el aplazamiento de los pagos

no contrarresta el precio superior de Programadores SA, de

forma adecuada, y que la selección de Paquete ST nos

ofrece un valor presente neto de €11,565 - €10,898 = €667. El

tema a recordar es que cuando las decisiones tratan de

dinero, se necesitan cálculos justos para el valor del dinero

en función del tiempo. El valor actual neto permite hacer

esto.

Quizás el método más simple de tomar decisiones sobre el

valor de los desembolsos de dinero, es determinar cuál es el

período de recuperación de la inversión. Este enfoque es

simplemente un cálculo del tiempo necesario para ganar o

ahorrar tanto como la inversión inicial. Por ejemplo, si hemos

invertido €5,000 en nuevo equipo y no esperamos recibir

ningún beneficio durante el 1er año pero ahorrar €1,000

cada año siguiente, la recuperación ocurrirá tras 6 años.

Claramente, cuanto más pronto viene la recuperación,

mejor. Para recibir los resultados más válidos de este

enfoque, especialmente cuando tratamos con grandes

períodos de tiempo y grandes cantidades de dinero, los

números utilizados en la determinación del período de

recuperación deberían ser actualizados para reflejar sus

valores actuales (PVs)

Período de

recuperación (Payback)


Acta de Constitución del Proyecto

El acta de constitución (Project Charter) es “un documento

emitido por la alta dirección (en otras palabras, el

patrocinador) que da al gestor de proyecto la autoridad

para utilizar los recursos de la organización a las actividades

del proyecto y reconoce formalmente la existencia de un

proyecto4”. Adicionalmente a la documentación sobre lo

que debe conseguir el proyecto, el gestor de proyecto

debería tener documentación sobre la autoridad de la que

dispone para lograrlo. Este es el propósito del acta de

constitución del proyecto. Se trata de un entregable de la

fase de inicio del proyecto y es un acuerdo por escrito entre

la alta dirección, el gestor de proyecto y los directores

funcionales. Fundamentalmente es un contrato que cede al

gestor de proyecto la autoridad sobre el trabajo que se le

está pidiendo.

El propósito de este documento es dar al gestor y al equipo

del proyecto el soporte necesario para que funcionen con

eficacia. La inclusión de los directores funcionales como

firmantes al acta de constitución podría ser crucial porque

muy a menudo son ellos los proveedores de los recursos que

se necesitan (gente, equipo, provisiones, locales, etcétera).

El acta de constitución es un compromiso para la alta

dirección, asignándoles la tarea de apoyar al gestor del

proyecto. Dependiendo del ambiente corporativo, esto

puede ser esencial para el éxito. ¡No les dejen escapar sin

esto!

Para autorizar formalmente el proyecto, debe documentarse

cierta información acerca del proyecto. Esta información de

alto nivel, puede ser vista como un informe ejecutivo, que

incluya:

Patrocinador del proyecto

Objetivos medibles del proyecto

Requisitos de alto nivel (normalmente lo requisitos de

negocio, pero en general, todos los requisitos

conocidos en este punto del proyecto)

Descripción del proyecto

Resumen de alto nivel y estimaciones preliminares de

presupuesto y fechas clave

Requisitos de aprobación del proyecto (quién tiene la

autoridad para firmar la conformidad de los

entregable, por ejemplo)



Acta de

constitución del

proyecto (Project Charter)


Resume y clarifica las fronteras inicialmente

establecidas para el proyecto.

El acta de constitución también es donde se asigna e

identifica al gestor de proyecto. Y también debería incluir:

Nombre del gestor del proyecto

Descripción de las responsabilidades del gestor del

proyecto

Detalle del nivel de autoridad que tiene el gestor del

proyecto en el manejo de recursos de la

organización.

Nombres (y firmas) de las personas que autorizan el

proyecto.

¿Qué pasa cuando la alta dirección no ha escrito un acta

de constitución y ni está dispuesta a emplear el tiempo en

esto? Entonces quizás debería hacerlo el gestor de proyecto,

asegurando luego su aceptación y firmas. Sin que el acta de

constitución esté firmada, no tendrán autoridad

documentada y explícita para actuar.

El nivel de formalismo del acta de constitución varía

enormemente de una organización a otra, e incluso de un

proyecto a otro dentro de una misma organización. En

algunas ocasiones, el acta será algo tan informal como un

email del jefe dando su OK proceder con el proyecto. En

otras, es posible que sea necesaria una revisión con el cliente

así como obtener autorización escrita para proceder con el

proyecto. En este caso, el concepto de acta incluye

también el caso de negocio, o éste puede incluso servir

como acta. En definitiva, diferentes organizaciones pueden

llegar a utiliza diferentes documentos para autorizar un

proyecto.


El Comienzo Correcto

Una vez seleccionado el proyecto a perseguir, debería

comenzar el inicio del proyecto con una valoración de

necesidades sólida y luego expandirla a través del desarrollo

de objetivos, requisitos funcionales, y requisitos técnicos.

Aunque distintas organizaciones definirán estos términos de

distintas formas, para los propósitos de este texto, significan lo

siguiente:

Necesidades/metas: Algo que se necesita o requiere;

a menudo algo inconcreto

Objetivos: Algo que trabajamos o luchamos para

conseguir (que deberían acordarse entre los que

tienen las necesidades y los que las van a cubrir)

Requisitos: Refinamientos de los objetivos; en términos

generales lo que el cliente necesita para cumplir los

objetivos y cubrir las necesidades; deberían ser

expresados en términos funcionales o de capacidad

deseada y explicar qué tendrá que hacer el resultado

del proyecto

Requisitos de Negocio: Cuantifican las necesidades

del negocio.

Requisitos de Calidad: Facilitan los niveles aceptables

de calidad.

Requisitos Funcionales: Están relacionados

directamente con la funcionalidad, como las reglas

del negocio, la generación de informes, etc.

Requisitos no Funcionales: Especifican características

de la solución como, seguridad, disponibilidad, etc.

Aquí tienen un ejemplo de un proyecto muy sencillo:

Necesidades: Se necesitan imprimir diapositivas de

PowerPoint más rápido, porque tardamos mucho en

prepararnos para nuestras presentaciones.

El comienzo correcto


Objetivos: Reducir el tiempo de preparación de los

paquetes de copias de diapositivas a menos de 4

horas.

Requisitos: Necesidad de un paquete para el cliente

que incluye copias de las diapositivas de las

presentaciones en alta calidad, en color y

encuadernadas dentro de 4 horas tras la finalización

de la presentación.

Requisitos de Calidad: Las diapositivas de la

presentación deben incluir imágines con

calidad fotográfica.

A medida que cada uno de estos conceptos se examina en

mayor detalle, es importante recordar que el gestor del

proyecto no debe permitir que los interesados apliquen

demasiada presión para conseguir sus requisitos técnicos

preferidos. Antes de que se puedan concretar los requisitos

técnicos, debe existir una comprensión clara y mutua de los

verdaderos objetivos y los requisitos funcionales. Si no, se

pueden pasar por alto soluciones mejores de las que se

eligen finalmente. En el ejemplo anterior, mucha gente iría

inmediatamente a comprar una impresora rápida de precio

elevado, mientras que un contrato de bajo coste con una

tienda de copias podría resultar más eficaz de cara a coste,

o más fiable.

La evaluación eficaz de necesidades requiere el

reconocimiento de que las necesidades existen en varios

niveles entre los diferentes interesados en el proyecto. De

hecho, los proyectos muchas veces surgen a través de

necesidades contradictorias. Eso pasa simplemente porque

cada persona tiene distintas necesidades. Por ejemplo,

imaginamos que un constructor ha sido encargado de un

contrato para construir un nuevo puente. El cliente, los

vecinos del barrio, los conductores que la utilizarán para su

transporte diario, los expertos en medio ambiente, los

políticos locales, tienen todos necesidades en relación con

este proyecto. En este caso, como muchas veces pasa, las

necesidades son conflictivas, y el proyecto no puede cumplir

las necesidades de todos. Los conductores prefieren un

puente de múltiples tramos para reducir el tráfico; los

expertos en medio ambiente prefieren preservar el pantano

que hay cerca, por ejemplo.

En situaciones como esta, la alta dirección debe entender y

luego encontrar el balance o priorizar las necesidades

conflictivas, frecuentemente trabajando con clientes para

ayudarles a decidir lo que necesitan de verdad (contra lo

que sería “bonito tener”). El gestor de proyecto debería

ayudar en el proceso siempre y cuando esté nombrado a

Evaluación de necesidades


tiempo para hacerlo. Cuanto antes se afronten los conflictos,

más fácil será gestionar el proyecto.

Las necesidades deberían también separarse de los deseos.

En el mismo ejemplo, la agencia del contrato necesita un

puente para cruzar 3.000 coches al otro lado del río cada

día laborable. También les gustaría tener un carril adicional

para un posible monorraíl. ¿Se trata de una necesidad o un

deseo? La agencia debe decidir.

Los clientes a menudo no saben exactamente o no

entienden sus necesidades. Frecuentemente es apropiado

expandir la visión del cliente sobre sus necesidades

enseñándole oportunidades que pueden construirse dentro

de un proyecto dado; éstas pueden ser opciones de las que

el cliente no es consciente pero que le gustaría aplicar.

Las necesidades en realidad se evalúan a través de

revisiones de documentos, entrevistas, encuestas y

auditorias. Éstas se realizan tanto de forma interna como con

el cliente. ¡No es correcto simplemente sacar un RFP y

avanzar! Analicen —y ayuden al cliente a analizar —lo que

se necesita contra lo que se desea, tanto como la prioridad

o jerarquía de las necesidades. Un trabajo superficial en este

punto tendrá sus repercusiones durante el proyecto y mucho

más allá.

Los objetivos deberían desarrollarse como una evolución de

las necesidades consideradas seriamente. Deberían

representar un entendimiento entre los que necesitan algo y

los que lo pueden proveer. Los objetivos existen a todos los

niveles: corporativo, de departamento, programa, proyecto,

equipo y tarea específica. Su compañía y cliente necesitan

objetivos claros para la obra en su total; su jefe y Usted

necesitan objetivos claros para el proyecto; y Usted y sus

empleados necesitan objetivos claros para la tarea. Sin este

entendimiento, es poco probable llegar al éxito, mientras

que es muy probable que se tenga que repetir el trabajo, y

que dominen la frustración y las disputas.

Los objetivos bien formados se caracterizan por los cinco

elementos del modelo SMART:

S = Specific – Específico

M = Measurable - Medible

A = Agreed upon - Consensuado

R = Realistic - Realista

T = Time-constrained – Limitado en el tiempo

Si no se conoce el objetivo, o si no está bien definido, no se

puede hacer bien el trabajo.

Formulando buenos objetivos


Un “objetivo” utilizado en este sentido es un concepto, no un

documento.

Los requisitos funcionales son el vínculo siguiente en la

cadena que empezó con las necesidades, que a su vez

estaba vinculada a los objetivos. Los requisitos funcionales—

el qué necesita el cliente— se derivan de los objetivos. Los

requisitos técnicos son lo que desarrolla el equipo del

proyecto para cumplir con los requisitos funcionales.

Los clientes tienen ciertas funcionalidades que necesitan

cumplir, que se basan sin duda en las necesidades ya

expresadas y los objetivos que ya han acordado. Cuanto

más claros y específicos sean estos objetivos, menos trabajo

será necesario para conseguir los requisitos funcionales. Unos

excelentes objetivos sirven como buenos requisitos

funcionales; unos objetivos imprecisos requieren mucho

trabajo.

El desarrollo de los requisitos técnicos puede desviarse en dos

maneras:

1. El equipo del proyecto no debería simplemente

parafrasear los requisitos funcionales en lenguaje

técnico. En vez de esto deberían estar pensando en la

solución técnica para los requisitos del cliente.

2. Los clientes no deberían inventar la solución técnica.

¡Esta es una de las razones principales por las que

ficharon al equipo del proyecto!

Parte del papel del gestor de proyecto es conseguir que la

gente haga su parte de trabajo. Necesita mantener a los

clientes centrados en sus capacidades, y los expertos y

tecnólogos centrados en los detalles. Lo que pasa

demasiadas veces, es que cada uno tiene tendencia a

distraerse pisando el dominio del otro.

Al final del proceso, debería controlar los pasos anteriores y

contestar a la pregunta de si los requisitos técnicos

responden a los objetivos. Si no lo hacen, entonces se

debería volver a trabajar en los requisitos o en los objetivos.

Requisitos y especificaciones


El prototipado es una opción en la que el equipo del

proyecto trabaja con el cliente para definir los requisitos,

aunque todavía sean vagos. Una vez esté creado el primer

prototipo, el cliente y el equipo del proyecto lo revisan, lo

refinan y lo modifican. Continúan construyendo a partir del

prototipo hasta que todas las necesidades estén definidas

adecuadamente.

La creación del prototipo promueve los cambios. Funciona

bien en entornos cambiantes y de complejidad conceptual,

e impulsa a la organización y al cliente a examinar o revisar

de forma cíclica. La elaboración progresiva - usada

comúnmente en desarrollo software - implica el desarrollo

progresivo de los requisitos. Éstos son definidos en etapas

iniciales del proyecto y refinados a medida que el proyecto

progresa. Sin que cambie el alcance del proyecto, las

características y requisitos de éste son elaborados de forma

progresiva. Le elaboración progresiva es muy similar a la

planificación gradual (rolling wave planning)

El objetivo es tener un cliente feliz; se puede utilizar el

concepto del prototipo o elaboración progresiva para

ayudar a los clientes a entender lo que quieren y lo que les

haría felices. No obstante, no podemos dejar al método del

prototipo o de la elaboración progresiva sin control. Primero,

debería existir un entendimiento común de en qué consistirá

el prototipo y de cómo se realizará la elaboración

progresiva. El método del prototipo y elaboración progresiva

pueden incluir varias herramientas para obtener buenos

requisitos.

Esbozos de alto nivel

Modelos a escala

Anteproyectos

Con cada enfoque se debería determinar el tiempo y los

recursos que deberían emplearse en cada ciclo. El método

del prototipo debe ser un proceso bien definido y necesita

tener modificaciones documentadas por escrito que se

procesan en cada ciclo y que puedan revisarse y valorarse.

Prototipado y

elaboración

progresiva


Documentación de los Requisitos

Una buena documentación de los requisitos suele ser un

punto clave en la oferta, análisis, formalización y validación

de los requisitos.

El documento de requisitos de negocio (BRD) lo crean los

analistas de negocio y se pasa al patrocinador del proyecto,

después de un proceso de aprobación. Este documento

describe la situación actual y la situación futura deseada.

El plan de trabajo de los requisitos, creado por el analista de

negocio, define el trabajo que hay que realizar durante la

toma de requisitos, su análisis, documentación y validación.

Debe completarse y aprobarse antes de que comience el

verdadero trabajo de análisis de requisitos y puede formar

parte del plan general de gestión del proyecto.

La matriz de trazabilidad se utilizar para mostrar la relación

entre los requisitos y tanto las necesidades del negocio como

los entregables que resulten. Todos los requisitos deben estar

relacionados a bajo nivel con los entregables y a alto nivel

con las necesidades de negocio para asegurar un caso de

negocio robusto.

El PRD es el documento oficial y forma que describe los

requisitos identificados para el proyecto en detalle para

conocimiento de todos los interesados. Dependiendo de la

organización, se le puede conocer con otras

denominaciones: especificación de requisitos, documento

de requisitos o especificación funcional.

Independientemente de su denominación, el PRD se emplea

para desarrollar el diseño y las especificaciones técnicas

para un producto, sistema o programa. Constituye el enlace

definitivo entre el Inicio y la Planificación. Es un registro escrito

de todo aquello que ya ha sido discutido y decidido, y sirve

de hoja de ruta para dirigir al equipo de proyecto. Preparar

un buen PRD reduce además la necesidad de tener que

rehacer trabajo en el proyecto.

El equipo de proyecto hace un borrador del PRD y se

entrega a la alta dirección y a los principales interesados

para su aprobación al final de la fase de Inicio. El PRD

debería incluir una visión general del producto o sistema a

realizar, así como las necesidades de negocio a las que se

pretende dar respuesta. También sería conveniente incluir un

glosario de los términos técnicos y de negocio empleados.

Esto es especialmente importante para asegurar un

Introducción a la

documentación de los requisitos.

Documento de

requisitos de proyecto (PRD)


entendimiento común de los términos más significativos entre

todos los interesados.

Otras secciones típicas son:

Objetivos del Proyecto

Declaración de alcance (Statement of Work, SOW)

Descripción del producto

Características de usuario

Hipótesis y asunciones

Restricciones

Proyectos relacionados

Requisitos funcionales y técnicos específicos

(interfaces externas, requisitos de funcionalidad y

rendimiento, requisitos de las bases de datos lógicas,

restricciones de diseño, atributos del sistema, requisitos

de calidad, etc.).

Para garantizar la trazabilidad, el PRD debería realizarse

utilizando procedimientos e incluso software para controlar

los vínculos entre requisitos y objetivos del proyecto. Debería

ser posible trazar un requisito desde su fuente- por ejemplo

un usuario final- a lo largo de todo el ciclo de vida del

proyecto hasta su comprobación y test final.

Mensajes Clave

Cada proyecto está influenciado por factores internos

y externos

La alta dirección normalmente selecciona e inicia los

proyectos.

En la selección de un proyecto intervienen métodos

cuantitativos y consideraciones cualitativas.

Los proyectos surgen por muchas razones, desde

obsolescencia de productos a los requisitos del cliente

hasta innovación personal.

Las necesidades deben ser evaluadas, los objetivos

fijados, y los requisitos funcionales y técnicos estar bien

definidos.

Los clientes definen los requisitos funcionales

El equipo del proyecto desarrolla los requisitos

técnicos.

Un acta de constitución del proyecto describe

explícitamente las funciones y responsabilidades del

gestor del proyecto y los miembros básicos del equipo

de proyecto, tanto como la información de otros

grupos de la organización.

Resumen de Unidad


El documento de requisitos de proyecto (PRD) es el

documento oficial describe los requisitos de proyecto

identificados.

La matriz de trazabilidad de requisitos hace un mapa

de la evolución de los requisitos desde el comienzo

hasta el final del proyecto.

Material de Referencia - esi-sp.com · un acta de constitución y un documento de requisitos del...

Documents

Transcript of Material de Referencia - esi-sp.com · un acta de constitución y un documento de requisitos del...