La creciente demanda del mercado de bienes y servicios ha hecho que estos sean mejores día con día, más rápidos y de menor costo. Esto hace que las empresas traten de mejorar y hacer sus procesos y rendimiento mejores con el fin de mantenerse en el mercado. Esto ha generado un fuerte enfoque al trabajo con la filosofía de proyectos pero, haciendo que los proyectos cada día sean más preciosos en sus estimaciones de tiempo, costo y calidad.
Con el aumento de proyectos se crearon una serie de estándares o buenas prácticas que se pueden implementar para mejorar las estimaciones. Estas buenas prácticas nos permiten crear una seria de documentos especializados en las diferentes áreas que un proyecto conlleva. Actualmente contamos con muchos diferentes estándares o políticas para el manejo de proyectos. Muchas empresa tienen sus propios estándares que utilizan día con día para poder llevar cabo esta dura tarea.
Creo que ahora si se le toma el grado de importancia que los proyectos deben tener al tratarlos con tanto cuidado y siempre tratando de hacer los procesos más eficientes. Esto ha llevado a generar largos procesos para la administración de proyectos, haciendo que esto sea una tarea compleja y de larga duración. Claro que todos estos planes y tiempo dependen directamente del tamaño del proyecto. Nosotros nos enfocaremos específicamente en el estándar de PMI que nos da una serie de pasos que podemos seguir. Claro está que esto es solo una seria de buenas prácticas por tanto ellos dicen que estas tareas pueden ser utilizadas en cuanto sean de relevancia para el proyecto. Es decir, que nosotros podemos o no utilizar en los proyecto todos los documentos del PMI.
PMI es una serie de buenas prácticas que nos da una muy buena idea de cómo abordar un proyectó. Podemos decir que PMI nos permite administrar todos los procesos del proyecto. Por ejemplo nos permite administrar riesgos, cambios, patrocinadores, etc. Claro esta que no estamos sujetos simplemente a sus herramientas y técnicas. Podríamos incorporar otras que nos ayudaran a manejar el proyecto. Yo me atrevo a decir que podemos tener una muy buena guía para administrar proyectos solo con lo que PMI nos indica.
Estas buenas prácticas nos permiten detallar todos los componentes que son importantes para realizar el proyecto. Nos permite conocer desde el inicio por ejemplo cual será el medio de comunicación con los diferentes stakeholders. Entre otras cosas nos da una visión muy amplia sobre el proyecto. Tendremos muy bien documentada todas las tareas desde el inicio del proyecto.
Otro aspecto importante del PMI es que los procesos se pueden ir alimentando conforme avanza el proyecto. Esto quiere decir que no es un modelo sin flexibilidad. Como todos sabemos los cambios pueden salir en cualquier momento. PMI nos permite manejar de una forma profesional y más segura los cambios que van saliendo en el proyecto.
Este documento nos permita conocer un poco de los procesos que nos presenta el PMI y algunas de sus técnicas.
El PMI nos presenta una seria de documentos y buenas prácticas que tenemos que realizar para poder llevar el desarrollo del proyecto con un buen orden y sin perder ningún detalle que este conlleva. Además, estas buenas prácticas nos dan una seria de aspectos que son importantes para no tener ningún contratiempo en ninguna de las etapas del proyecto.
Pero antes que todo me gustaría mencionar la diferencia entre dos términos que tendemos a confundir, los cuales son proyecto y operaciones ya que en muchas ocasiones se nos hace muy difícil de entender estos dos conceptos. Cuando nos dedicamos a trabajar en el área técnica o en empresas que no tienen la cultura de proyecto, con facilidad comentemos errores con estos términos y llamamos a todas las tareas que hacemos proyectos. Vemos las tareas que no son proyectos como proyectos.
Cuando nosotros hablamos de proyectos nos referimos a alguna tarea que tiene un inicio y final específico y claramente estipulado. Además, se habla que el proyecto debe de dar como resultado algún producto o servicio único. Esto no suena muy difícil de entender pero en la práctica se tiende a confundir el término proyecto con el trabajo de operaciones. Este segundo da como resultado un producto o servicio que no es único, es decir es una tarea repetitiva, y su resultado por consecuencia no es único. Por ejemplo en algunos trabajos donde he laborado, hablamos de un nuevo proyecto cuando estamos esperando algún cliente el cual vamos a instalar alguno de nuestros productos de software. Sin embargo eso no es un proyecto. El proyecto fue el desarrollo del producto de software como tal y las instalaciones del producto serian un trabajo de operaciones, como podríamos observar esta tarea no da ningún resultado único. Muchas empresa tienden a llamar todo como proyecto, utilizando mal el término de proyecto.
Bueno hablando un poco más sobre la administración de proyectos y específicamente lo que nos plantean el PMI tenemos muchos documentos y buenas prácticas que nos plantean para poder llevar a cabo la tarea del proyecto de la mejor manera. Nosotros vamos a mencionar alguno de los documentos y procesos que generamos y utilizamos.
Este estándar estipula que todos estos documentos y estándares son opcionales, es decir, que se pueden incluir los que pensásemos que son necesarios para el proyecto e incluso incluir en cada documento lo que el administrador de proyectos piense que el proyecto deba contener. Por ejemplo el proyecto que desarrollamos para el curso fue un proyecto pequeño y no se incluyeron todos los documentos del PMI.
Uno de estos documentos es el project charte. Este documento nos plantea un breve punto de vista de lo que será el proyecto. Entre la información más notoria que podemos encontrar en este documento es los requerimientos a un alto nivel. También podemos encontrar el alzase del proyecto a muy alto nivel. Sin olvidar que también nos plantea el costos del proyecto con su tiempo de finalización. Esto es como el primer acuerdo que se plante del proyecto. Pero además esta documentación nos dice que debe de aparecer una parte donde nos den la aprobación del proyecto. Esto último tiene que ser dada por la persona que tenga el poder de decisión de la empresa. Nosotros no debemos iniciar ningún proyecto sin antes tener una aprobación por escrito.
Algo muy importante para mi es la identificaciones de todas las personas que van a ser involucradas en el proyecto. Esto también está bien documentado en el Project charte. Claro está que este documento debe ser corto y directo al punto que se desea estipular en el proyecto.
Con la elaboración del project charter y la correspondiente aprobación podemos iniciar con el proyecto. Esto nos da pase para la elaboración de una serie de documentos que nos permitirá llevar el proyecto de la mejor forma posible. Claro que PMI es muy flexible y nos permite incorporar los documentos que realmente son necesarios para nuestro proyecto y no todos los que se plantean.
Otro de los documentos desde mi punto de vista muy importantes y que se deberían de implementar en todos los proyectos, es el de requerimientos. Para poder tener las cosas claras desde el inicio del proyecto. Aquí entramos con mayor detalle a los requerimientos, es decir que los requerimientos plateados en el Project charter se amplían con mayor profundidad. Claro está este documento no es solo para enlistar los requerimientos. Este es un plan para la administración de los requerimientos, como se van a recolectar, técnicas y herramientas a utilizar. Esto documento nos da los requerimientos que vamos a desarrollar para el proyecto y el producto. PMI también nos plantea que podemos identificar cuales stakeholders tienen relación con los diferentes requerimientos para poder buscar más información o comunicar cualquier eventualidad a lo largo del proyecto.
Todos sabemos que documentación amplia de requerimientos no pasa en muchas empresas de desarrollo de software. En muchos casos no se documentan con detalle los requerimientos y mucho menos que técnicas podemos utilizar para recolectarlos. Aquí podríamos mencionar las herramientas que nosotros utilizamos en el proyecto realizado en clase para la recolección de requerimientos. Básicamente nosotros utilizamos reuniones en el cual el arquitecto de software realiza para entender cuáles son las nuevas necesidades del negocio y del proyecto como tal. También se hace un trabajo de observación de cómo el usuario final realiza sus tareas diarias y poder obtener más información.
En este punto es importante comentar que los requerimientos no son solo del producto final si no que también estamos hablando del proyecto. Claro que al inicio a trabajar con proyectos es un poco difícil dejar de pensar en los requerimientos del producto e intentar buscar los del proyecto. Las personas que estamos acostumbrados a trabajar en el área técnica tendemos a buscar solo los requerimientos del producto. No es tan fácil cambiar esa visión de proyectos al inicio pero es parte del proceso.
Un documento muy importante es el del alcance, en este podemos describir el proyecto. Por otra parte se puede redactar los criterios de aceptación del proyecto, esto es cuales serán los parámetros que utilizaremos para confirmar si el proyecto fue exitoso o no. En esta sección se tiende a pensar en los criterios de aceptación únicamente del producto cuando tenemos que buscar y documentar los criterios de aceptación del proyecto.
Nosotros podemos incluir en el plan del alcance los hitos del proyecto, las restricciones que tiene el proyecto, limitaciones y la lista de los stakeholders con sus responsabilidades y role. Como ven este documento nos permite tener amplia información sobre que tenemos que desarrollar en el proyecto. Este documento lo veo como uno de los más importantes ya que describe que vamos hacer, que cosas no están incluidas en el proyecto con sus limitantes. Ponemos en claro el costo y el tiempo que vamos a durar realizándolo.
Por otra parte en el plan del alcance se puede adjuntar la información de los entregables del proyecto. Por ejemplo podemos hablar de los planes que se van a realizar durante todo el, esto sería un entregable. También el proyecto como tal es un entregable del proyecto.
Después de estos documentos iniciamos a trabajar con el plan de recursos humanos. Acá nosotros agregamos los stakeholder relaciones con sus roles, responsabilidad habilidades. También se agrego la información sobre cuándo serán incorporados en el proyecto y cuando ellos dejaran de trabajar en el proyecto. Este documento contiene la forma en la que se desarrollara la comunicación con los stakeholders. Como ven este documento nos permite documentar con un poco mas de detalle la información relacionada con los stakeholders del proyecto.
Generalmente el administrador de proyectos es el que se encarga de hacer el plan de recursos humano y el puede escoger el personal con el cual el gustaría desarrollar el proyecto. Claro está que también depende directamente de la organización. Puede ser que el administrador de proyecto solicite alguna persona específico pero por políticas, reglas de negocio o simplemente alguna decisión de una persona de alto rango puede que no permite que el recurso trabaje con el administrador de proyectos.
Importante recalcar que conocemos de ante mano el personal que va a trabajar con nosotros en el proyecto y esto implica que debemos saber en qué son mejores cada uno de las personas que estarán involucradas. Este levantamiento de cualidades de las personas nos permitirá asignarlo a las tareas que ellos puedan desarrollar con mayor facilidad. Incluso conociendo de ante mano las habilidades que tienen cada uno de los participantes se puede apoyar unos con otros que tengan cualidad similares en alguna eventualidad.
Calidad es una de las áreas más importantes en cualquier proyecto y PMI también lo toma en cuenta dentro de todos los documentos que se tienen que construir. En este punto tenemos que enumerar los procesos que debemos seguir para garantizar la calidad del proyecto y producto. Este documento básicamente debe cumplir dos características muy importantes. La primera es cómo voy hacer el control de la calidad y la segunda como voy hacer el aseguramiento.
Control es la tarea que nos permite ejecutar procesos para validar la calidad del proyecto y producto, este trata de garantizar la mejor calidad. Esta tarea cuenta con una seria de actividades que se estarán ejecutando a lo largo del desarrollo del proyecto, las actividades que se definen deben de estar documentadas en el plan, pero estar documentadas no nos garantiza que se van a ejecutar por las personas que deberían de hacerlo. Entonces es aquí donde tenemos que definir el otro proceso importante para este plan, el cual es verificación que las tareas de control se estén realizando. Por ejemplo auditoria puede ser una tarea de verificación del control de calidad para comprobar que estas se están ejecutando. Con este documento tenemos que garantizar la mejor calidad del producto y que las actividades de control se estén ejecutando, muy importantes tener las herramientas para la verificación de la ejecución de las tareas.
Ahora podemos hablar de un tema que es muy importante para la organización y en muchos casos lo único que el negocio ve. Estamos hablando del plan de costos. Acá planteamos el costo del proyecto. Podemos mostrar los costos divididos por los costos de los miembros por horas, el costo de las actividades o el costo total de los miembros del equipo entre otras formas de ver los costos. Este plan acarrea una gran cantidad de cálculos y técnicas para poder llevar el presupuesto de una forma ordenada y poder estar al tanto de cómo está el proyecto con respecto al costo en distintos puntos del mismo. Sin embargo, no se realizaron los cálculos o las medidas para ver como se desenvuelve el costo por todo el proyecto.
Después de una lista larga de procesos y documentos que tenemos que diseñar llegamos al plan de riesgos uno de los más interesantes. PMI nos dice que debemos hacer un plan que nos permite desarrollar una serie de proceso para el manejo de los riesgos del proyecto y el producto. A este nivel debemos crear el plan que nos permite tener claro en qué momento vamos a buscar riesgos, cuánto tiempo vamos a durar haciendo esta tarea, como nos vamos a comunicar con los involucrados en riesgos, entre otros documentos.
Veremos cómo vamos a caracterizar los requerimientos, como los vamos a medir y cómo vamos a atacar esos riesgos. Entre otra información que podemos incluir en este documento es como se documentaran los riesgos, que herramientas utilizaremos para manejar los requerimientos. Por otro lado, tenemos que documentar todos los requerimientos que podríamos detectar en el proyecto. Para generar todos estos requerimientos los tenemos que buscar de forma paranoica, es decir, tratar de buscar y clasificar todos los requerimientos posibles. Algunas de las técnicas que podernos usar es el famoso brainstorming, el juicio experto y también la información histórica de la empresa.
La búsqueda de requerimientos terminará hasta que ya no encontremos más. Cuando no podamos encontrar más riesgos con las técnicas que estamos utilizando y en las diferentes etapas que estipularemos para la recolección de lo requerimientos entonces hemos terminado con esta tarea de recolección.
Al inicio del desarrollo del proyecto pensé que esto era una tarea simple de realizar. Pero conforme íbamos desarrollando el proyecto me die cuenta que es una tarea muy elaborada. Importante es intentar cambiar la idea de pensar en proyectos y dejar un poco la idea de pensar sobre productos. Parte importante en el desarrollo del proyecto es saber que las tareas son repetitivas y conforme se van elaborando los documentos, estos podrían tener resultados que permiten actualizar otros documentos.
La elaboración de un proyecto es un trabajo muy complejo. Al inicio tenía una idea que diseñar un proyecto era un trabajo simple pero en realidad es una tarea de mucho cuidado y muy complejo. Debemos de tener un gran conocimiento sobre cómo desarrollarlo estos planes para poder finalizar con un buen proyecto.
Comenzando a trabajar en proyectos vemos una seria de documentos que pensaríamos que es un esfuerzo extra que no generaría alguna valor agregado. Muchas organizaciones piensan que la elaboración de estos planes hace que el costo aumente y que no ayudara mucho al desarrollo de software. Creen que el software se pude realizar únicamente con conocer a muy alto nivel los requerimientos. Pues bueno en realidad no es del todo falso, nosotros podemos desarrollar un software con solo conocer los requerimientos del negocio. Pero con todos estos planes tenemos una mayor posibilidad de desarrollar un proyecto exitoso. Si vemos todos los documentos que nos plantea PMI sin duda podemos afirmar que se puede desarrollar un proyecto de una manera muy seguro. Permitiendo conocer de ante mano la mayor cantidad de detalles. Los procesos están muy bien documentados para evitar la mayor cantidad de errores posibles.
Entre algunos de los errores que se comenten normalmente a la hora del desarrollo de un proyecto son los famosos “colchones”, esto es una práctica muy común. En la mayoría de lugares donde he trabajado se encuentra esto entre las prácticas para el desarrollo de sistemas. Otra de las grandes cosas que pudimos aprender es que cuando hablamos de proyecto lo primero que hacemos es ir a Project y generar la lista de tareas con los respectivos miembros del equipo que las realizarían. Siendo esto una casi de las ultimas tareas que se elaboran de acuerdo a PMI y por supuesto lo que es Project no es una tarea que se desarrolla por si sola si no que tenemos que realizar un poco mas de documentación que es necesaria para poder generar esto y siendo este solamente una herramienta para generar la estimación del tiempo.
Otro de los errores comunes que nosotros cometemos, es pensar que el administrador de proyectos debe saber todo del área en el que se está trabajando, es decir, se espera que un administrador de proyecto informático sea una persona con un amplio conocimiento en computación y sus áreas afines. Nunca esperaríamos que un administrador que no sea informático lidere proyecto de computación. Esto porque también creemos que el administrador de proyectos tiene que documentar, especificar, estimas costo y tiempo de todas las tareas del proyecto y producto. Pero notablemente podemos ver que esto no es así. PMI nos plantea que un administrador de proyectos puede manejar cualquier tipo de proyecto independientemente de su área. Pero cómo es posible que un administrador de proyectos pueda manejar algún proyecto de un área que no sea la suya. Bueno probablemente la mayoría de las personas piensa que esto no es posible porque él no podrá estimar tiempo y costo de muchas tareas. De acuerdo con PMI el administrador de proyectos debe buscar el juicio experto, esto quiere decir la persona que tenga más experiencia en el are relaciona con la tarea o tareas a las cuales se está estimando el tiempo y costo. Entonces para poder tener un mejor panorama sobre estimación de tiempo y costo, el administrador de proyectos debería de pedir la opinión de más de una persona sobre el tiempo que se necesita para poder realizar una estimación mejor de la tarea. Al pedir la opinión de más de una persona nos permite tener estimaciones más certeras. Claramente podes ver que esto permite que un administrador de proyectos administre cualquier tipo de proyecto. Lo que él debe hacer es realizar las tareas de administración específicamente, es donde el debería de tener su experiencia.
Con cada uno de los proyectos que desarrollamos ganamos experiencia y podemos desarrollar mejores planes. Ciertamente cada uno de los proyectos es único y su resultado no va hacer igual a ningún otro pero esto no quiere decir que no tenga características que se puedan compartir entre ellos. Entonces aquí es como utilizamos el juicio experto.
Juicio experto es una de las herramientas más mencionadas en PMI. Al parecer esta es de las favoritas. Creo que es una buena práctica en muchas ocasiones, ya que conforme uno gana experiencia en trabajos tiende a cometer menos errores y generar trabajo más limpio. Cada proyecto nos permite generar una seria de tareas que nos hacen aprender muchas nuevas cualidades para el próximo proyecto. En muchos proyectos podemos ver que muchas tareas son muy similares o incluso iguales. La información histórica de la empresa también pude ser utilizada esto desde mi punto de vista es parte del juicio experto. Los errores y bueno resultados se pueden tomar para las futuras decisiones en proyectos que llegan.
Con lo que puede aprender hasta ahora de proyecto creo que la mejor manera de desarrollar proyectos exitosos es llevarlos con mucho orden, bien detalladlos y estructurados. Entonces porque no seguir los estándares de PMI que en realidad nos permite tener una muy buena panorámica del proyecto desde sus inicios hasta el fin.