Archivo de la categoría: Gestión de Proyectos

Gestión de Proyectos

Maestría en Gestión y Política de la Innovación y la Tecnología

Gracias al FINCYT y CONCYTEC se ha formado en el 2010 una maestría enfocada en la creación y gestión de la innovación. Va muy de la mano con la labor del emprendimiento, de la creación de empresas de base tecnológica.

Esta maestría no es “de Ciencias” ni “de Letras”, es una maestría interdisciplinaria. Compartimos el enlace a la maestría en la PUCP.

Maestría en Gestión y Política de la Innovación y la Tecnología – PUCP

Es muy importante que se estimule la empoderación de las personas con las capacidades que esta maestría brinda. Es genial que haya una beca CONCYTEC de cobertura de 100%, estipendio mensual y seguro de salud.

Les invitamos a revisar el Plan de estudios. Y más aún la Descripción de cursos.

Destacamos algunos cursos obligatorios

  • Gestión de la tecnología y la innovación: Conceptos de ciencia. Herramientas para la gestión de los recursos tecnológicos…
  • Política científica y tecnología: El papel de la innovación, la ciencia y la tecnología en el desarrollo económico, en la competitividad y en la globalización…
  • Ciencia, Tecnología y Desarrollo: Perspectivas históricas sobre el desarrollo científico y tecnológico. Fundamentos y principios de la filosofía de la ciencia. El desarrollo científico y tecnológico en las teorías del desarrollo. Tendencias del desarrollo científico y tecnológico en las sociedades contemporáneas…

Destacamos también algunos cursos electivos

  • Creación de empresas de base tecnológica
  • Financiamiento de la innovación y el desarrollo tecnológico
  • Marketing de la innovación
  • Cooperación internacional
  • Crecimiento y desarrollo económico

¿Qué opinas de esta maestría?

¿Has visto la Maestría en Políticas y Gestión de la Ciencia, Tecnología e Innovación de la UP Cayetano Heredia?

 

¿Cómo ejecutar un proyecto en la empresa?

¿cómo ejecutar un proyecto en la empresa?

 

Revisamos un artículo que consigue, a base de simplificaciones, explicar la gestión de proyectos. Acude a argumentos que surgen en proyectos pequeños pero que en líneas generales están en todos los proyectos. Es que cada proyecto es una historia y hay historias de varios meses o años y una página es chocante.

El artículo es bueno y lo veo como un intro para quienes desean entender la función del gestor de proyectos o quienes por su propia cuenta deseen ser metódicos en la gestión de proyectos.

 

Carlos Acuña, director de la consultora PM Certifica señala que el error más frecuente cuando se implementa un proyecto en una empresa es no definir un plan y tratar de realizar el trabajo sirviéndose simplemente de la intuición. Los errores pueden ser más esenciales como no encontrar una misión clara de la empresa para que el proyecto conjugue. Aunque ya sabemos que las empresas cuando no acuden a la gestión de proyectos con sus documentos, esquemas, esbozos, requerimientos es porque están en el nivel de no saber que hacer.

 

 

Veamos los pasos.

 

1. Seleccionar la mejor opción

Se debe evaluar el costo/beneficio. Ambos valores a partir de sus componentes deben ser validados por las personas involucradas. El gestor con experiencia debe convencer de lo que sabe que es bueno.

Los objetivos y criterios de éxito deben quedar establecidos. Así se puede calificar las acciones y tener afirmar la consecución de lo buscado.

Tiempo y presupuesto son los recursos con los que generalmente se cuenta. Los diversos proyectos simultáneos suelen compartir recursos. Entre los gestores podría haber esa fea práctica de pelearse los recursos. A la empresa “le conviene” porque recorta gastos en extremo, y claro… consigue algo del valor que invirtió.

2. Planificar el proyecto

1. Definición de etapas. Consiguen sencillez a todo nivel. Ya que a cada punto los cambios son múltiples: de personal, de recursos, de motivación, etc. Los entregables le hacen bien al equipo de trabajo y a quienes aprueban el proyecto en cada fase.

2. Estimación de recursos. El cronograma. La empresa ya cuenta con un flujo de recursos, una dinámica por ejemplo que define la fecha en la que se contará con una herramienta o con una cantidad de profesionales a disposición. Son puntos que se deben contrastar con el plan teórico de que todo se sucede con inmediatez, es un plan lejano de la realidad.

3. Análisis de riesgo. En las reuniones irán surgiendo comentarios, dudas. Incluso desde la concepción del proyecto se considerarán oportunidades pero con condiciones de tiempo, por ejemplo. Tenerlos por escrito nos ayudará a definir el peligro de cada riesgo y también a despreocuparnos cuando un elemento haya dejado de ser una amenaza.

4. Métricas de calidad. Los gestores idealistas o perfeccionistas podrían aquí crear el mayor riesgo oculto. La empresa confía pero los costos de hacer algo muy bueno pueden no estar en planes de una empresa regular o de media tabla. Saber en qué cancha se está jugando es importantísimo, incluso para aceptar el proyecto. Proyecto y producto son monitoreados con estas métricas.

3. Ejectuar y controlar

Oh! esto está bien orientado al PMBOK, página 1. Con los resultados se debe contrastar el plan y verificar la triple condición de Costo, Tiempo y Alcance.

Se deben tomar las medidas correctivas necesarias y actualizar el estado del proyecto. La comunicación a los clientes del proyecto se realiza con esta información. Carlos indica que es crítica la verificación de que los interesados hayan sido informados de avances y cambios . Así es, parece sencillo pero en la ejecución de proyectos los interesados empiezan a dejar a criterio de los gestores el estado del proyecto y la postergación de reuniones de información se dan una y otra vez. Con resúmenes automatizados se corre el riesgo que todo quede en la bandeja, sin leer. Comentábamos en un artículo anterior sobre liderazgo en las decisiones que las malas noticias no deben de llegar de la noche a la mañana. No debemos tener temor que un proyecto se cancele. Así son las cosas y las personas que financian pueden tener decisiones que obedecen a criterios financieros o de especulación.

4. Cerrar el proyecto

Cerrar es bueno pues el portafolio de proyectos se alimenta de todo un nuevo set de lecciones aprendidas y herramientas disponibles que mejoran aspectos fundamentales en la gestión de costos para proyectos próximos. Se liberan recursos y nos da la oportunidad para nuevos desafíos. En proyectos muy grandes un cierre de un proyecto puede que solo sea el cierre de uno de los proyectos dentro de ese megaproyecto.

En términos prácticos, debe existir una transferencia al área de operaciones y mantenimiento.

Los visionarios consideran proyectos y empresas que duran, por lo tanto estos ciclos pueden ser parte de otros mayores a nivel de años

Un abrazo a los gestores PMI, a los empíricos, a los equipos de gestión. Una noble labor que con capacidad y ética hace que las cosas se hagan. Para muestra un botón, allí tenemos los millones del estado peruano que no se utilizan y falta revolucionar la educación, avanzar kilómetros de infraestructuras energéticas, de transporte, de comunicaciones. Y por otro lado en el caso de los más pequeños están los costos enormes que hasta los hacen quebrar, y punto a punto se detiene la economía.

 

 

Foto del artículo en el diario

Miércoles 22 en Infosoft

Recomiendo las siguientes conferencias y charlas para la jornada del miércoles 22 en Infosoft 2012 http://infosoft.inf.pucp.edu.pe/

 

Conferencia (Auditorio de Ingeniería)

Mobile Marketing: Utilizando las tecnologías móviles en marketing
Mobile Experience: Brindar una experiencia de usuario distinta
De 4 a 6 pm

 

(Charla)

Workshop Agile
Salón B101
De 5 a 10 pm

 

Sobre juegos/videojuegos tenemos dos conferencias (Auditorio de Ingeniería)

Industria de juegos en Latinoamérica y el Mundo
De 3 a 4 pm

Experiencias de Bamtang Games en la industria de videojuegos
De 8 a 9:30 pm

PMBOK vs Scrum

Expondré el porqué de Scrum como metodología adecuada para un proyecto de fin de carrera como es una tesis universitaria. Específicamente para uno que incluye un desarrollo en el área de Tecnologías de la Información.

En principio la metodología sugerida por el PMBOK supone:
Especialización: Miembros de equipo y roles bien delimitados y casi independientes lo que no considera una interacción cercana entre roles.
Fases: Delimitadas y rígidamente definidas, por lo que las tareas se concluyen en una fase y la acción de los roles se encuentra encasillada en una o más fases.
Requisitos detallados: Los requerimientos llegan al equipo de desarrollo a través de un artefacto. El cliente no interactúa estrechamente con el producto durante su desarrollo.
Seguimiento del plan: No se experimenta con opciones atractivas que se puedan presentar durante el transcurso del proyecto sino que se controla rígidamente el plan establecido.

En contraposición Scrum conssidera:

Solapamiento de actividades

Scrum establece ciclos en los que las fases se solapan de forma muy amplia lo que permite actualizar los requerimientos del proyecto, ajustar la planificación e incluso poder reformular el alcance. De esta forma, más que fases que se realizan de forma secuencial, se tienen actividades que se ejecutan en el momento en que se requieren. Educción de requisitos, análisis, codificación, pruebas e integración se
van realizando en cada momento según las necesidades en la evolución del proyecto. Todo esto está guiado por la gestión del alcance que otorga principalmente la exploración medida de actividades. Si se presenta la oportunidad de avanzar algún aspecto del proyecto sin correr riesgos pues este avance se realiza hasta que se vea la dimensión real del aspecto referido y plantear la planificación más adecuada en el contexto correspondiente y tratando de aprovechar los avances completados.

Visión del producto

Queda claro que se busca obtener un producto. La afirmación del concepto del producto tiene mucho más peso que los requisitos específicos del sistema. Se hace necesaria la dirección estratégica ante la ausencia de un plan detallado.

Roles

Para Scrum se considera su compatibilidad con un equipo multidisciplinar. Para el caso de una tesis, el tesista es el único encargado de los roles al interior del proyecto.
Otros roles pertenecen al asesor, asesores que realizarán correcciones al borrador del documento de tesis y el jurado.
– El asesor es cliente del documento de tesis y del producto del proyecto.
– El jurado es cliente del proyecto en su conjunto.
– Los otros asesores que realizarán una corrección al borrador del documento es un cliente no del proyecto sino de su propia apreciación del documento de tesis. Se debe atender sus apreciaciones en la medida que su posición es tan externa como lo es la de los miembros del jurado del proyecto de tesis.
El equipo de desarrollo es auto-organizado y en el caso particular de este proyecto es la unidad auto-organizada representada por el tesista.

Adaptación a los cambios

Pueden ser modificados, dejados de lado o cambiados:
– La elaboración del documento por su correspondencia con el producto a desarrollar.
– La selección de herramientas de desarrollo del producto y de gestión del proyecto.
– El software de terceros.
– El alcance hasta una etapa temprana y fijada del proyecto.

La modificación de un requisito no existe como tal ya que no ha existido la fase de requisitos tradicional sino que se ve enriquecida para concretar la visión del producto.
La incertidumbre es observada constantemente y por eso se permite el descubrimiento paulatino durante el desarrollo y se tiene cuidado con las circunstancias que se van produciendo.
El principal motivo para la elección de Scrum es que el margen de libertad amplio es propicio para que los encargados del proyecto aporten con su ingenio y compromiso.

Por ser un proyecto unipersonal son importantes las disciplinas de
Autocontrol: Se genera un ambiente de responsabilidad y de gusto por el trabajo que se realiza.
Autosuperación: Se desarrollan soluciones que son evaluadas, analizadas y mejoradas.

Por ser un proyecto único se considera:
– Muchos proyectos, como una tesis, no son parte de procesos industriales y no es el plan producir muchos sino un único producto, es un proyecto particular.

De acuerdo al Manifiesto Ágil se reconoce valor en los procesos formales que sugiere el PMBOK pero que considera preferibles otros aspectos:
Individuos y su interacción frente a Procesos y herramientas
Software que funciona frente a Documentación exhaustiva
Colaboración con el cliente frente a Negociación contractual
Respuesta al cambio frente a Seguimiento de un plan

PeruBlogs Tag: Scrum PMBOK Tesis Proyecto de Fin de Carrera Ventajas Comparación

BlogsPeru Tag: [Scrum] [PMBOK] [Tesis] [Proyecto de Fin de Carrera] [Ventajas] [Comparación]

Scrum

Scrum es una metodología de gestión de proyectos de software y es por eso que se percibe más cercana al desarrollo de la solución que la metología sugerida en el PMBOK, que es más genérica.

Roles

Roles en Scrum

Dueño del Producto mantiene la orientación del equipo hacia los requerimientos del cliente. El Product Backlog está a su cargo.
Scrum Master es quién mantiene la correcta aplicación de las prácticas Scrum al interior del equipo.
Equipo Scrum, dentro del cual están los desarrolladores.
– Los Usuarios y Clientes también son roles considerados en la metodología Scrum.

Artefactos

Artefactos en Scrum

Los artefactos principales son:
Product Backlog: Es una lista con las funcionalidades del sistema con sus correspondientes niveles de prioridad. Nuevas funcionalidades pueden ser adicionadas a esta lista.
Sprint Backlog: Es un documento detallado que indica la forma en la que se van a cubrir los requerimientos. Las tareas no deben ser demasiado extensas por lo que sí se admite que sean numerosas.

PeruBlogs Tag: Scrum Gestión de Proyectos de Software Metodología Ágil Gestión Ágil

BlogsPeru Tag: [Scrum] [Gestión de Proyectos de Software] [Metodología Ágil] [Gestión Ágil]

PMBOK

Aquí comparto con ustedes una breve reseña sobre las prácticas expuestas en el PMBOK.

El PMBOK, cuya referencia en español es Guía de Fundamentos de la Dirección de Proyectos, es una publicación del Instituto de Dirección de Proyectos (PMI) que es una organización sin fines de lucro de origen estadounidense y de presencia actual mundial.

PMBOK [PMB2004] define proyecto como un esfuerzo temporal tomado para crear un producto, servicio o resultado único.

Para enfocar el análisis de la gestión plantea la idea de la restricción desde tres perspectivas:
• Alcance: Describe claramente el objetivo del proyecto.
• Tiempo: Enfoca el tiempo asignado al proyecto.
• Costo: Observa el costo involucrado.

Alcance, Costo y Tiempo
Figura 1.1: Triple Restricción [MYM]

De acuerdo al PMBOK la gestión de proyectos agrupa los procesos en cinco grupos que son:
• Procesos de iniciación
• Procesos de seguimiento y control
• Procesos de planificación
• Procesos de ejecución
• Procesos de cierre

Grupos de Procesos de la Gestión de Proyectos en la 
metodologia PDCA
Figura 1.2: Grupos de Procesos de la Gestión de Proyectos en la metodología PDCA [PMB2004]

Las áreas de conocimiento en la gestión de proyectos son:
• Gestión del Alcance
• Gestión de Tiempos
• Gestión de Costos
• Gestión de la Calidad
• Gestión de los Recursos Humanos
• Gestión de las Comunicaciones
• Gestión de los Riesgos
• Gestión de las Adquisiciones
• Gestión de la Integración

Las áreas de dominio requerido por el equipo de proyecto son:
• Habilidades Interpersonales
• Conocimiento y Habilidades de Gestión
• Entendimiento del Entorno del Proyecto
• Conocimiento aplicado en el Área, Estándares y Regulaciones

De acuerdo a [PMTIC] se debe pensar en un modelo simplificado para pequeños proyectos de Tecnologías de Información.

Relación entre Grupos de procesos y Áreas del Conocimiento
Figura 1.3: Relación entre Grupos de procesos y Áreas del Conocimiento

La figura 1.3 muestra la forma en la que intervienen los Grupos de Procesos en cada Área de Conocimiento.

De acuerdo a [WPM] se debe enfatizar en:
• Entendimiento de lo que se hace
• Gestión del Riesgo
• Gestión del Cliente
• Control de Versiones

Fuentes:

[PMB2004]
Título: A Guide to the Project Management Body of Knowledge
Edición/Versión: Third Edition
Editorial/Grupo: Project Management Institute
Fecha: 2004

[PMTIC]
Título: Modelo Simplificado para la gestión de pequeños proyectos de Tecnologías de Información
Contexto: Congreso Nacional de Gerencia de Proyectos PMI 2007
Enlace: http://www.scribd.com/doc/3365954/ModSimp-TICs-PMI-Peru-Congreso-2007
Día de acceso: 16/07/2008

[WPM]
Título: Web Project Management
Contexto: TODcon en Orlando
Enlace: http://www.slideshare.net/jrrodgers/web-project-management-todcon2008
Día de acceso: 16/07/2008

PeruBlogs Tag: Proyectos PMBOK Dirección de Proyectos Gestión de Proyectos PMI Proyectos Web Proyectos TI Proyectos de Tecnologías de Información

BlogsPeru Tag: [Proyectos] [PMBOK] [Dirección de Proyectos] [Gestión de Proyectos] [PMI] [Proyectos Web] [Proyectos TI] [Proyectos de Tecnologías de Información]