|Back to Text-only Web Page|
Working on the Project
When you hear something, you will forget it.
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.
BackgroundBefore you agree on the project, you will have received an overview of the company or group you are working with, and the expectations of the project. Don't expect anything too detailed. Frequently the brief can be as sparse as “needs marketing help” or “must have a website developed.” Even if there is a fair amount of text in the requirements document, we often find that the actual requirements boil down to a sentence or two.
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.
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.
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.
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.
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.
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.
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!.
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.
Copyright © 2001 International Opportunities.
All Rights Reserved.|
Site Version 1.75 - Last updated December 20, 2006
This URL: http://www.InterOpp.org/htm/prep_working_tp.htm
|Back to Text-only Web Page|