Approach


Set Up The Project File

This seems like a dumb place to start. However, the project file is the critical repository of the project. Lessons learned, issues, experience, etc., are all in the project file. You should establish a standard set of tabs or headings for all project files. This standardization will facilitate communications, help less experienced project leaders, and provide guidance for future projects. One of us has a room filled with project files going back over 35 years. We still go back and pull information out of long dead projects.

You can first divide the project file into management and technical. In the management section you have:

  • Budget and actual data;

  • Schedules and plans;

  • Memoranda and notes on the project;

  • Staffing on the project;

  • Issues.

In the technical part, you have the following:

  • Technical end products from the project;

  • Milestone reviews;

  • Lessons learned from the project.

If you establish the project file early, then it provides both structure and flexibility for whatever may happen.

Employ Project Templates

Many people begin project planning with a blank piece of paper. This is not a good idea. The traditional approach was to use a work breakdown structure or WBS. A work breakdown structure is a detailed list of all applicable tasks. It was thought years ago that this was useful because people could just pick and choose among the tasks. However, over time a number of problems have surfaced with this approach. First, there is the problem of what tasks mean. In an international project with different cultures and languages, this can be a major problem—leading to misunderstanding and confusion. Second, the WBS is too rigid. What if you have tasks that are not in the WBS? Do you force fit them into some general category? A third problem is that no one on the team, including the project leaders, had involvement in the WBS—they did not buy into this.

Instead of a WBS, develop high-level tasks for each type of international project that you do. In Part III there are examples of international projects and these high-level tasks are given. How many tasks are to be defined? Maybe as few as 20–30 up to several hundred. The high-level tasks serve as the umbrella for the project. Detailed tasks will fit under these high-level, summary tasks. The high-level tasks are the start of the project template. A project template consists of the following:

  • High-level tasks;

  • General resources assigned to the tasks;

  • Tail-to-head dependencies among tasks;

  • All durations and dates, left unfilled.

A general resource is the name of the role that would typically undertake the task. An example might be construction foreman or systems engineer. Tail-to-head dependencies are the simplest and will cause the least problems.

There are two additional “rules of thumb” for using templates. One is that all projects must use the same customization form of the project management software. Almost all useful project management software can be customized. If people use different forms of customization, then you cannot put the schedules together to do analysis.

The second rule is that all project plans and templates must use the same resource pool. A resource pool is a project plan in which there are no tasks— only resources. There are general resources for the template and specific resources for the individual projects. If all of the project plans use the same resource pool, then you can combine the projects for analysis.

When you fill out the project plan from the template, you first create detailed tasks under the template tasks. Then you replace the general resources with the specific people or organizations doing the work. You can also add dependencies and, finally, the dates and durations of the tasks to produce the plan.

There are a number of advantages of using project templates, including:

  • It is easier for the team to understand and support these.

  • The template can be improved as the project goes on and after the project is over. As such, the body of templates constitute cumulative improvement through experience.

  • Management can understand templates easier than the detailed tasks.

  • Changes in the project can be made in the detail, leaving the high-level tasks unchanged except for the dates and durations.

How do you develop templates?

  • Take several schedules from current and past projects;

  • Extract the high-level tasks and milestones;

  • Have various project leaders and team members review and refine the tasks and milestones.

This produces the first version of the template. Note that in the third step there is discussion and collaboration to gain a common understanding of the tasks.

There is an overall roadmap here. It is shown in Fig. 5.1. This diagram reveals how templates, project plans, lessons learned, and issues tie together. Each of the arrows is labeled so that the following explanation helps you to see the overall picture.

click to expand
Figure 5.1: Roadmap for Templates and Projects

  • Each international project plan is generated from a template (arrow 1).

  • As you gain experience from the project, the template can be updated for future use (arrow 2).

  • Any task that has risk has one or more issues behind it (arrow 3).

  • Each issue that is identified can be associated with one or more tasks (arrow 4).

  • Template tasks refer to the appropriate lessons learned that help you carry out the task (arrow 5).

  • Each lesson learned would be difficult to find or use if it did not refer to some tasks in the templates (arrow 6).

  • You employ lessons learned to help in resolving issues (arrow 7).

  • From dealing with issues you gather more experience so that you can improve on the lessons learned (arrow 8).

  • Certain issues commonly arise in international projects so that they can be associated with the tasks in the template (arrow 9).

  • Lessons learned can be useful in resolving issues and doing work in the project; the lessons learned can also be updated (arrow 10).

In these comments there is a basic definition of risk in terms of the project plan. A task has risk or is risky if there is one or more associated significant issues with that task.

Note that without the cross reference of lessons learned with the tasks, it would be difficult, if not impossible, to uncover which lessons learned to use. The same applies to issues. Also, as time goes on and you gain more experience in international projects, you will likely experience the benefits given in Fig. 5.2.

click to expand
Figure 5.2: Benefits of a Structured Approach for International Projects

Many international projects involve consultants and contractors. It is important that the issues, templates, and project plans be shared with outside firms. Otherwise, a vendor may continue to use their own plan. Then you will spend literally hours with the vendor manager in reconciling your and their versions of the plans and interpretations of issues.

Split Up The Overall International Project

You could just create a giant template for international projects. However, this has many disadvantages. First, it will lead to many more templates. Second, this approach does not reflect the reality that many international projects contain common subprojects. For example, consider a project to merge with a recently acquired firm. There are three manufacturing facilities and two administrative offices. Now you could create five different plans. On the other hand, you could create two overall templates for the merging—manufacturing and administration. Now within each of the five locations, there are common functions such as general accounting, payroll, etc. It is rather stupid to include these individually. It is more useful to create smaller templates for general accounting, payroll, etc. Then the overall template is really composed of smaller templates. This is a basic guideline which we restate.

In order to get economies of scale of effort in project management, you should create smaller templates for specific activities in the project. The overall template and schedule is then a combination of the parts.

This is a modular approach and allows you to improve the individual templates as you go. It also provides more flexibility.

How do you break up an international project into parts? As was stated before, this is one place that many projects go wrong. Here are four actions to take:

  • Action 1: Identify and review the major areas of risk.

  • Action 2: Create a separate subproject for each area that has risk. This puts the focus on risk.

  • Action 3: Review the business and political purposes of the project.

  • Action 4: For the parts of the project that remain after Action 2, organize these so as to achieve the business and political purposes.

Remember the following. Many projects can be technical successes, but turn out to be business and/or political failures. They then fail overall. Hence, the emphasis on the business and political goals. Next, by organizing the project around the dual themes of minimizing risk and political/business objectives you work to achieve both. You orient the team and management toward these goals as well.

The areas of risk depend upon the type of international project that you are undertaking. However, the business and political goals are often more common and include:

  • There is a need to build relationships among staff and management at different locations so that there will be increased communications and collaboration after the project is concluded. Organizing the project across locations provides support to achieve this goal.

  • Instill a more standardized way of thinking across the organization. Look at recent failures in international finance and banking. Many of the problems were due to compartmentalization. People had become isolated in their jobs— making fraud and deception easier to carry out. Standardization and awareness are promoted by a cross-location project organization.

Let’s take an example. Whitmore Bank wanted to deploy a new banking family of products in a region of five countries. In their first attempt they based the project in the most technologically advanced country. The project leaders came from here along with the key team members. They were insensitive to the needs of the other locations. They ran into a brick wall. The project failed.

The project had the following major parts:

  • Marketing for the products;

  • Sales for the products;

  • IT work for the products;

  • Organization setup to support the products—four groups were needed;

  • Management controls and measurement of the performance of the products.

Of these the IT and management control parts of the project were the most risky. There were many detailed issues in the systems area as well as in government regulation and controls. Using the approach in this chapter, these were extracted and set up as separate subprojects.

This left three areas to be considered. After extensive discussions it was realized that there would be an ongoing need for collaboration and information sharing across the region after the project was completed. Therefore, each of these areas was organized across the region with two project leaders from different countries in charge of each part of the project.

This second approach was very successful. It became easier for Whitmore to move people around the region. There was greater uniformity and predictability of service for customers. Profitability goals were reached ahead of schedule.

Why don’t all or more international projects follow the above approach? Well, there are cultural and political barriers. First, project leaders may not want to force people in different locations to work together due to distance, culture, and other factors. They feel that this increases risk. Actually, it reduces risk.

What about time zones and culture? You are going to assign joint tasks between people in different locations within each subproject. Then you want the individuals to work out how they will deal with time and culture. The project leaders can help, but you want the people to gain experience and lessons learned from doing it for themselves.

Another reason is that many times the project is organized along the same lines as the organization. This often reflects faulty logic since you tend to have greater success using a matrix approach by going across locations.

Create The Issues And Lessons Learned Databases

Keys to the diagram in Fig. 5.1 are issues and lessons learned. You do not have time to establish databases for issues and lessons learned for each international project. Moreover, the same issues and lessons learned will recur many times. Therefore, you want to have a common issues database and a common lessons learned database.

What is the structure of these databases? Experience from past international projects has revealed the benefit of having three linked databases for each of the issues and lessons learned. For issues the databases are:

  • General issues database. This is a common database for all projects.

  • Issues applied to a specific project. This consists of the information for the issue as it applies to a specific project.

  • Actions on the specific issue. This database records the actions and results of steps taken for a specific issue.

The data elements for these databases are given in Fig. 5.3.

click to expand
Figure 5.3: Data Elements for the Issues Databases

Turning now to the lessons learned, the three databases are as follows:

  • General lessons learned database. This database contains the general guidelines for applying and using the lessons learned.

  • Cross reference of lessons learned to projects and templates.

  • Update database to record experience in applying specific lessons learned.

Data elements for these are given in Fig. 5.4. These databases can be established using a standard database management system such as Microsoft Access or groupware such as Lotus Notes. You might want to start out by using a spreadsheet first and then migrate to a database later.

click to expand
Figure 5.4: Data Elements for Lessons Learned Databases

All of the databases are resident on the computer network in the organization so anyone can access the information on a read-only basis. Write access is controlled and restricted to project leaders or a central coordinator (discussed later in this chapter).

Define Tasks And Milestones

With the above comments as background, let’s consider how to develop the detailed project plan. The sequence of actions is as follows:

  • Action 1: Review the template and breakdown of the project into subprojects with the team; assign areas of the template to pairs of team members.

  • Action 2: Create a general list of issues using the ones from Part IV. Use this as a checklist for the team. Have them add more issues as appropriate. This gives you the initial list of issues for the project.

  • Action 3: Each pair of team members works to define detailed tasks for the next 3–4 months.

  • Action 4: Review the detailed tasks with the team members. In doing so, you will identify additional issues that can be added or referenced using the issues database. This action will ensure that there is a common understanding of what is to be done.

  • Action 5: Arrange for presentations of the tasks to other team members. This will widen the understanding of what is to be done and gain additional input.

  • Action 6: Each pair of team members will now assign specific resources and dependencies. These are reviewed by the project leaders.

  • Action 7: Each pair of team members will develop the estimated durations and dates for the work. This is now reviewed by the project leaders.

As you can see, this approach is collaborative and leads to a better understanding of what is to be done. Later, the team members will update their own tasks. This gives the individual team member a role in project management and also ensures that the project leaders are not driven down to the level of clerks who just update the plans.

What is the appropriate level of detail for an international project? Experience indicates that you want detailed tasks at the bottom to be 1–2 weeks in duration. There is a trade-off here. If you go for more detail, the project plan takes more effort to update and maintain. It becomes unwieldy. We know of one international project where the project leader was not experienced. He created detailed tasks down to 1 or 2 days. It drove the project team nuts! It was so unworkable that within one month the plan had to be scrapped and the effort started over. If the team cannot reasonably update the tasks in a short amount of time, then the team members will perceive that using project management is getting in the way of the work. Credibility of the method and the project leaders drops. There is another benefit to this range. If team members are able to leave the project team, there is less potential damage since the tasks are of reasonable duration.

What about milestones? International projects are often far flung and spread out. It will be difficult to get status later if there are fewer milestones. So we recommend that you have more, rather than fewer, milestones.

It can happen that your project is interdependent with other projects that are going on in one or more locations. How do you address this situation? You could just put in the major milestones of the dependent project and then track these. Often, this is not effective. If the other projects are set up in templates, then you can combine the projects to do analysis of slippage. This is feasible if there is open information on the projects and they are on the network.

Another action is to establish a new subproject that addresses the interface between your project and another project. This “interface project” provides a focus for joint management between the two sets of project leaders. It also draws attention to the risk and importance of the interface. This is preferable to burying the interface in some detailed tasks that are not visible. It also makes the two sets of project leaders more jointly responsible; they are forced to work together on issues that affect both projects.

Deal With Estimation, Contingencies, And Uncertainty

Here is a series of guidelines for developing the schedule and plan:

  • If you cannot estimate a task, what do you do? Break up the task into smaller parts. Isolate the part you cannot estimate. Ask why you cannot estimate it. This will surface one or more issues. This is positive because it gets more issues out on the table earlier. Having identified the issue behind the task, you can now deal with it and then develop an estimate.

  • Only develop detailed tasks for 3–4 months in the future. Beyond this, stick to the template level. This will save you more time. For template level tasks later you can temporarily break up tasks to do estimation.

  • As the plan is updated, the team members will define additional detailed tasks so that there are detailed tasks for 3–4 months in the future at all times (see Fig. 5.5).

    click to expand
    Figure 5.5: Rolling Level of Detail in the Project Plan

How do you deal with contingencies? A commonly used approach is to pad the time for the work. However, if everyone does this, the project will not finish for years. What is the underlying purpose of contingency planning? To make management and the team aware of potential problems and impacts. We have found that a better approach is to define contingency tasks. These are added at the bottom of the project plan. They are not linked to any tasks in the plan. To show the impact of the contingency, you merely link the appropriate contingency tasks into the plan. Panic ensues as managers see the slippage—very good!

What is a major contingency for international projects? The team members must be drawn off the project for other work. Here is another guideline. Have each team member create their own plan that indicates what other work they will doing. You should review this with them and discuss the possible demands. This is much more precise that just yakking about their other work in general terms. Later in the project, they can update this and indicate to you what is going on. This will prevent many unpleasant surprises later. Moreover, if a team member has a number of real conflicts, you can consider if this person should be replaced on the team. This is a much better idea at the start of the project than in the middle in a panic situation.

Now suppose you have developed the plan and have a list of issues. How do you test if these are both complete? First, go through the list of tasks and ask if any of these have risk. If they do, then do you have the associated issues identified? If not, then you can add more issues and link these to the tasks. Second, go down the list of issues. Ask if these apply to the international project. If one does, then go down the list of tasks to see if the appropriate tasks are present. If not, you can add tasks. The end result is that you have verified both the issues and the tasks. Another step to take is to review the milestones and label the ones that involve major issues. These issues are related to the tasks that produce or lead to the end product.

Perform Cost Estimation

Cost estimation is often difficult in standard projects. It is more complex and difficult in international projects. One problem is that there is often no way to link the actual costs in the project to the project plan. Another problem is that budget estimation is performed individually based on the single project leader.

The overall project management approach in this chapter provides for an improvement in this situation.

  • There are two project leaders involved so that there is a wider perspective of what is to be estimated.

  • There are project templates for each type of project. As time goes on and experience grows, the template can grow in size. Lower-level tasks can be added.

  • Estimated durations can be given for some tasks that are performed in the plans that follow a specific template.

  • Issues are associated with tasks in the templates.

  • Budgeted and actual costs for projects can be inserted in fields in the project plan, thereby facilitating analysis.

  • By type of project, the costs (budgeted and actual) can be associated with tasks in the project templates.

Cost estimation is improved since the costs can be linked to the template.

The method is then to associate a new project with a template. Then the project leaders review the template to refine the tasks. They can review the issues associated with the tasks in the template and make adjustments. The project leaders can now perform improved estimation using this additional information.

There is an additional benefit of this approach. When management poses questions, asks for budget cuts or budget increases to reduce schedules, the project leaders can use a copy of the template file to perform “what if” analysis. This is more credible to management since it is based on more concrete data than just raw experience of one person.

Perform Resource Usage Analysis

You might be tempted to use the project management software to do automated resource leveling. We recommend that you never, ever use automated resource leveling. One reason is that you want to indicate the resource conflicts and over commitments by the team and others to them and to management. You will then gain their participation in determining what actions can be taken to manually resolve the resource conflict. If they participate in this analysis, they tend to understand and commit to the changes.

Set The Baseline Schedule

The baseline schedule is set in most project management software by copying the start and end dates to baseline or planned start and end dates. For international projects these are done separately for each subproject. Now suppose that you have developed the plan using the method (or any method) and you find that the final date for project completion is not acceptable. This must happen almost 100% of the time, don’t you think?

What do you do then? The often tried approach is to look at the critical path. The critical path is the path in the project from beginning to end that is the longest path in the project such that if any task in this path is delayed, the project is delayed. It sounds nice and simple, doesn’t it? Why doesn’t this approach work? Because of issues and risk. Who is to say that the tasks that have risk and issues are on the critical path?

Most of the time the tasks with issues and risk are not on the critical path.

Instead, they linger in the middle, vague zone of tasks. Management pays attention to the tasks in the critical path and ignores the tasks with risk unless they are on the critical path. They try to shorten tasks that have no risk. How can you do this? You cannot. If a task takes 10 days and has no issues, then it will take 10 days unless you make significant changes to the task!

What else can you do? Here is a series of actions you can take to shorten the schedule. It is the combination of the steps that add up to results.

  • Divide up tasks in the schedule (including the critical path tasks) to make the work performed more in parallel.

  • Consider paths in the project that contain tasks with significant issues. Here is where management and team attention can be employed with advantage. Why? You can examine the tasks that have issues and try to address the issues. By resolving or simplifying the issues, you can develop better and likely shorter durations for the tasks.

  • Review carefully dependencies among subprojects and major summary tasks. Can more parallel effort be done here?

How do you use these actions? Bottom up. You begin with the subprojects that have the most risk and issues. Then you progressively analyze and review other subprojects. Since you can link the subprojects together in the project management software, you can always get an overall view of the effects of the changes that you have made.

This approach was employed in a large-scale deployment of satellite television in a major global region. Originally, the plan called for the rollout to be done in 17 months. This was just too long due to competitive pressures. The traditional approach was taken to shorten the critical path by applying more resources. The result was a plan shorter by 4 months, but much higher in cost.

Then the approach in this section was taken. It was found that people had made many assumptions related to dependencies. Also, there were a number of issues that could be resolved in project planning. After 2 weeks of effort by the project leaders, the team, and management the time was reduced by 6 months! Not bad, eh? A side benefit was that people had a much better idea of what was involved in the project— they participated in the analysis and so supported and understood the work involved in more detail.

Evaluate Your Plan

You are sitting back having gone through the arduous work of developing the schedule. Are you finished? Not yet. There are some additional steps that you can take to review the overall schedule.

  • Look at the areas of the project that have tasks with major issues. If these issues were not to be resolved quickly, what would happen? Do you have an adequate list of contingency tasks?

  • Review the detailed tasks. Are there tasks that go for, say, 1 month and that have issues associated with them. These are likely to be trouble later. What do you do? Have the team members who are assigned to these tasks break up the tasks into 1–2 week tasks.

  • Consider the milestones of the project. International projects benefit from many milestones. Why? Because that is what you can review. If you are reviewing work in progress, then it is just verbal review—not very effective. There should be milestones showing up every 2 weeks in each subproject. This not only aids tracking of the work by the project leaders, it also raises the morale of the team since they will feel that they are making more progress.

In addition to these steps, you should answer and address the list of questions that are posed in Fig. 5.6.

  • What happens if the project is reduced in scope?

  • What will occur if the scope of the project is widened?

  • What if management wants to speed up the project?

  • What if one location is "too busy" to participate much?

  • What if a critical person leaves the project?

  • What if issues are not handled quickly and in a timely manner?

  • What if a dependent project is changed?


Figure 5.6: Questions to Ask in Reviewing the Project Plan

Establish The Role Of A Central International Project Coordinator

This chapter has identified a central theme in the management of international projects—standardization at the higher levels and individual detailed schedules and issues at the lower level. This approach provides both standardization and flexibility. Flexibility is achieved where it is most needed—at the detailed level where the work is performed.

Classically, in project management, there was support for the idea of a project office. A project office consists of a group of project coordinators who develop plans and do other work across projects to ensure standardization. However, the project office suffers from a number of drawbacks. First, it is pure overhead. Second, many of the people in the project office do not have in-country experience—making coordination more difficult. Third, the effect of the project office was often to slow the projects down.

In the approach here, you want to have participation and not overhead. So you should consider the role of the International Project Coordinator. This is a person who is a project leader and has experience. The position rotates every 6 months or so among different project leaders so that everyone gets a turn.

The roles and responsibilities of the International Project Coordinator are listed in Fig. 5.7. There are a number of benefits to the organization. First, standardization is supported. As you can see, the databases of templates, issues, and lessons learned are overseen and maintained. The International Project Coordinator can provide a separate input to management on schedules, plans, and issues.

click to expand
Figure 5.7: Roles and Responsibilities for the International Project Coordinator

There are also benefits to the people who serve as coordinators. They get an opportunity to get an overall view of all of the international projects. They can use the perspective to perform better in their next projects. The coordinator role gives them a chance to unwind after doing projects that have stress.




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