IEDGE – Estándares para la Gestión de TI, segunda parte
Como vimos en el anterior post, son muchos los estándares que tenemos a nuestra disposición para ayudarnos a una correcta Gestión de TI. En este post veremos algunos de los estándares más reconocidos relacionados con el Desarrollo de Software y la Gestión de Proyectos.
5.- Modelo de Madurez para el Desarrollo de Software
En el caso del proceso de Desarrollo de Software, uno de los estándares más aceptado dentro de la industria es un modelo de madurez, denominado CMMI (Software Capability Maturity Model), creado por Software Engineering Institute (SEI). El CMMI describe una serie de niveles que pueden alcanzarse en el desarrollo de software y en el que las empresas y organizaciones pueden certificarse:
- Nivel 1: Inicial (anárquico)
- Prevalece la anarquía, cada uno hace lo que quiere o puede, y tiene sus propias soluciones.
- Los programadores o desarrolladores se consideran artistas creativos no sujetos a reglas.
- El trabajo se realiza, pero de forma no controlada y en general poco eficiente.
- Es asumido por la empresa en que las cosas (actividades) son conocidas, pero no saben o no quieren cambiarlas.
- Es la situación en la que se encuentran la mayoría de las empresas y organizaciones.
- Nivel 2: Gestionado (repetitivo)
- La empresa ha logrado estabilizar un nivel repetitivo de control basado en compromisos, costos y cambios.
- Se asume que lo que se viene haciendo es correcto, sin intentar cambiarlo todo, aunque ahora está organizado de forma que es repetible.
- Todo está bien mientras no haya “perturbaciones”.
- Se usan métodos de comunicación no formal, permitiendo la subjetividad, pero haciendo más clara la ejecución de actividades.
- Nivel 3: Definido
- Su base es aprovechar los procesos que funcionan mejor.
- La empresa identifica el diseño, prueba, inspección, gestión, control de configuración y otros procesos que mejor funcionalmente en proyectos diferentes, y los integra para en el desarrollo de forma estable.
- Se entrena a toda la organización para que el personal tenga una referencia común de lo aprendido en proyectos anteriores y no tiene que reinventar los métodos de trabajo cada vez.
- Nivel 4: Gestionado de forma cuantitativa (administrado)
- La administración involucra los costos (cualitativos y cuantitativos) y la planificación de los procesos.
- La administración busca una mejora significativa de calidad.
- Se establece la medición detallada los procesos de desarrollo de software, que son asociados con los procedimientos, normas y estándares.
- Nivel 5: Optimo (mejora continua)
- La empresa tiene las bases para una mejora continua y busca optimizar cada vez más sus procesos de desarrollo de software.
- Se basa en el uso intensivo de mecanismos de optimización basados en métodos que usan la instrumentación de herramientas y técnicas.
- Se establece un programa formal y permanente de calidad de software y sus procesos.
Son muchas las empresas que han seguido este modelo para la mejora de sus procesos de desarrollo. No obstante, como en muchas otras ocasiones, la certificación en CMMI no garantiza el éxito en todos los proyectos. Algunos clientes se quejan de que sus proveedores con certificación CMMI también cometen errores, si bien, tienen que reconocer, que existen mecanismos y procedimientos para gestionar y resolver estos problemas y no es necesario improvisar soluciones basada exclusivamente en el esfuerzo y pericia personal.
La implantación de CMMI y su certificación no están al alance de cualquier organización y en general son empresas y departamentos relativamente grandes los que pueden abordar todos los procedimientos, normativas y herramientas que se exigen para ir avanzando en los diferentes niveles, además del coste económico que supone la certificación.
Les recomendamos que lean el post IEDGE – Métodos y sistemas para asegurar la calidad de software.
Para más información sobre CMMI también pueden consultar http://www.sei.cmu.edu/cmmi/
6.- Estándar para la Gestión de Proyectos
La gestión de proyectos no es una característica exclusiva del desarrollo de software o de los departamentos de TI. Más bien al contrario, es un tipo de gestión que realiza prácticamente todas las empresas, organizaciones y personas alguna vez en su vida.
Sectores como el de la construcción o la ingeniería son grandes “usuarios” de la gestión de proyectos. El desarrollo de software, o la implantación de Sistemas de Información también. Quizás, por su carácter inmaterial, los proyectos informáticos tienen algunas características especiales, ya que es más complicado entender su funcionamiento, evolución, diseño y en ocasiones su funcionamiento. Es por ello, que los proyectos relacionados con las Tecnologías de la Información son en general más complejos y difíciles de llevar a cabo.
Desde los años 50 se ha venido desarrollado una serie de técnicas, herramientas y metodologías para la gestión de los proyectos. Desde los sencillos y ampliamente utilizados Diagramas de Gantt, hasta los más sofisticados métodos de medición del rendimiento de los proyectos, disponemos de una gran cantidad de ayudas para la gestión de proyectos.
No obstante, los jefes de proyectos siguen afrontando un gran reto, dada la gran cantidad de elementos que tienen que tener en cuenta en su trabajo y no siempre cuentan con la formación y experiencia necesarias para abordarlos con éxito. Esta es, sin duda alguna, una de las principales causas de fracaso de los proyectos: la falta de preparación y capacidad de los jefes de proyecto.
El Project Management Body of Knowledge (PMBOK), desarrollado por el Project Management Institute (PMI) es una guía de fundamentos para la Dirección de Proyectos, de cualquier tipo y característica, que describe de forma precisa los conocimientos y herramientas que necesita conocer todo jefe de proyecto para poder abordar la tarea que le ha sido encomendada.
La guía del PMBOK define 9 áreas de conocimiento en las que agrupa cada una de las actividades, que van desde la Gestión Integrada del Proyecto, a las cuatro funciones principales (Gestión del Alcance, Gestión del Tiempo, Gestión del Coste y Gestión de la Calidad) y las cuatro auxiliares (Gestión de los Recursos Humanos, Gestión de la Comunicación, Gestión de Riesgos y Gestión de Compras):
Ilustración 1: Áreas de Conocimiento (PMBOK)
A su vez, el PMBOK describe un ciclo de vida del proyecto (que no debemos confundir con las fases o etapas de cada proyecto) que incluye inicio, organización-planificación, ejecución y cierre. Este ciclo de vida se puede realizar una sola vez en todo el proyecto, o en cada fase o etapa:
Ilustración 2: Ciclo de Vida del Proyecto (PMBOK)
Por cada una de las áreas de conocimiento y cada una de las etapas del ciclo de vida del proyecto el PMBOK define unas entradas, unas herramientas y técnicas que podemos utilizar y unas salidas que debemos generar, estableciendo de esta forma un completo mapa de los procesos que intervienen en la gestión de un proyecto.
Ilustración 3: Ejemplo de proceso (PMBOK)
El carácter generalista del PMBOK hace que sea aplicable a una gran cantidad de proyectos, tanto de desarrollo de sistemas informáticos, como de ingeniería, construcción, marketing o gestión empresarial, por lo que se ha convertido en una de las referencias más difundidas y utilizadas en la gestión de proyectos.
Como en otros casos, la certificación de un jefe de proyecto en PMBOK no garantiza el éxito en su gestión, pero nos asegura que dispone de unos conocimientos básicos para abordar la complejidad que supone la gestión de proyectos, y ofrece a las organizaciones y empresas un marco general de referencia sobre el que definir sus metodologías de gestión de proyecto, adaptadas a cada material y necesidades concretas.
Para más información sobre PMBOK les recomendamos que lean la nota técnica de esta signatura, así como los siguientes post, donde abordaremos con más detalle algunas de sus áreas.
Para más información sobre CMMI también pueden consultar http://www.pmi.org/
¡Quedo a la espera de sus comentarios!
Profesor de Dirección de Sistemas y Tecnologías de la Información
Nota: Para comprender la gestión de empresas y de recursos en un mercado global y como afecta a las decisiones, te invitamos a que consultes el Global MBA, donde, de una forma práctica y rápida, entenderás y aplicarás todos los conocimientos de management para una gestión empresarial de éxito.
* Los contenidos publicados en este post son responsabilidad exclusiva del Autor.
¡Puedes seguirnos en Facebook, Twitter, Google+, Youtube y Linkedin!
Obtenga su BECA 100% para el Global MBA.
Con stages en Madrid, San Francisco y Ciudad de México. ¡Becas limitadas a los mejores C.V.!
Fernando Pulido Soto
comento el día 28 de septiembre a las 8:01 pm (#)
hola Pablo,
nuestra empresa realizo un cambio de software de NAVISION de Microsoft a SAP, y meramente se llevaron los pasos que mencionas un control igual al que mencionas de ciclo de vida de proyecto.
1- INICIO- primero visitas de SAP, de SAP, entrevistas, procesos de trabajo, breve introducion a SAP,
2- 2- planificación por parte de ellos. Finanzas, logística… y IT.
3- Ejecución
4- Cierre
Saludos
Lorenzo Hombria
comento el día 13 de octubre a las 8:52 pm (#)
Hola Pablo:
Sobre las funciones principales y auxiliares de la Gestion integrada de proyectos, creo que han forzado el emparejado de dichas funciones. Yo no habría (perdon, no se sacar las tildes de esta tablet) separado la gestion de los riesgos. Creo que es una función principal aunque implicitamente gestinada por las funciones relativas al tiempo, el alcance, el coste y la calidad. ¿O es que todas las funciones auxiliares laten en las principales?Tampoco con esta afirmacion estaría de acuerdo, la dependencia no justifica la gestion implicita.