A client recently described an interesting situation – she had purchasing the new ISO31000 risk management standard, she had done the training with her team, conducted a risk identification and assessment workshop, and done the analysis and prioritization.  Yet no one seemed to be managing risks – they were something off to the side that people occasionally looked at.

What else could she do?

Risk management is one of the more overused, misunderstood and abused terms in project management these day.  There is a large body of work on risk management and a plethora of material available on the web to be used.

Yet many projects do not manage risk well.  They record their risks, identify the mitigations/treatments and review them during the project.  But for all of their planning, obvious risks seem to slip through the cracks.

Here are a few ideas that we can use:

Make sure everyone has a common understanding of what constitutes a risk, what constitutes an issue, and the difference between risks/issues and consequences/impacts.  This may seem trivial but different organisations have difference definitions of risk e.g.  “Only risks that we can influence”, “don’t include dependencies or constraints”, “the person who raises a risk deals with it”, ad infinitum

Keep it simple – have 3 ratings – negligible, moderate, project-killer – and review against schedule, scope, cost, technical and people.  Don’t have 5 ratings as it doesn’t really add value. And don’t have percentages as they are disguising a subjective guess with a number that makes it look quantitatively managed.

When introducing risks, don’t argue over the wording or structure – just make it understandable to stakeholders

Focus on mitigation/treatment actions.  These are the most critical component so you must make sure that every action has someone assigned and they understand the action and the deadline and that these actions are done just like any other project task.  Very often risk mitigations are seen as distinct and are reported separately.  No wonder they’re not afforded the appropriate focus.  Out of sight, out of mind.  Out of mind, out of time…

Set the bar lower to start, then as project management practices mature, you can be stricter when it comes to wording, ratings, severity etc.

Well as I noted I am catching up. I will have the rest of the article up then I will push a PDF version out.

Complexity:

The second component, complexity, is a measure of the number of properties of a project that are judged to be outside of the norm.  The applicable norm is relative to the person or group making the judgment.  Assessing the team’s understanding of complexity is important because when a person or group perceives something to be complex they act differently.  The concept of complexity can be decomposed into many individual components, for this model the technical components of complexity will be appraised in this category.  The people or team driven attributes of complexity are dealt with in the user involvement section (above).  Higher levels of complexity are an important reason for pursuing traceability because complexity decreases the ability of a person to hold a consistent understanding of the problem and solution in their mind.  There are just too many moving parts.  The inability to develop and hold an understanding in the forefront of your mind increases the need to document understandings and issues to improve consistency.

The model assesses technical complexity by evaluating the following factors:

1.    The project is the size you are used to doing
2.    There is a single manager or right sized management
3.    The technology is well known to the team
4.    The business problem(s) is well understood
5.    The degree of technical difficulty is normal or less
6.    The requirements are stable (ish)
7.    The project management constraints are minor
8.    The architectural impact is minimal
9.    The IT Staff perceives the impact to be minimal

As with customer involvement, the assessment process for complexity uses a simple yes or no scale for rating each of the factors.   Each factor will require some degree of discussion and introspection to arrive at an answer.  An overall assessment tip:  A maybe is equivalent to a ‘no’.   Remember that there is no prize for under or over-estimating the impact of these variables, value is only gained through an honest self-evaluation.

Project is normal size: The size of the project is a direct contributor to complexity; all things being equal, a larger than usual project will require more coordination, communication and interaction than a smaller project.  A common error when considering size of project is to use cost as a proxy.  Size is not the same thing as cost.  I suggest estimating the size of the project using standard functional size metrics.  Assessment Tip: Organizations with a baseline will be able to statistically determine the point where size causes a shift in productivity.  The shift is a sign post for where complexity begins to weigh on the processes being used.  In organizations without a baseline, develop and use a rule of thumb.  Consider using the rule that ‘if it is bigger than anything you have done before’ or the corollary ‘the same size as your biggest project’ as rules of thumb.  These equate to an ‘N’ rating.

Single Manager/Right Sized Management: There is an old saying ‘too many cooks in the kitchen spoil the broth’.  A cadre of managers supporting a single project can fit the ‘too many cooks’ bill.  While it is equally true that a large project will require more than one manager or leader it is important to understand the implications that the number of managers and leaders will have on a project.  Having the right number of managers and leaders can smooth out issues that are discovered, assemble and provide status without impacting the team dynamic while providing feedback to team members.  Having the wrong number of managers will gum up the works of project (measure the ratio of meeting time to a standard eight hour day anything over 25% is sign to closely check the level of management communication overhead).   The additional layers of communication and coordination are the downside of a project with multiple managers (it is easy for a single manager to communicate with himself or herself).  One of the most important lessons to be gleaned from the agile movement is that communication is critical (and this leads to the conclusion that communication difficulties may trump benefits) and that any process that gets in the way of communication should be carefully evaluated before they are implemented.  A larger communication web will need to be traversed with every manager added to the structure, which will require more formal techniques to ensure consistent and effective communication.  Assessment Tip: Projects with more than five managers and leaders or a worker to manager ratio lower than 8 workers to one manager/leader (with more than one manager) should assess this attribute as an ‘N’.

Well Known Technology: The introduction of a technology that is unfamiliar to the project team will require more coordination and interaction.  While the introduction of one or two hired guns into a group with experience is a good step to ameliorate the impact, it may not be sufficient (and may complicate communication in its own right).  I would suggest that until all relevant team members surmounts the learning curve; new technologies will require more formal communication patterns.  Assessment Tip:  If less than 50% of the project team has not worked with a technology on previous projects, assess the attribute as an ‘N’.

Well Understood Business Problem: A project team that has access to understanding of the business problem being solved by project will have a higher chance at solving the problem.  The amount of organizational knowledge the team has will dictate the level of analysis and communication required to find a solution.  Assessment Tip: If the business problem is not well understood or has not been dealt with in the past this attribute should be assessed as a ‘N”.

Low Technical Difficultly: The term ‘technical difficulty’ has many definitions.  The plethora of definitions means that measuring technical difficulty requires reflecting on many project attributes.  The attributes that define technical difficulty can initially be seen when there are difficulties in describing the solutions and alternatives for solving the problem.  Technical difficulty can include algorithms, hardware, software, data, logic or any combination of components.  Assessment Tip:  When assessing the level of technical difficulty, if it is difficult to frame the business problem in technical terms assess the level of complexity as ‘N’.

Stable Requirements: Requirements typically evolve as a project progresses (and that is a good thing).  Capers Jones indicates that requirements grow approximately 2% per calendar month across the life of a project.  Projects that are difficult to define or where project personnel or processes allow requirements to be amended or changed in an ad hoc manner should anticipate above average scope creep or churn.  Assessment Tip:  If historical data indicates that the project team, customer and application combination tends to have scope creep or churn above the norm assess this attribute as an ‘N’ unless there are procedural or methodological methods to control change.  (Note:  Control does not mean stop change, but rather that it happens in an understandable manner.)

Minor Project Management Constraints: Project managers have three macro levers (cost, scope and time) available to steer a project.   When those levers are constrained or locked (by management, users or contract) any individual problem becomes more difficult to address.  Formal communication becomes more important as options are constrained.  Assessment Tip:  If more than one of the legs of the project management iron triangle is fixed, assess this attribute as an ‘N’.

Minimal Architectural Impact: Changes to the standard architecture of the application(s) or organization will increase complexity on an exponential scale.  This change of complexity will increase the amount of communication required to ensure a trouble free change. Assessment Tip:  If you anticipate modifications (small or wholesale) to the standard architectural footprint of the application or organization, assess this attribute as an ‘N’.

Minimal IT Staff Impact: There are many ways a project can impact an IT staff ranging from process related changes (how work is done) to outcome related changes (employment or job duties).  Negative impacts are most apt to require increased formal communication, therefore the use of traceability methods that are more highly documented and granular.  Negative process impacts are those that are driven by the processes used or organizational constraints (e.g. death marches, poorly implemented processes, galloping requirements and resource constraints).  Outcome related impacts are those driven by the solution delivered (e.g. outsourcing, downsizing, and new application/solutions).  Assessment Tip:  Any perceived negative impact on the team or to the organization that is closely associated with the team should viewed as not neutral (assess as an ‘N’), unless you are absolutely certain you can remediate the impact on the team doing the work.  Reassess often to avoid surprises.

In preparation for scaling total the number of Y’s and N’s.  Scaling will be discussed after all components are described.

Many organizations worldwide have very successfully implemented CMMI.  As a part of process improvement, one has to identify the current status of process maturity and has to have a roadmap for higher maturity levels.  In this process, Measurement & Analysis plays a big role.

In order to implement a good measurement practice, you need to know:

• What is to be measured?
• What data to be collected?
• How to distill information from the collected Data?
• What are the best practices to be followed? Etc.

This will vary from organization to organization, their current process maturity levels, size and complexity of the project, etc.  But there are some common things:

• Identification of the right techniques to be deployed
• Automation of various tasks involved
• Effective data collection with automation

Organizations with great effort implement a process improvement model.  Once they successfully implement CMMI and get the assessment done, the first part is over.  Maintaining the process improvement task continuously is another challenge.  I feel at this area, the Measurement & Analysis plays the big role.  We have to spend more time to analyze the right information, than collecting the same from different sources on a routine basis.

In this context, “IBM Rational Dashboard” comes very handy to automate various tasks in the Measurement & Analysis process area of CMMI.   It helps you:

• Improve analyses of strategic and operational decisions
• Empower teams to make information-based decisions
• Enable continual improvement using metrics and measurements
• Implement best practices with guidance and compliance tracking

So let’s spend more time to take informed decisions, than just collecting the data.

Read more…

The Methods & Tools newsletter has just released in its html archive section the article “Mature Scrum at Systematic” written by Carsten Ruseng Jakobsen and Jeff Sutherland. This article presents an experience report about mixing CMMI and Scrum in the same company

El SCAMPI (Standard CMMI Appraisal Method for Process Improvement) es un método desarrollado por Instituto de Ingeniería de Software (SEI) para evaluar el estado de los procesos de software de una organización basado en los modelos CMMI. Existen tres tipos de SCAMPI: A, B, C, en donde la profundidad de la evaluación, la duración, costo y uso varían. Estas evaluaciones son hechas por un Asesor Líder acreditado por el SEI.

• Un SCAMPI C es el de menor duración y alcance, y es utilizado para ver el uso de los procesos en la organización y de las iniciativas de mejora con relación al modelo CMMI. Al ser más breve los resultados permiten identificar una tendencia en el uso del proceso. No da un nivel de madurez.
• Un SCAMPI B es de mayor duración que un C y su alcance permite identificar la implementación del proceso en la organización con una muestra más amplia de información. No da un nivel de madurez.
• Un SCAMPI A es el de mayor duración y permite ver la institucionalización de los procesos en la organización. Es mas riguroso en cuanto a la muestra de proyectos a observar y da un nivel de madurez a la organización.

Un punto interesante del SCAMPI es que la evaluación la realiza un equipo de la misma organización, en donde también pueden participar personas externas si así lo desean, y son liderados por el Asesor Líder quién define las guías, que se cumplan lineamentos del método, y hace que el equipo trabaje. El tamaño del equipo varía según el tipo de SCAMPI y el alcance del mismo.

Los resultados de un SCAMPI permiten a la organización conocer la situación actual de sus procesos, establecer prioridades, enfocar las actividades de mejora, reforzar áreas de oportunidad, así como tener las bases sobre las cuales establecer el siguiente ciclo de mejora.

Las evaluaciones SCAMPI es un nuevo servicio que ofrece Allsoft.

Nossa sessão Links foi reestruturada e ampliada.

Sugestões e indicações são sempre bem vindas.

Obrigado,

Giovani Faria

A gestão por processos pressupõe o conhecimento dos mesmos e a melhoria contínua requer frequentemente a modificação desses mesmos processos.

Para além de ser uma tarefa complexa, a implementação de processos redesenhados tem por vezes resultados inesperados e disruptivos, pois o que julgávamos ser feito afinal é apenas parte do “filme”.

Segundo o ITIL, um processo é um conjunto estruturado de actividades concebido para alcançar um objectivo específico, transformando um ou mais entradas definidas em saídas definidas.

Ainda segundo a mesma fonte, os processos são mensuráveis, proporcionam resultados específicos, têm clientes/intervenientes e respondem a eventos específicos.

…Mas em lado algum a definição diz que têm de estar no papel antes de serem realizados.

Dito isto, em terra com tradição de exploradores, há que reconhecer que a descoberta de processos é uma abordagem com enorme potencial.

A descoberta de processos consiste em mapear o tratamento dado às tais “entradas definidas” (um pedido de suporte, por exemplo) até que elas se transformem numa das saídas definidas (a colocação do registo do pedido no estado fechado, por exemplo).

Esta abordagem é particularmente interessante se for suportada por uma plataforma colaborativa, ao estilo Web 2.0, em que quem executa a tarefas indica o que faz, para quem envia o assunto em seguida e o que lhe solicita (autorizar, tratar, conhecer, etc.) Uma vez terminada a execução do processo, voilà! O processo está mapeado.

…Ou quase.

Para mapear o processo será necessário que o mesmo seja executado nas suas múltiplas variações, para se descobrir os diferentes percursos alternativos de tratamento. No entanto, se Pareto nos ensinou alguma coisa é que com 20% do esforço alcançaremos provavelmente 80% do resultado.

Fazer o levantamento do processo é a primeira parte.

Para “ITILizar” uma organização é necessário reformular os processos para introduzir boas práticas e melhorias continuadamente, o que será muito mais fácil se tivermos como ponto de partida a realidade, em vez de um conto bem contado.

Hacemos actividades para mejorar la calidad del software que generamos, sin embargo sobre el re-trabajo, el esfuerzo que le dedicamos a corregir errores, no hacemos mucho. El re-trabajo es uno de los mayores problemas del desarrollo de software y que consume mucho del presupuesto, pero la mayoría de las organizaciones no le pone atención. Una de las razones es que frecuentemente estos costos quedan mezclados entre todas las actividades de los proyectos, las agendas y los cambios.

Es común que las organizaciones de software no midan cual es su re-trabajo. El problema radica principalmente en que no tienen forma de conocer y controlar el esfuerzo que le dedica cada integrante al desarrollo o a las correcciones, ni tampoco el tipo de trabajo se esta haciendo, ambos necesarios para tener datos con los cuales trabajar.

¿Que cantidad de defectos inyectamos en el proceso de desarrollo y de que tipo?, ¿Cuándo se inyectaron?, ¿Cuál es el costo de estos defectos que estamos inyectando, en su identificación y corrección?, ¿Cuál es el costo de los defectos que aparecen en producción?, ¿Qué tantas liberaciones se hacen para corregir errores?

Si contáramos con información, podríamos tomar acciones encaminadas a disminuir los defectos, mejorar la calidad y la productividad, sin ellos, solo estamos trabajando a prueba y error, y muy probablemente, no usando los recursos eficientemente.

The purpose of a Quality System is to create an internal control system through defining and documenting processes with well-written procedures so that a company can address a few key areas such as Compliance, Operational Needs, Manage Risks, Knowledge Sharing and Continuous Improvements. For e.g. complying with the law of the land is a basic function of an organization and so is ensuring that the activities fundamental to the organization’s success are properly guided by the management and are performed in a consistent way that meets the organization’s need. While processes and procedures themselves may not demonstrate compliance, well-defined and documented processes (i.e. procedures, training materials) along with records that demonstrate process capability can make evident an effective internal control system and compliance to regulations and standards.

Creating dozens and dozens of procedures is usually not helpful.  In fact, such an approach can create more problems than it resolves.  They can’t be found, they aren’t used, they aren’t updated, and a glut of uncontrolled copies are scattered throughout the organization. This is exactly what happens when Quality Standards are imposed on businesses without due deligence.

On the other end of the spectrum are a set of companies, that have not gone for certifications, but instead have chosen to pick and choose the best of the processes from various standards based on their applicability to their businesses. E.g. of such companies are Oracle Corporation and Microsoft Corporation, both of which have stayed away from formal CMMi certification but do get an external auditor to benchmark once in a while how they are placed viz-a-viz the industry. Of course, such a strategy works well for product based companies rather than services company which needs to assure clients that it has the process to handle their requirements, but what this shows is that Quality Standards are not required for certification alone, but for a specific benefit. So what is the benefits that the organization plans to derive decides what Quality Standards are to be followed.

Lean processes tend to retain the processes that add value to the customer while cutting out those processes that do not. The simple fact is that if a process does not add value or generate revenue then it simply adds cost!! Lean Processes follow 5 basic steps:

One of the major irritants that I have faced with Quality Processes is when I am told to follow a process without knowing how it benefits me. It makes it all so easy when I know the value I get from following a process. Improper or Inadequate training has other drawbacks, as people in order to ensure that they are not flagged off for following processes tend to create records without following or understanding the actual process. This most of the times results in additional non-required records and documentation and again adds no real value at all.

La certificación de la calidad del software, entendida como la mejora de los procesos encaminados a obtener productos software, ha adquirido una gran importancia en el mundo durante los últimos años y España no es ajena a estos movimientos.

Las ayudas concedidas a las PYMES TIC para apoyar la certificación dentro del Plan Avanza 2006-2010, puesto en marcha por la Secretaria de Estado de Telecomunicaciones y para la Sociedad de la Información han jugado un papel importante en este resultado. Así lo atestigua el balance final de la convocatoria de ayudas del año 2008, que muestra una tendencia de consolidación en el interés de las PYMES en abordar la certificación, como un elemento no sólo de prestigio, sino de utilidad real a la hora de acometer sus procesos de negocio.

En la búsqueda de la certificación de la calidad, la empresa española apunta a CMMI (Capability Maturity Model Integration) como el modelo más valorado en la actualidad. Esta apuesta por CMMI se traduce en un incremento constante del número de organizaciones evaluadas en CMMI en España en los últimos años. Según el último informe publicado por el SEI (Software Engineering Institute) correspondiente a septiembre de 2009, contamos en nuestro país con 155 organizaciones evaluadas, frente a un número que no alcanzaba la decena a comienzos del 2005, fecha en la que el Plan Avanza comienza su andadura. España, de esta forma, se posiciona a la cabeza de Europa, superando a Francia (153 organizaciones evaluadas) que hasta la fecha ostentaba el liderazgo europeo. A nivel mundial, España ocupa la quinta posición, por detrás de Estados Unidos (1405), China (946), India (460) y Japón (290).

INTECO, y concretamente el Laboratorio Nacional de Calidad del Software, también pretende respaldar y contribuir a esta tendencia, con iniciativas como la colaboración en la traducción al castellano de CMMI o en la elaboración, junto con la Asociación Española para la Calidad, de una guía de gestión de proyectos basada en CMMI y adaptada a la pequeña empresa.

Nearly a decade ago, the Department of Trade & Industry (DTI) began to actively engage in the development of the information communications technology and electronics sector (ICT&E). The broad objectives were to grow the ICT&E industry to increase employment, broaden participation, encourage exports and promote small business development in this important sector… (more)

Se você é da área de TI, Informática ou Computação, provavelmente já ouviu falar de CMMI. CMMI (Capability Maturity Model Integration) é um conjunto de boas práticas de gerenciamento e melhoria de qualidade a serem aplicadas no processo de desenvolvimento de software.
Ao contrário do que muitos pensam, o CMMI não é uma metodologia de desenvolvimento de software! O CCMI é um conjunto de boas práticas para o processo de desenvolvimento e não para os projetos em si. Nesse caso, o CMMI deve ser visto no processo de forma macro e suas regras podem ser aplicadas nos mais diversos tipos de metodologias de desenvolvimento.
O metamodelo define uma série de medidas para a maturidade do seu processo de produção e classifica os processos de software em 5 níveis, de acordo com sua maturidade:

Etapas do CMMI

1.Realizado: Todas as metas específicas da área de processo foram satisfeitas. Isso inclui: definição de escopo dos projetos, ciclo de vida do projeto, estimativa de custos, prazos e esforço demandado para cada módulo/funcionalidade.

2.Gerido: Todo trabalho associado à área de processo está de acordo com a política definida pela organização. Envolve práticas de gerenciamento mais sofisticadas, algumas semelhantes à práticas do PMBoK, tais como: Gestão de Riscos, Orçamentos, Cronogramas, Planejamento de Recursos, Project Charter etc.

3.Definido: Todos requisítos do nível 2 foram alcançados e a empresa está alinhada com as ferramentas e comprometida com o modelo. O processo é mapeado e documentado.

4.Quantitativamente Gerido: A área de processo é controlada e aperfeiçoada usando medições e avaliação quantitativa. Indicadores para avaliação do desempenho dos projetos são criados.

5.Otimizado: O processo entra em fase de melhoria contínua. A maturidade é tanta que não é necessário mais criar novos subprocessos, apenas refinar os já existentes através de métodos estatísticos, garantindo maior qualidade e maior satisfação do cliente.

Obs: Os processos que não alcançam nem o nível 1 são considerados como Incompletos, e classificados a parte como nível 0.

E aí, qual é o nível de maturidade do seu processo produtivo?

Actualmente nos encontramos en un momento en que disponemos de estándares, marcos de trabajo y metodologías en el ámbito TI para cualquier trabajo del ámbito TI. Normalmente estas “normas” o “recomendaciones” están orientadas a ayudar a aquellas organizaciones especializadas en producir, mantener o explotar los sistemas TI. De un tiempo a esta parte, la externalización de los servicios de TI ha sido cada vez más habitual, y no existía un marco orientado específicamente a ayudar a las organizaciones no TI a gestionar y controlar la calidad del trabajo realizado por las empresas especializadas. Este es justamente el objetivo de CMMI-ACQ.

Este modelo ha sufrido pocas evoluciones, de hecho actualmente se encuentra en la versión 1.2 y fue liberado en noviembre de 2007. La documentación es de libre disposición en la página web del SEI.

La siguiente imagen permite situar los tres modelos CMMI según su ámbito. Como se puede observar, existen ciertas áreas de proceso que son comunes, no sólo entre dos modelos, sino para los tres, lo que facilita la comunicación cliente-proveedor y proveedor-proveedor. Estos procesos comunes están orientados a estandarizar, principalmente la gestión de los proyectos, procesos organizativos y elementos de soporte para toda organización.

CMMI-ACQ-DEV-SVC

El punto fuerte de este marco se centra en los procesos de adquisición, es decir, conocer qué externalizar, a quién hacerlo y si el resultado obtenido es el esperado. Dada la especialización, paso a exponer el propósito de cada uno de sus procesos:

• Desarrollar los requisitos de la adquisición (ARD) – Nivel 2: Analizar y desarrollar los requisitos del cliente y contractuales.
• Solicitar y desarrollar acuerdos con proveedores (SSAD) – Nivel 2: Preparar una solicitud, seleccionar uno o más proveedores que suministren el producto o servicio, y establecer y mantener el acuerdo con el proveedor.
• Gestionar el acuerdo (AM) – Nivel 2: Asegurar que tanto el proveedor como el demandante trabajan bajo los términos del acuerdo.
• Gestionar las soluciones técnicas (ATM) – Nivel 3: Evaluar la solución técnica del proveedor y gestionar las interfaces seleccionados para esta solución.
• Verificar las adquisiciones (AVER) – Nivel 3: Asegurarse que los productos cumplen con las especificaciones.
• Validar las adquisiciones (AVAL) – Nivel 3: Demostrar que el producto adquirido o servicio cumple con su uso previsto cuando se coloca en su entorno previsto.

Como se puede observar, estos procesos son claves para que una organización gestione la capacidad atendiendo a la demanda solicitada por su organización. Si añadimos aquellos procesos que garantizan el control de los proyectos externalizados, y además incluimos aquellos procesos de soporte básicos para disponer de la información necesaria en cada momento, tenemos un conjunto de procesos básicos para cualquier organización cliente que externalice la realización de los mismos. Este subconjunto, junto con sus interrelaciones entre procesos, está representado mediante el siguiente gráfico.

CMMI-ACQ-MarcoBasico

En en siguiente archivo pdf CMMI-ACQ-MarcoBasico (no permite incluir ficheros Excel), he listado todos los procesos clave incluidos en CMMI-ACQ, y si están o no incluidos en los otros marcos, cada proceso tiene además una ficha con su descripción, propósito y objetivos específicos.

La parte más dura, y en la que se centra el proceso de consultoría, es en la particularización de los procesos, la selección de técnicas y la particularización de las herramientas.

Espero que este post sea de vuestro interés y  vuestros comentarios al respecto para seguir por este camino.

CMMI son las siglas de Content Capability Maturity Model Integration, y viene a ser los estándares de mejora y procesos buenas prácticas que tienen que cumplir las empresas que se dediquen al desarrollo, mantenimiento y operación de software, definido por el Software Engineering Institute de la Carnegie Mellon University.

La última versión disponible es la v1.2, y se puede descargar en tres bloques (DEV; SVC y ACQ) desde:

• CMMI for Development, Version 1.2 (CMMI-DEV)
• CMMI for Acquisition, Version 1.2 (CMMI-ACQ)
• CMMI for Services, Version 1.2 (CMMI-SVC)

Aproveitando um pouco da idéia do post anterior (sobre melhoria de processos), comecei a analisar a “sopa de letrinhas” relacionada a este tema.  Esta sopa de letras inclui algumas das metodologias e técnicas que visam garantir eficiência e qualidade dos projetos com que tenho trabalhado nos últimos anos no ambiente de Desenvolvimento de Software para Telecomunicações.

Dentre elas, selecionei uma pequena amostra, as minhas Top 3, que são: PMBoK®, Scrum (Agile) e CMMi®.

• O PMBoK® (Project Management Book of Knowledge), do PMI® (Project Management Institute), tem uma posição de destaque na lista por ser considerado um guia de referência em gerenciamento de projetos. Nele, existem vários grupos de processo e áreas de conhecimento (com entradas e saídas bem definidas) que auxiliam na condução do projeto.
• Seguindo minha lista temos o SCRUM, que não descreve um processo ou técnica, mas uma metodologia de trabalho que na qual você pode empregar vários processos e técnicas no desenvolvimento. Este é voltado principalmente para atividades de  gerenciamento (monitoramento e controle) e incentiva a criação de uma estrutura dinâmica de desenvolvimento que regularmente faz entregas de partes do produto.
• E então, o CMMi® (Capability Maturity Model Integration), que é um modelo de melhoria que visa proporcionar às organizações elementos necessários (ou essenciais) para a maturidade em disciplinas (Áreas de Processo) relacionadas a melhoria da performance organizacional. Com CMMi® procura-se estabeler, documentar, institucionalizar e aprimorar um processo eficaz de desenvolvimento de software.

 O desafio

Informações sobre estes três elementos podem facilmente ser encontradas na internet e em livros de referência, entretanto, transformar toda esta Informação em Conhecimento exige bastante estudo, dedicação e, principalmente, experiência prática.

Olhando para o grande volume de informações disponíveis, creio que alguns questionamentos sejam bastante comuns:

• Por onde começar?
• Qual metodologia, técnica ou prática se adequa melhor aos requisitos e características do meu projeto? 

A prática

As respostas a estas questões não são triviais e requerem, além do entendimento das metodologias, um conhecimento mais profundo do tipo de projeto onde se deseja aplicá-las. Assim, para entender este universo e produzir bons resultados, pode-se desenvolver algumas atividades:

- Analisar o seu processo de desenvolvimento

- Identificar os pontos principais (eg. documentação, qualidade, ‘burocracia’, etc.)

- Determinar os tipos de controles necessários (eg. custos, esforço, estimativas, etc.)

- Avaliar os aspectos característicos de cada metodologia

- Selecionar os mais aderentes às suas necessidades

- Praticar, Otimizar e Melhorar = Inovar.

 Afinal de contas, não existe a metodologia perfeita, e sim, a metodologia mais adequada a realidade da sua organização e dos tipos de projetos que ela desenvolve.

Abraço, Giovani Faria

Rather than some tirade on why metrics are so great for projects, let’s just list some critical ones:

Schedule – Planned vrs Actual – preferably via Earned Value

Functional – % designed, implemented, tested, released

Delivery on Time – Milestones Planned vrs Actual

Cost – Planned vrs Actual to date

Cost – Planned Total at Completion vrs Revised/Re-estimate at Completion

Critical & Other Defects – Planned vrs Actual conducted + Trend

Resources (people, hardware, etc) – Planned vrs Actual

Resources (people, hardware, etc) – Planned At Completion vrs Revised/Re-estimate at Completion

Risks – New, Closed, Open + Trend

Issues – New, Closed, Open + Trend

Deliverables – Planned vrs Actual to date

Tests – Planned vrs Actual Conducted + Trend

Naturally all of these metrics are quantifiable.  Qualitative information can be useful when prepared in conduction with the above metrics.

Problems start to happen when people start wordsmithing their qualitative statements and start to leave out some of the quantitative stuff from reports.  That’s a BIG RED flag and caution should be taken.

Industrializar las Tecnologías de la información no es labor de un día. Ni hemos empezado ayer ni vamos a terminar mañana. En un reciente curso de ITIL, el profesor empezaba comentando cómo la aviación, una de las tecnologías e industrias recientes, tiene ya casi cien años. En comparación, las TI vienen a tener ahora unos treinta o cuarenta. Por lo tanto, estamos aún en la infancia: mucho por aprender, mucho por experimentar, pero muchos fallos todavía.

Efectivamente, en muchas empresas, al igual que en las Administraciones, las TI juegan un papel muy importante, pero al mismo tiempo se implantan y gestionan de forma muy artesanal. ¿Qué supone eso?.

Supone que, en primer lugar, su funcionamiento es irregular. La percepción del usuario, del utilizador, es que aquello puede fallar en cualquier momento. En mi opinión, ese es uno de los grandes obstáculos para la tecnificación y automatización de procedimientos, y por lo tanto de la optimización de los mismos. Sabemos que en esta fase final de la implantación del Acceso electrónico a los Servicios Públicos en la AGE, a la que obliga la Ley 11/2007, se van a poner muchos trámites en Internet, pero en la inmensa mayoría de los casos, si no en todos, seguiremos manteniendo la vía de entrada manual “por si acaso”.

Esto nos lleva al segundo problema: el coste. La inseguridad hace que se mantenga la segunda vía, y ello en si mismo es un coste importante, al tener que mantener varias formas distintas de hacer lo mismo. Y no es eso sólo: se achaca a muchos proyectos informáticos altas inversiones asociadas a fracasos. La percepción general es que, en plazos o en coste (que tienen efectos equivalentes), más de la mitad de los proyectos informáticos fallan.

Y ya sabemos que en una época de ajuste como la actual, en la que no sólo no podremos aumentar los presupuestos TI, sino que probablemente habrá que reducirlos, lo que sucederá es que, o bien se aumentarán los plazos, o bien, cuando eso no se pueda hacer, pues se trate de plazos improrrogables, el efecto será la disminución de la calidad de los proyectos y servicios TI asociados, contribuyendo más a la leyenda negra de las TI.

Así, el proceso de industrialización de las TI es necesario e inevitable, pero ¿cómo?

La respuesta corta es: aplica metodologías, estándares, catálogos de buenas prácticas como ITIL, CMMI, PMBOK, COBIT, … hay mucha información en la red. Asociado a ello, hay muchos movimientos en boga: IT Governance (Gobierno de las TI), Lean IT (TI delgadas), etc.

La respuesta larga es: todo ello será inútil si no implicas a toda la Organización. Especialmente importante es ser consciente de que la efectividad de todas estas acciones está supeditada a los cambios organizativos pertinentes, dentro y fuera del Departamento TI.

Y en el caso particular de las Administraciones, por su tamaño e idiosincrasia, sabemos que los cambios organizativos se llevan tiempo, MUCHO tiempo. ¿Quiere ésto decir que no debemos abordarlos?. No. Quiere decir que hay que planificar con plazos suficientes, si queremos ser eficaces, a pesar de que la presión diaria nos empuje a pensar sólo en lo inmediato.

Y con esto basta para iniciar éste extenso y recurrente tema. Terminaré con una cita encontrada en IT Cortex:

“Errar es humano, pero para conseguir líos verdaderamente monumentales, necesitamos ordenadores”