Se ha formulado un cuestionario tomando en cuenta los puntos más importantes de la gestión de proyectos de acuerdo con el PMBOK.
A. CUESTIONARIO 01
En el ANEXO I, se adjunta el cuestionario, las preguntas que han sido formuladas han sido tomando en cuenta los puntos más importantes en la gestión exitosa de los proyectos, se han formulado un total de 40 preguntas, que involucra a todas las áreas de conocimiento de la guía del PMBOK. A continuación, se indican algunas consideraciones tomadas en cuenta para formular el cuestionario:
Las alternativas de las respuestas se han establecido en relación a la escala Likert del 1 al 5 según el manejo de la gestión de proyectos.
Tabla 3
Valoración y Nivel de Gestión
Nivel de gestión de proyectos
Valoración de las respuestas 5 Excelente 4 Bueno 3 Regular 2 Malo 1 Deficiente Elaboración propia
La pregunta con más de una respuesta no será calificada
Cada pregunta tiene un peso asociado a la importancia que esta tiene en la gestión de proyectos:
Tabla 4
Ponderacion y Nivel de importancia
Nivel de importancia en la gestión de proyectos Ponderación de las preguntas 7 Muy importante 5 Importante 3 Regular importancia 1 Poco importante Elaboración propia
En algunas respuestas abiertas se ha agrupado en relación a la similitud que tengan en la respuesta de los encuestados
a. Herramienta de análisis: Terminada la recopilación de la información se ha procedido a clasificarla en MS Excel 2016. Se estableció para cada una de las instituciones un cuadro en donde se refleja el número de preguntas totales de la encuesta, los puntajes de cada una, así como el valor de cada alternativa (para todos igual), los valores de las alternativas marcadas con sus respectivos pesos, el puntaje total mínimo, puntaje total máximo de cada pregunta y el puntaje total obtenido.
b. Formula de Puntuación
Una vez obtenido el puntaje total mínimo, puntaje total máximo, puntaje total obtenido, se elabora un cuadro de comparaciones y se evalúa en forma porcentual con la siguiente formula
Donde:
PT: puntaje total Pmin: puntaje mínimo Pmax: puntaje máximo
Tabla 5
c. Intervalos y calificación de nivel de gestión
Rango de Puntaje en % Nivel de Gestión
81% al 100% Excelente 61% al 80% Aceptable 41% al 60% Regular Menos de 40% Deficiente Elaboracion propia Tabla 6
d. Resultados obtenidos por institución:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 A 5 5 5 5 3 3 5 5 4 4 4 5 4 5 2 1 2 4 1 2 B 2 5 2 3 3 4 2 4 4 4 5 4 3 2 1 2 2 2 4 3 C 5 5 2 2 5 3 4 5 5 4 3 4 5 4 3 3 1 2 4 4 D 5 2 2 5 3 3 4 2 4 4 4 5 4 5 4 5 4 4 4 1 E 2 5 5 5 3 4 5 5 4 4 4 5 4 5 3 4 2 2 1 3 Elaboración propia 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 A 2 4 2 2 3 1 1 5 4 2 5 2 2 5 2 4 4 3 4 3 B 4 4 2 5 5 0 1 4 4 2 2 2 2 2 2 4 2 4 4 3 C 2 4 2 2 3 1 1 4 3 2 2 2 5 5 2 4 5 4 4 3 D 2 4 2 2 3 1 4 5 4 5 2 5 2 5 5 5 4 5 1 3 E 2 3 2 2 5 4 1 4 1 2 2 2 2 2 5 4 4 4 4 3 %Obtenido= 100* (PT-Pmin)/(Pmax-Pmin)
Tabla 7
e. Resultados ponderados obtenidos por institución:
Pmin Pmax PT %Obtenido
A 232 767 570 63.1 B 232 767 503 50.6 C 232 767 575 64.1 D 232 767 579 64.8 E 232 767 561 61.5 Elaboración propia Interpretación de resultados Institución A
En la institución A, el nivel de administración de proyectos es regular calificado con un puntaje total de 570 equivalente un 63.1%
Institución B
En la institución B, el nivel de administración de proyectos es regular calificado con un puntaje total de 503 equivalente un 50.6%
Institución C
En la institución C, el nivel de administración de proyectos es regular calificado con un puntaje total de 579 equivalente un 64.8%.
Institución D
En la institución D, el nivel de administración de proyectos es regular calificado con un puntaje total de 579 equivalente un 64.8%
En la institución E, el nivel de administración de proyectos es regular calificado con un puntaje total de 561 equivalente un 61.5%
f. Procesos de Gestión Encontrados
A continuación, se describirán las actividades de gestión que se
realizan en cada institución. Como base se ha tomado la encuesta y la entrevista: A continuación, se muestran los resultados de los datos obtenidos por cada una de las diez áreas de conocimiento, a fin de tener un panorama parcial de estas instituciones.
Secuencia de gestión para institución A
Se reciben requerimientos
Se hacen reuniones para coordinar los requerimientos
Se llegan a acuerdos para definir el inicio del proyecto
Se firma un acta de inicio
Se tiene un plan de proyecto basado en tiempo, alcance y costos
Luego de la planeación se da inicio al proyecto
Se desarrolla el cronograma con cierta holgura
Se hacen modificaciones al cronograma en la medida que se avanza
El aprovisionamiento lo ve otra área de logística
Se hacen pruebas, validaciones y afinamientos de procesos
Se hace conformidad del usuario
Se hace cierre de contrato
Secuencia de gestión para institución B
Se usa metodología de transición, se centra todo en resultados, no es formal.
Se manejan los proyectos por actividades mas no por áreas de conocimiento
Hay declaración preliminar de alcance, a veces.
Hay una estimación de costos y presupuesto lo ve el comité técnico legal.
Se ve la cantidad de recursos necesarios, generalmente dinero, con el que cuenta el proyecto.
Se toma como referencia proyectos anteriores si es el caso
Se establece línea base de cronograma, no sufre cambios formales
Se hace selección de proveedores
Se informa a los involucrados del proyecto
Se desarrolla la lista de actividades
Las actividades pocas veces tienen holgura
El aprovisionamiento lo ve el área beneficiada del proyecto
Hay recojo de requerimientos
Hay cambios en el alcance, solo si es muy necesario
Se identifican los factores que crean cambios
Hay supervisiones de avances.
La conformidad del trabajo es por avances.
Secuencia de gestión para institución C
Se usa una metodología propia
Se tiene un plan para administrar el proyecto
Se reúne el equipo de proyecto
El alcance es según los requerimientos y recursos disponibles
Se ven las actividades generales del proyecto
Se estipulan las tareas a cumplir por cada participante
Se definen entregables
Se usa un diagrama de Gantt para el control
Se incluyen holguras en las actividades.
Se estima recursos por actividad.
Hay revisiones de aceptación por parte del jefe de proyecto y luego los usuarios.
Se reúnen requerimientos al detalle por el personal pertinente
Se adecua lo que se quiere con los términos de referencia del alcance inicial.
Se desarrollan los prototipos
Los controles son mensuales o según el jefe de proyecto lo estime
Una vez terminado se hacen las pruebas con los usuarios
Si funciona correctamente el jefe de proyecto lo prueba con el usuario
Se hace copia de seguridad del servidor mensualmente
Se hace cierre de contrato
Secuencia de gestión para institución D
La metodología usada aún no se define, se basa en métricas
Se vale de un presupuesto inicial
Se justifica el proyecto a través de memos de los usuarios
Los requerimientos se adquieren mediante documentos de los usuarios
Los requerimientos se transforman en entregables
Declaración preliminar del alcance de manera verbal
Se hace alcance, pero solo lo principal
Se establecen reuniones mensuales
Se ve la cantidad de los recursos que se tienen
Se usa un archivo de MS Excel para hacer el cronograma
Hay cronograma inicial
Los directivos tienen puntos de control
Hay holgura en el cronograma
Identificación de riesgos
Se recurre al plan de respuesta a riesgos que esta desactualizado
Se costea el proyecto según las horas hombre
Se tienen en cuenta los riesgos de la perdida de información
Una entidad determina las actividades informáticas
El personal se autoevalúa entre ellos a fin de mejorar, no se documenta
Es permanente la identificación de riesgos y la respuesta a los mismos
Se priorizan riesgos de información
Termino de contrato
Termino de proyecto
Secuencia de gestión para institución E
La metodología usada aún no se define, se basa en métricas.
Se vale de un presupuesto inicial.
Se justifica el proyecto a través de memos de los usuarios.
Los requerimientos se adquieren mediante documentos de los usuarios.
Los requerimientos se transforman en entregables.
Declaración preliminar del alcance de manera verbal.
Se hace alcance, pero solo lo principal.
Se establecen reuniones mensuales.
Se ve la cantidad de los recursos que se tienen.
Se usa un archivo de MS Excel para el cronograma.
Hay cronograma inicial.
Los directivos tienen puntos de control.
Hay holgura en el cronograma.
Identificación de riesgos.
Se recurre al plan de respuesta a riesgos que esta desactualizado.
Se tienen en cuenta los riesgos de la pérdida de información.
Un ente determina las actividades informáticas.
El personal se autoevalúa entre ellos a fin de mejorar, no se documenta.
La selección de proveedores lo ve Logística, ya está normado.
Es permanente la identificación de riesgos y la respuesta a los mismos.
Se priorizan riesgos de información.
Término de contrato.
Término de proyecto.
Se reciben los requerimientos.
Se define la fecha a realizar.
Se reúne el equipo de proyecto y se define el inicio.
El proyecto se justifica por los propios usuarios.
El alcance es según los requerimientos y recursos disponibles.
El aprovisionamiento lo ve otra área Logística.
Se establece el cronograma.
Se estipulan las tareas a cumplir por cada participante.
Se incluyen holguras en las actividades.
Se estima recursos por actividad.
Hay revisiones de aceptación por parte del jefe de proyecto y luego los usuarios.
Alcance y/o priorización de otras actividades fuera del contexto del proyecto (el día a día, por ejemplo).
Una vez terminado se hacen las pruebas con los usuarios.
Se hacen reconocimientos por buen nivel de desempeño.
Se toman medidas disciplinarias por falta de capacidad.
Se cierra contrato.
Se cierra proyecto.
g. Secuencia de gestión de los proyectos en las instituciones públicas de Huamanga
Se estudia el inicio del proyecto. Las empresas del estado manejan el alcance al recibir los requerimientos y al hacer reuniones de consenso. También definen en parte su alcance al emitir memorandos, es aquí donde se define el inicio forma del proyecto.
Se hace recojo de requerimientos de manera rápida a través de reuniones.
Se emplea una metodología de gestión informal.
Se convoca al personal que se tiene a evaluar el proyecto.
Se estudian las actividades a realizar (no siempre).
Se estima el personal que se va a necesitar según especificaciones para ser contratado.
Se hace un alcance del proyecto de manera genérica (en algunos casos es más estudiado que en otras).
Se ve la disponibilidad en materia de costos (generalmente esto es
tomado como base).
Se hace las gestiones con RRHH para la contratación de personal y/o
equipos que se necesiten.
Se hace gestiones con Logística para definir el contrato de servicio de terceros para algunas actividades del proyecto o todo el proyecto según sea el caso (Tercerización de Servicios).
Se arma un plan de trabajo.
Se reúnen requerimientos en el campo mismo de trabajo según el proyecto de manera usual.
Se hacen reuniones iniciales para definir bien la forma de trabajo. El jefe de proyecto fija tiempos según su experiencia. Se usa un diagrama de Gantt para esto. Se manejan cronogramas, donde se indican a lo mucho las actividades, la duración y en algunos casos las fechas.
Algunos consideran riesgos. Algunas instituciones documentan los riesgos, básicamente los técnicos e incluso con un plan de respuesta y con los responsables para cada eventualidad. No se actualizan registros de riesgos. Básicamente se planean riesgos relacionados a pérdida de información.
Se va verificando el avance del proyecto según avances mensuales, semanales, etc. No se hace un control de cronograma. Si hay algún cambio en las fechas o actividades se
cambia el cronograma y queda actualizado, la versión anterior se elimina por completo.
Se hacen las pruebas del trabajo. En algunas instituciones, solo algunas personas del personal de sistemas tienen intención de hacer estandarización por juicio experto, pero no hay nada formal. Sin embargo, hay alguna empresa que ha buscado estandarizar la forma de construcción en cuanto a programación se refiere. Como piloto hay un manual de estándares que poco a poco se viene implementando.
Se presenta al usuario el entregable final.
Se vuelve a recolectar información para mejorar el trabajo del proyecto.
Se documentan los principales cambios (casi nunca se hace porque no hay tiempo).
Se vuelven a hacer pruebas.
Una vez que está aceptado por el usuario, el proyecto obtiene el visto
bueno.
Se cierra el contrato.
B. CUESTIONARIO 02
El cuestionario 02 (ANEXO 02), consta de 19 preguntas con respuestas abiertas, las cuales para poder dar una interpretación se han leído cada una de ellas, además, estas han reforzado el objetivo que se buscaba en recabar información mediante el cuestionario 01:
El inicio de un proyecto software en todos los órganos desconcertados, lo que representa un 100%, motivo de estudio, se dan con el objetivo de resolver un problema a corto y mediano plazo, relacionado con el desarrollo del software, sin previa elaboración de un plan de sistemas de información o tecnologías de información.
En la mayoría de los órganos desconcertados, que llega a un 90%, los proyectos de software están orientados a resolver problemas en parte de un área, unidad o dirección que básicamente es automatizar algunos procesos, sin involucrar a la mayoría de los existentes.
En el 95 % de las instituciones motivo de estudio se toma como grupos de interés prioritarios los usuarios o trabajadores de las áreas que están en el alcance del proyecto, no se incluye a las otras áreas que interactúan con ellos, o los usuarios finales o llamados clientes, tampoco a la alta dirección.
En el 95 % de las instituciones, no se realizan documentos relacionados a PMBOK, sien embargo el desarrollos de los proyectos es respaldado por documentos que garanticen su continuidad.
En el 100% de las instituciones, el área responsable del desarrollo de software, da conocer que se distribuye el trabajo y el alcance que es
parte de un Work Breakdown Structure, lo cual básicamente es automatizar progresivamente algunos procesos, no usan este término como lo define el PMI, además que no todos los esfuerzos para desarrollar software son tratados como proyectos, este termino lo asocian mayormente en otras áreas de las instituciones.
El 100% de las instituciones refiere que si cuentan con un cronograma mediante el cual se va a desarrollar el proyecto software, en el que se establece las actividades y las fechas en que se van a realizar.
El 100% de las instituciones define el alcance, y al mismo tiempo los planes que van a ser desarrollados, incluyendo actividades y cronograma.
El 100% de las instituciones manifiesta que realiza la estimación de los costos al mismo tiempo de definir las actividades y los recursos que serán necesarios para cumplir con la actividad.
El 100% de las instituciones indican que no existe una actividad formal de cierre o culminación del proyecto, se entrega el producto desarrollado al usuario final y se da por finalizado el proyecto.
El 98% de los órganos desconcertados manifiesta que verifican el cronograma relacionado con el avance, respecto al tiempo y avance del trabajo, implícitamente los costos, sin embargo, estos cuando no sobrepasan de lo planificado no requieren mayor atención hasta su culminación.
El 95% manifiesta que no registran los factores que afecten de algún modo el progreso y posterior cumplimiento del proyecto. El 5% de las
instituciones si documenta los motivos por los cuales el proyecto se ve afectado en el cronograma.
El 100% considera que las responsabilidades en el no cumplimiento del cronograma de las personas deben darse a conocer, y que incluso deben ser sujetas a sanciones, sin embargo, esto no se realiza en ninguna de las instituciones a menos que el mal desempeño ocasione una sanción administrativa, la intervención del órgano de control interno o incluso procuraduría.
El 100% de los órganos desconcertados, manifiesta que no realizan ninguna actividad relacionada con la evaluación de los riesgos, esto se puede considerar como que no existe el personal adecuado y conocedor del tema que pueda de algún modo prever alguna situación de riesgo y su posible implicancia en el desarrollo del proyecto.
Considerando la evaluación de las respuestas y asociado al ítem anterior se concluye que el 100% de las instituciones, no establece nada relacionado a los riesgos del proyecto de desarrollo de software.
El 100% de instituciones manifiesta que como lo establecen las normas nacionales, el proceso de selección de los vendedores no se realice ar antes del proceso de convocatoria, por lo tanto, la información estará disponible para todos los que se encuentren en el registro de proveedores, y dispondrán de la información necesaria de acuerdo con las bases propuestas.
El 100% de instituciones da a conocer que la contratación de personas necesarias para el proyecto tiene su propio proceso y que
es muy diferente al proceso para las adquisiciones de materiales o equipamiento.
El 100% de órganos desconcertados refiere que el control se aplica solamente a los tiempos, costos y alcance basado en los requerimientos de los usuarios.
El 90%, de las instituciones manifiesta que la forma de trabajo les da resultados, sin embargo, se percibe que solo automatizan algunos procesos y en todos los casos no requieren la adquisición de equipos ni contratación de personal.
El 100% de las personas coincide en que necesitan contar con un buena práctica o metodología que garantice la realización de proyectos exitosos, no solamente en el área de sistemas o tecnologías de información, sino en todas las que requieren resolver problemas mediante proyectos.
Por el análisis que se hace mediante los dos cuestionarios es que se concluye que el PMBOK, es la metodología más adecuada y además de hace una propuesta para su aplicación concretamente en el área de desarrollo de software.