by Diego Ponce de Leon Barido, ERG PhD Candidate
with team members Javier Rosa (TIER, UC Berkeley), Stephen Suffian (Villanova University), and Odaly (Nicaragua local team)
I feared the worst: The bags had been thrown around at customs damaging our gadgets, the humidity and heat had fried our circuits, mice had eaten away at the cables, and our equipment was now being sold in Managua’s electronics black market.
Our ultimate objective for the trip in Nicaragua was to deploy a wireless sensor network in thirty micro-enterprises and households to monitor and inform the design of a micro-level demand response implementation for renewable energy integration.
One of the most stressful moments of our two and a half-month implementation was the ride back from customs to our home-stay, after recovering all our equipment. On my ride back, I shared a tiny Nissan car with two strangers with some of our equipment being tied to the car’s roof with the rest of the equipment overflowing the Nissan’s tiny trunk. The bags also weighed much less than when we initially handed them off at customs, but stopping to check the bags’ contents in the street could have meant losing even more equipment to petty theft.
We planned to be in Nicaragua for two and a half months. We allowed for failure in our mind, knowing well that we could only plan for the few things that we could control, and left extra mental space and time for the natural uncertainty of bureaucratic processes, as well as all the unforeseen mistakes that our team would surely make along the way.
Basically, we planned for what we could control, and assumed that good luck and hard work would take care of randomness. First, we would forget nothing back in Berkeley. Then, our technology would spend exactly two weeks at customs, and Nicaragua’s National Engineering University (UNI) would help us release it without paying taxes. Because we had tested our hardware and software ad nauseam in Berkeley, our deployment would be a simple "plug and play," and we would "figure out" communications for a demand response implementation "in country."
Customs was a nightmare that required 15 full days of absolute patience, cultural navigation, and polite pestering (and thousands of dollars paid in taxes). Our hardware passed most tests, but some sensors failed in the field after being exposed to being thrown around, drowning in freezing water, and sharp metal doors searing connections away. We got carried away in what we thought would be useful (but not necessary) software developments instead of focusing on a bulletproof version of our minimum viable product (MVP), and were not even close to "figuring out" a cost-effective communications protocol in Managua.
However, despite our "natural" missteps (things that can go wrong, will go wrong), we have begun developing a unique regional dataset which will allow us to correlate micro-level demand and behavior, to grid level measurements such as system frequency, generation from fossil and renewable resources, and weather data.
Our project also considers increasingly important equity implications of smart grid deployments: How are data exchanges mutually beneficial? How can urbanites be more engaged in a low carbon transitions? How can renewable energy based grids provide higher quality service and useful information to their clients?
To our knowledge, our project is the first of its kind in the region and will greatly contribute to shedding light on how existing grid infrastructure can be used to further increase the equitable penetration of uncertain and variable renewable energy.
SURVIVING IMPLEMENTATION
Throughout this process, our team learned a lot about what it takes to go from plans to implementation. Below are ten takeaways for future implementation that other researchers introducing new technology into foreign countries may find useful as well.
1. Customs
Depending on where you are traveling and what technology you’re deploying, your experience will vary drastically. If you are in a country where rules, guidelines and regulations are carefully detailed and followed your job is easy – read the rules and play by the book and most likely you won’t have a problem. However, if you are in country where everything is routinely improvised, you’ll most likely be at the mercy of a local customs agent at the beginning of your first "in country" adventure.
Make sure a handy person in your team is fluent in the local language and culture, you have "extra" money in case you need to hire a customs agency, and that your patience "hat" and best manners are at their best all the time. Two to three weeks is normal operating procedure, if you do everything right. If you make mistakes, don’t have the right permits or forms, or are being regularly scammed because you don’t understand the language well enough, this process could take months.
2. Parts
Bring an extra set of cheap "parts" that you may not be able to find in country. Doing your due diligence is very important. Make a list of the things you can find in country and a list of things you can’t find in country. Bringing extra things that you can’t find in country will cause problems at customs, so make sure you have lists of parts. Bring an extra two or three "final products" (whatever those may be). Regardless of how good you think your product is, you’ll have to keep iterating in the field – having a working final product as a test bed while you deploy is very important.
3. Money
If you are working on a tight budget, you’ll have to be very creative about how you spend your money. Besides your technology, and if you have a team, you will all have to stay in the same place (and that place must have a good working space). You’ll also need a car, money for food, extra parts, and many other things that will show up as you begin your project. You’ll also need to hire a local team, both for the deployment as well as for your project’s follow up.
Although "strong collaboration" with institutions is important, and "community ownership" and "partnerships" are essential (these buzzwords are all the rage in development circles), nothing gets people working – at the pace that you want them to work like money. Be wise in how you spend your money, and prepare a detailed budget months ahead of time.
4. Contacts
5. Local Team
Nothing – NOTHING - happens without a local team. You might think your clever engineering skills have taken you far in life, or that your Peace Corps experience has turned you into a community relations expert, but you’ll soon find out that your Berkeley education and prior experiences mean very little once your project "breaks ground."
We hired a community liaison (Odaly), an electrician (Roberto), and an electronics engineer (Jorli) to work with us throughout the implementation and to stay with us through follow up. While we handled the implementation logistics and directed everything, they were heavily involved in troubleshooting, surveying, and follow up. They have all learned a wide variety of skills along the way, such as fixing broken sensors, accessing PostGRES databases, and setting up a local WiFi network.
Once you leave, you need to make sure that there is a team of people that will be able to solve problems as they arise. Without a good local team, your project will last only about two to three weeks post-implementation.
6. Build/Deploy Team
A small team needs to be composed of people with interchangeable skills that complement each other well. (Three people sounds about right). One person can be responsible for a lot but not for everything. If your project is technical, then everyone in your team must be able to help, or everyone must be willing to learn (fast). There will be plenty of times for PANIC to sneak in.
If you’re leading, you can never panic. If you’re someone who panics, control yourself. When things get hot, you’re stressed, or you’re panicking, control yourself. Drink water. Take a break. Be respectful. Try not to complain (too much). Nothing sucks more than having to deal with a difficult situation, and with someone who is complaining about it.
7. Respect your MVP
You arrived to your site with a minimum viable product (MVP). You have something that works. Your goal should be to make that product work on site with as little change as possible. Don’t add components (hardware or software) to your MVP "in country." You need time to test new additions, and more time to make them work like you want them to. Additional things can be done once your MVP is fully functional on the field. Until that point, eschew any ideas to make the product better, faster, or easier to use. Any improvements should have happened during the testing phase and can happen when you’re done with your deployment. If you have a short deployment time, respect your MVP.
8. Time
You should leave, at minimum, three weeks of follow up after you have finished your deployment. Things will fail and break, and you need time to fix them. You also need time to train your local team on troubleshooting. Leaving a country right after deployment is symptomatic of the "parachute" approach that most "development engineers" work with (drop in, have your adventure, drop some technology, fly off to another adventure). After your deployment, do your due diligence and stay in country to finish the training with your local team, make and solve problems, troubleshoot, and prepare your project for the next few months before the next iteration.
9. Release
Deployments are high-stress situations. Make sure that you’re doing something fun the entire time. Bond. Keep things fun. Remember that no one is forcing you to do this, so make sure that you’re enjoying life while doing it. If not, what’s the point?
10. Humility, Respect
Respect the people you’re working with. Respect your local team. Respect each other. Be humble about what you can accomplish. Accept and apologize when you make mistakes. Accept others' apologies. Don’t dwell. Ignore the little things that don’t matter, but REALLY pay attention to detail. Appreciate your team, you’re part of it. You are all learning from each other.
Note: The views expressed here belong solely to the author of each entry and are not representative of the position of the Energy and Resources Group, UC Berkeley.
with team members Javier Rosa (TIER, UC Berkeley), Stephen Suffian (Villanova University), and Odaly (Nicaragua local team)
I feared the worst: The bags had been thrown around at customs damaging our gadgets, the humidity and heat had fried our circuits, mice had eaten away at the cables, and our equipment was now being sold in Managua’s electronics black market.
Our ultimate objective for the trip in Nicaragua was to deploy a wireless sensor network in thirty micro-enterprises and households to monitor and inform the design of a micro-level demand response implementation for renewable energy integration.
One of the most stressful moments of our two and a half-month implementation was the ride back from customs to our home-stay, after recovering all our equipment. On my ride back, I shared a tiny Nissan car with two strangers with some of our equipment being tied to the car’s roof with the rest of the equipment overflowing the Nissan’s tiny trunk. The bags also weighed much less than when we initially handed them off at customs, but stopping to check the bags’ contents in the street could have meant losing even more equipment to petty theft.
We planned to be in Nicaragua for two and a half months. We allowed for failure in our mind, knowing well that we could only plan for the few things that we could control, and left extra mental space and time for the natural uncertainty of bureaucratic processes, as well as all the unforeseen mistakes that our team would surely make along the way.
Basically, we planned for what we could control, and assumed that good luck and hard work would take care of randomness. First, we would forget nothing back in Berkeley. Then, our technology would spend exactly two weeks at customs, and Nicaragua’s National Engineering University (UNI) would help us release it without paying taxes. Because we had tested our hardware and software ad nauseam in Berkeley, our deployment would be a simple "plug and play," and we would "figure out" communications for a demand response implementation "in country."
Customs was a nightmare that required 15 full days of absolute patience, cultural navigation, and polite pestering
Again, our objective was to deploy a wireless sensor network in thirty micro-enterprises and households. We call these "sensors nodes" a FlexBox. In the end, we implemented 29 (out of 30) partially working FlexBoxes in Managua, and kept one for future testing in Berkeley.Customs was a nightmare that required 15 full days of absolute patience, cultural navigation, and polite pestering (and thousands of dollars paid in taxes). Our hardware passed most tests, but some sensors failed in the field after being exposed to being thrown around, drowning in freezing water, and sharp metal doors searing connections away. We got carried away in what we thought would be useful (but not necessary) software developments instead of focusing on a bulletproof version of our minimum viable product (MVP), and were not even close to "figuring out" a cost-effective communications protocol in Managua.
However, despite our "natural" missteps (things that can go wrong, will go wrong), we have begun developing a unique regional dataset which will allow us to correlate micro-level demand and behavior, to grid level measurements such as system frequency, generation from fossil and renewable resources, and weather data.
Our project also considers increasingly important equity implications of smart grid deployments: How are data exchanges mutually beneficial? How can urbanites be more engaged in a low carbon transitions? How can renewable energy based grids provide higher quality service and useful information to their clients?
To our knowledge, our project is the first of its kind in the region and will greatly contribute to shedding light on how existing grid infrastructure can be used to further increase the equitable penetration of uncertain and variable renewable energy.
SURVIVING IMPLEMENTATION
Throughout this process, our team learned a lot about what it takes to go from plans to implementation. Below are ten takeaways for future implementation that other researchers introducing new technology into foreign countries may find useful as well.
1. Customs
Depending on where you are traveling and what technology you’re deploying, your experience will vary drastically. If you are in a country where rules, guidelines and regulations are carefully detailed and followed your job is easy – read the rules and play by the book and most likely you won’t have a problem. However, if you are in country where everything is routinely improvised, you’ll most likely be at the mercy of a local customs agent at the beginning of your first "in country" adventure.
Make sure a handy person in your team is fluent in the local language and culture, you have "extra" money in case you need to hire a customs agency, and that your patience "hat" and best manners are at their best all the time. Two to three weeks is normal operating procedure, if you do everything right. If you make mistakes, don’t have the right permits or forms, or are being regularly scammed because you don’t understand the language well enough, this process could take months.
 |
| Our technology traveled from San Francisco... |
 |
| ... to El Salvador... |
 |
| ... to the customs of Manauga... |
 |
| ... and finally to 29 homes |
2. Parts
Bring an extra set of cheap "parts" that you may not be able to find in country. Doing your due diligence is very important. Make a list of the things you can find in country and a list of things you can’t find in country. Bringing extra things that you can’t find in country will cause problems at customs, so make sure you have lists of parts. Bring an extra two or three "final products" (whatever those may be). Regardless of how good you think your product is, you’ll have to keep iterating in the field – having a working final product as a test bed while you deploy is very important.
3. Money
If you are working on a tight budget, you’ll have to be very creative about how you spend your money. Besides your technology, and if you have a team, you will all have to stay in the same place (and that place must have a good working space). You’ll also need a car, money for food, extra parts, and many other things that will show up as you begin your project. You’ll also need to hire a local team, both for the deployment as well as for your project’s follow up.
Although "strong collaboration" with institutions is important, and "community ownership" and "partnerships" are essential (these buzzwords are all the rage in development circles), nothing gets people working – at the pace that you want them to work like money. Be wise in how you spend your money, and prepare a detailed budget months ahead of time.
4. Contacts
You’ll soon find out that your Berkeley education and prior experiences mean very little once your project "breaks ground"
Things will inevitably go wrong. Make sure that you have friends and connections in the right places. Our team had signed collaboration agreements with the National Engineering University, the Ministry of Energy and Mines, and a local renewable energy startup. None of these signed agreements meant much until we needed to show that we knew people in high places, and that they were keeping a close eye on our project. Keep those signed agreements handy, you never know when you might need them.5. Local Team
Nothing – NOTHING - happens without a local team. You might think your clever engineering skills have taken you far in life, or that your Peace Corps experience has turned you into a community relations expert, but you’ll soon find out that your Berkeley education and prior experiences mean very little once your project "breaks ground."
We hired a community liaison (Odaly), an electrician (Roberto), and an electronics engineer (Jorli) to work with us throughout the implementation and to stay with us through follow up. While we handled the implementation logistics and directed everything, they were heavily involved in troubleshooting, surveying, and follow up. They have all learned a wide variety of skills along the way, such as fixing broken sensors, accessing PostGRES databases, and setting up a local WiFi network.
Once you leave, you need to make sure that there is a team of people that will be able to solve problems as they arise. Without a good local team, your project will last only about two to three weeks post-implementation.
6. Build/Deploy Team
A small team needs to be composed of people with interchangeable skills that complement each other well. (Three people sounds about right). One person can be responsible for a lot but not for everything. If your project is technical, then everyone in your team must be able to help, or everyone must be willing to learn (fast). There will be plenty of times for PANIC to sneak in.
If you’re leading, you can never panic. If you’re someone who panics, control yourself. When things get hot, you’re stressed, or you’re panicking, control yourself. Drink water. Take a break. Be respectful. Try not to complain (too much). Nothing sucks more than having to deal with a difficult situation, and with someone who is complaining about it.
 |
| Javier and Stephen did A LOT of hacking to get an excellent MVP |
7. Respect your MVP
You arrived to your site with a minimum viable product (MVP). You have something that works. Your goal should be to make that product work on site with as little change as possible. Don’t add components (hardware or software) to your MVP "in country." You need time to test new additions, and more time to make them work like you want them to. Additional things can be done once your MVP is fully functional on the field. Until that point, eschew any ideas to make the product better, faster, or easier to use. Any improvements should have happened during the testing phase and can happen when you’re done with your deployment. If you have a short deployment time, respect your MVP.
8. Time
You should leave, at minimum, three weeks of follow up after you have finished your deployment. Things will fail and break, and you need time to fix them. You also need time to train your local team on troubleshooting. Leaving a country right after deployment is symptomatic of the "parachute" approach that most "development engineers" work with (drop in, have your adventure, drop some technology, fly off to another adventure). After your deployment, do your due diligence and stay in country to finish the training with your local team, make and solve problems, troubleshoot, and prepare your project for the next few months before the next iteration.
9. Release
Deployments are high-stress situations. Make sure that you’re doing something fun the entire time. Bond. Keep things fun. Remember that no one is forcing you to do this, so make sure that you’re enjoying life while doing it. If not, what’s the point?
10. Humility, Respect
Respect the people you’re working with. Respect your local team. Respect each other. Be humble about what you can accomplish. Accept and apologize when you make mistakes. Accept others' apologies. Don’t dwell. Ignore the little things that don’t matter, but REALLY pay attention to detail. Appreciate your team, you’re part of it. You are all learning from each other.
 |
 |
| Our project looks to use thermostatically controlled loads at the micro-level to develop cost-effective strategies for renewable energy integration. |
Note: The views expressed here belong solely to the author of each entry and are not representative of the position of the Energy and Resources Group, UC Berkeley.
.jpg)
No comments:
Post a Comment