SlideShare une entreprise Scribd logo
1  sur  11
UNIVERSIDAD VERACRUZANA
SISTEMAS COMPUTACIONALES ADMINISTRATIVOS
E.E.:
Gestión y Evaluación de Proyectos
Tarea 4:
Definiendo el proyecto
Catedrático:
Dr. Carlos Torres Gastelú
Alumnos:
Ocampo Pierre Karina
Ramírez Díaz Juan Manuel
Rosete Osorio Marcos Adrián
Bloque:
8
Equipo:
11
H. Veracruz, Ver. 18 de Marzo del 2009
Capitulo 3 Definiendo el Proyecto
Muchos proyectos se gestionan por el principio del explorador
principio: "Hay que moverse y ver qué pasa." Si bien este enfoque
puede ser excitante, sobre todo a las dos de la mañana, antes de que un
hito entregable sea debidamente apto, es raro que se produzca lo que
quiere el cliente. Definir el proyecto consiste en averiguar lo que es.
Puede parecer elemental señalar que con el fin de satisfacer a un cliente,
es necesario identificar lo que se va a hacer, pero con demasiada
frecuencia, las necesidades del cliente se van convirtiendo en una clara
aplicación. Antes que sea demasiado tarde.
Existe una actitud de "hacerlo antes" por parte de su equipo (incluido
usted). Usted puede, por lo tanto, ser engañado al creer que porque
usted entiende la aplicación (por ejemplo, inventario), usted sabe lo
que el cliente necesita y que no tiene mucho sentido en la adopción de
un valioso tiempo pidiendo preguntas tontas.
Cuando usted y su equipo abordan los problemas, que se centran en las
soluciones técnicas en lugar de las necesidades del cliente. Si va a estar
Entendiendo el
Proyecto
Entendiendo el
Proyecto
Definiendo el
Proyecto
Definiendo el
Proyecto
Planeando el
Proyecto
Planeando el
Proyecto
Corriendo el
Proyecto
Corriendo el
Proyecto
¿Tengo definidos los entregables del proyecto?
¿Tengo establecido el ambiente en el que se desarrollará
el sistema y/o proyecto?
¿Tengo determinado cómo serán generados y aprobados
los entregables?
¿Cómo será definida la estructura y organización del
equipo del cliente?
¿Tengo definidos los entregables del proyecto?
¿Tengo establecido el ambiente en el que se desarrollará
el sistema y/o proyecto?
¿Tengo determinado cómo serán generados y aprobados
los entregables?
¿Cómo será definida la estructura y organización del
equipo del cliente?
AQUÍ
VAMOS!
enfocada al cliente y, a continuación, todos los problemas que usted y
su equipo van a discutir deben resolverse teniendo en cuenta lo que es
mejor para el cliente, no sobre la base de ingenio técnico.
El proyecto es apresurado en la salida. Es casi imposible para usted
cumplir con los plazos y la inminente
inevitabilidad de la noche y los fines de semana. Si este es el caso, usted
está siendo presionado para "estar en lo cierto" y para producir algo que
sea rápido, y se llega a considerar que la desaceleración de hablar con
el cliente es como una carrera de limitación de movimiento.
Su cliente o su gestión (o usted) cree que el único producto valioso del
equipo de sistemas es el código y que todo lo demás es preámbulo
costoso, consume tiempo, y de un valor limitado. Si ese es el caso, toda
acción que retrase el comienzo de los trabajos "reales" será
desperdiciados y no deseados.
Si cualquiera de estas condiciones es verdadera, entonces usted tiene
fuerzas por las que se esta desviando las bases necesarias. Contrarrestar
la fuerza de cada uno de ellos es insistir en que los requisitos del
proyecto se definen claramente y sin ambigüedades como sea posible.
Existe una nueva amenaza para una definición clara de los resultados
finales. Muchos proyectos están actualmente estructuradas alrededor de
alguna forma de desarrollo iterativo de prototipos en los que se
preparan, revisan y, sucesivamente refinan todos los prototipos se
transforma en el sistema final. En este enfoque para el desarrollo de
sistemas, el prototipo es a menudo utilizado para identificar las normas
y procedimientos, lo que lleva a la tentación de despedir a las
necesidades de definir los requisitos, ya que "se convertirán claramente
como evolucionará el prototipo".
Si usted entiende este argumento, señala que el desarrollo iterativo es
una manera de alcanzar el resultado final deseado, pero el resultado
aún está por definirse. De hecho, este enfoque a las necesidades de los
proyectos define de forma mas clara la meta final.
Para definir el proyecto, usted debe definir, documentar y obtener la
aprobación del cliente en dos aspectos: los productos y el alcance. Estos
se analizan más adelante en este capítulo.
Sin embargo, la definición de un proyecto es más que la definición de
los resultados y el alcance. También es necesario definir la forma en que
el proyecto se llevará a cabo. En concreto, deberá establecer:
• Cómo va a gestionar las solicitudes de cambios en el ámbito de
aplicación.
• La forma en que el cliente se examinará y aprobará los resultados
• Para proyectos de desarrollo, ¿qué tipo de enfoque del proyecto
se llevará a cabo.
Estos son los temas del capítulo 3. Una lista al final le ayudará a
asegurarse de que usted y el cliente están de acuerdo sobre las
cuestiones importantes en el proyecto.
DEFINIENDO DE LOS ENTREGABLES
En la vista, la definición de los resultados debe ser simple. El cliente
quiere una recomendación sobre un paquete de un programa
informático, un conjunto de modelos, una tecnología de la arquitectura,
o un sistema de aplicación que consiste de código y documentación. Si
bien estos productos pueden ser complejos para la producción, la
definición de ellos parece ser sencilla. Lamentablemente, el mundo de
los proyectos, por lo general conduce directo al fracaso.
Definir un proyecto
Durante la fase de planificación de proyectos que tienen una duración
significativa o requieren los servicios de muchas personas, es importante
definir los objetivos, las suposiciones y las delimitaciones del proyecto.
Definir los objetivos del proyecto
Unos objetivos de proyecto claros son cruciales pues el éxito del
proyecto vendrá determinado por el grado de cumplimiento de los
mismos. Un objetivo de proyecto claro es específico y mensurable.
Deben evitarse objetivos imprecisos como "Crear resultados modernos".
Los objetivos de un proyecto pueden incluir:
- Una lista de resultados del proyecto.
- Fechas de cumplimiento específicas, tanto para la finalización del
proyecto como para los hitos intermedios.
- Criterios de calidad específicos que deben cumplir los resultados.
- Límites de costo que no debe sobrepasar el proyecto.
Para que los objetivos resulten eficaces, es importante que todos los
participantes del proyecto estén oficialmente de acuerdo con ellos. A
menudo, el administrador del proyecto crea un documento de objetivos
que se convierte en una parte permanente del proyecto. Tras crear un
documento de objetivos en un programa diferente de Microsoft Project,
puede adjuntarlo al archivo de proyecto para tener acceso a él de
forma sencilla.
Definir las suposiciones del proyecto
Durante la etapa de planificación de un proyecto, probablemente
surgirán muchas cuestiones importantes sin respuesta; por ejemplo,
cuándo estarán disponibles los recursos clave para iniciar el trabajo, y
cuánto tiempo llevará un nuevo proceso. Para comenzar la
planificación, se hacen conjeturas hipotéticas y, a continuación, se
utilizan esas estimaciones para crear la programación.
Es importante hacer un seguimiento de las suposiciones que se hacen de
manera que:
- Los participantes del proyecto puedan criticarlas y, después, apoyar
formalmente un conjunto de suposiciones del proyecto.
- Se pueda actualizar la programación cuando se disponga de
información adicional sobre esos factores.
Hay que tener en cuenta las siguientes áreas del proyecto para
identificar suposiciones subyacentes:
- Entregas de otros proyectos o departamentos: Si el proyecto
va a depender del trabajo de otras personas, ¿son conscientes dichas
personas de esta dependencia y están de acuerdo con las fechas de
entrega establecidas?
- Disponibilidad y uso de recursos (incluyendo personas,
materiales y equipamiento): Si algunas de las personas que van a
trabajar en el proyecto están bajo otro cargo, ¿a cargo de quién están?
Y, ¿ha aprobado esa persona la utilización de estos recursos?
- Duraciones de las tareas: ¿Están fundamentadas las estimaciones
de tareas en una información sólida o en conjeturas?
- Costos del proyecto: ¿Qué importancia tiene el costo en el
proyecto? ¿Quién debe aprobar el presupuesto o aumentarlo si es
necesario?
- Tiempo disponible: Si se está trabajando teniendo presente una
fecha límite conocida, ¿se puede completar de forma realista todas las
tareas con un nivel aceptable de calidad?
- Resultados: ¿Cumple el resultado esperado las expectativas del
cliente y de otros participantes? Si se deben hacer concesiones en el
resultado, ¿están de acuerdo los participantes sobre los aspectos del
resultado en que se han de hacer las concesiones en primer lugar?
Estos son unos pocos ejemplos de los asuntos a considerar antes de
empezar un proyecto complejo. El éxito del proyecto depende en
último término de la identificación de suposiciones y de la realización
de planes alternativos de seguridad, así como de llevar a cabo el
proyecto tal como fue planeado.
Definir las delimitaciones del proyecto
Las delimitaciones en un proyecto son factores que pueden restringir las
opciones del administrador del proyecto. Normalmente, las tres
delimitaciones principales son:
- Programación, como una fecha de fin fija o una fecha límite para un
hito principal.
- Recursos (materiales, instalaciones, equipamiento y personal, así como
los costos asociados), como un presupuesto preestablecido.
- Ámbito, como un requisito de realización de tres modelos del
producto.
Un cambio en una de estas delimitaciones afecta normalmente a las
otras dos, y también afecta a la calidad total. Por ejemplo, si decrece la
duración del proyecto (programación), puede aumentar el número de
trabajadores necesarios (recursos) y reducirse el número de
características que pueden incluirse en el producto (ámbito). El
administrador del proyecto determina entonces si este ajuste es
aceptable. Este concepto se denomina "delimitaciones triples de
administración del proyecto" o "triángulo del proyecto".
Durante el proceso de planificación, se deben enumerar las
delimitaciones del proyecto para asegurarse de que todos los
participantes del proyecto las conocen y tienen la oportunidad de hacer
observaciones acerca de las mismas.
También es importante que los participantes se pongan de acuerdo
sobre la forma en que se ha de responder a delimitaciones inesperadas
que puedan surgir durante el proyecto. Por ejemplo, si los costos
laborales resultan superiores a los previstos, los participantes pueden
desear reducir el ámbito del proyecto de ciertas maneras específicas
predefinidas.
Preparar un plan de administración del ámbito
Una vez identificados los objetivos, suposiciones y delimitaciones del
proyecto, está en condiciones de preparar un plan de administración del
ámbito. El ámbito del proyecto es la combinación de todos los
objetivos y tareas del proyecto con el trabajo necesario para su
ejecución, y el plan de administración del ámbito establece un
procedimiento para el tratamiento de los cambios que se efectúen en el
proyecto.
El plan de administración del ámbito es útil porque los equipos del
proyecto deben ajustar a menudo sus objetivos durante el mismo, y
todos los participantes del proyecto tienen que estar informados
puntualmente de los cambios que se introduzcan.
El plan de administración del ámbito puede incluir:
- Una evaluación de la probabilidad de que haya que cambiar el
ámbito, con qué frecuencia y en qué medida.
- Una descripción de cómo se identificarán y clasificarán los cambios del
ámbito. Por ejemplo, en un proyecto de construcción, puede establecer
que si el cliente solicita cambios del diseño con un costo inferior a 1.000
dólares, el capataz puede aprobarlos, pero si el costo es superior, el
administrador del proyecto y el cliente deben evaluar de nuevo el
ámbito del proyecto en términos de costo, recursos y otros factores.
- Un plan para determinar las acciones a emprender cuando se
identifique un cambio del ámbito (por ejemplo, informar del mismo al
patrocinador e impartir una orden de cambio del contrato).
Un plan de administración del ámbito bien preparado puede servir de
base para confeccionar el plan de emergencia del proyecto.
Crear un plan de proyecto
Cuando se hayan definido los objetivos del proyecto y decidido sus
fases principales, se puede comenzar a crear el plan.
Primero se especifica y organiza la lista de tareas que se deben realizar,
así como la duración de cada tarea. A continuación, se agrega al plan
personas, equipamiento y materiales, y sus costos. Después se asignan
estos recursos a las tareas. Con esta información, Microsoft Project crea
una programación. Se puede comprobar la programación y ajustarla
según sea necesario.
Los primeros pasos en la creación de una programación consisten en
iniciar un nuevo archivo, designar una fecha de comienzo o fin del
proyecto e introducir información general del proyecto.
B I B L I O G R A F Í A
Hallows, Jolyon. (1998).
Information Systems Project Management.
USA: American Management Association.

Contenu connexe

Tendances

PLANEACION DE PROYECTOS DE SOFTWARE
PLANEACION DE PROYECTOS DE SOFTWAREPLANEACION DE PROYECTOS DE SOFTWARE
PLANEACION DE PROYECTOS DE SOFTWAREAlberto Zurita
 
Planificacion del proyecto de software
Planificacion del proyecto de softwarePlanificacion del proyecto de software
Planificacion del proyecto de softwareMaricela Ramirez
 
Presentacion planificación de proyecto de software
Presentacion planificación de proyecto de softwarePresentacion planificación de proyecto de software
Presentacion planificación de proyecto de softwareJose Ignacio Rojas Henriquez
 
Gestión de los recursos materiales y financieros de un proyecto de desarrollo...
Gestión de los recursos materiales y financieros de un proyecto de desarrollo...Gestión de los recursos materiales y financieros de un proyecto de desarrollo...
Gestión de los recursos materiales y financieros de un proyecto de desarrollo...caasiekm1
 
Estimación para proyectos de software cap26
Estimación para proyectos de software cap26Estimación para proyectos de software cap26
Estimación para proyectos de software cap26DEBANI SALAS
 
Planificación de proyectos de software
Planificación de proyectos de software Planificación de proyectos de software
Planificación de proyectos de software Yaskelly Yedra
 
Planificación de proyectos de software
Planificación de proyectos de softwarePlanificación de proyectos de software
Planificación de proyectos de softwarehrubenleiva21
 
Estimación de Proyectos de Software
Estimación de Proyectos de SoftwareEstimación de Proyectos de Software
Estimación de Proyectos de SoftwareDaniel Valdivieso
 
Planteamiento del problema o necesidad que se pretende solucionar
Planteamiento del problema o necesidad que se pretende solucionarPlanteamiento del problema o necesidad que se pretende solucionar
Planteamiento del problema o necesidad que se pretende solucionarjuan carlos
 
Gestión de Proyectos Informáticos
Gestión de Proyectos InformáticosGestión de Proyectos Informáticos
Gestión de Proyectos InformáticosPilar Pardo Hidalgo
 
proyecto de sistemas o sofware
proyecto de sistemas o sofwareproyecto de sistemas o sofware
proyecto de sistemas o sofwaregueste38b69
 
Planeacion y elaboración de proyectos de software
Planeacion y elaboración de proyectos de softwarePlaneacion y elaboración de proyectos de software
Planeacion y elaboración de proyectos de softwareTtomas Carvajal
 
Gestión de proyectos
Gestión de proyectosGestión de proyectos
Gestión de proyectosM B
 
Procesos de Ingenieria de Software
Procesos de Ingenieria de SoftwareProcesos de Ingenieria de Software
Procesos de Ingenieria de SoftwareAngel Macas
 
analicis,diseño,software
analicis,diseño,softwareanalicis,diseño,software
analicis,diseño,softwarevanguevara
 
Conceptos sobre Gestión de Proyectos de Software
Conceptos sobre Gestión de Proyectos de Software Conceptos sobre Gestión de Proyectos de Software
Conceptos sobre Gestión de Proyectos de Software Joselito B
 
Estimación para Proyectos de Software
Estimación para Proyectos de SoftwareEstimación para Proyectos de Software
Estimación para Proyectos de SoftwareJohanna Caragolla
 

Tendances (19)

PLANEACION DE PROYECTOS DE SOFTWARE
PLANEACION DE PROYECTOS DE SOFTWAREPLANEACION DE PROYECTOS DE SOFTWARE
PLANEACION DE PROYECTOS DE SOFTWARE
 
Planificacion del proyecto de software
Planificacion del proyecto de softwarePlanificacion del proyecto de software
Planificacion del proyecto de software
 
Gestión de proyecto de software
Gestión de proyecto de softwareGestión de proyecto de software
Gestión de proyecto de software
 
Presentacion planificación de proyecto de software
Presentacion planificación de proyecto de softwarePresentacion planificación de proyecto de software
Presentacion planificación de proyecto de software
 
Gestión de los recursos materiales y financieros de un proyecto de desarrollo...
Gestión de los recursos materiales y financieros de un proyecto de desarrollo...Gestión de los recursos materiales y financieros de un proyecto de desarrollo...
Gestión de los recursos materiales y financieros de un proyecto de desarrollo...
 
Estimación para proyectos de software cap26
Estimación para proyectos de software cap26Estimación para proyectos de software cap26
Estimación para proyectos de software cap26
 
Planificación de proyectos de software
Planificación de proyectos de software Planificación de proyectos de software
Planificación de proyectos de software
 
Planificación de proyectos de software
Planificación de proyectos de softwarePlanificación de proyectos de software
Planificación de proyectos de software
 
Estimación de Proyectos de Software
Estimación de Proyectos de SoftwareEstimación de Proyectos de Software
Estimación de Proyectos de Software
 
Planteamiento del problema o necesidad que se pretende solucionar
Planteamiento del problema o necesidad que se pretende solucionarPlanteamiento del problema o necesidad que se pretende solucionar
Planteamiento del problema o necesidad que se pretende solucionar
 
Gestión de Proyectos Informáticos
Gestión de Proyectos InformáticosGestión de Proyectos Informáticos
Gestión de Proyectos Informáticos
 
proyecto de sistemas o sofware
proyecto de sistemas o sofwareproyecto de sistemas o sofware
proyecto de sistemas o sofware
 
Desarrollo de Sistemas de Información
Desarrollo de Sistemas de InformaciónDesarrollo de Sistemas de Información
Desarrollo de Sistemas de Información
 
Planeacion y elaboración de proyectos de software
Planeacion y elaboración de proyectos de softwarePlaneacion y elaboración de proyectos de software
Planeacion y elaboración de proyectos de software
 
Gestión de proyectos
Gestión de proyectosGestión de proyectos
Gestión de proyectos
 
Procesos de Ingenieria de Software
Procesos de Ingenieria de SoftwareProcesos de Ingenieria de Software
Procesos de Ingenieria de Software
 
analicis,diseño,software
analicis,diseño,softwareanalicis,diseño,software
analicis,diseño,software
 
Conceptos sobre Gestión de Proyectos de Software
Conceptos sobre Gestión de Proyectos de Software Conceptos sobre Gestión de Proyectos de Software
Conceptos sobre Gestión de Proyectos de Software
 
Estimación para Proyectos de Software
Estimación para Proyectos de SoftwareEstimación para Proyectos de Software
Estimación para Proyectos de Software
 

Similaire à Eq11 Traducción Cap3 Hallows Defining The Project

DEFINING THE PROJECT
DEFINING THE PROJECTDEFINING THE PROJECT
DEFINING THE PROJECTnohemizamudio
 
Alcance del proyecto y EDT
Alcance del proyecto y EDTAlcance del proyecto y EDT
Alcance del proyecto y EDTEdwin Ortega
 
proyectos informaticos
proyectos informaticosproyectos informaticos
proyectos informaticossopaipilla
 
Gestion de proyectos Informáticos
Gestion de proyectos InformáticosGestion de proyectos Informáticos
Gestion de proyectos InformáticosReimer Xavier
 
Conceptos relativos a la Administración de proyectos
Conceptos relativos a la Administración de proyectosConceptos relativos a la Administración de proyectos
Conceptos relativos a la Administración de proyectosCarlos Roa
 
Proyecto.
Proyecto.Proyecto.
Proyecto.yulis08
 
Apuntes proyectos.
Apuntes proyectos.Apuntes proyectos.
Apuntes proyectos.adproycom
 
AdministracióN Proyectos Desarrollo
AdministracióN Proyectos DesarrolloAdministracióN Proyectos Desarrollo
AdministracióN Proyectos Desarrolloadproycom
 
Clase 2 cómo iniciar el proyecto
Clase 2 cómo iniciar el proyectoClase 2 cómo iniciar el proyecto
Clase 2 cómo iniciar el proyectoexpert28
 
Gestión de proyectos de software - Subtema 3.1: Objetivo del proyecto
Gestión de proyectos de software - Subtema 3.1: Objetivo del proyectoGestión de proyectos de software - Subtema 3.1: Objetivo del proyecto
Gestión de proyectos de software - Subtema 3.1: Objetivo del proyectoJair Valenz
 
GRUPO czxc zxczxczxcxzcxzcxzcxzczxc7.pptx
GRUPO czxc zxczxczxcxzcxzcxzcxzczxc7.pptxGRUPO czxc zxczxczxcxzcxzcxzcxzczxc7.pptx
GRUPO czxc zxczxczxcxzcxzcxzcxzczxc7.pptxRonaldPereira30
 
Taller#1 planificacion del proyecto rocio lópez -leonela gomez.
Taller#1 planificacion del proyecto rocio lópez -leonela gomez.Taller#1 planificacion del proyecto rocio lópez -leonela gomez.
Taller#1 planificacion del proyecto rocio lópez -leonela gomez.ADriana LeOnela
 

Similaire à Eq11 Traducción Cap3 Hallows Defining The Project (20)

DEFINING THE PROJECT
DEFINING THE PROJECTDEFINING THE PROJECT
DEFINING THE PROJECT
 
Alcance del proyecto y EDT
Alcance del proyecto y EDTAlcance del proyecto y EDT
Alcance del proyecto y EDT
 
proyectos informaticos
proyectos informaticosproyectos informaticos
proyectos informaticos
 
Gestion de proyectos Informáticos
Gestion de proyectos InformáticosGestion de proyectos Informáticos
Gestion de proyectos Informáticos
 
Conceptos relativos a la Administración de proyectos
Conceptos relativos a la Administración de proyectosConceptos relativos a la Administración de proyectos
Conceptos relativos a la Administración de proyectos
 
Proyecto.
Proyecto.Proyecto.
Proyecto.
 
Apuntes proyectos.
Apuntes proyectos.Apuntes proyectos.
Apuntes proyectos.
 
AdministracióN Proyectos Desarrollo
AdministracióN Proyectos DesarrolloAdministracióN Proyectos Desarrollo
AdministracióN Proyectos Desarrollo
 
Proyectos informaticos
Proyectos informaticosProyectos informaticos
Proyectos informaticos
 
Trabajo planeamiento
Trabajo planeamientoTrabajo planeamiento
Trabajo planeamiento
 
Proyectos1
Proyectos1Proyectos1
Proyectos1
 
Clase 2 cómo iniciar el proyecto
Clase 2 cómo iniciar el proyectoClase 2 cómo iniciar el proyecto
Clase 2 cómo iniciar el proyecto
 
M.A.P.A
M.A.P.AM.A.P.A
M.A.P.A
 
Gestión de proyectos de software - Subtema 3.1: Objetivo del proyecto
Gestión de proyectos de software - Subtema 3.1: Objetivo del proyectoGestión de proyectos de software - Subtema 3.1: Objetivo del proyecto
Gestión de proyectos de software - Subtema 3.1: Objetivo del proyecto
 
GRUPO czxc zxczxczxcxzcxzcxzcxzczxc7.pptx
GRUPO czxc zxczxczxcxzcxzcxzcxzczxc7.pptxGRUPO czxc zxczxczxcxzcxzcxzcxzczxc7.pptx
GRUPO czxc zxczxczxcxzcxzcxzcxzczxc7.pptx
 
Proyecto informatico
Proyecto informaticoProyecto informatico
Proyecto informatico
 
Proyecto informatico
Proyecto informaticoProyecto informatico
Proyecto informatico
 
Proyectos de tecnología informática
Proyectos de tecnología informáticaProyectos de tecnología informática
Proyectos de tecnología informática
 
Taller#1 planificacion del proyecto rocio lópez -leonela gomez.
Taller#1 planificacion del proyecto rocio lópez -leonela gomez.Taller#1 planificacion del proyecto rocio lópez -leonela gomez.
Taller#1 planificacion del proyecto rocio lópez -leonela gomez.
 
Etapas de un proyecto
Etapas de un proyectoEtapas de un proyecto
Etapas de un proyecto
 

Plus de marcos_0887

Gep09 Eq11 T14 Control del Proyecto
Gep09 Eq11 T14 Control del ProyectoGep09 Eq11 T14 Control del Proyecto
Gep09 Eq11 T14 Control del Proyectomarcos_0887
 
Gep09 Eq11 T13 Hallows Cap 5 Running The Project
Gep09 Eq11 T13 Hallows Cap 5 Running The ProjectGep09 Eq11 T13 Hallows Cap 5 Running The Project
Gep09 Eq11 T13 Hallows Cap 5 Running The Projectmarcos_0887
 
Gep09 Eq11 T11 Gido Hallows
Gep09 Eq11 T11 Gido HallowsGep09 Eq11 T11 Gido Hallows
Gep09 Eq11 T11 Gido Hallowsmarcos_0887
 
Gep09 Eq11 L17 Consideracionessacercaderecursos
Gep09 Eq11 L17 ConsideracionessacercaderecursosGep09 Eq11 L17 Consideracionessacercaderecursos
Gep09 Eq11 L17 Consideracionessacercaderecursosmarcos_0887
 
Traducción Cap.9 Arquitectura de Integración de Procesos
Traducción Cap.9 Arquitectura de Integración de ProcesosTraducción Cap.9 Arquitectura de Integración de Procesos
Traducción Cap.9 Arquitectura de Integración de Procesosmarcos_0887
 
Cap.9 Arquitectura de Integración de Procesos
Cap.9 Arquitectura de Integración de ProcesosCap.9 Arquitectura de Integración de Procesos
Cap.9 Arquitectura de Integración de Procesosmarcos_0887
 
Preguntas - Understanding and Defining The Project
Preguntas - Understanding and Defining The ProjectPreguntas - Understanding and Defining The Project
Preguntas - Understanding and Defining The Projectmarcos_0887
 
Eq11 Presentacion Cap3 Hallows Defining The Project
Eq11 Presentacion Cap3 Hallows Defining The ProjectEq11 Presentacion Cap3 Hallows Defining The Project
Eq11 Presentacion Cap3 Hallows Defining The Projectmarcos_0887
 

Plus de marcos_0887 (8)

Gep09 Eq11 T14 Control del Proyecto
Gep09 Eq11 T14 Control del ProyectoGep09 Eq11 T14 Control del Proyecto
Gep09 Eq11 T14 Control del Proyecto
 
Gep09 Eq11 T13 Hallows Cap 5 Running The Project
Gep09 Eq11 T13 Hallows Cap 5 Running The ProjectGep09 Eq11 T13 Hallows Cap 5 Running The Project
Gep09 Eq11 T13 Hallows Cap 5 Running The Project
 
Gep09 Eq11 T11 Gido Hallows
Gep09 Eq11 T11 Gido HallowsGep09 Eq11 T11 Gido Hallows
Gep09 Eq11 T11 Gido Hallows
 
Gep09 Eq11 L17 Consideracionessacercaderecursos
Gep09 Eq11 L17 ConsideracionessacercaderecursosGep09 Eq11 L17 Consideracionessacercaderecursos
Gep09 Eq11 L17 Consideracionessacercaderecursos
 
Traducción Cap.9 Arquitectura de Integración de Procesos
Traducción Cap.9 Arquitectura de Integración de ProcesosTraducción Cap.9 Arquitectura de Integración de Procesos
Traducción Cap.9 Arquitectura de Integración de Procesos
 
Cap.9 Arquitectura de Integración de Procesos
Cap.9 Arquitectura de Integración de ProcesosCap.9 Arquitectura de Integración de Procesos
Cap.9 Arquitectura de Integración de Procesos
 
Preguntas - Understanding and Defining The Project
Preguntas - Understanding and Defining The ProjectPreguntas - Understanding and Defining The Project
Preguntas - Understanding and Defining The Project
 
Eq11 Presentacion Cap3 Hallows Defining The Project
Eq11 Presentacion Cap3 Hallows Defining The ProjectEq11 Presentacion Cap3 Hallows Defining The Project
Eq11 Presentacion Cap3 Hallows Defining The Project
 

Dernier

GESTIÓN POR PROCESOS - 09.12 y 16.12.23 - parte 2 - MILAGROS FERNANDEZ - PRES...
GESTIÓN POR PROCESOS - 09.12 y 16.12.23 - parte 2 - MILAGROS FERNANDEZ - PRES...GESTIÓN POR PROCESOS - 09.12 y 16.12.23 - parte 2 - MILAGROS FERNANDEZ - PRES...
GESTIÓN POR PROCESOS - 09.12 y 16.12.23 - parte 2 - MILAGROS FERNANDEZ - PRES...ssuser66a3da
 
GERENCIA DE OPERACIONES MBA ADMINISTRACION DE EMPRESAS
GERENCIA DE OPERACIONES MBA ADMINISTRACION DE EMPRESASGERENCIA DE OPERACIONES MBA ADMINISTRACION DE EMPRESAS
GERENCIA DE OPERACIONES MBA ADMINISTRACION DE EMPRESASSilvanabelenCumpasip
 
El Ejército y las Operaciones en el Ciberespacio
El Ejército y las Operaciones en el CiberespacioEl Ejército y las Operaciones en el Ciberespacio
El Ejército y las Operaciones en el CiberespacioEjército de Tierra
 
METODO MIXTOpresentaciondeadministracion.pptx
METODO MIXTOpresentaciondeadministracion.pptxMETODO MIXTOpresentaciondeadministracion.pptx
METODO MIXTOpresentaciondeadministracion.pptxBrayanParra38
 
Libros - Las 48 leyes del Poder vida.pdf
Libros - Las 48 leyes del Poder vida.pdfLibros - Las 48 leyes del Poder vida.pdf
Libros - Las 48 leyes del Poder vida.pdfomd190207
 
INTELIGENCIA EMOCIONAL -ADMINISTRACION.pdf
INTELIGENCIA EMOCIONAL -ADMINISTRACION.pdfINTELIGENCIA EMOCIONAL -ADMINISTRACION.pdf
INTELIGENCIA EMOCIONAL -ADMINISTRACION.pdfELISATORRES56
 
1 GENERALIDADES Bioestadística y demografia.pdf
1 GENERALIDADES Bioestadística y demografia.pdf1 GENERALIDADES Bioestadística y demografia.pdf
1 GENERALIDADES Bioestadística y demografia.pdfjoanjustiniano98
 
PPT Planilla Foro logistica (1).pptDMEDMEOD
PPT Planilla Foro logistica (1).pptDMEDMEODPPT Planilla Foro logistica (1).pptDMEDMEOD
PPT Planilla Foro logistica (1).pptDMEDMEODferchuxdlinda
 
LOS BANCOS EN PERÚ establece las normas para la contabilización de los invent...
LOS BANCOS EN PERÚ establece las normas para la contabilización de los invent...LOS BANCOS EN PERÚ establece las normas para la contabilización de los invent...
LOS BANCOS EN PERÚ establece las normas para la contabilización de los invent...EmelynYesmynVegaArre
 
INVESTIGACIÓN EN INGENIERIA - El Problema de investigación
INVESTIGACIÓN EN INGENIERIA - El Problema de investigaciónINVESTIGACIÓN EN INGENIERIA - El Problema de investigación
INVESTIGACIÓN EN INGENIERIA - El Problema de investigaciónGabrielaRisco3
 
CADENA DE SUMINISTROS DIAPOSITIVASS.pptx
CADENA DE SUMINISTROS DIAPOSITIVASS.pptxCADENA DE SUMINISTROS DIAPOSITIVASS.pptx
CADENA DE SUMINISTROS DIAPOSITIVASS.pptxYesseniaGuzman7
 
INSPECCION-PREOPERACIONAL DE PULIDORA.pdf
INSPECCION-PREOPERACIONAL DE PULIDORA.pdfINSPECCION-PREOPERACIONAL DE PULIDORA.pdf
INSPECCION-PREOPERACIONAL DE PULIDORA.pdffaguilarpgrarlboliva
 
Presentación Martin Purisaca - BCP...ppt
Presentación Martin Purisaca - BCP...pptPresentación Martin Purisaca - BCP...ppt
Presentación Martin Purisaca - BCP...pptjoseccampos94
 
modalidades de importaciones de productos
modalidades de importaciones de productosmodalidades de importaciones de productos
modalidades de importaciones de productosRaynelLpezVelsquez
 
Aprendizaje basado en proyectos. La vida no son asignaturas_CPAL_PERU.pdf
Aprendizaje basado en proyectos. La vida no son asignaturas_CPAL_PERU.pdfAprendizaje basado en proyectos. La vida no son asignaturas_CPAL_PERU.pdf
Aprendizaje basado en proyectos. La vida no son asignaturas_CPAL_PERU.pdfLizbethMuoz40
 
Regímenes laborales en el Perú actualizados al 2024
Regímenes laborales en el Perú actualizados al 2024Regímenes laborales en el Perú actualizados al 2024
Regímenes laborales en el Perú actualizados al 2024fanny vera
 
Unidad 1 Modelo de Internacionalizacion de la empresas.pdf
Unidad 1 Modelo de Internacionalizacion de la empresas.pdfUnidad 1 Modelo de Internacionalizacion de la empresas.pdf
Unidad 1 Modelo de Internacionalizacion de la empresas.pdfLuisFernandoRozasVil
 
EXPLICACIONES DE ASIENTOS CONTABLES DE SUELDOS Y JORNALES .pptx
EXPLICACIONES DE ASIENTOS CONTABLES DE SUELDOS Y JORNALES .pptxEXPLICACIONES DE ASIENTOS CONTABLES DE SUELDOS Y JORNALES .pptx
EXPLICACIONES DE ASIENTOS CONTABLES DE SUELDOS Y JORNALES .pptxFelicia Escobar
 
Evaluación y Mejora Continua Guía de Seguimiento y Monitoreo para Cursos de C...
Evaluación y Mejora Continua Guía de Seguimiento y Monitoreo para Cursos de C...Evaluación y Mejora Continua Guía de Seguimiento y Monitoreo para Cursos de C...
Evaluación y Mejora Continua Guía de Seguimiento y Monitoreo para Cursos de C...Oxford Group
 
Emprendedores peruanos, empresas innovadoras.pptx
Emprendedores peruanos, empresas innovadoras.pptxEmprendedores peruanos, empresas innovadoras.pptx
Emprendedores peruanos, empresas innovadoras.pptxFERNANDOMIGUELRIVERA1
 

Dernier (20)

GESTIÓN POR PROCESOS - 09.12 y 16.12.23 - parte 2 - MILAGROS FERNANDEZ - PRES...
GESTIÓN POR PROCESOS - 09.12 y 16.12.23 - parte 2 - MILAGROS FERNANDEZ - PRES...GESTIÓN POR PROCESOS - 09.12 y 16.12.23 - parte 2 - MILAGROS FERNANDEZ - PRES...
GESTIÓN POR PROCESOS - 09.12 y 16.12.23 - parte 2 - MILAGROS FERNANDEZ - PRES...
 
GERENCIA DE OPERACIONES MBA ADMINISTRACION DE EMPRESAS
GERENCIA DE OPERACIONES MBA ADMINISTRACION DE EMPRESASGERENCIA DE OPERACIONES MBA ADMINISTRACION DE EMPRESAS
GERENCIA DE OPERACIONES MBA ADMINISTRACION DE EMPRESAS
 
El Ejército y las Operaciones en el Ciberespacio
El Ejército y las Operaciones en el CiberespacioEl Ejército y las Operaciones en el Ciberespacio
El Ejército y las Operaciones en el Ciberespacio
 
METODO MIXTOpresentaciondeadministracion.pptx
METODO MIXTOpresentaciondeadministracion.pptxMETODO MIXTOpresentaciondeadministracion.pptx
METODO MIXTOpresentaciondeadministracion.pptx
 
Libros - Las 48 leyes del Poder vida.pdf
Libros - Las 48 leyes del Poder vida.pdfLibros - Las 48 leyes del Poder vida.pdf
Libros - Las 48 leyes del Poder vida.pdf
 
INTELIGENCIA EMOCIONAL -ADMINISTRACION.pdf
INTELIGENCIA EMOCIONAL -ADMINISTRACION.pdfINTELIGENCIA EMOCIONAL -ADMINISTRACION.pdf
INTELIGENCIA EMOCIONAL -ADMINISTRACION.pdf
 
1 GENERALIDADES Bioestadística y demografia.pdf
1 GENERALIDADES Bioestadística y demografia.pdf1 GENERALIDADES Bioestadística y demografia.pdf
1 GENERALIDADES Bioestadística y demografia.pdf
 
PPT Planilla Foro logistica (1).pptDMEDMEOD
PPT Planilla Foro logistica (1).pptDMEDMEODPPT Planilla Foro logistica (1).pptDMEDMEOD
PPT Planilla Foro logistica (1).pptDMEDMEOD
 
LOS BANCOS EN PERÚ establece las normas para la contabilización de los invent...
LOS BANCOS EN PERÚ establece las normas para la contabilización de los invent...LOS BANCOS EN PERÚ establece las normas para la contabilización de los invent...
LOS BANCOS EN PERÚ establece las normas para la contabilización de los invent...
 
INVESTIGACIÓN EN INGENIERIA - El Problema de investigación
INVESTIGACIÓN EN INGENIERIA - El Problema de investigaciónINVESTIGACIÓN EN INGENIERIA - El Problema de investigación
INVESTIGACIÓN EN INGENIERIA - El Problema de investigación
 
CADENA DE SUMINISTROS DIAPOSITIVASS.pptx
CADENA DE SUMINISTROS DIAPOSITIVASS.pptxCADENA DE SUMINISTROS DIAPOSITIVASS.pptx
CADENA DE SUMINISTROS DIAPOSITIVASS.pptx
 
INSPECCION-PREOPERACIONAL DE PULIDORA.pdf
INSPECCION-PREOPERACIONAL DE PULIDORA.pdfINSPECCION-PREOPERACIONAL DE PULIDORA.pdf
INSPECCION-PREOPERACIONAL DE PULIDORA.pdf
 
Presentación Martin Purisaca - BCP...ppt
Presentación Martin Purisaca - BCP...pptPresentación Martin Purisaca - BCP...ppt
Presentación Martin Purisaca - BCP...ppt
 
modalidades de importaciones de productos
modalidades de importaciones de productosmodalidades de importaciones de productos
modalidades de importaciones de productos
 
Aprendizaje basado en proyectos. La vida no son asignaturas_CPAL_PERU.pdf
Aprendizaje basado en proyectos. La vida no son asignaturas_CPAL_PERU.pdfAprendizaje basado en proyectos. La vida no son asignaturas_CPAL_PERU.pdf
Aprendizaje basado en proyectos. La vida no son asignaturas_CPAL_PERU.pdf
 
Regímenes laborales en el Perú actualizados al 2024
Regímenes laborales en el Perú actualizados al 2024Regímenes laborales en el Perú actualizados al 2024
Regímenes laborales en el Perú actualizados al 2024
 
Unidad 1 Modelo de Internacionalizacion de la empresas.pdf
Unidad 1 Modelo de Internacionalizacion de la empresas.pdfUnidad 1 Modelo de Internacionalizacion de la empresas.pdf
Unidad 1 Modelo de Internacionalizacion de la empresas.pdf
 
EXPLICACIONES DE ASIENTOS CONTABLES DE SUELDOS Y JORNALES .pptx
EXPLICACIONES DE ASIENTOS CONTABLES DE SUELDOS Y JORNALES .pptxEXPLICACIONES DE ASIENTOS CONTABLES DE SUELDOS Y JORNALES .pptx
EXPLICACIONES DE ASIENTOS CONTABLES DE SUELDOS Y JORNALES .pptx
 
Evaluación y Mejora Continua Guía de Seguimiento y Monitoreo para Cursos de C...
Evaluación y Mejora Continua Guía de Seguimiento y Monitoreo para Cursos de C...Evaluación y Mejora Continua Guía de Seguimiento y Monitoreo para Cursos de C...
Evaluación y Mejora Continua Guía de Seguimiento y Monitoreo para Cursos de C...
 
Emprendedores peruanos, empresas innovadoras.pptx
Emprendedores peruanos, empresas innovadoras.pptxEmprendedores peruanos, empresas innovadoras.pptx
Emprendedores peruanos, empresas innovadoras.pptx
 

Eq11 Traducción Cap3 Hallows Defining The Project

  • 1. UNIVERSIDAD VERACRUZANA SISTEMAS COMPUTACIONALES ADMINISTRATIVOS E.E.: Gestión y Evaluación de Proyectos Tarea 4: Definiendo el proyecto Catedrático: Dr. Carlos Torres Gastelú Alumnos: Ocampo Pierre Karina Ramírez Díaz Juan Manuel Rosete Osorio Marcos Adrián Bloque: 8 Equipo: 11 H. Veracruz, Ver. 18 de Marzo del 2009 Capitulo 3 Definiendo el Proyecto
  • 2. Muchos proyectos se gestionan por el principio del explorador principio: "Hay que moverse y ver qué pasa." Si bien este enfoque puede ser excitante, sobre todo a las dos de la mañana, antes de que un hito entregable sea debidamente apto, es raro que se produzca lo que quiere el cliente. Definir el proyecto consiste en averiguar lo que es. Puede parecer elemental señalar que con el fin de satisfacer a un cliente, es necesario identificar lo que se va a hacer, pero con demasiada frecuencia, las necesidades del cliente se van convirtiendo en una clara aplicación. Antes que sea demasiado tarde. Existe una actitud de "hacerlo antes" por parte de su equipo (incluido usted). Usted puede, por lo tanto, ser engañado al creer que porque usted entiende la aplicación (por ejemplo, inventario), usted sabe lo que el cliente necesita y que no tiene mucho sentido en la adopción de un valioso tiempo pidiendo preguntas tontas. Cuando usted y su equipo abordan los problemas, que se centran en las soluciones técnicas en lugar de las necesidades del cliente. Si va a estar Entendiendo el Proyecto Entendiendo el Proyecto Definiendo el Proyecto Definiendo el Proyecto Planeando el Proyecto Planeando el Proyecto Corriendo el Proyecto Corriendo el Proyecto ¿Tengo definidos los entregables del proyecto? ¿Tengo establecido el ambiente en el que se desarrollará el sistema y/o proyecto? ¿Tengo determinado cómo serán generados y aprobados los entregables? ¿Cómo será definida la estructura y organización del equipo del cliente? ¿Tengo definidos los entregables del proyecto? ¿Tengo establecido el ambiente en el que se desarrollará el sistema y/o proyecto? ¿Tengo determinado cómo serán generados y aprobados los entregables? ¿Cómo será definida la estructura y organización del equipo del cliente? AQUÍ VAMOS!
  • 3. enfocada al cliente y, a continuación, todos los problemas que usted y su equipo van a discutir deben resolverse teniendo en cuenta lo que es mejor para el cliente, no sobre la base de ingenio técnico. El proyecto es apresurado en la salida. Es casi imposible para usted cumplir con los plazos y la inminente inevitabilidad de la noche y los fines de semana. Si este es el caso, usted está siendo presionado para "estar en lo cierto" y para producir algo que sea rápido, y se llega a considerar que la desaceleración de hablar con el cliente es como una carrera de limitación de movimiento. Su cliente o su gestión (o usted) cree que el único producto valioso del equipo de sistemas es el código y que todo lo demás es preámbulo costoso, consume tiempo, y de un valor limitado. Si ese es el caso, toda acción que retrase el comienzo de los trabajos "reales" será desperdiciados y no deseados. Si cualquiera de estas condiciones es verdadera, entonces usted tiene fuerzas por las que se esta desviando las bases necesarias. Contrarrestar la fuerza de cada uno de ellos es insistir en que los requisitos del proyecto se definen claramente y sin ambigüedades como sea posible. Existe una nueva amenaza para una definición clara de los resultados finales. Muchos proyectos están actualmente estructuradas alrededor de alguna forma de desarrollo iterativo de prototipos en los que se preparan, revisan y, sucesivamente refinan todos los prototipos se transforma en el sistema final. En este enfoque para el desarrollo de sistemas, el prototipo es a menudo utilizado para identificar las normas y procedimientos, lo que lleva a la tentación de despedir a las necesidades de definir los requisitos, ya que "se convertirán claramente como evolucionará el prototipo". Si usted entiende este argumento, señala que el desarrollo iterativo es una manera de alcanzar el resultado final deseado, pero el resultado aún está por definirse. De hecho, este enfoque a las necesidades de los proyectos define de forma mas clara la meta final.
  • 4. Para definir el proyecto, usted debe definir, documentar y obtener la aprobación del cliente en dos aspectos: los productos y el alcance. Estos se analizan más adelante en este capítulo. Sin embargo, la definición de un proyecto es más que la definición de los resultados y el alcance. También es necesario definir la forma en que el proyecto se llevará a cabo. En concreto, deberá establecer: • Cómo va a gestionar las solicitudes de cambios en el ámbito de aplicación. • La forma en que el cliente se examinará y aprobará los resultados • Para proyectos de desarrollo, ¿qué tipo de enfoque del proyecto se llevará a cabo. Estos son los temas del capítulo 3. Una lista al final le ayudará a asegurarse de que usted y el cliente están de acuerdo sobre las cuestiones importantes en el proyecto. DEFINIENDO DE LOS ENTREGABLES En la vista, la definición de los resultados debe ser simple. El cliente quiere una recomendación sobre un paquete de un programa informático, un conjunto de modelos, una tecnología de la arquitectura, o un sistema de aplicación que consiste de código y documentación. Si bien estos productos pueden ser complejos para la producción, la definición de ellos parece ser sencilla. Lamentablemente, el mundo de los proyectos, por lo general conduce directo al fracaso.
  • 5. Definir un proyecto Durante la fase de planificación de proyectos que tienen una duración significativa o requieren los servicios de muchas personas, es importante definir los objetivos, las suposiciones y las delimitaciones del proyecto. Definir los objetivos del proyecto Unos objetivos de proyecto claros son cruciales pues el éxito del proyecto vendrá determinado por el grado de cumplimiento de los mismos. Un objetivo de proyecto claro es específico y mensurable. Deben evitarse objetivos imprecisos como "Crear resultados modernos". Los objetivos de un proyecto pueden incluir: - Una lista de resultados del proyecto. - Fechas de cumplimiento específicas, tanto para la finalización del proyecto como para los hitos intermedios. - Criterios de calidad específicos que deben cumplir los resultados. - Límites de costo que no debe sobrepasar el proyecto. Para que los objetivos resulten eficaces, es importante que todos los participantes del proyecto estén oficialmente de acuerdo con ellos. A menudo, el administrador del proyecto crea un documento de objetivos que se convierte en una parte permanente del proyecto. Tras crear un documento de objetivos en un programa diferente de Microsoft Project, puede adjuntarlo al archivo de proyecto para tener acceso a él de forma sencilla.
  • 6. Definir las suposiciones del proyecto Durante la etapa de planificación de un proyecto, probablemente surgirán muchas cuestiones importantes sin respuesta; por ejemplo, cuándo estarán disponibles los recursos clave para iniciar el trabajo, y cuánto tiempo llevará un nuevo proceso. Para comenzar la planificación, se hacen conjeturas hipotéticas y, a continuación, se utilizan esas estimaciones para crear la programación. Es importante hacer un seguimiento de las suposiciones que se hacen de manera que: - Los participantes del proyecto puedan criticarlas y, después, apoyar formalmente un conjunto de suposiciones del proyecto. - Se pueda actualizar la programación cuando se disponga de información adicional sobre esos factores. Hay que tener en cuenta las siguientes áreas del proyecto para identificar suposiciones subyacentes: - Entregas de otros proyectos o departamentos: Si el proyecto va a depender del trabajo de otras personas, ¿son conscientes dichas personas de esta dependencia y están de acuerdo con las fechas de entrega establecidas? - Disponibilidad y uso de recursos (incluyendo personas, materiales y equipamiento): Si algunas de las personas que van a trabajar en el proyecto están bajo otro cargo, ¿a cargo de quién están? Y, ¿ha aprobado esa persona la utilización de estos recursos? - Duraciones de las tareas: ¿Están fundamentadas las estimaciones de tareas en una información sólida o en conjeturas?
  • 7. - Costos del proyecto: ¿Qué importancia tiene el costo en el proyecto? ¿Quién debe aprobar el presupuesto o aumentarlo si es necesario? - Tiempo disponible: Si se está trabajando teniendo presente una fecha límite conocida, ¿se puede completar de forma realista todas las tareas con un nivel aceptable de calidad? - Resultados: ¿Cumple el resultado esperado las expectativas del cliente y de otros participantes? Si se deben hacer concesiones en el resultado, ¿están de acuerdo los participantes sobre los aspectos del resultado en que se han de hacer las concesiones en primer lugar? Estos son unos pocos ejemplos de los asuntos a considerar antes de empezar un proyecto complejo. El éxito del proyecto depende en último término de la identificación de suposiciones y de la realización de planes alternativos de seguridad, así como de llevar a cabo el proyecto tal como fue planeado. Definir las delimitaciones del proyecto Las delimitaciones en un proyecto son factores que pueden restringir las opciones del administrador del proyecto. Normalmente, las tres delimitaciones principales son: - Programación, como una fecha de fin fija o una fecha límite para un hito principal. - Recursos (materiales, instalaciones, equipamiento y personal, así como los costos asociados), como un presupuesto preestablecido. - Ámbito, como un requisito de realización de tres modelos del producto.
  • 8. Un cambio en una de estas delimitaciones afecta normalmente a las otras dos, y también afecta a la calidad total. Por ejemplo, si decrece la duración del proyecto (programación), puede aumentar el número de trabajadores necesarios (recursos) y reducirse el número de características que pueden incluirse en el producto (ámbito). El administrador del proyecto determina entonces si este ajuste es aceptable. Este concepto se denomina "delimitaciones triples de administración del proyecto" o "triángulo del proyecto". Durante el proceso de planificación, se deben enumerar las delimitaciones del proyecto para asegurarse de que todos los participantes del proyecto las conocen y tienen la oportunidad de hacer observaciones acerca de las mismas. También es importante que los participantes se pongan de acuerdo sobre la forma en que se ha de responder a delimitaciones inesperadas que puedan surgir durante el proyecto. Por ejemplo, si los costos laborales resultan superiores a los previstos, los participantes pueden desear reducir el ámbito del proyecto de ciertas maneras específicas predefinidas.
  • 9. Preparar un plan de administración del ámbito Una vez identificados los objetivos, suposiciones y delimitaciones del proyecto, está en condiciones de preparar un plan de administración del ámbito. El ámbito del proyecto es la combinación de todos los objetivos y tareas del proyecto con el trabajo necesario para su ejecución, y el plan de administración del ámbito establece un procedimiento para el tratamiento de los cambios que se efectúen en el proyecto. El plan de administración del ámbito es útil porque los equipos del proyecto deben ajustar a menudo sus objetivos durante el mismo, y todos los participantes del proyecto tienen que estar informados puntualmente de los cambios que se introduzcan. El plan de administración del ámbito puede incluir: - Una evaluación de la probabilidad de que haya que cambiar el ámbito, con qué frecuencia y en qué medida. - Una descripción de cómo se identificarán y clasificarán los cambios del ámbito. Por ejemplo, en un proyecto de construcción, puede establecer que si el cliente solicita cambios del diseño con un costo inferior a 1.000 dólares, el capataz puede aprobarlos, pero si el costo es superior, el administrador del proyecto y el cliente deben evaluar de nuevo el ámbito del proyecto en términos de costo, recursos y otros factores. - Un plan para determinar las acciones a emprender cuando se identifique un cambio del ámbito (por ejemplo, informar del mismo al patrocinador e impartir una orden de cambio del contrato). Un plan de administración del ámbito bien preparado puede servir de base para confeccionar el plan de emergencia del proyecto.
  • 10. Crear un plan de proyecto Cuando se hayan definido los objetivos del proyecto y decidido sus fases principales, se puede comenzar a crear el plan. Primero se especifica y organiza la lista de tareas que se deben realizar, así como la duración de cada tarea. A continuación, se agrega al plan personas, equipamiento y materiales, y sus costos. Después se asignan estos recursos a las tareas. Con esta información, Microsoft Project crea una programación. Se puede comprobar la programación y ajustarla según sea necesario. Los primeros pasos en la creación de una programación consisten en iniciar un nuevo archivo, designar una fecha de comienzo o fin del proyecto e introducir información general del proyecto.
  • 11. B I B L I O G R A F Í A Hallows, Jolyon. (1998). Information Systems Project Management. USA: American Management Association.