By Sheldon C. Bachus
As a United Nations field advisor, I was under contract with the United Nations Development Programme and the Ghanaian government to provide computer technology support to the Volta River Authority (VRA).
As I departed for Africa, I realized that what I was setting out to change would end up changing me. Although this assignment took place two decades ago, the experience still shapes many aspects of my professional life—from how I manage computer resources to how I view IT in the developed and developing worlds.
Technology management and culture
My responsibilities included providing general software application design and implementation support. Shortly after my arrival at VRA headquarters in Accra, it was apparent that I was also expected to provide technical support for a variety of other areas. The major surprise was—I would also have the operational responsibility for VRA’s data processing operation. Luckily, I had previously managed mainframe shops.
A Ghanaian worker assigned to the project by VRA managed day-to-day operations while I focused on long-range planning, review, and application design and development.
One of the challenges I faced required that I quickly learn diplomatic skills. Frequently, data entry operators would ask me to resolve a minor issue—a batch was out of balance or a deadline was missed. Usually, the issue involved a conflict between operators or operations staff.
I was a bit concerned that the staff members were avoiding the chain of command already built into VRA’s data processing operation. Why where Ghanaian staff coming to me to solve their problems?
I later realized that because I was a foreigner, the Ghanaian staff members viewed me as a neutral party with no stake in their problems.
In almost every instance, the individuals involved with a conflict were from different Ghanaian culture groups—one might be a Ga and the other an Ewe, for example. Once I was aware of this, I quickly involved my counterpart in the mediation process, and the staff eventually realized that he, too, would solve their differences fairly.
Modifying management goals
Early during my tenure with the VRA, I had been asked by the Authority’s engineering staff to develop a hydrological database and reservoir modeling system to help them manage the hydroelectric resources provided by the Akosombo Dam and the resulting Volta Lake.
Volta Lake is one of the world’s largest hydroelectric reservoirs, covering approximately 8,500 square kilometers with a storage capacity of nearly 150 million cubic meters. The VRA is charged with the lake’s management, as well as the generation and transmission of electrical power from the dam’s six huge turbines.
We decided to cast the project into two phases:
- Phase 1: Development of HYDRO, a hydrological database containing observed rainfall and river flow data. This information was historically recorded at various stations in the Volta Lake catchment.
- Phase 2: Creation of the Akosombo Flood Routing Model (AFROMOD), a simulation system designed to predict the expected “flood” and requisite discharge at the Akosombo dam site.
The HYDRO database was to be implemented as flat ASCII table files, with each flat file either directly accessed on a sequential record-by-record basis, or by indirect index files defining logical subsets of the master table file.
These subsets were typically organized as groups of river flow or rainfall data sorted in time series order. They were to be plugged into the AFROMOD simulation system.
The primary purpose of AFROMOD was to establish the specific river flow and rainfall stations that could be used to predict and control the discharge at Akosombo Dam. As such, AFROMOD was to be developed using both conventional bivariate linear regression, as well as multivariate, correlation methodologies.
The project takes shape
The Ghanaians had kept excellent hydrological records, so we were able to populate the HYDRO database with an accurate set of catchment data.
The database schema proved both flexible and responsive to our test requirements. Daily river flow rates could be extracted easily for the Volta and other catchment tributaries.
Likewise, daily precipitation data was readily available for all major observation stations including critical interior stations.
Our success continued with the start of Phase 2, the design and preliminary coding of the AFROMOD simulation engine. Written in FORTRAN, we implemented AFROMOD so that multiple catchment datasets could be cross-correlated for the full hydrological year in less than 15 seconds of CPU time, and be run within the 64 KB partition provided by the Authority's System 3 computing platform.
Then, we tested local precipitation against river flow data as a crosscheck on the accuracy of the database. These simple bivariate analyses showed extremely high correlation rates that verified the accuracy of the historical catchment data in the newly developed HYDRO database.
Using flow rates at Akosombo prior to the construction of the dam, we began testing multiple catchment stations against the observed flow of the main stem of the Volta at Akosombo. To our chagrin, we found negative correlations occurring with respect to river flow observations taken for several interior stations.
These inverse correlations seemed to appear whenever there were periods of exceptionally high rainfall recorded along the southern periphery of the Volta’s catchment.
While pondering this problem, I observed a band of dark clouds moving in off the Gulf of Guinea, just one sign of the impending monsoon season. When I saw a lightning strike, I realized the missing piece of the puzzle. The inverse correlations were the result of the monsoon rain band stalling over the latitude of the Kwahu Plateau and not making its typical path north into the Volta’s primary catchment area.
I reran AFROMOD, controlling for high rainfall in the South. I then compared the results with U.N. historical information on the Sahelian drought. That was the reason for the aberrant data—the years of severest drought also were the years of highest inverse correlation.
Did this mean we could now predict the intensity of African drought? Probably not. But hopefully our findings would provide grounds for future research. More importantly, I realized that I should never dismiss unexpected results.
My experience in Ghana more than 20 years ago is still with me. I learned invaluable IT management and technology skills that I use everyday on the job.
Today, as an independent consultant, I conduct up to 30 IT bank audits per year. Working with other auditors contracted to BancAudit Associates, our clients are typically small to medium-sized community banks. Our goal is to assure that these institutions are in compliance with federal banking regulations.
When I walk into one of these banks, located throughout California's central valley, I recognize that each bank has a different corporate culture that can have an impact on how IT is viewed at each institution.
Sometimes, these audits result in recommending modifications to a bank's network infrastructure or core processing platform. This involves searching for technology-based solutions. I take great care to ensure that these solutions do not result in a long list of rigid procedures. That’s one way to respect the corporate culture that’s already in place. Often, I believe these solutions come about through an intuitive problem-solving approach. It’s better to find a mutually-beneficial solution than to use brute-force engineering.
In a larger sense, every IT team member potentially comes from a different culture. In the United States, those cultures are reflected by an individual’s background, including differences in culture based on where a person lives and whether they have a rural or urban background. A good IT manager should be able to mediate potential conflicts that sometimes result from diverse backgrounds.
Using this type of diplomacy is one of the most important lessons I learned in Ghana.
Share your project success story with TechRepublic. There are so many reasons why:
- Publishing your accomplishments provides more proof of performance when it’s time for your annual job review or when you want to change jobs.
- Bragging about staff members is a great way to show them that you appreciate their hard work.
- Sharing the details of a tough project you’ve tackled can help peers benefit from the lessons you’ve learned.