Working on the Project

When you hear something, you will forget it.
When you see something, you will remember it.
But not until you do something, will you understand it.

— Chinese Proverb

If you have signed up for a volunteer service project, internship, research project, or most projects involving a group, the guidelines for carrying out your project will probably be well specified.

A technical assistance project, especially one where you will be working alone, is another matter. You may be the first international advisor to work with your client.

You should have support in terms of housing, arrangements, and setting up the initial meetings with the client. However, how the project is carried out may be largely up to you. This page has suggestions on how to carry out a technical assistance project.

Background

If you can establish contact with the client or the country director prior to the project, you can possibly get a better understanding of the situation. The goal here is not to start the work. The goal is to identify resources — books, data, materials, competitive samples — that will be helpful on the project. Concentrate on things which might be very difficult to obtain once you arrive at the client.

You can also research the overall economic situation in the country, research the product category relating to the project, and start developing a list of questions to ask upon your arrival.

Again, be careful not to start work on the project before you arrive. The trap is to do work in the wrong direction, because the project specification is sketchy or inaccurate. Then, when you arrive, you will be tempted to offer your work as the solution, even though it does not address the client's problem.

The Goal

Most technical assistance projects aim at transferring business or technical skills, not doing work. International advisors are there to explain, demonstrate, and coach.

The natural impulse is to do the work yourself. You will rationalize that this is the simplest and fastest way to get the job done. This is OK on a very small scale — building a prototype in a day or two or visiting a customer with your client to demonstrate sales techniques.

However, beyond this, you are shortchanging the client and defeating the purpose of technical assistance projects.

Arrival

The real work begins once you arrive. Well, maybe. Different cultures have different customs for “getting started.” We have been met the airport by the client, who politely asked how early we could start the next morning. We have spent the entire first day on another project with nothing but introductions. Take your cue from the client as to their customs, but don't be afraid to propose getting down to work if it seems appropriate.

When work does get underway, you will find out firsthand what the project really entails — and it could be very different from what you thought!

Our first project was working for a pasta manufacturer in Zimbabwe. The project description called for little more than “needs marketing help.” Upon arrival, it was apparent that marketing was not their problem. Demand was high, and they were shipping product as soon as it came off the production line.

Their core problem was that they did not know the cost of production. They had no basis to set pricing and had no idea whether they were making or losing money on any given product. Their stop-gap solution was to limit production to one-fifth capacity, so as not to lose too much money. This left the expensive factory equipment idle most of the time.

Financial modeling was not our specialty, but we developed some spreadsheets that outlined the costs of production. The key factor was that the idle equipment was raising the cost of each bag of pasta produced. The combination of going to full production and a modest price increase put them in the green, and allowed them to hire more workers.

And yes, we did do some marketing — an analysis of their competitor's pricing was needed to have confidence that sales would hold under the new pricing and production program.

Be prepared for the business practices of your client to be very different from what they are at home. Meetings may not start on time, office space may be minimal, office supplies might not exist, and phone calls may be difficult to place. When this is combined with general culture shock on arrival, the effect can (will) really throw you off in the beginning.

On one project, paper was so expensive (by local standards) that printing from our computer involved telling a secretary exactly how many pages you were going to print. She would go to a supply cabinet and fetch exactly that many sheets and load the printer. We used some excess money from our stipend to buy them a case of copy paper as a parting present. They were thrilled.

Don't let the culture shock undermine your self-confidence. Don't get pushed into giving up (“I can't work this way!”). You are on the project because of your experience or particular skill. The rest is “noise” that you will soon get used to.

Every aspect of working on a technical assistance project calls for balance: Balancing your technical competence with modesty avoids problems of percieved arrogance. Balancing your shock at an unexpected situation with an open-minded appraisal can avoid absolute judgments that can kill any benefit you have to offer. Balancing doing with teaching will maximize the long-term benefit of your visit.

Realize that many cultures in developing countries are more sensitive to arrogance and modesty than in developed countries. Perceived arrogance will block any exchange of skills, but excess humility can be taken as lack of self-confidence. This in turn can raise doubts about your competence.

If possible, try to work with different levels within the company. You will get a better feel for how the company operates, and your recommendations will be more easily accepted. You will also learn what really goes on within the company, and head off possible concerns about your role on the project. Subordinates sometimes fear that you are there to fire them.

After the project gets underway, you may percieve that a client is procrastinating: appointments are missed, meetings get postponed, and decisions are delayed. You must be patient and understanding. It is rare that a client “just doesn't care.” It is more likely that they are busy with the many other things it takes to run a business. The challenges of running a business in a developing country are enormous, especially where the pace of getting anything done is slower. Again, patience!

Jack of All Trades

Once you are on a technical assistance project, you may find that you are asked to advise on all sorts of topics. They may be areas outside of your field of expertise. These situations have to be treated with care. You don't want to give advice on areas in which you have no expertise. However, you may be the only source of advice for your client.

Given the situation and the trust that has formed, you need to carefully explain the limits of your experience, and what you can try to do for the client given those limits. You might feel like you are “making it up” as you go, but as long as your client knows where you stand, you can still be an asset.

Another situation we've coined is the “hot tamale” syndrome. Your client introduces you to business associates, who ask for “a bit of casual advice.” Lunches are scheduled, then dinners, parties, and outings. People start bringing notepads to cocktail parties.

While this can be tiring, the value of this kind of interaction is immense. If you can listen to a person and envision their real issues and challenges, you can often suggest a direction or point them to a resource that can make a huge difference in their business. It is unlikely you'll ever hear about the outcome of this kind of work, but the outcomes are there nonetheless.

The Paperwork

We all hate paperwork. But, for once, we feel that the paperwork involved in a technical assistance project is not just busy-work.

The field organization overseeing your project will probably give you specific guidelines about what reports are needed. If not, you can use the basic outline given here.

The Work Plan

This is a written document developed within the first or second week (or sooner, if the project is very short). It describes the specifics of what is to be achieved during the project, time schedules, and the desired outcomes.

While you draft this document, it must be jointly agreed upon by you and the client. If possible, set up a quasi-formal “sign-off” meeting on the work plan, and try to include personnel from the field organization. Remember to confirm this (and all) meetings the day before, to avoid surprises.

You have spent some time with the client and the Work Plan is your best opportunity to put your experience to use. Are the client's objectives viable? Are the underlying assumptions valid? How can you be of best use to the client? What are the one or two key things that will cause your client to fail, and can you help fix them? What problems will your client face in the near future, and can you help avoid them?

An advisor we met in Zimbabwe had been called in to provide rather general assistance to a manufacturing company. He was very experienced in the particular production technology that they were using, but he found that they had no production problems, and there were only a few efficiency items he would be able to suggest.

However, he sensed that the factory had fundamental safety issues. He proposed developing a comprehensive safety program but the client balked. He then reasoned that the safety program would improve worker morale, foster a sense of paternal concern, and make the company more desirable to the best workers. The client still balked. He persisted by presenting case histories of established companies that had failed due to a single catastrophic accident.

The client finally consented to listen to his plans. The project proceeded smoothly, and in the end the client fully adopted the safety program over a three year period. The advisor was invited back each year to review how the program was proceeding and suggest improvements.

Setting a realistic time schedule in the Work Plan is very important. Consider what can realistically be achieved. Adjust this by the pace of business you have observed. Adjust this again to account for language interpretation or differences.

The Work Plan is setting a key set of goals against which you and the project's benefits will be judged. Be realistic about what can be achieved. If you are working with a company competing with others in a local industry, realize that all you need to do is improve their competitiveness in relation to their local competitors. They do not need to function up to the standards of a company in a developed country.

Progress Documents

The field organization may require interim progress reports every week or two. If not, consider keeping a daily log and jotting down what was done each day. This can come in handy when assembling the final report.

As you work, consider that most things you produce should become part of the final report. Memos, spreadsheets, drawings, and research data should all be printed or organized so that they can easily be included in the final report.

The Final Report

The final report puts on record everything done on the project. It is written with a view to the original project specification, and demonstrates how the Work Plan was fulfilled.

The final report is a stand-alone document. It should not rely on the reader having read the project specification or work plan. Sections of it may be used by the client or other workers in the organization as reference documents.

Be sensitive to the needs of the field organization that oversees the project. They probably have strict accountability standards with their own funding sources. They need to prove that the project was indeed done, and your written documents will serve as part of that proof. They may also need some metrics about the project — How much will it improve commerce? How many jobs will it create? How will the quality of life and standard of living be improved?

Once the project is nearing completion, schedule a turnover meeting with your client. Make it something special! We had the top management over to our rental villa, where we had our house staff serve tea and scones!.

Sample Reports

Here are some sample reports from actual projects.

The documents tagged with are in PDF format. If you cannot read them, you will need the Adobe Acrobat Reader installed.

• El Salvador Building Inspection Report developed on a technical assistance project by Global Village Engineers in January 2001. It reviews buildings in the town of Tecoluca, San Vicente in the aftermath of an earthquake.
• Reforestation Plan for the Lower Lempa also developed on a Global Village Engineers technical assistance project. This forest management plan is an incomplete prototype plan which is intended as a starting point from which communities may work together to develop a more specific forest management plan.
• The Farmer to Farmer site of Partners of the Americas has many standard forms available for download, as well as samples of completed forms. There is also a library of completed trip reports.