Project Management Trainee Program Tracasa

Progressive Elaboration and The Project Management Plan in the PMBOK 4th Edition

2009-11-05T05:35:00.001-08:00

Progressive Elaboration and The Project Management Plan in the PMBOK 4th Edition

During last weeks PMBOK course here at Tracasa we covered Chapter 4 and there was a lot of confusion about the process output, Project Management Plan Updates. One of the main reasons for the confusion is that the DFD diagrams show the Plan Updates flowing back to the Develop Project Management Plan process. At first reading, this may seem appropriate but it contradicts a popular interpretation of the integration knowledge area and progressive elaboration of the Project management plan. This interpretation is that you only carry out the process develop project management plan only once per phase iteration. That is to say that the full PDCA cycle is only carried out once per iteration and that the plan updates, which may or may not be subject to change control, update the project management plan directly or in some cases through the directing and executing process.

Several arguments can be made for this way of thinking.

The develop project management plan does not a have a plan updates input
The work of integrating input from the individual knowledge areas which is carried out in develop project management plan process has already been carried out in integrated change control process and hence there would seemingly be redundant work.

An explicit presentation of this view has been made by Muhamed Abdomerovic (thanks for the link to Alberto Goicoechea). We contacted Muhamed and asked if he had gotten input from PMI or PMBOK authors on his conclusion that the DFD flow for Project Plan updates is indeed incorrect in the PMBOK. He tells us that he has not.

We also searched for any other references to this error in the DFD diagrams but so far have not found any.

The more high level view and one more consistent with making the standard more flexible would be that the Develop Project Management Plan can in fact be repeated as needed even in a single phase but it must at least be performed once. Since the PMI view would most likely be that this first use of the process is the most important one, it is this iteration of the inputs and outputs that are focused on and hence diagrammed in the book. If indeed project management plan changes are made they may require re-planning to some degree and this reflects more of a PDCA structure. The Integrated change control would represent the Act phase of the PDCA cycle and the develop project management plan in the follow on cycles of the plan phase.

Which is better? The answer as usual is that it probably depends. In many ways this type of process "short circuit" can be found in other best practices frameworks such as ITIL where some short cuts are taken in the name of efficiency such as the support-operations bridge configuration.

In many real situations there are cases where it may seem like a too costly of an exercise to enter the develop project management plan process for every plan update. On the other hand some plan updates may just be to big and may require it. Maybe this signals a good time to think about using multiple phases in your project.

Workshop Gestión de Proyectos, PM Workshop 27 of October

2009-10-14T12:15:00.000-07:00

Our friends at TecnoEbro have organized a project management conference on the 27th of October. There are some very interesting talks planned (Full Disclosure: I am speaking about thats right...Trainee programs and certifications ...maybe this will be an exception but I´ll try my best...) in the areas of:
- Case Studies / Experiencias en Gestión de Proyectos
- Methodologies/ Metodologías de Gestión de Proyectos
- Tools/ Herramientas para la Gestión de Proyectos
- Standards and Certifications/ Estándares y Certificaciones para las personas y las entidades

Here is the link to sign up (its free!) http://www.gestoresdeproyectos.es/blog.

Español:

Desde TecnoEbro, junto a CAAR, AERA, IDIA y TECNARA estamos organizando un workshop, cuya participación es gratutita, que tendrá lugar la mañana del día 27 de octubre.

Para realizar la inscripción, así como para conocer todos los detalles de la jornada, les invitamos a visitar el blog preparado a tal efecto:

http://www.gestoresdeproyectos.es/blog

2009-09-29T03:56:00.000-07:00

Ayer cumplí un hito en el proceso de formación en gestión de proyectos que vengo relizando desde septiembre de 2008 de la mano Mans Shapshak. Este hito ha sido la obtencion de la acreditación Comptia Project+ (http://www.comptia.org/certifications/listed/project.aspx).
No os cuento nada nuevo si os digo que el estudio para este examen exige un esfuerzo suplementario al que requiere la lectura y comprensión de los términos propios de esta disciplina. Sobre todo en lo referente a la metodología basada en el PMBOK del PMI, áreas y procesos de la gestión de proyectos, entradas y salidas a los procesos, roles y responsabilidades...

Personalmente me ha ayudado a:

Ordenar las prácticas que venía aplicado a la gestión de proyectos y conocer los riesgos que tiene el no aplicarlas.
Ubicar cada una de las tareas que vengo realizando en una de las 9 areas de experiencia y en uno de los 5 grupos de procesos.
Poner en práctica algunas de las técnicas que he estudiado.
Darme cuenta que todavía me queda mucho por aprender.

Projects, Programs and Portfolios and the PMO Service Catalog

2009-07-05T03:30:00.000-07:00

In the latest edition (4th) of the PMBoK the framing of Projects, Programs and Portfolios has been expanded. Some of the highlights which I found most interesting include:

An implication that program managers actively manage project managers while portfolio managers are less hands on and only provide coordiantion.
it is normal to have a mixture of individual projects and programs in a Portfolio.

Also there is an expanded section about the Project Mangement Office (PMO) with a basic Service Catalog. We have developed a similar service catalog with basically the same content as can be found in section 1.4.4 :

Managing shared resources (This will true for a Strong Matrix or Project Organization)
Developing a Project Management Methodology for our Corporate Domains (One of our Favorites)
Monitoring Compliance with project management standards, policies and procedures (Normally coordinated with quality departments)
Coaching and Training
Developing organizational process assets
Coordinating Communication across projects (Program and Portfolio Roles)

Cuestiones sobre Comptia Project+

2009-04-07T09:44:00.000-07:00

Voy a poner aquí algunas cuestiones que he desarrollado en la preparación para la certificación en Comptia Project +. Me ayuda a fijar conceptos y a vosotros a refresarlos.

1- Un WBS es:
A. Una descomposición de trabajos para el proyecto
B. Una lista de tareas a realizar concatenadas en el tiempo
C. Una descomposición de trabajos orientada a entregables
D. Una descomposición de trabajos orientada a presupuesto

2- Cuales de las siguientes frases son correctas respecto a la estimación de costes basada en “phased gate” (Elige varias opciones)
A. Es la forma más rápida de obtener un presupuesto.
B. Es la forma de que el presupuesto sea lo más exacto posible.
C. Siempre aprobarán un presupuesto preparado con esta técnica.
D. La estimación está basada en el WBS

3- La ley de los rendimientos decrecientes (Law of Diminishing Returns) considera:
A. Al aumentar los recursos asignados a una tarea disminuye la duración de la misma.
B. Al aumentar los recursos asignados a una tareas aumenta la duración de la misma.
C. Al aumentar los recursos asignados a una tareas no disminuye proporcionalmente la duración de la misma.
D. Al aumentar los recursos asignados a una tarea disminuye proporcionalmente la duración de la misma.

4- Para la estimación de la duración de una tarea se puede utilizar la técnica PERT. Con esta técnica que entradas se deben obtener.
A. La estimación optimista y la pesimista
B. La estimación máxima y mínima
C. La estimación superior e inferior
D. Ninguna de las anteriores

5- En la elaboración de un presupuesto cuales de estos casos se deben contemplar (elegir varios)
A. Adquisición de Hardware
B. Actualización del Hardware
C. Adquisición de Software
D. Siguientes versiones de Software
E. Instalación del software en los equipos

LAS SOLUCIONES ESTÁN EN EL SIGUIENTE COMENTARIO

PMO 2.0 Survey Report Podcast

2009-03-29T13:58:00.000-07:00

Here is a great PM podcast with Cornelius Fichtner, PMP about the PMO 2.0 Survey Report which talks about how the PMO is becoming a "Business Management Center". Just a few key points to wet your appetite:

Many PMOs are getting involved with operations (This seems like an obvious and welcome step to me since so much of operations is actually continuous improvement where each PDCA cycle is really a well .... project. See ITIL and MOF literature for more.)
You really need more than 4 people to get an PMO off the ground. (Did somebody say critical mass. Even Dr. House has a staff of 4 ;-) )

Lots more excellent details in the report.

Project Management is a "sweet spot" of CMMI

2009-03-15T15:35:00.000-07:00

Just ran into this excelllent CMMI presentation. Here Keith Heston, a Senior Manager at Accenture, puts CMMI in perspective from a complete quality program.

For software development point of view with a Microsoft flavour we can even blend in MSF and MOF (actually Keith mentions ITIL). But elements of Six Sigma and product development and general business strategy are also mentioned.

Of course the question comes up "What is the benefit to me for implementing CMMI and how long is it going to take me to implement it.". And natually the Keith answers "it depends."

And he specifically mentions that it depends on:

Where you are starting from as an organization
What you priorities are
How many resources you want to devote
How complex your organization is
How many sites do you have
How mnay project do you have.

He focuses that Project Management as a "sweet spot" of CMMI.

You can find the audicast of an interview with Kieth Heston here.

Bookmark this on Delicious

Estimación agil

2009-02-17T10:15:00.000-08:00

A la hora de estimar el esfuerzo que puede suponer el desarrollo de una funcionalidad. Además de poder basar la estimación en experiencias similares ( top - down ). O deducir el esfuerzo dividiendo el esfuerzo en tareas más pequeñas y fáciles de estimar (down - up). Os propongo un novedoso, ágil y divertido método de estimación.

Los detalles completos se pueden obtener la página: http://www.planningpoker.com/

Os explico brevemente el funcionamiento:

Una vez dado de alta en la web, que es muy sencillo.
Se crea un nuevo juego en el que se detalla una funcionalidad para estimar el esfuerzo.
Se invita por medio de correo electrónico a los participantes.
Mediante una multiconferencia (podeis utilizar http://www.dimdim.com) se debate el tema y pasado un tiempo se pide que cada participante estime el esfuerzo eligiendo una carta.
Al finalizar el juego ya se tiene las estimaciones de los participantes, sin desplazamientos ni largas reuniones.

Six Sigma and the TOC

2009-02-15T13:46:00.000-08:00

Just ran into this excellent Six Sigma presentation. What stikes me is how closely it is related to the theory of contraints. The PMBok does mention Six Sigma but only in passing and what is interesting is the focus on finding the important variables just like in TOC. Six Sigma DMAIC

Define
Measure
Analyze
Improve
Control

is linked to controling only the important variables.

In TOC the focus is on defining the contraint

0. Set the goal
1. Identify the constraint
2. Decide how to exploit the constraint
3. Subordinate all other processes to above decision (align all other processes to the decision made above)
4. Elevate the constraint
5. If, as a result of these steps, the constraint has moved, return to Step 1.

In a way the language is different but the key is intense focus on the most important factors. TOC is more production oriented with the assumption that the desired result is clear ie. think of the Factory in "The Goal" while Six Sigma seems to add more ambiguity in the casue effect relationship to finding the constraint.

Issue logs vs. Risk Register

2009-01-30T00:32:00.000-08:00

We have discussed risk management a lot here so we thought it might be interesting to mention the difference between the Issue log and Risk Register.

The risk register is the list of ranked risks which have been analyzed analytically and qualitatively and hopefully integrated into the Critical Chain ;-)

The Issue log is the list of “things” that keep the project team from meeting goals. In terms of software development these issues are most often software bugs. But in the wider PM context they could be anything from a spelling mistake in documentation to a human resources issue.

These issues can be assigned to a team member and a resolution date fixed - kind of project "To Do" list that doesnt formally go into the project schedule.

Riesgos y toma de decisiones

2009-01-27T08:45:00.000-08:00

[English readers please skip to the bottom...]

Hace unos días se dio una circunstancia especial. En un proyecto que estaba en la fase de aprobación del alcance, con el alcance prácticamente definido, surgió un riesgo que podría modificar sustancialmente el alcance del proyecto. La duda en aquel momento fue ¿que hacer?:

Parar el proyecto, puesto que si ponemos en duda la validez del alcance, todo el trabajo que se haga con esa base habrá que rehacerlo o modificarlo.

Continuar con la aprobación del actual alcance y seguir con las actividades ya planificadas, para después gestionar el riesgo y las modificaciones que pudieran surgir.

Hacer una evaluación rápida del riesgo para decidir que es mejor si parar el proyecto o continuar.

¿En que podemos basarnos para tomar una decisión acertada?
Existen algunas técnicas para ayudar a tomar decisiones que podemos utilizar para valorar cada una de las opciones y tomar una elección. Una de esas técnicas es el uso de un árbol de decisión, es una técnica en la que se valora económicamente los riesgos y beneficios de cada opción (véase http://www.mindtools.com/dectree.html ).

Otra técnica posible es el Análisis Jerárquico de Procesos, que es capaz de ponderar aspectos subjetivos como por ejemplo preferencias empresariales, alcance, tiempo, y aspectos objetivos, como por ejemplo económicos.
(véase http://www.mindtools.com/pages/article/newTED_88.htm )

Se podrían enumerar aquí varias técnicas más, de mayor o menor complejidad, pero la cuestión que está de transfondo es ¿Cuáles son los criterios que vamos a tener en cuenta a la hora de valorar las opciones, el tradicional Coste, Alcance, y Tiempo?
La almohada nos dirá algo más…

For our English readers:

Here Alberto discusses the decision making process of what to do when one discovers a potential important change in the scope which could implicate re-doing work.

He provides a link to typical financial decision trees ( which is obviously what I think is cool - having dollars for eyeballs.)

And then he provides a link to a tool which allows for the use of several different types of factors including scope, cost and time.

Scope, Time, Cost Redux

2009-01-25T08:15:00.000-08:00

We have been thinking about how to make the best decision about when to stop work and review a change of scope or when to continue work. I won't go into detail about that since Alberto will surely be posting about it soon but I wanted to discuss something that has been on my mind for a while.

Do we really need to include Scope and Time in analytical analysis? The issue comes up in integrated risk management.

Money makes the world go around or as we have been noticing lately the lack of credit certainly makes it slow down. (We cant complain about plain old money since M0 has been pouring out of the fed...woops wrong blog :-) )

But my point is that often we try to balance the magic triangle of scope, time and cost in projects.

Maybe its time to just throw that out and really use money for whats its good for. That is to say use it as a way to value other things. So instead of asking functional managers what they want, it might be more interesting to ask them "how much will that save you?" or even better "How much will that save you on that date vs. that date".

Of course project leaders are not supposed to make those kind of decisions but when you have to decided what to do in most cases it comes down to a financial decision. In the PMI spirit of Project Managers as empowered leaders who make decisions about the change scope and timelines will always comes down to the economical realities merged in an ethical environment.

Is this the Ayn Rand world we live in? Well probably not completely. So while cost redux is something that we most certianly must use for risk analysis it maybe be difficult to do in meetings with funcional managers and program managers who in the best case can actually provide the numbers to provide us with scope and time translated to dollars or euros.

Coaching y gestión de proyectos.

2008-11-25T09:19:00.000-08:00

El artículo publicado en la revista “Fortune” del 27 de octubre, de título “Why talent is overrated?", hace ver que el talento de las personas no es la clave para alcanzar la excelencia en una actividad. Esa excelencia se basa en lo que denominan “práctica deliberada”. Esta “practica deliberada”, que yo denominaría práctica planificada, está basada en la consecución de un objetivo concreto. En el artículo hacen una serie de recomendaciones para conseguir obtener la excelencia en nuestro desarrollo profesional. Entre las técnicas cabe destacar el coaching.

¿Podemos preparar un plan de desarrollo profesional que incluya coaching y gestionarlo como si se tratara de un proyecto? La respuesta es “no completamente”. Podemos incluir en nuestro plan una serie de facetas a mejorar, y dentro de nuestro plan podemos establecer que actividades vamos a hacer para mejorarlas. Hasta aquí es planificable y gestionable como un proyecto. Pero si en este momento incluimos un coach, la planificación se queda en una mera guía de deseos. El incluir un coach en este proceso, tiene como consecuencia una vigilancia continua de las actividades, y continuas y concretas recomendaciones para corregir lo que el coach ha detectado. Este comportamiento de continua vigilancia y de continuas propuestas de mejora, todas ellas muy personalizadas impide el poder aplicar las técnicas de gestión de proyectos. Supondría realizar continuamente una gestión del cambio y el alcance sería algo completamente dinámico, lo que va en contra de la buena gestión de proyectos.

Note for our english readers: In this blog posting Alberto discusses the problems of combining coaching and project management. He refers to the article "Why talent is overrated" and explains that the excersize of delivberate practice which is carried out by coaches is a very interactive process and requires the continual shifting of the objectives. One may start of with a broad goal but the work of the coach is to always push the student to the maximum of her abilities. This is opposed to project management where a clear and defined goal is prefered.

-Mans

Merging the Business Process and Project Methodology

2008-11-25T07:38:00.000-08:00

As organizations get to the maturity level where they focus on developing a PMO the first action on the agenda is often the most difficult: develop a company project methodology.

Having been involved in several consulting services companies efforts to develop such a methodology I very much appreciated Cornelius Fichtner´s interview with Jeff Berkel from Metafuse about the development of PM Methodology Tool.

What some teams may find somewhat perplexing is to differentiate the project methodology from the business processes.

In a way this complexity is the result of the complexities of matrix organizations with well established processes at the department level mixing with project methodologies which are newer to the organization.

And of course there is the challenge of integrating the tools that are invariably from departmental silos(D) or the buding PMO:

Financial Reporting and Accounting(D)
Time Tracking (D)
Project scheduling (PMO)
Resource Planning (PMO if you are lucky, Departments if you are not)
Customer Relationship Management and Sales Software (Sales and Marketing)
Product Lifecycle tools for version control, release, distribution and version control (Operations, Engineering)
Project Management Information System with Knowledge database(PMO)

Share your Play Book

2008-11-12T00:47:00.000-08:00

[image: http://senseable.mit.edu/nyte/]

Network theories have been around for some time. And they have been popularized recently with the rise of the Internet, a game about how movie stars are related, how to fight terrorism and most recently by social networking tools online like twitter and linkedin.

The main take away from these theories is that the number of connections that nodes (think people, computers, cells etc) have is not a bell curve as one might expect but rather a power law curve decreasing exponentially as we reach a high number of interconnections. This hub model has huge implications for everything including project management and organizational theory.

The same thing tends to happen in organizations. People work with the same teams and there is very little dynamic interlinking. This is obviously more the case in the functional organization and in fact the projectized organization is much more able to receive the benefits of the cross pollination by having project members sharing their play books (A play book is a set of strategic ideas to be used in a play in American football. It is a metaphor for the strategies that most of us use repeatedly in our daily based on our experiences of success with them.)

So it seems like a no brainer. The more you share experiences the better. Share between people in different disciplines, different functional organizations, different providers. Move people around and mix it up to create more interlinking.

One criticism is that once people are used to working together the communication is much more fluid. I think this is mainly the case for people that are not used to switching teams. So the more you practice…the better you get at it.

Another criticism is that it is destabilizing. Obviously very interlinked group tends to reduce the power of hierarchies because information does not only flow up and down the chain of command.

And a third is that at some point once people are massively interconnected there tends to be a weighting to a sort of average as pointed out by James Surowiecki. That is to say the same diversity which created increased creativity and productivity by cross pollination is squashed by the feedback of the most successful of these ideas (think memes) feeding back into the nodes so that individual team members are more impressed by others ideas than their own novel ideas.

A little more About CCPM and a CCPM MS Project Plugin

2008-11-05T14:56:00.000-08:00

In response to my last post the people at PM Hub sent me a link to a short article about critical chain which briefly sums up some of the issues with Critical Chain.

There are some good references in the article including Lawrence Leach’s book Critical Chain Project Management which is especially interesting because Lawrences company also sells a Critical Chain Microsoft Project plugin CCPM+ which is available to try with a 60 day trial.

Resource Critical Path, Critical Path and Critical Chain

2008-11-04T14:31:00.000-08:00

A survey of Project Management books and articles should lead us to believe that we live in a world of infinite access to resources. This has probably never been true but even less so today as organizations get more projectized and resource contention gets worse than ever.

One of the ways that this bizarre fantasy land shows up in the literature is the focus of Critical Path. Because what becomes clear is that as soon as you resource level your schedule your critical path is no longer a true critical path since resource restrictions open up scheduling gaps.

This is where RCP or Resource Critical Path comes into play. RCP is not a widely used term but a discussion can be found here and here.

And most importantly RCP is what is used as the Critical Chain in CCPM since Critical Chain places the focus on resource contention as the constraint and exploits it by optimizing resources on this RCP or Critical Chain.

NASA Project Management Video

2008-11-03T06:38:00.000-08:00

Well there is nothing like NASA to pump up Project Management. Enjoy the Video Above!

Mihaly Csikszentmihalyi on Flow: Can we double the Flow Rate?

2008-10-25T14:04:00.000-07:00

Here is a great talk by Mihaly Csikszentmihalyi on Ted about flow.
Its a great thing to remeber just how important it is to get people to work in an area which is challenging and where they have expert knowledge.
It is really clear that when people have been developing skills for some time (10 years is a common number) and have developed an expertise and then they are presented with a real challenge this is when they can go into that hyper productive and creative state called "flow".
This tells us a lot about recruiting for projects or organizations:

Experts are valuable when we can give them challenging work

If you are training people you need to keep them focused on getting to the expert level and then retain them.

Dont disturb flow by moving experts into roles where they are not focused or challenged ie. upwards in the functional divisions.

From my experience most organizations probably have less than 3% of flow going on. Imagine just doubling that to 6%.

Combining Risks that Occur in parallel or in series

2008-10-20T03:19:00.000-07:00

One of the benfits of doing integrated risk management is that by pooling risk we can normally shorten a projects ciritical path. The reason for this is that risks can be treated in parallel. This is the case when the issues can be solved by seperate organizations or individuals in parallel as would normally be the case for risks in specific work packages. We don´t need to sum the durations but actually we should use the formula for parallel availability.

For example for a risk which have a 50% risk we find as the number increase the probabilty of having to extend the project to the entire period of those risks is:

On the other hand for risks in series we find that as the number of risks increases the distribution goes towards a binomial or normal distribution.

Don’t expect things to happen - plan and visualize them

2008-10-16T02:04:00.000-07:00

There is quite a bit of material from mental health and improvement material which implies that one should have “expectations of achieving a goal low and our motivation for working to achieve it high”.

About expectation

Another way to view this is that expectation is another way of saying that we expect something to happen without planning. If we have planned it, are checking the results and above all identified the risks we are managing our expectations or those of our client.

As an example some people might go through the day with the expectation that their spouse will bring them a martini when they come in the door. To expect a bonus a the end of the year but not to have planned to get it and executed the steps nor analyzed the results is pretty silly. Have they considered the milestones to see if they are on track to reach that goal and carried out risk mitigating plans?

The answer is probably not, since if they had done that they wouldn´t have expectation, rather they would have a reasonable idea of their chance of getting to their goal.

Phrases like “Plan for success” come to mind. Basically what it comes down to is that expectation is an emotional response without substantial analytical planning and analysis.

About Visualization

But isn’t expectation the same as positive thinking. After all there is a very strong movement in psychology to get people to believe that they will achieve results, to think positive if you will.

They are not exactly the same. Consider the following phrases:

A) Expectation: I expect that my project team will deliver the results on time and budget.
B) Positive Thinking: I am visualizing my project team delivering the results on time and budget.

What is clear from the expectation phrase is that expectation is kind of resigned state and that the positive thinking phrase is an active exploration of how these events might occur. By visualizing you are exploring the path in your mind before and after and it helps you create a plan.

If you want something to happen you can’t simply expect it and shut down your mind and wait for it to happen. You have to plan it, execute your plan, measure the results and reflect on your plan (PDCA) while including a good share of risk planning.

Risk Seminar at TecnoEbro

2008-10-08T13:48:00.000-07:00

Yesterday I was in Zarragoza presenting our Integrated Risk Management methodology at a TecnoEbro Project Management Workshop. There was a lot of interest in how we are combining Critical Chain Project Management (CCPM) with risk contingency planning to reduce schedules and make projects more efficent.
I presented one implementation of the methodology we are using in the CINeSPACE project for our semi-automatic annotation tool. The diagram above shows the schedule. Some of the key features are:

Ask for estimations without any risk included
Take best case (Positive Risk as baseline) (CCPM)
Include risk negative risk register
Identify risks as discrete or continuous
Identify risk dependencies serial or parallel with other tasks
Late Start (CCPM)

I dedicated a fair amount of time show the importance of the statistical combination of risks in the contingency buffer and I will cover this in the next few blog entries.

Quantitative Risk Analysis and Response Planning

2008-09-16T13:47:00.001-07:00

We have been working on developing a consistent Risk Plan and one of the clear results is the importance of combining response planning and quantitative analysis processes in risk management. Our focus has been that for every task we want to move schedule risk and cost elements from baked in estimations into the risk register so that we can control risk and move to a critical chain type of schedule development and avoid unecessary schedule buffers at the activity level.

This means that both mitigation and contingency plans should be included in the risk register and hence passed to the project or feeding buffers depending on the risk tolerance. Most of the time risk tolerance will keep mitigation plan but contingency plans will be left on the risk register.

An example of this developed by one of our trainee´s is the mitigation plan of carrying extra fuel on a boat to counter strong currents. Obviously we need to include the effects of strong currents in the budget and schedule buffers. But at some point if we may need to go to our contingency plan of going to a port and wait cancel the trip. Our tolerance for risk might move this unprobable risk out of the schedule and budget. It would stay on the risk register of course as a low probabilty risk.

Integration Management

2008-09-02T12:27:00.000-07:00

One way to look at the integration management processes is projecting them onto the PDCA cycle.

Above is a diagram carrying out this exersize.

The inputs and output become easier to follow. Some of the key features are:

Work performance data comes out of the Do part of the cycle
Forecasts come out of the Check part
Requested changes typically start their life with the green arrow as a result of results which are not inline with the plan or in the Integrated change control as an external input.

What is maybe a bit fuzzy is the way quality control is handled in coordination with Integrated change management.

Formulas for Work Rates, Estimating Revised Values and the relationship to SPI

2008-08-26T12:48:00.000-07:00

In some situations one may run accross that the initial work rate for a open price contract is going to fast or too slow so it is necessary to vary the rate after the measurement. The formulas above show the simple case where two periods P1 and P2 add up to the total period Pt.

The initial estimate to do work Wt is that a rate of Ro for the time Pt is required. If this rate is used the SPI will be 1 since the planned value will equal the earned value.

On the other hand if we have a rate R1 during P1 which is too low or too high (as in the graph) we need to reduce the rate R2 during P2 in order to reach the goal. The value of R2 to reach the goal is given in formula (5).

The SPI at any point during P1 with rate R1 is obviously higher than 1 (for the example in the graph) and is constant for the period since EV/PV=R1*t/Ro*t= R1/R0.

The SPI during the second period P2 with R2, however, is variable and varies from R1/R0 at the begining of the period to 1 at the end since we calculated R2 with just this purpose in mind. The exact formula can be found by combining the EV/PV from

and equation (5). The result leads to a variable SPI for the period which is somewhat missleading in the sense that if we are using SPI as an indicator it serves us well as we drift from the schedule during P1 and gives us a sense of how much we need to correct during that period.
But once we have started the correction, however, as we have in the second period SPI varies and shows us how close we are to getting to the schedule.
To see the overall trends and for forecasting therefore it is more interesting to use R1/Ro or R2/R0 ratios and not use SPI.