International Project Management: Leadership in Complex Environments

Characteristics Of Issues

An issue surfaces. But it may not be an issue. It may be a symptom of a more complex problem. It may be a previous issue reappearing. Or it may just be more about an existing issue. This gives us the following guideline:

In an international project, you always want to analyze and assess an issue before making decisions and taking action.

You should not rush out and assign it to someone until you understand better what you are dealing with. The next guideline is that it is the project leaders who should undertake to do the initial analysis of an issue. Then it may end up being assigned to someone.

Issues can be considered by types. What is a type? It is a category of issue. One method of defining categories is to consider the source of the issue.

Use the above list as a starting point for type. Another method of rating or typing an issue is by impact. This also might be considered important. A third method is by time urgency. How pressing is the issue?

Still another categorization of issue is by control. Do you have the resources and management authority to act on the issue? The killer issues for many international projects lie in those that are beyond the control of the team. It is these that you have to build contingencies for. You might want to assume the worse that can happen and then minimize the impact. This is the minimax approach to issues management. It sounds good, but it has several drawbacks. First, it tends to make the situation and you more negative. Second, it can lead to an overly conservative approach to a project when a more aggressive stance is required. Temerity is not often a winning trait in international projects.

Another characteristic of an issue is the status. When an issue appears, it should be given a pending status depending on investigation. Then if it becomes an issue, its status is open. When you resolve an issue, it becomes closed. An issue can also be combined with another issue.

Why do some issues fail to surface until the end of the project? There are many, often political reasons. Some people may not want to use the results of the project. When they see that it will be completed, they may raise last minute issues. Another reason is that team may be too isolated from the real world. As the project gets closer to completion, the real world starts to move in on the project— just like fog. The issues could have been there all of the time, but they went unnoticed.

Potential Actions And Decisions

What can you do about an issue?

Most of the time you should do nothing about an issue.

Why nothing? Because you lack information. The issue may not yet be “ripe” in terms of urgency. If you act too soon, management may not support your decision. That can look real bad. Also, you may end up treating a symptom and not the underlying problem. The issue will then surface again in another guise. It is the same with children growing up. If the parents run to the doctor with the child for treatment for every cold, the child could become over-treated with antibiotics. Then when the child really becomes sick, the antibiotics are not effective and the child gets sicker.

There is another guideline here. Many issues that surface in one country are specific to a situation. The situation may change on its own and cause the issue to change or go away. Or it could become more pressing. This is especially true with issues that you do not control.

There are political currents related to issues. You may not want to solve an issue right away. You and team might look better to management if the issue becomes more acute. This sounds perverse, but remember you are dealing in a political world. If the project and the world around it won’t collapse, what is the harm in doing nothing? If you keep acting on issues quickly, you can be seen by some managers as “shooting from the hip” without thinking—not a good way to be typecasted.

You can also examine the following as decisions and actions to take. Use this as a checklist when you are evaluating an issue.

Follow these guidelines when getting ready to solve a group of issues:

Many mistakes made by many governments on the international level could have been prevented had these actions been taken.

A General Process For Managing Issues

You should always consider groups of related issues. In an international project of any size and complexity, if you consider one issue at a time, you are going to drive yourself crazy.

The general process for handling issues is presented in steps in Fig. 10.2. Here are some additional comments on these steps:

Figure 10.2: Steps in Addressing Issues

Issues And Multiple Projects

Many issues may impact several subprojects and other projects. Solving an issue for one project may make the issue worse in another setting. Thus, as part of the analysis of issues, you should employ the table in Fig. 10.3. In the table the rows are issues and the columns are the projects or subprojects. There are several ways to fill the table. One approach is to use “X’s”. You put in an X if the issue pertains to the specific subproject or project. A second method is to put text in each box that explains in a summary form the impact of the issue on the subproject or project.

Figure 10.3: Issues versus Projects and Subprojects

There is another approach. Return to the GANTT chart. Since you are employing standardized templates, you can create an overall GANTT chart that contains summary tasks from all of the projects along with the tasks that are affected by the specific issue. This is often a good graphic method for getting management to sit up and take the issue seriously. You can do the same with groups of issues.

Now let’s suppose that you are a manager over a number of international projects that differ in size and issues. Figure 10.4 shows two projects that differ in size and issues. Where do most managers spend their time? On the larger project. But this is wrong. The other project, B, has many more issues and so should get more attention. You might want to use this graphic to focus attention on those projects of moderate size, but with many issues.

Figure 10.4: Example of Two Projects Differing in Size and Number of Issues

Issue Analysis

There is a great deal that can be done with only a small amount of information in the issues database. Let’s restrict our attention to the following data elements:

In fact, you can export data elements into a spreadsheet to go with the graphs that will be presented. The point here is to emphasize that this is easy to do, has a number of benefits, and can be done without interfering with your regular work. Six different analyses will be discussed using the basic data. You can expand on this by considering other graphs and charts.

Open Issues by Type

At any given time an international project has a number of open, unresolved issues. The mixture of the open issues is very important as you will see. Let’s use the following types:

Now at the start of an international project, many of the known issues typically relate to requirements, technology, the team, and the work. A typical chart is shown in Fig. 10.5 for a project. Another example is given in Fig. 10.6. These are two spider charts.

Figure 10.5: First Example of Number of Open Issues by Type

Figure 10.6: Second Example of Number of Open Issues by Type

If you could choose which chart would apply to your project, which would it be? If you picked the first one, you would be correct. Why? In the chart of Fig. 10.5 most of the issues are in areas that you control. In the chart of Fig. 10.6 disaster may loom. Most of the issues that are open are in areas that you don’t control. Bad news!

What can do with these charts? They first show that you are on top of the issues. This shows you and the team in a favorable light. Another use is as a tool to press for resolution of some of the issues. However, a major use of the chart is to understand the state of the overall international project. Status, percentage complete, and budget versus actual are OK, but this chart speaks volumes about the project.

You should also redraw and update these charts on a regular basis. They will tell you how you and the team are doing in solving the critical issues and getting these addressed.

Total Number Of Issues Over Time

Here you only use the date of discovery of the issue. The x axis is time. On the y axis is the number of issues that have been found as of that point in time. You can also do this chart by type of issue. Figure 10.7 gives an example chart with two international projects. The solid line represents a project that is going well. As time progresses, there are few new issues found. There is a spike toward the end to accommodate the seemingly inevitable hidden issues that surface late in the project. The dotted line is another matter entirely. This is a project in trouble where new issues keep surfacing. Note that this chart says nothing about solving the issues. Nevertheless, it is another indicator of the project state.

Figure 10.7: Total Number of Issues by Date of Discovery

Open Issues over Time

Let’s add the status to the data in the previous chart. You will chart the number of open issues that exist at a particular point in time versus time. Again, you could do this by type of issue as well. Figure 10.8 contains two examples. The solid line for Project A represents a project in which the issues are under control. The dashed line represents a problem project. Note that the number of issues that are open tends to rise and then drop off. It may temporarily pick up and then drop again.

Figure 10.8: Open Issues over Time

This chart is useful in tracking how the project is doing in resolving issues. It also serves as an early indicator of a project in trouble. If the number of open issues is not declining toward the end of the project, it is possible that the project will fail.

Aging Analysis of Open Issues

Every issue has a discovery date and status. You can determine the percentage of issues that are open by the date of discovery. That is, for issues that were discovered in the past week, the percentage is almost 100%. Meanwhile, the issues that were discovered long ago should be solved—leaving a very small percentage. This is the solid chart in Fig. 10.9. A more difficult situation appears in the dashed graph for Project B. Here there is a bump or jump far back in the project. This means that there are a number of issues that have remained unresolved for some time. This will either cause major problems to the project or even cause the project to fail.

Figure 10.9: Aging Chart of Issues over Time

Average Elapsed Time to Resolve Issues

This chart plots the average elapsed time it takes to resolve an issue for all issues discovered up to a specific point in time. Figure 10.10 is an example of this chart. The solid line corresponds to a well-behaved project in which the elapsed time increases as the team, leader, and managers get familiar with solving issues. Then the elapsed time declines until at the end you almost will solve an issue the minute it appears.

Figure 10.10: Average Elapsed Time to Resolve an Issue

Analysis of Open Issues by Impact and Time Urgency

Two factors have not been considered—impact and time urgency. These are subjective, depending on the person who is viewing the issues. Nevertheless, their analysis is useful. Figure 10.11 presents a general chart in which time pressure is the horizontal axis and impact on the project is on the vertical axis. Issue 5 is time urgent, but of low impact. Issue 12 is both time urgent and high impact. It is important. So you should pay attention to the issues in the upper right quadrant.

Figure 10.11: General Chart of Impact and Time Urgency

However, you cannot stop there. While you cannot address all open issues, you can consider those that have less impact, but that are time urgent. This is the lower right quadrant. So if you put this together, you are going to give attention to the issues in the ellipse.

Now let’s consider an example. Figure 10.12 shows the open issues on the chart at a specific time. Figure 10.13 reveals the issues at a later time. Note that focus at the first time was on the issues in the upper right and lower right quadrants. The other issues were left alone. In Fig. 10.13 these issues are removed, but new issues emerged and the position of the other unresolved issues changed.

Figure 10.12: Chart of Impact and Time Urgency at Time 1

Figure 10.13: Chart of Impact and Time Urgency at Time 2

Some specific notes are:

What is going on? Over time the time urgency and impact of specific issues may change. This method gives you a useful way to chart these. It is understandable to management and makes an interesting slide show out of what would normally be a boring and arcane subject.

Overall, how do you use these charts? You should consider these as additional templates for issues analysis. These should be produced for each critical and major international project.

Characteristics Of Lessons Learned

Lessons learned were defined in the first chapter. Let’s delve into this subject more now. A lesson learned is a guideline for doing something. It can be related to the international project. It can be related to management. It can be related to the using the project results in a business process. Lessons learned don’t tell you what to do. That is a procedure. Instead, lessons learned tell you how to do the work better. Lessons learned are not a new phenomenon. They go back in time before languages were invented when people used symbols and word of mouth to pass information on. Lessons learned were a critical success factor for the ancient Egyptians, Romans, Chinese, and others. It has been shown by many historians that when a society or civilizations fail to continue to improve through lessons learned, then the society often fails. This was one of the causes for the fall of the Roman Empire. Moving to modern times, lessons learned have shown to be very useful in the military, manufacturing, marketing, and a wide variety of other areas.

Lessons learned cannot just be written down when they are discovered. They have to be discussed and analyzed. It could be that the lesson learned only applies to a unique situation. It may also be capable of being generalized to more situations. Once a lesson learned is defined, it must be organized so that it can be used again. That is why you have the lessons learned database. It serves as a repository of knowledge. However, knowledge doesn’t do you much good if you cannot get at it and use it. That is why the lessons learned are cross-referenced to the project templates. You can go back and forth between templates and lessons learned to find those that apply to the upcoming work.

It doesn’t stop there. International projects are dynamic. When you attempt to apply a lesson learned, there are several possible outcomes:

It is as important to capture this additional experience as it is the original lesson learned. A related guideline here is that you should purge lessons learned that have not been used in a long time. The key idea here is to use the additional experience to update and expand on the lesson learned.

As with issues, there are various types of lessons learned. Here are some examples. Note that you would take the technical category and expand this for the type of international projects that you do.

A General Process For Lessons Learned

Figure 10.14 presents the steps in the process of using lessons learned. As with issues, a number of comments are appropriate.

Figure 10.14: General Process for Lessons Learned

Gather Lessons Learned

How do you get started gathering lessons learned? You don’t just ask people for them. You have to reference some tasks and ask how they would go about the work. As they talk about it, consider asking the following questions:

Write down the lesson learned as a sequence of steps. This helps you organize the information. Then you can get feedback from the individuals who provided this.

Use Lessons Learned For Advantage

Lessons learned are useful in almost all lines of work. For many international projects, you can institute lessons learned for the work of the current process. This is what is called a “Quick Hit” or “Quick Win.” It is very useful politically because you show that you care about what people are doing. You are showing respect for them and how they do their work. You are also helping them in their future work. It is useful to structure these around established procedures. Consider the following table:

Step Who What Lessons learned

The first three columns constitute the procedures. You will recognize them as playscript. The last column contains the lessons learned on how best to do the work.

You should apply this to your project team. You will get the same benefits. Lessons learned are timeless.

Project Meetings For Lessons Learned

In the previous chapter on communications, it was indicated that a good strategy is to employ about 1/3 of the project meetings to lessons learned. This is very ambiguous. What are you going to do in these meetings? Here is a useful list of things to do:

Related

Категории