Our guest author, Albert Garriga, the man behindrecursosenprojectmanagement.com, covers in detail two of the most powerful methodologies for multiproject situations: critical chain and earned value.

vector modern colorful geometry triangle pattern, color abstract geometric background, pillow multicolored print, retro texture, hipster fashion designA common situation in many companies is the existence of several projects running in parallel, which share and compete for the resources of the departments. This is what is known as a multiproject environment, and requires criteria and tools to prioritize the allocation of these resources and maximize the overall result of the organization.

In this article, we are going to discuss two methods to be able to manage multiproject organizations; which are based on two well-known project management methodologies: Critical Chain and Earned Value.

 

Start calculating the earned value of your ITM Platform projects

Critical Chain Prioritization

If projects are planned using the Critical Chain method, the protections of the different projects allow for an objective criterion for the decision making process, at least in relation to the schedule; as this shows the actual status of the project and the risk of not complying with the delivery date.

Imagine that we have six projects, each with its protection related to the tasks in its critical chain and its degree of progress. From this data, we can place them in a graph that shows the percentage completed on the horizontal axis and the percentage of protection consumption on the vertical axis.

The graph would be as follows and allows to distinguish three areas:

  • Green area. The consumption of protection is low in relation to the progress of the task, implying that the project is performing better than expected, and therefore the confidence interval to meet the schedule has increased. This would be the case for projects D and E.
  • Yellow area. The consumption of protection is close to the estimated, so we expect the project to meet the schedule. This would be the case for projects A and C.
  • Pink area. These projects have consumed more protection than estimated for their degree of progress, so they will not meet the schedule if their performance does not improve or countermeasures are implemented. This would be the case for projects B and F.

This graph allows us to objectively compare the state of the different projects from the point of view of the schedule, and thus determine which of them need additional action to meet the objectives and which are less of a priority. Obviously, from the point of view of the organization, the objective is that all the projects fulfill their objective, which implies that all are in the green and yellow areas.

Based on this, it would be reasonable to pass resources from the green area projects to those in the pink area, and prioritize the latter in case of conflict. In a way, we are "damaging" the projects that are better to "favor" those which are worse, with the aim of all going as expected.

Another important point when it comes to prioritizing projects according to this chart is to view their progress, since a more advanced project will cost more to change their situation than one that is just starting:

  • In the pink area, means that a more advanced project will have higher priority when it comes to receiving resources than one that is less advanced.
  • In the green area, the opposite is true: the more advanced projects are the least priority, since the reduction of resources will have a lower impact on the final result (less time to act).

Prioritization with Earned Value

In projects managed with Earned Value, it is also possible to objectively prioritize and compare their status’, with the advantage being that in this case we can make time and cost comparisons simultaneously through different parameters:

Cost variation (CV), which is calculated as a percentage CV = (EV-AC) / EV, where EV is the earned value and AC is the actual cost, which is used with the following criteria:

  • CV> 0: project is saving money
  • CV = 0: the project is following the planned cost line
  • CV <0: the project presents extra costs.

Schedule variation (SV), which is calculated as SV = (EV - PV) / PV, where EV is the earned value and PV is the planned value, and is used with the following criteria:

  • SV> 0: the project is ahead of schedule.
  • SV = 0: the project is on schedule.
  • SV <0: the project is behind schedule.

Imagine that we have six projects managed with Earned Value, which allows them to be shown together in a chart according to their SV and CV; distinguishing four areas:

  • The pink area (3) shows the projects that are not meeting either the costs or deadlines (projects A and E); which then become the highest priority.
  • The two yellow areas (1 and 4) show the projects that are not meeting one of either cost (project C) or schedule (project B).
  • The green area (2) means that the project is better than planned in relation to cost and time (project F), or is progressing just as planned in point 0.0 (project D)

According to this criterion, the goal of the organization would be to have all projects in the green area. Therefore, the criterion in prioritizing resources would be as follows:

  • Prioritize the use of the most economical resources for projects in areas 3 and 4, which can be done even if it implies a delay in the projects of area 4, since these have more time in terms of schedule.
  • Increase resources for projects in areas 1 and 3 so that they can be completed quicker, even at the expense of higher costs in area 1 projects, taking advantage of having savings on them.
  • This prioritization can be done "at the expense" of the projects in area 2, since these have the margin to delay or assume higher costs. Except the projects in 0,0 which would be better left alone, as they are perfectly on track.

The most complex situation occurs in the projects located in area 3, since these must improve simultaneously both cost and time. This implies that we must avoid improving one variable by lessening the other.

Final considerations on prioritization

So far, the prioritization between projects has been treated objectively and based on quantifiable variables, which is correct but insufficient. In reality, there is another aspect to take into account: the political or commercial interests of the organization.

If we think beyond the time or cost of executing the projects, we see that not all of them are just as important for the organization. In some cases, we will have projects that can generate new orders or have high visibility, which gives them priority. Therefore, the person in charge of managing the portfolio of projects must know these political and commercial aspects, and know how to balance them with the objective criteria.

 

Albert Garriga

 

 

Receive the latest blogs directly into your inbox

 

A board, people filling columns Stories, To do, In progress, Test, Done

Implementing agile methodologies (Scrum, Kanban or any of their variations) is a challenge faced by all kinds of organizations, project offices and managers. The advantages to be gained from this type of method for a great number of projects are clear, but actually implementing them is no simple task. At many organizations their implementation is often met with fear, rejection and obstacles. Here are a few keys to successfully implementing a agile methodology.

 

 

1. Start with the Right Project

It is actually possible to apply the agile methodologies to almost any type of project but the successful implementation of these methods does indeed require selecting the right projects to begin with, so as to achieve the maximum benefit in the shortest time.
Trying to apply agile methodologies to clearly predictive or classic projects does not usually lead to good results, as there is a considerable sense of losing control, with teams (and management) tending to revert to methods they already know. In contrast, experimental projects: presenting a lesser defined or highly changeable scope with multidisciplinary teams and needing swift results: provide an excellent opportunity for applying agile methodologies.

2. Clearly define the Team's Role

The role played by a team in classic or predictive projects is significantly different to their role in agile projects. The Project Manager plays a leading role in the former, with control over all aspects of the project, whereas the team has a much more relevant role in the latter and the Project Manager becomes a facilitator of the methodology. It is important to clearly define the team’s role in order to implement the method correctly.
An agile project requires a multidisciplinary, self-organized and self-managed team, which is a confidence challenge for many organizations that tend to apply managed and controlled methods. Understanding and building this type of team is very important. If you can build a team that consists of relationships between equals and a shared goal, a large portion of your future success will be guaranteed.

3. Estimation of Effort is still Key

One of the most common problems when implementing agile methodologies is believing that estimates no longer need to be made. Even though it is no longer necessary to make an estimate of the whole project and we can focus on the tasks for the next sprint or those with a higher priority in the product backlog, it is important to realistically estimate the efforts required for the tasks and ensure they are reasonably equal or that the size difference between them is clear.
If a task has not been completed at the end of a sprint or a task is constantly shown as “ongoing” in a Kanban project, it is very likely that we have made a mistake in our estimation that should be corrected, the task should be broken down into more manageable parts and our commitments should often be revised. Flexible management will ensure that the estimate focuses on the tasks providing the highest value or that we need to tackle most quickly. However, the estimation itself is still important.

4. Know and control Limitations

Agile methodologies have limitations and they must be taken into consideration. There are scope, deadline, cost and quality factors that need to be met. It is true that priorities might be inverted or the scope might be more negotiable, but the limitations on deadline, cost and quality remain and must be managed.
These methods state that tasks should not exceed a certain effort, define a maximum Work in Progress (WIP) we can manage or establish a time-box by using sprints. Limitations must be strictly maintained and not changed lightly, as they are a very important part of their model. If we make changes or adjustments and accept all types of changes, we are losing control.

5. Manage tension

Although it might seem contradictory, agile methodologies are more like a long-distance race than a sprint. Some organizations approach these methods as a way of moving more quickly - getting more done in less time – taking advantage of the fact that teams are more deeply involved. This is true, but if we want the implementation of these methods to last, we must manage team tension.
Having a motivated, results-focused, self-managed and efficient team is possible with agile methodology. In order for these characteristics to last over time, we need to ensure that the team also perceives an improvement to productivity and not only a constant increase in effort and workload.

6. Metrics: “power without control is useless”

These methods are extremely powerful. They are capable of producing motivated teams that obtain impressive results in genuinely short spaces of time. Nonetheless, all this power does not come at odds with control. Agile methodologies encourage us to measure, analyze and constantly improve.

Metrics are the way to explicit project management based on real data rather than intuition, opinions or occasional emergencies. Speed, flow and commitment compliance are all key metrics that we should gather and analyze in order to streamline our processes and improve our teams.

7. Quality, Quality and… Quality

Quality means repeat business. Increasing delivery speeds, managing estimates incrementally or having a self-managed team do not mean setting quality aside. It is very important to deliver products quickly in agile methodologies but those products should also work; they need to do what is required of them efficiently.

That is why it’s important not to leave quality until the end and incorporate aspects of quality validation, revision and measurement of all the items, deliverables and products we generate during the project from the outset.

8. Remain to the methodology rigorously

Agile methodologies have few rules, standards or products. It is important to follow the method precisely, especially at the start. It is better to change nothing (or almost nothing) before gaining experience. If something seems strange, have a little patience and give it a chance.
Scrum methods establish a series of roles, meetings and stages that should be preserved, experienced and maintained in order for these methods to truly work as we expect. It is possible to go from less to more in these methods, but follow their instructions precisely until you are comfortable with their use.

9. Revise and adjust the method

As soon as we have advanced significantly in the use of agile methodologies, we can consider making adjustments to them. It is important to conduct reviews or retrospective exercises that allow you to see what does and doesn’t work within your organization and make the necessary changes to adapt the method to your culture, style and requirements. However, this should always be done after having tried the standard models.

Agile methodologies are indeed flexible, very flexible, and that is why they can be adapted to almost any type of project, organization or team. With a little experience, possible imbalances can be identified and changes, adaptations or additions can be made to these methods so as to ensure they perfectly suit our needs and circumstances.

10. Maximize visibility

One of the most important keys to the success of agile methodologies is visibility. Implementing these methods is done “behind the scenes” at some organizations, almost invisibly or as if applying this type of tool were embarrassing in some way. It is important for this type of implementation to be made visible, open and public so that the entire organization can see what is being done, how it is being done and what has been achieved by doing it.
Avoid using private "Kanban" methods or hiding them when the project client or sponsor appears. Be brave and show, explain and harness the most visible advantages. There is no better ally than a project client or sponsor that is involved in management, added to which agile methodologies enable maximum visibility and maximum participation from all stakeholders. An agile methodology is not an exception or an extravagance from an isolated team but something that can be applied throughout the organization.

11. Manage expectations

Many teams and organizations that embark down this path believe that all their problems will be solved as if by magic; that the client will never change their mind, that products will no longer have defects or that nothing “unpleasant” will ever happen during the project again. Agile methodologies adapt very well to changing and stressful environments but they are not the solution to every problem. Managing expectations from teams, clients and management is important to successful implementation.

The method may well not be perfect the first time around, that teams will feel uncomfortable with certain aspects of the method or that the project will encounter certain problems. This is completely normal. You will quickly see that progress is being achieved, that progress is significant and that the results are very positive.

12. Select the right tools

Using a support tool when applying agile methodologies facilitates their implementation at organizations. Having centralized support for sharing information, measuring progress and maintaining project control is highly important. With the right tool, teams will be able to work independently while the organization can maintain control over project progress, costs and revenue, efforts, etc.

Do not be fooled by tools that are free but completely disconnected from the rest of your organization. Agile methodologies are not an anecdotal or exceptional process implemented by teams with highly unprofessional tools; it is an important decision by the organization to adapt and improve. We are facing a project management revolution that is allowing us - with the right tools - to improve our performance, deliver high-value products very quickly and achieve great success.

 

Receive the latest blogs directly into your inbox