Approach


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.

  • Management. The issue deals with management areas such as resources, budget, and schedule.

  • Work. The issue involves specific work in the project. Quality and completeness are issues.

  • Project team. There can be personality conflicts in the team. People may be getting pulled off of the team to work on other things.

  • Business situation. The underlying business situation in a country may have deteriorated, affecting the project.

  • Other projects. Your project may be highly interdependent on other projects that have issues.

  • Government regulations. Your project may be hung up on getting government approvals or reviews.

  • Culture. There could be substantial cultural problems and conflicts.

  • General external factors. These could include labor unions and the weather.

  • Competition. The competitors may be ahead of you on a similar project, creating more pressure to get the work completed.

  • Headquarters. There can be issues arising from headquarters such as changes in priorities.

  • In-country operations. There could be new work or problems that interfere with the project.

  • Customers or suppliers. There can be dynamic factors here that affect the project.

  • Business processes. There may be issues with shadow systems, procedures, and policies.

  • Vendors and consultants. Availability of staff and quality of work are two issues here.

  • Technology. There may a number of systems and technology problems and opportunities.

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.

  • Add resources to the work;

  • Take resources away from the work;

  • Stop using the method or tool;

  • Enforce a different use of a method or tool;

  • Change a policy to alter the scope of the project to make the issue disappear;

  • Change the issue into another form that may be less political and easier to address;

  • Break up an issue into parts and deal with each part;

  • Combine issues so that one issue is swept up in the actions for other issues;

  • Assign the issue to a different person;

  • Throw money at an issue;

  • Throw more technology at an issue;

  • Involve a vendor in the issue;

  • Take a vendor out of the issue;

  • Reorganize the work;

  • Move the issue away from the project to the line organization or another project;

  • Restructure the project plan;

  • Apply different types of resources in the project.

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

  • Make sure that the group of issues is related in some way that is acceptable to management.

  • Take care to have the issues stated clearly and succinctly.

  • Ensure that management is aware of the issues. Surprises are bad here.

  • Examine as many alternatives as possible before making any decision.

  • Weigh the effect of delaying a decision with that of making a decision.

  • Make certain that the decisions that you are about to make are backed up completely by the actions.

  • Work to understand the business, technical, and political implications, impacts, and effects of the actions and decision at both the local and headquarters levels.

  • Define how you are going to measure the actions after they have been carried out.

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:

click to expand
Figure 10.2: Steps in Addressing Issues

  • The initial investigation of the issue. The project leader should try to determine where the issue originated from. What caused it to surface now? Has it always been there? Why didn’t people become aware of this issue earlier? Can you quickly group it with other issues? Can it be dealt with now?

  • Assignment of the issue. It is good to spread the issues around the team politically. The team members become more sensitive to what is going on beyond their immediate work. Of course, this requires care so that they are not diverted off of their work in the project.

  • Tracking the issue. Have the team members log what they are doing in the issues database rather than e-mail. E-mail lacks structure.

  • Surfacing the issues to management. You want to alert management of the symptoms and problems. But you initially do not want to press for action. They will often just push it back to you. A gradual buildup is better.

  • Presenting the issue, and recommended actions and decision to management. Here you want to show the impact of continuing to do nothing about the issue. It is the fear of the impact of the issue getting worse that drives people often to make decisions.

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.

click to expand
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.

click to expand
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:

  • Identifier of the issue;

  • Type of the issue;

  • Status of the issue;

  • Date that the issue was discovered;

  • Date that the issue was resolved.

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:

  • Team-related issues;

  • Work-related issues;

  • Vendor-related issues;

  • Process-related issues;

  • Organization-related issues;

  • Management-related issues;

  • Policy-related issues;

  • Technology-related issues.

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.

click to expand
Figure 10.5: First Example of Number of Open Issues by Type

click to expand
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.

click to expand
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.

click to expand
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.

click to expand
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.

click to expand
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.

click to expand
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.

click to expand
Figure 10.12: Chart of Impact and Time Urgency at Time 1

click to expand
Figure 10.13: Chart of Impact and Time Urgency at Time 2

Some specific notes are:

  • Issues 17, 24, and 47 were resolved after the first time and do not show up in the second chart.

  • Issue 36 is still there and didn’t change position over the time.

  • Issue 65 appeared for the first time on the second chart.

  • Issue 8 became critical over time.

  • Issue 19 changed but it did not become critical as yet.

  • Issue 26 appeared as low impact, but high time urgency.

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:

  • The lesson learned did not apply or did not work in your project.

  • Using the lesson learned, you produced work of higher quality or did the work in less time with fewer resources.

  • You used the lesson learned and improved upon it.

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.

  • Project management;

  • Project team;

  • Project work;

  • Methods;

  • Tools;

  • Technology;

  • Technical;

  • Marketing;

  • Customer service.

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.

click to expand
Figure 10.14: General Process for Lessons Learned

  • The maintenance of the lessons learned database and its updating are performed by the coordinator function defined earlier in the book for the multiple international projects.

  • The project leaders cannot afford to treat lessons learned lightly. They need to take them seriously and enforce them being considered. Their attitude should be “Why reinvent the wheel again and again?”

  • Some might think that this will take time away from the project. Any time spent reviewing and updating lessons learned is more than offset by the increased productivity.

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:

  • How did you come across this?

  • What did you do before you started using this technique?

  • If you did not use this method, what could you do?

  • Has the method ever failed?

  • Have you had to change the method?

  • Have you tried to use the method for other things?

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:

  • Have team members present their milestones and results to the group. This provides a format that is friendly and routine. It is not done on an exception basis.

  • New team members can present lessons learned from their past projects and work. This familiarizes the team members with what that person has done. It also helps to socialize the person into the team.

  • Team members who are critical and who may be leaving the project can use the lessons learned to aid in transferring of knowledge of what they have been doing. Using the lessons learned meetings provides a useful, non-threatening approach for knowledge transfer.

  • Vendor staff and consultants can present what they are doing so that knowledge transfer is again facilitated.

  • Lessons learned meetings are a good place to collect experience on the use of methods and tools and tips for effective use of these.




International Project Management
International Project Management: Leadership in Complex Environments
ISBN: 0470578823
EAN: 2147483647
Year: 2003
Pages: 154

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net